New ECPP record (currently: 59,798 digits)

[frmky]

Originally Posted by Batalov

If that process gets killed - you have to start from scratch because no data in the state file (.cert2) are written that are not in sequence from #0 to #tests. Maybe this can be refactored (thinking about it)?

That's no longer true in the current development version. That was a patch I sent to Andreas before embarking on these large runs.
https://gitlab.inria.fr/enge/cm/
https://gitlab.inria.fr/enge/cm/-/co...2b479edd45cd16

[Batalov]

Originally Posted by frmky

That's no longer true in the current development version.

Good!

[paulunderwood]

Originally Posted by Batalov

Good!

What would be "good" too is saving the class number calculations, even if it is gigabytes, because that can take several hundred core hours every time one starts stage 1. It would not take as long to read them into memory again on resumption.

[frmky]

Originally Posted by paulunderwood

What would be "good" too is saving the class number calculations, even if it is gigabytes, because that can take several hundred core hours every time one starts stage 1. It would not take as long to read them into memory again on resumption.

Also done.
https://gitlab.inria.fr/enge/cm/-/co...56d9c57e5e8454

Edit: For the run I just completed, the class numbers file is 32GB, and the primorials (also optionally saved and loaded) are 11GB.

[Batalov]

Gigabytes are pennies these days. Our disks are necessarily over a petabyte (at a genome sequencing center).
Saving a temp image of a few gigabytes is certainly fine. Could draw a limit at, say, a terabyte or two.

Surely, the good idea is to start the ecpp.ini file with some limit settings. Everyone could set for themselves.

[xilman]

Originally Posted by frmky

125330^3+3^125330, at 59,798 digits, is prime.

Nice.

[xilman]

Originally Posted by Batalov

Gigabytes are pennies these days. Our disks are necessarily over a petabyte (at a genome sequencing center).
Saving a temp image of a few gigabytes is certainly fine. Could draw a limit at, say, a terabyte or two.

Surely, the good idea is to start the ecpp.ini file with some limit settings. Everyone could set for themselves.

Indeed.

Here is a GNFS Cado run, only half-way completed and using only two machines sieving. Chicken feed, IOW.


pcl@horus:~/nums/cado-nfs/work$ du -h
11M ./client/horus.work
11M ./client/horus+4.work
40M ./client/download
11M ./client/horus+5.work
9.7M ./client/horus+3.work
11M ./client/horus+2.work
11M ./client/horus+6.work
101M ./client
14G ./GW3_619.upload
4.7G ./GW3_619.dup1/0
4.7G ./GW3_619.dup1/1
9.3G ./GW3_619.dup1
26G .
pcl@horus:~/nums/cado-nfs/work$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 917G 235G 636G 27% /home
pcl@horus:~/nums/cado-nfs/work$


Essentially all of that is temporary files in that the relations are superfluous after the square root computation has finished.

[paulunderwood]

Originally Posted by frmky

Also done.
https://gitlab.inria.fr/enge/cm/-/co...56d9c57e5e8454

Edit: For the run I just completed, the class numbers file is 32GB, and the primorials (also optionally saved and loaded) are 11GB.

I found from the news file that you have to setup a directory and flag it to CM. Here is what I did in my ecpp directory

mkdir R_class
export CM_ECPP_TMPDIR="R_class"

(The estimation for the whole process to complete for R86453 is 1300 core hours. Reading back on resumption will take minutes.)

[rudy235]

The seven largest primes in the category ECPP have been discovered in the last 10 months (Mar-Dec 2022)