Anything I can do to get it to run on linux? I have more/better linux assets than windows.

We are working on a wine version for linux.

Announcing: Srbsieve_mthd version 2.1.

The biggest updates are changes to how the k's are handed out to workers, more flexible data entry, and headings on the main menu pages.

Enhancements:

1. Will send 5% more k's to worker 1, 2% more k's to worker 2, with the remainder of the k's divided equally among the remaining workers when mink < 100,000. The k's remaining must be > 5X workers. If mink >= 100,000 or k's remaining <= 5X workers, the # of k's will be divided equally among all workers. The problem with workers 1 & 2 often finishing long before the others mostly only exists for workers with very small k's. This should equalize work better.

2. In the final srbsieve.log in the Step 1 and Output folders, it will print a completion date/time for each phase that is the latest time that a worker completed the phase in a manner that is similar to the fbncsieve steps. This gives a better of idea of how long each phase took for the slowest worker allowing for better future job time estimates.

3. Added more flexible data entry on the screens. If you've chosen an option and not yet entered something, just hit cancel or Ctrl-C and it will return to the menu.

*******

Changes to defaults and values allowed:

1. Changed default maxKsrsieve2 to 200000, phases to [100, 250, 500, 1000], and workers to 4.

2. Changed the minimum workers allowed from 1 to 2. If only one worker is desired, srbsieve.exe should be run standalone.

3. Check if maxk > mink before beginning process. Previously this was not checked and it attempted to execute srbsieve.exe causing a program failure.

4. Check that phases are all >= 10 and differ by 2 from one another. Previously it only looked for unique positive integers. The smallest phase cannot be <= the maximum n for fbncsieve and srsieve2 cannot handle n-values closer together when sieving.

*******

Cosmetics:

1. Added a menu title at the top of each screen.

2. On the first two menu options (Switch to XXXXX) of all 3 menus, removed the default suffix labels of (new) or (resume) or (extend). These were not applicable for what the menu options are for.

3. Changed the help menu option from '?' to 'h' for ease of use.

4. Added the program and version number at the bottom of each of the 3 help menus.

5. On the help screens at the end of some descriptions, removed the incorrect suffix of "NONE".

*******

Error checking fixes: The program previously failed in the following situations. They are now handled as noted.

1. If the Update Programs option is chosen on the Resume or Extend menus and the Step 1 folder is missing, an error message is displayed.

2. If option 0 is chosen on the Resume screen, run_config.json exists, and pl_remain.txt in the Step 1 folder (or the folder itself) is missing, an error message is displayed.

3. If Ctrl-C is hit anytime while running step 1 including the fbncsieve steps, an error message is displayed.

4. If Ctrl-C is hit on any of the menus where it is asking for an Option, it will cleanly exit the program.

5. If Ctrl-C is hit after a menu option is chosen, it will return to the menu.

srbsieve_mthd version 2.1.1. There are 3 changes that impact very few situations...

1. Write a concatenation of any pl_unknown files from the Worker folders as a single file to the Output folder. This was requested by Reb and was needed to better isolate problems with PRP's that could not be definitely proven as prime or composite. Both pl_missing and pl_unknown files will now be in the Output folder if the problem happens.

2. Allow the script to run with 1 Worker. With version 2.1, I had changed this to a minimum of 2 but decided to revert it back to 1 for two reasons:
(a) Oftentimes during testing, running only 1 Worker is easier.
(b) When populating the New Bases screen with an initial run_config.json file, this value was not checked so it was possible to override the minimum and choose 1.

3. Because of the possibility of overriding the minimum of 2 Workers from #2 (an override that I had not been aware of), there was a bug from version 2.1 only when 1 Worker was chosen from the .json file. This came about as a result of the changes to better distribute the k's across the workers that caused it to not send all k's to Worker 1 it there was only 1 Worker. That has now been fixed.

#1 is a rare situation that seems to have come up when k's are very large (k=~1e9) on bigger bases. As of yet, it hasn't seemed to have impacted the huge k's on base 7.

#3 previously only came up if you chose 1 worker from the .json file (now can be chosen from the New Bases screen). Hopefully people would normally not be running with 1 worker (except during testing) when running a multi-thread script. srbsieve.exe can be run standalone for one thread.

new bugfixes...

I have posted srbsieve version 1.9.1 and srbverify version 1.8.4 in the first post of this thread. Please download them at your convenience.

These updates fix a problem when the k-range is > 2^32 (4,294,967,296). This does not impact large k-values, only large k-ranges. When one or more of the categories of k's remaining is > 2^32, they were not displayed properly in srbsieve.log when running srbsieve or in the output from srbverify. The values would be off by 2^32.

The fix expanded some variables and print displays from 32-bits to 64-bits. A recent example is the k=10G range for Riesel base 7 k=21G-31G. In both the srbsieve.log file and the srbverify output, it showed the "Odd k and base" category with 705,032,704 k's removed. It should have been 5 billion (half of the k-range), a difference of 2^32. Also in srbsieve.log, the k's remaining at the end of the preliminary steps also printed incorrectly.

Fortunately this is only a display/print problem. Recently run k-ranges of 10G and 20G do not have their important files impacted. Only the displayed/printed counts are/were wrong.

If you are running the multi-thread script but not currently running a job, you should replace the srbsieve.exe and srbverify.exe files in your Base and Step 1 folders, if applicable.

If you are in the middle of running a job either with or without the multi-thread script, the following would apply:
1. If your k-range is < than the above, wait until your job is done before updating anything.
2. If your k-range is > than the above, replace srbverify.exe in your Base and Step 1 folders (or where applicable if not running the script) right away. Wait until your job is done to update srbsieve.exe. Your srbsieve.log file will be incorrect but that will be expected. Srbverify should run correctly at the end.

Notice: Trying to get property of non-object in /home/boincadm/projects/sr5/html/user/forum_thread.php on line 56
Unable to handle request
Bad thread ID

Looks like link to reservation page is broken?

srbsieve_mthd v2.2. This is an important release that corrects a serious data validation problem but also has a couple of useful enhancements.

Enhancements:

1. When processing is complete, displays the total run time on the screen and writes it to the srbsieve.log file. If extending, only the time for the extend operation is used. If resuming, total time from the original start date/time is used.

2. Waits to create Worker folders until the beginning of Step 2 instead of immediately in Step 1. This allows it to reduce the number of workers if there are fewer k's remaining than workers at the beginning of the phases. No worker folders are written if no k's remain. The .json file is also updated for a potential future resume or extend. Previously this resulted in unneeded folders if few k's remained or if the user chose to abandon the search before completing the initial steps.

3. Changes per recent updates to srbverify.exe (the changes have no effect if srbverify.exe is not updated):
(a) Remove applicable counter lines from srbverify_res.txt on large k-ranges.
(b) Copies the phases from Worker 1 to Step 1 srbsieve.ini prior to running srbverify. This is now needed for srbverify to verify that primes are within the applicable n-range.

Bug fixes:

1. Validate all fields in the run_config.json file. In a release prior to version 2.0, changes allowed this file to be used as input instead of the New Base Menu when starting a new base. The file can be manually edited by the user but previously the fields were not validated. Invalid values would crash the program or produce unexpected results.

2. If Ctrl-C is hit during the Step 3 srbverify process, it cleanly exits. Previously the program crashed. This was needed because srbverify can run for an extended period on large k-ranges so the user may wish to stop it and resume from Step 3 at a later time.

3. Cleanly exits and creates an Output folder if zero k's are remaining after initial steps. Previously the program crashed.

4. Correctly deletes all old Worker folders when the current number of threads is fewer than the previous number of threads. Previously the program only deleted Worker folders applicable to the current run leaving folders for higher Workers remaining, which was misleading.

5. If a resume or extend results in zero k's remaining, removes the pl_remain file from the Output folder. Previously the file incorrectly remained because it was still there from the original run.

#1 in the bug fixes is the crucial change that prompted this release. Previously anything could be entered in the .json file with no verification. #3 in the bug fixes was pointed out to me by Reb, which then led me to enhancement #2 when few (or zero) k's are remaining. #1 in the enhancements was requested by Reb after some requests by the SRBase folks.

srbverify v1.9 There are no changes to srbsieve. Because of that. The main change is that it will show a status on large categories as follows:

1. For categories with more than 10 million k's in them, in its verification phase, it will display a counter that shows where they are at. For the verification, there will be no percentage completion as the program does not know ahead of time how many lines are in the file and the time taken is much less than later on. At this time, it counts the lines on the pl_prime and pl_remain files. After the verification comes the sorting and writing of the files that take the most time. You will still see the same counters as before but you will also see a percentage completion for the prime and remain files, which take the most time.

2. It will now check primes against the final phase in srbsieve.ini. If a prime n-value is > than the largest phase, it will display an error and stop.

If you are running a range that has no categories with >= 10 million k's, you will see no difference from the change in #1.

If you are running the multi-threaded script and wish to use this new version of srbverify, you must run with the newest srbsieve_mthd.py script that will be posted shortly. If you are currently running a job and and want to use the new srbverify, do the following:

1. Go to the main screen and Ctrl-C to stop all workers.
2. Replace srbverify in your Base (or Programs or Files) folder with the new version.
3. Replace srbsieve_mthd.py with the new version (to be posted shortly).
4. Use the Resume screen to resume your job.

The above process was tested in several scenarios with no problems.

On an AMD 7750X running a k=10G range of R7, srbverify ran for about an hour and it allocated a max of 21 GB of memory for ~15 mins. All of the counters and percentages were displayed as expected.

To set expectations and as FYI for people running srbverify on large k-ranges in the future:

Srbverify allocates ~2.1 bytes of memory for each k in the k-range regardless of the actual size of the files since it has to verify that every k is present. 2 bytes are needed to store the n-values of the primes. If you are running a k=10G range, it will allocate ~21 GB of memory for about 1/4th of its entire process. The memory is only allocated during the primes sorting and writing process and it is released after that.

I would like to try, but this is confusing. The sticky reservation thread is unavailable.

srbverify v1.9.1. This is a non-functional change in Windows and there are no changes to srbsieve so I will also attach it here. Changes to srbverify:

There are no functional changes when running in Windows. Changes were needed for it to run correctly in Linux under Wine. The change turned out to be an improvement, no matter how it is run: Instead of backing up one character at a time in a loop to the beginning of a line when displaying a counter, one command sets it back to the beginning of the line.

For those familiar with C++, it's a single \r command vs. a loop on the \b command when displaying a counter that is updated many times

Can we safely continue with PFGW 4.1.3. while we wait for an update?
I saw your message on mersenneforum to rogue (?) mentioning an update on the Gwnum library or is there still an issue?

Just curious :)

Good to hear! Thanks.

srbsieve_mthd.py v2.3. It corrects a number of problems when doing extend operations on partial k-ranges when using a pl_remain file for the entire base. Most of these came about with changes in versions 2.0 and 2.1 that more equitably divided k's across workers.

Bugs corrected that apply to extend operations only:
1. If pl_remain.txt and srbsieve.ini exist in the Step 1 folder but there are zero k's remaining between mink and maxk in srbsieve.ini, it displays a warning message. Previously the program would crash.
2. If the k-range in srbsieve.ini only includes a subset of pl_remain, it now correctly chooses the subset that is within the range to pass to the workers. Previously it would pass all k's to the workers.

Misc. bugs corrected:
1. If the Output folder exists from a previous run and pl_prime.txt exists in the folder, if no primes are found for the current run, the file is deleted. Previously the file remained, which was inconsistent and could cause confusion.
2. When 9 workers is chosen, it now correctly writes folder names without an extra zero. Previously it wrote folder names "Folder 01, Folder 02, etc. for 9 workers. The same thing would happen with 99 or 999 workers.
3. Write the total time on the screen and in srbsieve.ini when there are zero k's remaining before the beginning of phase 1. This was previously missing.

Cosmetics for extend operations only:
1. It will display the k-range on the screen that is being processed.
2. It will display a message on the screen if pl_prime.txt exists in the Step 1 folder, which indicates that it will run srbverify at the end.
3. It will print the k-range and the beginning # of k's remaining in the srbsieve.log file.
4. If Step 1 srbsieve.log did not previously exist, it will no longer print a blank line at the top of the file.

The first post of this thread has also been updated.

Important general note:
The program will also run correctly without the "*b^n+1" or "*b^n-1" suffix in the pl_remain file. This may be useful depending on where you are getting your k's remaining file from. The base and k-range must be correct in srbsieve.ini in the Step 1 folder.

pfgw4.1.7 is now content of the pythonscript package.