[QUOTE=Prime95;469073]Note: You cannot do PRP-DC without version 29.4. Two PRP results from version 29.3 will look identical and the second one rejected as a duplicate. Version 29.4 implements shift counts, so that prime95 can do both the PRP and PRP-DC.[/QUOTE]

In some cases, it is actually reporting a successful double check, although obviously it will have to be redone if both shift counts are zero. For example:

processing: PRP=(false) for M[M]1675801[/M]/2932651751/2467992190252774327/26305191321180053684999
PRP test successfully completes double-check of M1675801 -- CPU credit is 0.0909 GHz-days.

Note one small potential problem though, in the history section for that exponent, the order of the factors for the two results is different:

[CODE]
2017-10-03 kkmrkkblmbrbk PRP M1675801/2932651751/2467992190252774327/26305191321180053684999 is not prime. Res64: 1FDDCD18A87084__
2017-09-30 alpertron PRP M1675801/2467992190252774327/26305191321180053684999/2932651751 is not prime. Res64: 1FDDCD18A87084__
[/CODE]

When real double-checking with shift counts is implemented, I hope the program will recognize two factor strings as the same even if the factors are in a different order.

Actually I am more worried about the message indicating that the mail server failed.

We already had two Mersenne primes, I think, whose discovery was delayed by months because no e-mail was sent. And it looks like maybe that's a problem again with the new server?

Aaron, can you check the mail server. I turned off and restarted the SMTP service when James spammed himself. Maybe more needs to be done.

[QUOTE=Prime95;469079]Aaron, can you check the mail server. I turned off and restarted the SMTP service when James spammed himself. Maybe more needs to be done.[/QUOTE]

Oh yeah, how about that. It was still stopped.

No new primes came in while the email notifications were disabled... drat. :smile:

[QUOTE=GP2;469077]In some cases, it is actually reporting a successful double check, although obviously it will have to be redone if both shift counts are zero. For example:

processing: PRP=(false) for M[M]1675801[/M]/2932651751/2467992190252774327/26305191321180053684999
PRP test successfully completes double-check of M1675801 -- CPU credit is 0.0909 GHz-days.
[/QUOTE]

Odd. There were 2 incorrect entries in the app_versions table. I fixed the problem so it shouldn't happen in the future, but I did not go back and mark DC'ed PRPs as not DC'ed.

Can we add PRP work-type to manual assignment selection:
[url]https://www.mersenne.org/manual_assignment/[/url]

[QUOTE=preda;469113]Can we add PRP work-type to manual assignment selection:
[url]https://www.mersenne.org/manual_assignment/[/url][/QUOTE]

I like to experiment and break things. I found something that might be a problem.

The explanation is a bit long, so bear with me.

First of all, I think there are two different kinds of PRP testing, no? One is the PRP-cofactor testing for trying to find fully-factored Mersenne exponents, which has been a capability of mprime for a long time, although mersenne.org did not accept these results until very recently so they had to be manually reported to mersenne.ca instead. The other is the Gerbicz PRP testing, a new way to look for Mersenne primes, currently implemented in gpuOwL, and to be implemented in the upcoming mprime v 29.4

However, when we look at the [URL="https://mersenne.org/worktypes/"]Work Types page[/URL], which is linked from the [URL="https://mersenne.org/assignments/"]Active Assignments page[/URL] column heading, then it shows only work types "PRP" = "PRP test" and "PRP-D" = "PRP double-check", with no additional types for PRP-cofactor testing and PRP-cofactor-doublecheck testing.

Anyway, here's what I did...

In an mprime work directory, I edited the prime.txt file to set WorkPreference=150

I had some reason to think that this would produce assignments of the PRP-cofactor work type. That's because when I reported some PRP-cofactor residues to Primenet for exponents that I was already doing ECM tests on, there was a warning message about returning a different work type than expected, and that message mentioned work types 150 and 5. The numerical value WorkPreference=5 is already known to be for ECM testing (and 0 = "Whatever makes most sense", 2=TF, 100=First time LL tests, 101=Double checking LL tests, etc...)

So I figured that was a strong indication that 150 is the numerical code for the PRP-cofactor work type.


With WorkPreference=150 in prime.txt, I ran mprime, and the worktodo.txt file got some PRP assignments lines from Primenet.

It returned lines that looked like this:

[CODE]
PRP=<<a hex digit string of length 32>>,1,2,[M]82202839[/M],-1
[/CODE]

This looks exactly like the type of worktodo.txt lines generated by mersenne.ca for PRP-cofactor testing, with the same prefix of "PRP=", except it has an actual assignment ID string instead of "N/A". However the exponent is in the 82M range, rather than the single-digit-millions that would be normal for PRP-cofactor testing. And obviously there is no factor string at the end, because there are no known factors for this exponent.

So it looks like the Primenet server actually assigned me a Gerbicz-PRP test instead of a PRP-cofactor test...

The weird thing is that [B]mprime version 29.3 actually started crunching[/B] on this!

There are savefiles, and Primenet says it's 1.90% complete.

The magic number at the start of the p82202839 savefile is 0x87f2a91b, which is the same as for the PRP-cofactor savefiles.

I halted it, of course. But what work was v 29.3 performing on this exponent? I thought Gerbicz PRP testing will only be available in v 29.4

Is Primenet confusing the two different kinds of PRP testing, or am I the one who's confused?


PS,
to answer preda's question, I don't know about manual assignment of Gerbicz PRP work type, but this seems to be a weird way to get automated Gerbicz PRP assignments from the server. Just run mprime to generate the worktodo lines, then halt it, and use gpuOwL on those exponents.

Work preference of 160 is PRP-cofactor, work-preference 161 is PRP-cofactor-DC

A Gerbicz-PRP is just an ordinary PRP with better error checking. Thus, v29.3 (and earlier) can produce an acceptable PRP result for a first-time Mersenne number test -- though there is no good reason to do so.

What's up (or down) with the Manual Results page? Firefox shows a blank page. IE 11 returns 500, Internal Server error.

Please try again

[QUOTE=James Heinrich;469168]Please try again[/QUOTE]
Success! Thanks.