[QUOTE=Pascal Ochem;549766]Yes, it is good to see this one down. Thank you very much, Ryan!
No auto-update, I removed the line from the MWRB file.
The weight of the remaining composites will be updated in a month or so.
732541 is (29^5-1)/28, so (732541^47-1)/732540 was also a composite of interest for lower bounds on the total number of prime factors.[/QUOTE]

It is presumably worth waiting for the obvious continuations to be attacked a bit before rerunning the tree. Any before and after statistics on tree size etc would be appreciated.

In case anyone is interested, here's the full msieve log for 732541^47-1.

[PASTEBIN]PjYMLaPT[/PASTEBIN]

The new list of roadblock composites is here
[url]http://www.lirmm.fr/~ochem/opn/mwrb2100.txt[/url]
and the old one is here
[url]http://www.lirmm.fr/~ochem/opn/old_mwrb2100.txt[/url]
Most of the changes are due to the recent factorizations of sigma(3^660) and sigma(732541^46).
Notably, the weight of sigma(6115909044841454629^16) drops from 79580833 to 67959517 and
the weight of sigma(127^192) drops from 29196565 to 14190689.

Are the files available that contain all the factors used in the proof?
How do you check that all the composites hit have been trial factored to at least the assumed level given that pfn doesn't output a file containing the composites hit(I suppose you could extract them from the log)?
Does it even matter if there are unfound small factors in non-roadblock composites apart from them causing gcd errors?

My policy is to increase the lower bound by a factor 10^100 when the run takes less than one week.
A couple of years ago, it took 3 weeks to prove 10^2100.
The goal of the run of july 2020 was to get the timing (it took 12 days) and to update the list of roadblocks.
Some composites would have been needed in order to circumvent sigma(3^660) or sigma(732541^46) but are not needed elsewhere.
They are not needed anymore and do not appear in the updated mwrb2100.txt

Since the program was not aiming at a new lower bound, it was run with trial factoring up to 300 only,
in order to catch the tiny factors that may cause the abundancy to exceed 2 (a higher trial limit or some ECM would slow things down).
This produces a load of uninteresting factors.
Trial factoring up to 10^10 is indeed required for roadblock composites. This is checked a posteriori.

The list of useful factors has been updated:
[url]http://www.lirmm.fr/~ochem/opn/checkfacts.txt.gz[/url]
[QUOTE]Does it even matter if there are unfound small factors in non-roadblock composites apart from them causing gcd errors?
[/QUOTE]

No. The program encountered over 18 million composites, attacking them all with ECM would be a big effort for low benefit.
Most probably, the cofactor will be composite.
In this case, a given factor [$]P[/$] with [$]d[/$] digits counts for [$]d[/$] digits if [$]P[/$] is in the unfactored part
and counts for [$]2d[/$] digits if [$]P[/$] is in the factored part, because we can usually assume that [$]P^2 [/$] divides the OPN.
So finding [$]P[/$] contributes only [$]d[/$] digits to the 2100 digits, in only one or few branches of the proof tree.

The composites worth considering are in mwrb2100.txt and t2100.txt

All of the remaining entries in the MWRB file have SNFS difficulty above 210.


That is about the upper limit of my resources and NFSNET has reserved the next one, so this is a good point to stop working on this file.

Update on the OPN road blocks. The following are the number of composites remaining in the respective file along with the number queued for the grid.

[CODE]File Entries Queued
==== ======= ======
t550 18 4
t600 137 6
t800 2475 10[/CODE]
The MWRB file has been taken down. I’m guessing Pascal is currently running a new update with more accurate weights for each number. I have a copy locally which I am working from.

I have a few numbers (mostly from t550 & t600) that are ready for SNFS but they will go to the larger sieve queues. I will wait for those queues to work through some of their numbers.

[QUOTE=RichD;560739]The MWRB file has been taken down. I’m guessing Pascal is currently running a new update with more accurate weights for each number. [/QUOTE]Can anyone refresh my memory about the amount of effort put into the MWRB numbers? When it gets put back up I thought I might have a go at running some ECM, but I wouldn't know what size factors to search for.

[QUOTE=lavalamp;560864]Can anyone refresh my memory about the amount of effort put into the MWRB numbers? When it gets put back up I thought I might have a go at running some ECM, but I wouldn't know what size factors to search for.[/QUOTE]

Pascal doesn't keep track of ECM work and I have been starting at t50. Some of the newer numbers (added in the latest update) have shown a few factors in the p40s. Other numbers have much more work done. By contrast, the smallest job is an SNFS-213. It is a p^19-1 with a large coefficient so the equivalent difficulty would be closer to SNFS-230 because of poor sieving.

I usually follow a couple dozen numbers at a time while I feed yoyo and NFS@Home. I don't touch any numbers beyond what NFS@Home can do on the 15e queue, say < SNFS-280.

[QUOTE=lavalamp;560864]Can anyone refresh my memory about the amount of effort put into the MWRB numbers? When it gets put back up I thought I might have a go at running some ECM, but I wouldn't know what size factors to search for.[/QUOTE]

I'm doing some ECM now on the top 500 of the current mwrb2100. Have already found 2 factors, of (4889^101-1)/4888 and (10627^71-1)/10626.

I've reported these to FactorDB; does Pascal's script/process periodically query the latest state from FactorDB?

[QUOTE=ryanp;561213]I've reported these to FactorDB; does Pascal's script/process periodically query the latest state from FactorDB?[/QUOTE]

He has some ability to scrape the data base. Here is a comment he made from a different thread.
[url]https://www.mersenneforum.org/showpost.php?p=518106&postcount=464[/url]