Why is no sieving occurring on any of the crunching_e projects? Have I made some consistent syntax error in all the polynomial files?

I don't know if this is the problem but I don't see the folders in the "main" directory for those numbers.

Edit: Oh, I see them now by a different name, if that makes a difference.

Edit2: lasieved uses "type:" instead of "lss:" -- maybe?

The server was working its way through the non-"a" workunits for OPN_463442 and C179_139_137 that were created. Deleting those entries in the management interface doesn't actually delete the previously created wus. I just manually deleted them, so the server is now handing out C179_139_137a wus.

Are the C179_139_137 results useful? Did you change the polynomial or just the sieving side?

[QUOTE=frmky;403203]The server was working its way through the non-"a" workunits for OPN_463442 and C179_139_137 that were created. Deleting those entries in the management interface doesn't actually delete the previously created wus. I just manually deleted them, so the server is now handing out C179_139_137a wus.

Are the C179_139_137 results useful? Did you change the polynomial or just the sieving side?[/QUOTE]

I just changed the sieving side, so the R-side ones are fine (but obviously rather lower yield-per-Q). Thanks for sorting this out!

Are the rls.txt / rls4.txt / rls6.txt files in the NFS data directory additional relations or just the result of some processing on C179_139_137.dat.gz ?

The rls* files are gone now. There are almost 47M unique relations in C179_139_137.dat.gz in the C179_139_137a directory from the rational side.

Thanks. Does this mean that, in the future, if I find I've pushed a GNFS job without the lss:0 line, I should ask you to sort it out directly rather than deleting the job and re-pushing with a different polynomial?

If it's in the sieving stage and workunits have already been created, yes.

Neither of my GTX580s is working at the moment; would someone with a working high-end GPU be willing to run polynomial selection for XYYXF C182_147_125 ([url]http://factordb.com/index.php?id=1100000000408940296[/url]) ?

No urgency, it'll be a couple of months before the big GNFS jobs in the 15e queue are done.

(in fact, with an hourly spot rate of $0.2804 for an Amazon g2.8xlarge instance, maybe I should be looking in that direction - that instance has four GPUs each of which is about half a GTX780, so I could get two GTX780-weeks for £32; not quite twice as expensive per cycle as getting 208 GTX980 GPU-weeks at home for £1060, and I get them as fast as I like rather than over four years)

I have a GTX750Ti available. If you can supply me with the files needed to run the selection on 64bit Linux I can start next week.

I already have Msieve v. 1.53 (SVN 984) compiled with CUDA support and working on aliquot sequences.

[QUOTE=fivemack;403483]Neither of my GTX580s is working at the moment; would someone with a working high-end GPU be willing to run polynomial selection for XYYXF C182_147_125 ([url]http://factordb.com/index.php?id=1100000000408940296[/url]) ?

No urgency, it'll be a couple of months before the big GNFS jobs in the 15e queue are done.
[/QUOTE]

Sure, I'll give it a few GPU-days to see what turns up. If nothing else, it'll help Christian know his run is productive when he beats the heck out of mine.

Christian-
I determine parameters for poly search by taking the msieve defaults and dividing stage 2 norm by 20 to 25 (whatever gets me ~100 hits per day saved to the .ms file). Stage1 norm can be reduced also; for big jobs I reduce by a factor of 5 or so, but others are more aggressive. My invocation looks something like:
msieve -np1 -nps "stage1_norm=2e27 stage2_norm=3e21 3000000,4000000" -s day1 (the norms are fabricated, as I am not at the machine with msieve installed)
Once a day or so, I then run the root-optimization: msieve -npr min_evalue={something higher than default to reduce output} -s day1

At the moment I'm using the factmsieve.py script to factor aliquot sequences. I set USE_CUDA=True and I always thought it's working because it never complained. It turns out msieve is not using my GPU for poly select after all.

It seems I need a msieve invocation that worked for someone else that I can try to see why msieve is not using the GPU. Maybe there is an error message that is supressed by factmsieve.py

On the off-chance this is an issue: you need a GPU-capable binary in addition to modifying the script.

It turns out I have a GPU capable binary but factmsieve.py is not using the right parameters to fully utilize the GPU.

I asked on the msieve subboard: [URL="http://www.mersenneforum.org/showpost.php?p=403541&postcount=48"]verify that gpu is used[/URL] - [URL="http://www.mersenneforum.org/showpost.php?p=403543&postcount=49"]answer by fivemack[/URL]

So what I need is the correct parameters to run poly selection for XYYXF C182_147_125

If you don't mind, I will explain to you how to figure out the right parameters, rather than giving you them outright - they depend on the speed of your GPU and on the amount of time you have available.

Start off with
[code]
msieve -v -g -np1 1000000,1001000
[/code]

to get some idea of the yield (length of msieve.dat.m file) and runtime with the default stage-1 bound (I think it is 2.61e27) on your machine.

Then copy msieve.dat.m aside and run with the stage-1 norm halved (ie msieve -v -g -np1 "stage1_norm=1.3e27 1000000,1001000"), and see how the yield and runtime have changed.

Post the two yields and the two runtimes here, and tell me how much GPU time you want to devote to the search, and I'll give you a stage1_norm and a range.

Some local testing (without a GPU) suggests that stage2_norm=4e24 min_evalue=4e-14 are about right for the secondary (-nps and -npr) phase.

It's not a problem, as long as you tell me which parameter to wiggle on. Here is the result of my little test.
[CODE]test1: stage_1_norm=2.61e27, time: 07:47, yield: 38104 lines
test2: stage_1_norm=1.30e27, time: 09:12, yield: 28759 lines

test3: stage_1_norm=2.61e27, time: 08:10, yield: 41591 lines[/CODE]
The GPU was used in all three tests.

I can run the poly select for two weeks 24/7 but I usually have to restart once a week.

I'm assuming those runtimes are in minutes:seconds.

With a bound of 1.3e27 you're getting a yield of about fifty raw-relations a second and about thirty raw-relations per range-of-c5. Two weeks is 1.2 megaseconds, and that'll get sixty million raw-relations which is a fairly reasonable number; given the production rate, if you want sixty million relations you'll want a range of about two million c5. Very small c5 tend to produce rather high skews, but 'very small' means <10^5 in this case.

So I would run

[code]
msieve -v -np1 "stage1_norm=1.3e27 100000,2100000"
[/code]

If you have to stop it, look at the end of msieve.dat.m to see what c5 value you got up to, and replace '100000' with that number when you restart.

Good luck with the search, and thanks very much for the contribution of cycles.

If you don't mind, could you create a new directory with the worktodo.ini in, concatenate the test* outputs into dir/msieve.dat.m, run
[code]
msieve -v -nps stage2_norm=4e24
msieve -v -npr min_evalue=4e-14
[/code]
and post the number of lines in msieve.dat.ms, the number of polynomials in msieve.dat.p, and the best one.

Thanks for the parameter help.

Here is the output you requested with all three msieve.dat.m files concatenated:
[CODE]polynomial selection complete
R0: -103873937587578637527742939605272616
R1: 1622521601024837503
A0: 1605340936826730247166481182139309231061138933
A1: 70061025315179782873048580290594406872
A2: -11463054102595913174631430761451
A3: -75518693168867128412410
A4: 1554465813696588
A5: 1000008
skew 86919565.35, size 5.214e-18, alpha -7.841, combined = 4.557e-14 rroots = 5

$ wc -l msieve.dat.ms
15 msieve.dat.ms

$ grep "norm" msieve.dat.p | wc -l
214[/CODE]
This is the poly from the msieve.dat.p file:
[CODE]# norm 6.304652e-18 alpha -7.841116 e 4.557e-14 rroots 5
skew: 86919565.35
c0: 1605340936826730247166481182139309231061138933
c1: 70061025315179782873048580290594406872
c2: -11463054102595913174631430761451
c3: -75518693168867128412410
c4: 1554465813696588
c5: 1000008
Y0: -103873937587578637527742939605272616
Y1: 1622521601024837503[/CODE]

I'll start the poly selection as soon as my Einstein@home work is done, sometime tomorrow. Is it correct that I just need to monitor the number of lines in msieve.dat.m and compare this to 60 million to see how the progress is going?

The 14e queue is down to three numbers whose sieving hasn't started.

Have I forgotten some numbers again ? If not, which batches of which kinds of numbers remain within 14e's reach ? :smile:

[QUOTE=debrouxl;403886]The 14e queue is down to three numbers whose sieving hasn't started.

Have I forgotten some numbers again ? If not, which batches of which kinds of numbers remain within 14e's reach ? :smile:[/QUOTE]

There remains a bunch of numbers from the Homogeneous Cunningham tables between SNFS C235 and C250.

All sextics.

[QUOTE=ChristianB;403756]Thanks for the parameter help.

Here is the output you requested with all three msieve.dat.m files concatenated[/quote]

That all seems about right. 100k raw msieve.dat.m lines gave fifteen msieve.dat.ms lines, which is maybe a bit too much if there are going to be sixty million msieve.dat.m lines ... I would do sort -gk10 msieve.dat.ms on the output from the concatenated msieve.dat.m and use the third or fourth value down as the stage2_norm, and min_evalue=4.5e-14 might be good to avoid getting too many entries in the final polynomial file.

(though check first that msieve.dat.ms is not full of duplicate lines - I tend to see about 10% duplication in msieve.dat.m files, so I run them through sort -u before going to stage 2 processing)

Checking the number of lines in msieve.dat.m is indeed the best way to measure progress for stage 1.

[QUOTE=debrouxl;403886]Have I forgotten some numbers again ?[/QUOTE]

From [URL="http://www.mersenneforum.org/showpost.php?p=397659&postcount=46"]message 46[/URL] in this thread. All of these are now at 2/9.

[QUOTE=wblipp;397659]
8627^61-1
9109^61-1
3348577^37-1
8713^59-1
9029^59-1
9239^59-1
2617^71-1[/QUOTE]

[QUOTE=fivemack;403926]Checking the number of lines in msieve.dat.m is indeed the best way to measure progress for stage 1.[/QUOTE]

I already have over 10 million unique lines in msieve.dat.m in the last 2 days and my current c5 value is 244200. So it seems I'm right on track for 60 million within the next 12 days.

It seems that the duplicate ratio at the moment is 10% (11 million lines but only 10 million unique).

I have a status update after 8 days. So far I'm at c5 629004 and collected 32,5 million lines (29,6 million unique). It seems I'm a little behind the schedule for 60 million unique relations within 14 days.

Could I request the addition of a C171 for HP[SUB]2[/SUB](4496) to the appropriate queue? I have a polynomial for it and it has been ECM'd to approximately t55.

[CODE]N 164734138912788678256479747716239929335382228391809572849095528713715496507882648716880741408541101343435610294841078615883189224796473803882207225417108537023419486342801
SKEW 6900060.53
R0 -586227845088152037248455645986030
R1 7881795585370193
A0 -1037951927614370166680117943694468414463
A1 6645924911756341314440980103389782
A2 86632063607336250424710599
A3 -472563531659210325966
A4 -2931238837008
A5 2379312

#size 1.127e-016, alpha -6.110, combined = 3.102e-013 rroots = 5
#expecting poly E from 3.01e-013 to > 3.46e-013
[/CODE]

There was only one number queued for sieving so I've added a few more GCW numbers.

Yup, I'll queue Ben's number, and the remainder of the numbers posted above by William.

Thanks!

As far as I can see Ben's C171 hasn't been queued yet. Should I queue it?

(it'll be at the back of a fairly long line whichever queue I put it on; tempted to use 14e)

I would certainly appreciate it, and it can go wherever is convenient. This is a big favor to me, and I am perfectly happy to wait patiently (and churn through some NFS@Home on my laptop in the meantime).

I see you went for 14e, that's good.

This number shall not be the hardest 14e sieving ever for RSALS / NFS@Home. Shortly before we shut RSALS down, due to the fantastic 10+x surge in computing power created by the stats-minded people as a result of the announcement of RSALS going down, I queued a GNFS difficulty 172 task (properly ECM-ized near-repdigit number) to 14e, out of despair. The polynomial was said to be sub-par, but 14e didn't run out of steam.

I've queued up a moderate SNFS (XYYXF_132_101) for 15e. My GPU appears to have come back to life, so I'll try doing some polynomial selection for 115!+1.

The 14e queue will be empty in several days.

What's the plan for the lasievee application (15e)? Do you guys need more power in there....please reply.

At the moment the limiting factor for putting GNFS jobs on 15e is getting the polynomials produced. There are lots of 260-digit SNFS jobs on XYYXF if the pipeline looks to be getting empty.

The C190-scale jobs take a month on my fastest machine for the linear algebra, so that's getting to be the limiting factor.

[QUOTE=debrouxl;406984]The 14e queue will be empty in several days.[/QUOTE]

These are ready - ECM to 2/9 of SNFS size done by yoyo@home

10321^61-1 C241
10739^61-1 C242
11159^61-1 C243
9311^61-1 C239
86693739546562035101^13-1 C240

Thanks William, all queued to NFS@Home's 14e :smile:

For the fifth one, I reused the coefficients from previous x^13-1 tasks. It's a good thing that these coefficients make it possible to sieve that C240 at difficulty 239, because the full number is C260...

[QUOTE=debrouxl;406984]The 14e queue will be empty in several days.[/QUOTE]

Is there any interest in doing 30-bit LP jobs?
There are currently 42 composites in the OPN road block file in the C220 range - not counting many in the low C230’s.
Of course some of the polys would be elevated out of this range.
It wouldn’t take much to get some numbers to t50 or so to satisfy 2/9 SNFS.
(Maybe this should be posted in the OPN thread.)

On the one hand, we're less interested in 30-bit LPs jobs than before, as the computing power accessible to individuals keeps increasing over time, and smaller tasks need more administrative work in proportion.
On the other hand, there are more people with access to the admin interface than before, so if we share the duty of pre-processing the numbers and filling in the admin page, the work is more palatable for every involved admin.

[QUOTE=RichD;407413]Is there any interest in doing 30-bit LP jobs?
There are currently 42 composites in the OPN road block file in the C220 range - not counting many in the low C230’s.
Of course some of the polys would be elevated out of this range.
It wouldn’t take much to get some numbers to t50 or so to satisfy 2/9 SNFS.
(Maybe this should be posted in the OPN thread.)[/QUOTE]I still have a few candidates left in the C225-235 range but they've been kept back for individuals (like me!) to work on. Some of them could be released to NFS@Home.

Reality is that sievers will always be looking for having their milestone badges on all three sievers. I suggest feeding everything to NFS@Home and just have a couple spare for individuals effort. Right now I am running 16e siever, reached there one milestone of 1M points, might do the same for 14e and 15e applications.

[QUOTE=pinhodecarlos;407453]Reality is that sievers will always be looking for having their milestone badges on all three sievers. I suggest feeding everything to NFS@Home and just have a couple spare for individuals effort. Right now I am running 16e siever, reached there one milestone of 1M points, might do the same for 14e and 15e applications.[/QUOTE]
The only way to 'remedy' this behaviour is to shut down the 14e siever, but that may be premature for now.

[QUOTE=VictordeHolland;407482]The only way to 'remedy' this behaviour is to shut down the 14e siever, but that may be premature for now.[/QUOTE]

I agree, still premature.

What are the current guidelines/thoughts/rules of thumb in terms of SNFS/GNFS size for each of three sievers?

The few xyyxf numbers I've requested help from NFS@Home were moderate in size but horribly slow in test sieving. On the order of 6-12 months for an individual machine to factor. Maybe they were suboptimal polys but I could not find better.

As others have said, it's tough requesting NFS to sieve a composite that an individual could complete in < a couple of months. I can't do it, feel guilty. And embarrassed. Many 14e candidates fall into this category, though not all are "easy". It's these SNFS 235-240 that will take 7+ months to sieve that I look for. Just not many of them.

Ah well, there's always ECM...in moderation of course.

Only way to have more 14e and 15e sievers is to increase the points per wu , to match 16e credit. This is an old discussion.

* for 14e, nowadays, we queue few numbers of SNFS difficulty < 235 or GNFS difficulty < 160, and therefore, few 30-bit LPs tasks. 29-bit LPs tasks definitely belong to the past.
* for 15e, we seem to queue tasks up to SNFS difficulty ~28x-29x or GNFS difficulty ~190;
* 16e and lasieve5f are Greg's duty :smile:

This week, I'm on holiday, so I suppose I could spread over the week the pre-processing of at least a dozen integers for 14e. The usual rules of thumb apply for ECM work, ~2/9 of SNFS difficulty or ~ 2/7 of GNFS difficulty.

[QUOTE=debrouxl;407525]* for 14e, nowadays, we queue few numbers of SNFS difficulty < 235 or GNFS difficulty < 160, and therefore, few 30-bit LPs tasks. 29-bit LPs tasks definitely belong to the past.
* for 15e, we seem to queue tasks up to SNFS difficulty ~28x-29x or GNFS difficulty ~190;
* 16e and lasieve5f are Greg's duty :smile:

This week, I'm on holiday, so I suppose I could spread over the week the pre-processing of at least a dozen integers for 14e. The usual rules of thumb apply for ECM work, ~2/9 of SNFS difficulty or ~ 2/7 of GNFS difficulty.[/QUOTE]

The current GCW tables, which will hit the web in a few minutes, have 9 composites < C160 and 27 < S232. Some of them have already been reserved.

Anyone who wants to search for GNFS polynomials is welcome to do so. Mail me which one(s) you want to do and I'll reserve them on the web page.

Incidentally the extension tables for the Homogeneous Cunninghams are in preparation. There are many composites < C150 so possible 29-bit 14e candidates. Up to now I've done all the work on them. Bob S. has offered to run ECM on them once the remaining main table composites become too hard for his resources. In principle I could release them under a few conditions: you're responsible for taking them to 2/9 by ECM (they've had a t30 so far); you're responsible for polynomial finding for the survivors; you won't get any detailed acknowledgement in the tables when they are eventually published, which won't be until the main table composites are much fewer than at present. "You" in that sentence, of course, means anyone who wants to take on some of this work. Anyone willing to take on a thankless task? You will be in good, if sparse, company.

Paul

[QUOTE=RichD;407413]Is there any interest in doing 30-bit LP jobs?
There are currently 42 composites in the OPN road block file in the C220 range - not counting many in the low C230’s.
Of course some of the polys would be elevated out of this range.
It wouldn’t take much to get some numbers to t50 or so to satisfy 2/9 SNFS.
(Maybe this should be posted in the OPN thread.)[/QUOTE]

Looking at that list sorted by weight/(estimated CPU time to factor) the top few would be:
28210267^31-1
9239^59-1 - already ECMed to 2/9, see post 118 in this thread, is it already queued?
8821^61-1
10271^59-1

If you want a bigger challenge 732541^47-1 (SNFS 283) had a weight of 1424854 which is more than everything else from the list I've done or know of other people doing put together.

Chris

732541^47-1 (so 732541^48-732541) is I think too hard to be run sensibly with 15e - I'm seeing yields of 700 relations per 1kQ and times of nearly two CPU-seconds per relation on Ivy Bridge.

From the xyyxf world, how about these for 14e:

C211_128_95
C216_119_108
C177_123_92

I've ECM'd each towards t55 (6-10k curves @110M), though I can do more if that's preferred.

C211_128_95 128^96 + 128*95^2 * 95^126 255.3
C216_119_108 108*119^108+108^120 244.0
C177_123_92 123^2 * (123^15)^6 + 23^3 * (2^41*23^20)^6 241.6

C177_123_92, 14e, 31-bit LP:
(a, 14e) total yield: 791, q=90001003 (0.25492 sec/rel)
(r) total yield: 826, q=90001003 (0.30864 sec/rel)
(a, 15e) total yield: 1617, q=90001003 (0.30139 sec/rel)
(r, 15e) total yield: 1627, q=90001003 (0.36709 sec/rel)

C216_119_108, 14e, 31-bit LP:
(a) total yield: 1785, q=90001003 (0.22541 sec/rel)
(r) total yield: 1190, q=90001003 (0.22871 sec/rel)

I've queued those two up.

Thanks for queuing those two.

I'll ECM C211_128_95 up to a full t55 - is that sufficient preprocessing for 15e? Or should it go higher by the 2/9 rule?

255.3 x (2/9) = 56.7. I realize that is a 'rule of thumb' and the level of precision is fuzzy at best, but I am never quite sure how to round up or down at these levels. A full t60 seems overkill. Is 25k curves @B1=110M warranted?

I don't think more ECM on 128_95 is particularly necessary; I just think it's big enough that it will be handled more efficiently on the 15e queue, and I thought we were discussing options for 14e.

[QUOTE=fivemack;407809]Should take until September 1 (452 hours estimate) for 23.9M density-120 matrix (8 cores Xeon D1540)

190-digit GNFS seems to be about the point where the linear algebra on one fast machine and the 15e sieving on NFS@home take equal time - according to my logs, the sieving has taken about 24 days and the linalg will take 19 days. I just about have enough fast machines to keep up.

For comparison, C193_2340_742 averaged 19.2M relations per day, and sieved 435M relations, so that's 23 days of sieving and the linear algebra ETA was 650 hours = 27 days.[/QUOTE]

Tom,

Can you give me a forecast of the numbers to be queued for 15e application? Do you have anything in mind or do you have a list, etc? After the NFS@Home challenge I would like to propose a rally to the 15e application, I want to change your figures...hehe

I don't have a very good idea of what would be most interesting to do next for 15e.

A decent polynomial has been found for aliquot 4788:5236 C194, and I have added it to the queue.

There are 294 numbers in the XYYXF with SNFS difficulties between 250 and 270, any of which could go through at a price of about 1 CPU-day of trial sieving each; I'd concentrate on the 12 which also have composite size >260 digits.

There are 20 C18x numbers with digits < 0.7*SNFS, though some of those may still be SNFS candidates.

GNFS 18x numbers require significant prep effort - say two to four GPU-weeks, and at present I have precisely one GPU. ChristianB has prepped one number but otherwise I'm the only person doing that. I am currently polynomial-selecting for 115!+1, should have that around start of September.

There are three other plausible factorials for GNFS: (129!+1 C176 is already being done by sean); 125!+1 C184; 145!-1 C185; 122!+1 C186

2,2590L C192 has already been done.

[QUOTE=fivemack;407837]

2,2590L C192 is a possibility.[/QUOTE]

Why do numbers from the extensions? There are still earlier numbers available.

[QUOTE=fivemack;407837]I don't have a very good idea of what would be most interesting to do next for 15e.

There are 294 numbers in the XYYXF with SNFS difficulties between 250 and 270, any of which could go through at a price of about 1 CPU-day of trial sieving each[/QUOTE]
There are two GCW candidates in that range which have no known factors, 4,437-_C266 and 3,560-_C270. The relevant ecmserver.ini records are

GW_4_437 B 43000000 5489:0 3:0 1:0
GW_3_560 B 43000000 5883:0 3:0 1:0

so each have around 0.8t50 ECM work performed. My GPU is idle right now but a full t60 would take it some time.

Paul

[QUOTE=fivemack;407837]2,2590L C192 is a possibility.[/QUOTE]

NFS@Home already completed 2,2590L back in February.

Barring a find of a 50-55 digit factor, I'll likely have a C181 available in a few weeks. I can do the polynomial search for it as well.

We were addressing 14e, sorry about the scope creep.

I see there is a good discussion on the 15e queue for all projects in general over in the other thread, so I'll take a step back on 128_95.

Thanks again for queuing the two xyyxf into 14e.

You can request a few polys in [url=http://www.mersenneforum.org/showthread.php?t=18368]this thread[/url]. Folks have been generous with GPU cycles in the past.

I've given it a go, but I appreciate that a C184 is a big ask (say a month of GPU time, probably $30 in electricity alone)

[QUOTE=wombatman;407845]Barring a find of a 50-55 digit factor, I'll likely have a C181 available in a few weeks. I can do the polynomial search for it as well.[/QUOTE]

Famous last words. I found a 53 digit cofactor, so this one is out.

I'm on vacation from Wednesday. I will start polynomial selection on an interesting C188 suggested by Sean as part of the Euclid-Mullin graph.

I'll go overseas on work next Tuesday and I will come back on the 28th of August therefore please queue up for 14e and 15e applications as much as possible 10 days before the start of the challenge.

Greg could queue the SNFS numbers with 4deg polys on the 15e siever should it run dry. They should still be in this thread/subforum, I can run the LA on them if needed. But there have been a lot of Fib/Lucas numbers sieved by the 15, so I understand if other numbers take precedence.

For 15e, how about the [url=http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl]five highest SNFS remaining for Homogenous Cunningham numbers[/url]? They are just over SNFS difficulty 250, the polys are quickly discerned and it's a long time project. They've been ECM'd for years, though I don't know exactly to what level for these particular five. Just a suggestion.

Number SNFS
5^359+2^359 250.9
5^359+3^359 250.9
5^359+4^359 250.9
7^298+3^298 251.8
7^298+2^298 251.8

For 15e, there are still a few low Fibonacci/Lucas numbers available.

F1405
x^4 + 3x^2 + 1 with m: L281

F1415
x^4 + 3x^2 + 1 with m: L283

L1397
x^5+x^4-4x^3-3x^2+3x+1 with m: L254

Plus some for GNFS:
F2145
F2163
F1585

L2037
L1502
L1583
L1541

Plus a ton of Lucas quartics:
L2645A
L2675A
L2675B
L2705B
L2735B
L2755A
L2785A
L2785B
L2815A
L2825A
L2845A
L2845B
L2855A
L2855B

This will keep us busy for quite a while, but feel free to intersperse with numbers from other sources.

Queued L1405 and L1415.

Now just needed to queue more 14e tasks.

The two XYYXF 14e tasks require a relatively wide range, which I've just updated, so 14e shouldn't be empty for at least a couple more days.


Last week, William suggested that I post some more detailed guidelines for choosing 14e candidates. Here's a draft heavily based on his suggestion:

Ultimately, the suitability of any composite depends on how well it sieves. The following guidelines usually produce composites suitable for the 14e siever:
* SNFS polynomials should have leading coefficients < 10^5
* SNFS tasks with degree 6 polynomials (preferred) should have 225 <= difficulty <= 250, ECM to 2/9 of SNFS difficulty
* SNFS degree 5 tasks should have 210 <= difficulty <= 235, ECM to 2/9 of (15+SNFS difficulty)
* SNFS degree 4 tasks should have 195 <= difficulty <= 220, ECM to 2/9 of (30+SNFS difficulty)
* GNFS tasks should have 155 <= difficulty <= 170, ECM to 2/7 of GNFS difficulty (a bit more than that for difficulty close to 170).

As shown by the "crunching" pages, over time, RSALS and NFS@Home's 14e have used numbers from a variety of projects, especially OddPerfect, thanks to William. Numbers which are of interest to multiple projects, as were dozens of OP numbers, have slightly higher priority than numbers from other projects. Likewise, Aliquot sequence numbers, due to their blocking aspect.

For 14e, I suggest the following candidates from the xyyxf project

C179_139_61

C172_122_101

C178_147_44

I believe they all meet the criteria and I've ECM'd each beyond t50.

For your consideration.

I've just pre-processed C179_139_61, it would be a relatively lengthy sieving but it would work. Needs about t55 ECM work, though.

[code]n: 75160334405053835461494923382958398301840986146380929845000731140297137795893087427283921355088498730255343147094389415017971202233439468483527437717537648743360786599454203497659
deg: 6
c6: 61
c5: 0
c4: 0
c3: 0
c2: 0
c1: 0
c0: 139
Y1: 2692452204196940400601
Y0: -115501122579584388592138579457905758648181
type: snfs
skew: 1.14713402332363
rlim: 134217727
alim: 134217727
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/code]

[QUOTE=debrouxl;408234]I've just pre-processed C179_139_61, it would be a relatively lengthy sieving but it would work. Needs about t55 ECM work, though.[/QUOTE]

I've ECM'd each of these numbers to 8-10k curves @B1=110M (varies), however I will carry each on to the full t55 if necessary.

Thanks.


Edit to add: currently in ECM to t55.

[QUOTE=swellman;408168]For 14e, I suggest the following candidates from the xyyxf project

C179_139_61
C172_122_101
C178_147_44

[/QUOTE]

C179_139_61 is currently in ECM and should reach t55 sometime on Sunday. Not sure how long until the 14e queue runs dry.

I will then ECM the other two composites to t55 as well, though help gratefully accepted. Each need 10k additional curves for t55.

These three are ready. The last has a C157 that may be better by GNFS.

1900421426047^19-1
6301^61-1
181^103-1

Paul,

Please add your GCW integers to 14e, all of them.

Carlos

Time to queue up more wus for 14e, 15e and 16e application. For 14e more 10x, for 15e more 5x and for 16e more 2x. Please do it ASAP, challenge is less than 6 days. This is urgent.

[QUOTE=pinhodecarlos;408396]Paul,

Please add your GCW integers to 14e, all of them.

Carlos[/QUOTE]
I tried but had trouble authenticating to the site. Demigods have been informed of the situation and of the polynomials to be added.

[offtopic]Let's bet how long till a mod changes the title from "fast breeding" to "breast feeding" :razz:[/offtopic]

[QUOTE=LaurV;408545][offtopic]Let's bet how long till a mod changes the title from "fast breeding" to "breast feeding" :razz:[/offtopic][/QUOTE]

It has already gone there, though that title lasted only a few days.

Oh, well... and I was kind of happy of this English invention I did... I was wondering myself how my English improved overnight, so much that I can make word plays.. hehe, it might be that I have read it here...:redface: but ignored it at that time and it popped to my mind now when I was reading this current title...

Lionel,

Did you see Paul's email with some numbers to queue on 14e side? We need to add them ASAP because challenge is due.

Carlos

I did, but other numbers were posted here earlier by William, and therefore, they take precedence. So would all three numbers posted by Sean, though only C179_139_61, which I've already pre-processed, should have received enough ECM work by today.

I've queued William's two first numbers. The third one would be slightly easier by GNFS, but I don't have a GPU to search for a poly quickly, so I'll queue it as SNFS - it's still a relatively easy 30-bit LPs task.

Besides Paul's numbers, I've reserved three easy 30-bit LPs tasks from near-repdigit.


There's no hurry for queuing numbers: none of the 5000 WUs in the initial set for 1900421426047_19_minus1 has been distributed yet, and this number will actually require sieving a much wider range.

Lionel, let's queue up what's needs to be first but don't forget that a challenge is coming and clients like to see cache full with wus to crunch otherwise they ran away. This is my only concern.

[QUOTE=pinhodecarlos;408396]Paul,

Please add your GCW integers to 14e, all of them.

Carlos[/QUOTE]The 14 hardest are in SIEVING status. The other 15 are not yet added into the queue but will be when I get another burst of enthusiasm.

Paul

Yeah, I'm aware that clients participating in challenges selfishly like to reserve loads of WUs in advance, which disrupts the input queue.

Carlos, which computing resources do you have access to nowadays, in order to help with post-processing the backlog, which is especially important for projects like NFS@Home, whose post-processing is relatively costly ? Our resources prove to be adequately sized for the average level of activity, but bursts of activity disrupt our routine :smile:

The 14e input queue now contains 19 numbers whose distribution to clients hasn't started yet, mostly thanks to Paul, as he's just indicated.

Lionel,

My machines are all i7 laptops, one Sandy Bridge with 16 GB of memory and one Ivy Bridge with 8GB.

Paul,

Thank you for adding the numbers.

Kind Regards,

[quote]My machines are all i7 laptops, one Sandy Bridge with 16 GB of memory and one Ivy Bridge with 8GB.[/quote]
Good :smile:
Which numbers shall I reserve for you ?

[QUOTE=debrouxl;408615]Good :smile:
Which numbers shall I reserve for you ?[/QUOTE]

Right now due to my work, where I travel a lot most of the times with limited access to Internet, I leave my cores to sieve for NFS@Home.

[QUOTE=swellman;408318]C179_139_61 is currently in ECM and should reach t55 sometime on Sunday. Not sure how long until the 14e queue runs dry.

I will then ECM the other two composites to t55 as well, though help gratefully accepted. Each need 10k additional curves for t55.[/QUOTE]

C179_139_61 has survived a full t55 with no factors found. Thanks for queuing it on 14e.


ECM of C172_122_101 to full t55 is now underway.

For 15e queue?
 

Bump

[QUOTE=swellman;408054]For 15e, how about the [url=http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl]five highest SNFS remaining for Homogenous Cunningham numbers[/url]? They are just over SNFS difficulty 250, the polys are quickly discerned and it's a long time project. They've been ECM'd for years, though I don't know exactly to what level for these particular five. Just a suggestion.

Number SNFS
5^359+2^359 250.9
5^359+3^359 250.9
5^359+4^359 250.9
7^298+3^298 251.8
7^298+2^298 251.8[/QUOTE]

Are these viable candidates for 15e? Sufficient ECM run?

I realize there is a discussion/debate on the other thread about inserting some Homogeneous Cunninghams into queue but I believe it is limited to 14e.

[QUOTE=swellman;408866]

I realize there is a discussion/debate on the other thread about inserting some Homogeneous Cunninghams into queue but I believe it is limited to 14e.[/QUOTE]

About this maybe hurry up....just an advise.

Yeah, Homogeneous Cunninghams are one of the sources of numbers we tap once in a while, under the usual guidelines ( [url]http://www.mersenneforum.org/showpost.php?p=408161&postcount=167[/url] ).
But now that we've queued a couple dozen numbers, there will be some latency for the three XYYXF numbers suggested by Sean, some yet unreserved Homogeneous Cunninghams, or anything else.

[QUOTE=debrouxl;408934]Yeah, Homogeneous Cunninghams are one of the sources of numbers we tap once in a while, under the usual guidelines ( [url]http://www.mersenneforum.org/showpost.php?p=408161&postcount=167[/url] ).
But now that we've queued a couple dozen numbers, there will be some latency for the three XYYXF numbers suggested by Sean, some yet unreserved Homogeneous Cunninghams, or anything else.[/QUOTE]

Just please be aware of a boom on the 14e crunching side that might happen during the challenge.

Yes, the bunkering has already started, and creates some latency (overly long tail) on 6301_61_minus1.

[QUOTE=debrouxl;408937]Yes, the bunkering has already started, and creates some latency (overly long tail) on 6301_61_minus1.[/QUOTE]

Wait a few hours until bunker is released. 15 hours and 18 mins to start.

Please be aware that more 14e integers might be needed. Let's wait for the first dump from teams regarding the challenge but my expectation is to see more than 14e 10k wus processed daily during this period. It can be higher if Mumps decides to run it because we are trying to reach a milestone badge for the team.