[QUOTE=debrouxl;495530]As long as the number is in QUEUED for SIEVING state, the starting q value, and other parameters, can be changed.
The 14e clients are going to starve by the end of this European morning, so I'll start this number very soon anyway, unless Sean is in a comparable timezone and beats me to it.
That's a persistent issue with the 14e grid: clients chew through WUs very quickly, which makes for a poor management effort / amount of food for clients ratio.[/QUOTE]

Basically Greg needs to add more 16e work otherwise the Gridcoin clients will just crunch the 14e/15e wus in no time.

If a number for 16e is needed, I have a C208 blocker on HP2(4496) -- [url]http://factordb.com/sequences.php?se=2&aq=4496&action=last&fr=0&to=100[/url]

I have a polynomial, and I believe it's been test-sieved, but I can double-check tonight if there's any interest.

C243 from the MWRB file with OPN weight of 17501. (for 14e)
[CODE]n: 529240584967009887418759189153762339953358445714031976694898445666783001971824396861966104538278993554027238807452605192095977191609642828920933074769390052310464338550743576121946908022304449245179580931209109736429915065760138298351371037557
# 15307^59-1, difficulty: 251.09, skewness: 4.98, alpha: 0.00
# cost: 9.02623e+18, est. time: 4298.20 GHz days (not accurate yet!)
skew: 4.983
c6: 1
c0: -15307
Y1: -1
Y0: 706156273912323084390219106603222678396249
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
30M 10469
60M 8964
100M 8593
150M 7210
200M 6803
250M 5942
300M 5751
350M 5592[/CODE]

Sean: I'll let you create an entry (button at the bottom of the page) for the number in post #1606, we'll check it and you or me can start it later :smile:

On my side, I'm going to create and start Rich's latest number for 14e, and start 57779_231. Even with those, the grid's probably going to starve by tomorrow morning...

EDIT: looks like I used 20M-220M instead of the suggested 20M-200M range for 13_2_857m1, so there's going to be some oversieving, probably around 800M raw relations.

[QUOTE=debrouxl;495582]Sean: I'll let you create an entry (button at the bottom of the page) for the number in post #1606, we'll check it and you or me can start it later :smile:[/QUOTE]

Done. I think I got it but please check my work. While I was in there, I also corrected the poly for C241_148_110 - it was missing the "n:" in the first line. I checked my original posting and I own the error. :blush: At least it was corrected before sieving started,

Also added some postprocessor names to 14e that appeared tonight.

I have no immediate numbers to add. Maybe one or two in the next 5-7 days.

Are there other projects that would like to submit numbers, at least for the 14e queue? Aliquot?

Sean: doh. Good thing you found the error I failed to detect as well :smile:
The poly looks alright, it has the appropriate number of lines for a two-coefficient polynomial without lss: line anyway.
Neither ^, nor - are reserved characters for Windows or *nix, so the "5009^73-1" prefix for filenames will be alright. Historically, we've avoided such names - in fact, yesterday evening, I created and immediately deleted an entry for this exact reason, that's why there's a hole between #1448 and #1450 - but AFAICT, we don't [i]have[/i] to avoid such names.

[QUOTE=debrouxl;495612]Sean: doh. Good thing you found the error I failed to detect as well :smile:
The poly looks alright, it has the appropriate number of lines for a two-coefficient polynomial without lss: line anyway.
Neither ^, nor - are reserved characters for Windows or *nix, so the "5009^73-1" prefix for filenames will be alright. Historically, we've avoided such names - in fact, yesterday evening, I created and immediately deleted an entry for this exact reason, that's why there's a hole between #1448 and #1450 - but AFAICT, we don't [i]have[/i] to avoid such names.[/QUOTE]

Well. I should have remembered this fact about naming conventions but did not. Why don’t I change it to 5009_73m1? Or can the name be changed now? If not I’ll delete this entry and add it back with the better name choice. Even if it shouldn’t break NFS@Home, why risk it?

You mention “lss:” - should this always be present in the poly or only lss:0 if sieving on the algebraic side?

At best, the "5009^73-1" prefix could now be changed only by Greg, or whoever else has direct write access to the database. It's the only non-editable field in the Web form, and I've just checked that the comment for that database field in the SQL schema reads "number name (cannot be changed)".
It's simpler to create a new entry, copy the contents, and delete #335.

The "lss:" line needn't be present if the sieving side is the one corresponding best to the "type:" line. Most polys I managed over time do not have "lss:" lines. Or put another way: if the original poly has one, I usually keep it, but I don't add it if it's not there.

I've just noticed that polys for e.g. C215_46988659_29 and C210_35111_47 (14e) and C253_131_98b (15e) do [i]not[/i] have "type:" lines - so the fact is that the whole chain works without it, but I didn't remember about that...
There doesn't seem to be any code to fix up the poly, so the sievers seem to be able to cope without these lines, I guess. I remember that missing "skew:" lines caused immediate failures for several past RSALS and/or NFS@Home.

C179_374xx231_19 has a high dup rate (which doesn't surprise me). Can we get a few more relations added to this guy? My last 31-bit job had 178M+ unique relations and built a matrix at TD=120. This failed at TD=112 with 154M unique. I may peek ahead at a couple others. In the mean time I will take another number - posting in the appropriate thread.
[CODE]Found 154649059 unique, 65501730 duplicate, and 6681 bad relations.
Largest dimension used: 568 of 1200
Average dimension used: 472.0 of 1200[/CODE]

Alright, I raised the upper bound for C179_374xx231_19 to 300M.
The poly doesn't have a "type:" line, but since it has a "lss:" line, I'd expect it to have been sieved on the right side anyway.