Let's see if I learned anything or if I'm way off track...

If i try to figure out how much ecm to do on the c144, (0.31*144=~45). This means I should go for a t45 threshold.

All the little B1 values equate to very tiny percentages, so if I start at:
2390@3e6
3860@11e6
2000@43e6

I get just over 220% of t45, or just about 1/3 of t50.

Have I gotten any of this correct?

Running ecm-toy.py with the 2000@43e6, I am told to run 300 curves at 110e6.

I currently am passing 830@110e6, which, if I have things correct, adds 23% to the t50 value, taking it over 50% of t50.

Does this signal that enough ECM has been done?

Am I correct at all in my calculations?

If the above is correct, should I move into the gnfs work, or would someone else like to run this one?

I think your calcs are fine, and half a t50 is about 3*t45, so you're about triple the usual amount of ECM for a number this size. Head to GNFS!

Take it yourself, IMO; you've surely done enough work on the sequence recently to have the honor (?) of advancing it a couple more steps.

Thanks!

I'll have one of my machines run a poly overnight while the rest keep running curves.

I'll look to see if anyone else chimes in by tomorrow morning and run with it, if not.

After something like a t35 is done I would then ask the script what it things. Maybe more of the curves should have been at 110e6 for this number.

Ed, please let me know if you need support from myself for the next LA. Currently I am on a job which will finish in 43 hours and already queued up the next job but between these two I can squeeze a LA to help you out. PM me if you are interested. Take care.

[QUOTE=henryzz;444943]After something like a t35 is done I would then ask the script what it things. Maybe more of the curves should have been at 110e6 for this number.[/QUOTE]My scripts from long ago have a fixed pattern, but I don't know where I got that pattern. I suppose to be most efficient I should make a specific pattern for each job. I have the easy capability to set the curves and values in the main script. I just don't know how to make up the table. Would entering a low value into the ecm-toy script tell me the best amounts for each in any rough manner? I don't have the true data for the ecm-toy gnfs table, but would that matter very much at the digit levels I can run?

[QUOTE=pinhodecarlos;444946]Ed, please let me know if you need support from myself for the next LA. Currently I am on a job which will finish in 43 hours and already queued up the next job but between these two I can squeeze a LA to help you out. PM me if you are interested. Take care.[/QUOTE]Thanks Carlos, I can do this one, if everyone is patient enough to wait for my ancient hardware.:smile:-Ed

Overnight my machines finished 2000@110e6. They were supposed to start 2000@430e6, but my script had a bug that prevented the 430e6 runs from being assigned. My calculations come up to 90% of a t50 now. I have a poly and will be swapping everything over to gnfs. How is sieving range normally determined? Is it by testing or is there a calculated start point? I was guessing for the others but my guess here would be, maybe 15e6.

Thanks for all the "learnin'" everyone.

For GNFS jobs, I start sieving at 1/3rd of the factor base bound. The original factmsieve script started at 1/2 the bound, so somewhere in that range is reasonable.

If your tools don't supply a default factor base (factmsieve.py does) it doesn't matter very much (within a factor of two of "best", say) what factor-base bounds you pick; perhaps 30M for the bounds with sieving starting at 12M should work fine. 14e is probly best; if you want to play with a little test-sieving, try using 14e the regular way and also invoking with with "-J 12" in the flag list. The latter may be a bit faster, at the expense of less yield (and thus a larger range of Q to be sieved).

[QUOTE=EdH;444955]My scripts from long ago have a fixed pattern, but I don't know where I got that pattern. I suppose to be most efficient I should make a specific pattern for each job. I have the easy capability to set the curves and values in the main script. I just don't know how to make up the table. Would entering a low value into the ecm-toy script tell me the best amounts for each in any rough manner? I don't have the true data for the ecm-toy gnfs table, but would that matter very much at the digit levels I can run?

Thanks Carlos, I can do this one, if everyone is patient enough to wait for my ancient hardware.:smile:-Ed

Overnight my machines finished 2000@110e6. They were supposed to start 2000@430e6, but my script had a bug that prevented the 430e6 runs from being assigned. My calculations come up to 90% of a t50 now. I have a poly and will be swapping everything over to gnfs. How is sieving range normally determined? Is it by testing or is there a calculated start point? I was guessing for the others but my guess here would be, maybe 15e6.

Thanks for all the "learnin'" everyone.[/QUOTE]

It is difficult without the gnfs data matching the ecm data. It probably isn't too bad as long as you are within a factor of 2 of the best amount of ecm. These things usually have a fairly flat curve. There was the argument a while back whether it was better to tell aliqueit to do ecm to 0.25 digits or 0.33 digits. It didn't make that much difference.
You can run the script telling it you have run 0 curves (0@3e6 or something like that).

[QUOTE=VBCurtis;444961]For GNFS jobs, I start sieving at 1/3rd of the factor base bound. The original factmsieve script started at 1/2 the bound, so somewhere in that range is reasonable.

If your tools don't supply a default factor base (factmsieve.py does) it doesn't matter very much (within a factor of two of "best", say) what factor-base bounds you pick; perhaps 30M for the bounds with sieving starting at 12M should work fine. 14e is probly best; if you want to play with a little test-sieving, try using 14e the regular way and also invoking with with "-J 12" in the flag list. The latter may be a bit faster, at the expense of less yield (and thus a larger range of Q to be sieved).[/QUOTE]
Unfortunately, I don't understand factor base. I am doing everything manually although I have some scripts I wrote to distribute sieving and ECMing among my machines. I have used factmsieve.py in the past and even modified a version to work with my cluster I had running then. I should probably resurrect that script...

I was out all day, so I didn't try the "-j 12" switch this time - maybe next.

[QUOTE=henryzz;444963]...
You can run the script telling it you have run 0 curves (0@3e6 or something like that).[/QUOTE]
Excellent! This works great. I will do this and use the returned values to seed my ECM script from now on.

On the good side, I was able to build a matrix with a little over 36M unique relations and I have LA running on my cluster. I should have the factors in the morning:
[code]
Thu Oct 13 22:32:44 2016 Msieve v. 1.53 (SVN 993)
Thu Oct 13 22:32:44 2016 random seeds: 78202805 bdd4a0ec
Thu Oct 13 22:32:44 2016 MPI process 0 of 3
Thu Oct 13 22:32:44 2016 factoring 131954905347588391934699304738827948133275634558635457624548533060467418907362122329509131668522067078677069743086471484822031174847391546400311 (144 digits)
Thu Oct 13 22:32:46 2016 searching for 15-digit factors
Thu Oct 13 22:32:47 2016 commencing number field sieve (144-digit input)
Thu Oct 13 22:32:47 2016 R0: -10853864674370357346890831166
Thu Oct 13 22:32:47 2016 R1: 2070175205206213
Thu Oct 13 22:32:47 2016 A0: 1567149971784611966940117631701000925
Thu Oct 13 22:32:47 2016 A1: 57830699450094690463301740533
Thu Oct 13 22:32:47 2016 A2: -399896828755837210648218
Thu Oct 13 22:32:47 2016 A3: -58194781578947499
Thu Oct 13 22:32:47 2016 A4: -6125301397
Thu Oct 13 22:32:47 2016 A5: 876
Thu Oct 13 22:32:47 2016 skew 5656895.57, size 6.878e-14, alpha -6.666, combined = 1.347e-11 rroots = 3
Thu Oct 13 22:32:47 2016
Thu Oct 13 22:32:47 2016 commencing linear algebra
Thu Oct 13 22:32:47 2016 initialized process (0,0) of 3 x 1 grid
Thu Oct 13 22:32:48 2016 read 2789376 cycles
Thu Oct 13 22:32:57 2016 cycles contain 8822764 unique relations
Thu Oct 13 22:34:58 2016 read 8822764 relations
Thu Oct 13 22:35:10 2016 using 20 quadratic characters above 4294917295
Thu Oct 13 22:35:51 2016 building initial matrix
Thu Oct 13 22:37:43 2016 memory use: 1208.9 MB
Thu Oct 13 22:37:46 2016 read 2789376 cycles
Thu Oct 13 22:37:46 2016 matrix is 2789288 x 2789376 (849.1 MB) with weight 269812589 (96.73/col)
Thu Oct 13 22:37:46 2016 sparse part has weight 189118354 (67.80/col)
Thu Oct 13 22:38:18 2016 filtering completed in 2 passes
Thu Oct 13 22:38:19 2016 matrix is 2786778 x 2786925 (848.9 MB) with weight 269715636 (96.78/col)
Thu Oct 13 22:38:19 2016 sparse part has weight 189092868 (67.85/col)
Thu Oct 13 22:38:41 2016 matrix starts at (0, 0)
Thu Oct 13 22:38:41 2016 matrix is 929002 x 2786925 (372.8 MB) with weight 144909846 (52.00/col)
Thu Oct 13 22:38:41 2016 sparse part has weight 64287078 (23.07/col)
Thu Oct 13 22:38:41 2016 saving the first 48 matrix rows for later
Thu Oct 13 22:38:42 2016 matrix includes 64 packed rows
Thu Oct 13 22:38:42 2016 matrix is 928954 x 2786925 (346.7 MB) with weight 89762927 (32.21/col)
Thu Oct 13 22:38:42 2016 sparse part has weight 63022146 (22.61/col)
Thu Oct 13 22:38:42 2016 using block size 8192 and superblock size 294912 for processor cache size 3072 kB
Thu Oct 13 22:38:46 2016 commencing Lanczos iteration (2 threads)
Thu Oct 13 22:38:46 2016 memory use: 245.8 MB
Thu Oct 13 22:39:05 2016 linear algebra at 0.1%, ETA 9h 9m
Thu Oct 13 22:39:11 2016 checkpointing every 310000 dimensions
[/code]

Posted:
[code]
Fri Oct 14 08:43:00 2016 commencing square root phase
Fri Oct 14 08:43:00 2016 reading relations for dependency 1
Fri Oct 14 08:43:01 2016 read 1392884 cycles
Fri Oct 14 08:43:03 2016 cycles contain 4409660 unique relations
Fri Oct 14 08:43:50 2016 read 4409660 relations
Fri Oct 14 08:44:15 2016 multiplying 4409660 relations
Fri Oct 14 08:49:34 2016 multiply complete, coefficients have about 199.19 million bits
Fri Oct 14 08:49:35 2016 initial square root is modulo 14071643
Fri Oct 14 08:56:03 2016 sqrtTime: 783
Fri Oct 14 08:56:03 2016 p65 factor: 10034588955103289779660710855255598470263096964861235086632824637
Fri Oct 14 08:56:03 2016 p80 factor: 13150006037913501232049838541645294463485178998835505659359474149104392799427203
Fri Oct 14 08:56:03 2016 elapsed time 00:13:04
[/code]

200 digits! :w00t::shock::cmd: