Weird error message
 

Just started getting a really strange error message with factmsieve.py. I've already run over 400 composites since loading this up.

-> ________________________________________________________________
-> | Running factmsieve.py, a Python driver for MSIEVE with GGNFS |
-> | sieving support. It is Copyright, 2010, Brian Gladman and is |
-> | a conversion of factmsieve.pl that is Copyright, 2004, Chris |
-> | Monico. Version 0.76 (Python 2.6 or later) 10th Nov 2010. |
-> |______________________________________________________________|
-> This is client 1 of 1
-> Running on 4 Cores with 1 hyper-thread per Core
-> Working with NAME = 28Mar
-> Selected default factorization parameters for 112 digit level.
-> Selected lattice siever: gnfs-lasieve4I13e
-> No parameter change detected, resuming...
-> Running setup ...
-> Estimated minimum relations needed: 7.95e+06
-> resuming a block for q from 1750000 to 1850000
-> Running lattice siever ...
-> entering sieving loop
-> making sieve job for q = 1750000 in 1750000 .. 1775000 as file 28Mar.job.T0
-> making sieve job for q = 1775000 in 1775000 .. 1800000 as file 28Mar.job.T1
-> making sieve job for q = 1800000 in 1800000 .. 1825000 as file 28Mar.job.T2
-> making sieve job for q = 1825000 in 1825000 .. 1850000 as file 28Mar.job.T3
-> Lattice sieving algebraic q from 1750000 to 1850000.
-> gnfs-lasieve4I13e -k -o spairs.out.T0 -v -n0 -a 28Mar.job.T0
-> gnfs-lasieve4I13e -k -o spairs.out.T1 -v -n1 -a 28Mar.job.T1
gnfs-lasieve4I13e: L1_BITS=15, SVN $Revision: 406 $
-> gnfs-lasieve4I13e -k -o spairs.out.T2 -v -n2 -a 28Mar.job.T2
gnfs-lasieve4I13e: L1_BITS=15, SVN $Revision: 406 $
-> gnfs-lasieve4I13e -k -o spairs.out.T3 -v -n3 -a 28Mar.job.T3
Traceback (most recent call last):
File "C:\ggnfs\example\factmsieve.py", line 2066, in <module>
run_siever(client_id, num_clients, SV_THREADS, fact_p, lats_p)
File "C:\ggnfs\example\factmsieve.py", line 1701, in run_siever
ret = monitor_sieve_threads()
File "C:\ggnfs\example\factmsieve.py", line 1650, in monitor_sieve_threads
read_spq(fact_p)
File "C:\ggnfs\example\factmsieve.py", line 1638, in read_spq
t = int(chomp(tmp))
ValueError: invalid literal for int() with base 10: ''
siever terminated

C:\ggnfs\example>

I tried changing the composite to see if starting fresh would help. Exact same error. I don't have enough experience in Python to make much sense of the error message. Any ideas?

Not sure if this helps or not, but factmsieve is still able to find polynomials just fine.

First, please use [code] tags.

Second, the error is that the script has a variable that's an empty string [c]''[/c] where instead it's expecting a number (and the error is saying the empty string is not a valid [base 10] number). As for what's causing that, I couldn't tell you, I know nothing about factmsieve.py. Looks like something's going wrong when it creates sieving threads?

You want something even more bizarre? I reinstalled the program - recopied every file to the working directory from the zips I used at the beginning. Exact same error message. Input files were formatted exactly the same as the last 400+ tests.

Really the only thing different was that I came home yesterday to find a momentary power outage had turned the machine off. When I turned it back on everything ran fine.

[QUOTE=Dubslow;455708]First, please use [code] tags.

Second, the error is that the script has a variable that's an empty string [c]''[/c] where instead it's expecting a number (and the error is saying the empty string is not a valid [base 10] number). As for what's causing that, I couldn't tell you, I know nothing about factmsieve.py. Looks like something's going wrong when it creates sieving threads?[/QUOTE]

Code tags?

[QUOTE=ThomRuley;455711]Code tags?[/QUOTE]

the one I squared off in red in the attachment.

[QUOTE=ThomRuley;455711]Code tags?[/QUOTE]

yes, they make your
[CODE]output text
look
like
this
i.e. nice
and aligned[/CODE] instead of lo
oking like t
his
(broken an
d misa
ligned)

:razz:

[QUOTE=LaurV;455722]yes, they make your
[CODE]output text
look
like
this
i.e. nice
and aligned[/CODE] instead of lo
oking like t
his
(broken an
d misa
ligned)

:razz:[/QUOTE]
And more importantly, they put the text in question inside a scroll-bar'd box, thus significantly reducing pain-to-read levels of the thread.

OP, certainly *seems* like a bug, though like I said I'm of no use in debugging it.

[CODE]-> ________________________________________________________________
-> | Running factmsieve.py, a Python driver for MSIEVE with GGNFS |
-> | sieving support. It is Copyright, 2010, Brian Gladman and is |
-> | a conversion of factmsieve.pl that is Copyright, 2004, Chris |
-> | Monico. Version 0.76 (Python 2.6 or later) 10th Nov 2010. |
-> |______________________________________________________________|
-> This is client 1 of 1
-> Running on 4 Cores with 1 hyper-thread per Core
-> Working with NAME = 28Mar
-> Selected default factorization parameters for 112 digit level.
-> Selected lattice siever: gnfs-lasieve4I13e
-> No parameter change detected, resuming...
-> Running setup ...
-> Estimated minimum relations needed: 7.95e+06
-> resuming a block for q from 1750000 to 1850000
-> Running lattice siever ...
-> entering sieving loop
-> making sieve job for q = 1750000 in 1750000 .. 1775000 as file 28Mar.job.T0
-> making sieve job for q = 1775000 in 1775000 .. 1800000 as file 28Mar.job.T1
-> making sieve job for q = 1800000 in 1800000 .. 1825000 as file 28Mar.job.T2
-> making sieve job for q = 1825000 in 1825000 .. 1850000 as file 28Mar.job.T3
-> Lattice sieving algebraic q from 1750000 to 1850000.
-> gnfs-lasieve4I13e -k -o spairs.out.T0 -v -n0 -a 28Mar.job.T0
-> gnfs-lasieve4I13e -k -o spairs.out.T1 -v -n1 -a 28Mar.job.T1
gnfs-lasieve4I13e: L1_BITS=15, SVN $Revision: 406 $
-> gnfs-lasieve4I13e -k -o spairs.out.T2 -v -n2 -a 28Mar.job.T2
gnfs-lasieve4I13e: L1_BITS=15, SVN $Revision: 406 $
-> gnfs-lasieve4I13e -k -o spairs.out.T3 -v -n3 -a 28Mar.job.T3
Traceback (most recent call last):
File "C:\ggnfs\example\factmsieve.py", line 2066, in <module>
run_siever(client_id, num_clients, SV_THREADS, fact_p, lats_p)
File "C:\ggnfs\example\factmsieve.py", line 1701, in run_siever
ret = monitor_sieve_threads()
File "C:\ggnfs\example\factmsieve.py", line 1650, in monitor_sieve_threads
read_spq(fact_p)
File "C:\ggnfs\example\factmsieve.py", line 1638, in read_spq
t = int(chomp(tmp))
ValueError: invalid literal for int() with base 10: ''
siever terminated

C:\ggnfs\example>[/CODE]

Like this?

[QUOTE=ThomRuley;455682]Just started getting a really strange error message with factmsieve.py. I've already run over 400 composites since loading this up.

-> ________________________________________________________________
-> | Running factmsieve.py, a Python driver for MSIEVE with GGNFS |
-> | sieving support. It is Copyright, 2010, Brian Gladman and is |
-> | a conversion of factmsieve.pl that is Copyright, 2004, Chris |
-> | Monico. Version 0.76 (Python 2.6 or later) 10th Nov 2010. |
-> |______________________________________________________________|
-> This is client 1 of 1
-> Running on 4 Cores with 1 hyper-thread per Core
-> Working with NAME = 28Mar
-> Selected default factorization parameters for 112 digit level.
-> Selected lattice siever: gnfs-lasieve4I13e
-> No parameter change detected, resuming...
-> Running setup ...
-> Estimated minimum relations needed: 7.95e+06
-> resuming a block for q from 1750000 to 1850000
-> Running lattice siever ...
-> entering sieving loop
-> making sieve job for q = 1750000 in 1750000 .. 1775000 as file 28Mar.job.T0
-> making sieve job for q = 1775000 in 1775000 .. 1800000 as file 28Mar.job.T1
-> making sieve job for q = 1800000 in 1800000 .. 1825000 as file 28Mar.job.T2
-> making sieve job for q = 1825000 in 1825000 .. 1850000 as file 28Mar.job.T3
-> Lattice sieving algebraic q from 1750000 to 1850000.
-> gnfs-lasieve4I13e -k -o spairs.out.T0 -v -n0 -a 28Mar.job.T0
-> gnfs-lasieve4I13e -k -o spairs.out.T1 -v -n1 -a 28Mar.job.T1
gnfs-lasieve4I13e: L1_BITS=15, SVN $Revision: 406 $
-> gnfs-lasieve4I13e -k -o spairs.out.T2 -v -n2 -a 28Mar.job.T2
gnfs-lasieve4I13e: L1_BITS=15, SVN $Revision: 406 $
-> gnfs-lasieve4I13e -k -o spairs.out.T3 -v -n3 -a 28Mar.job.T3
Traceback (most recent call last):
File "C:\ggnfs\example\factmsieve.py", line 2066, in <module>
run_siever(client_id, num_clients, SV_THREADS, fact_p, lats_p)
File "C:\ggnfs\example\factmsieve.py", line 1701, in run_siever
ret = monitor_sieve_threads()
File "C:\ggnfs\example\factmsieve.py", line 1650, in monitor_sieve_threads
read_spq(fact_p)
File "C:\ggnfs\example\factmsieve.py", line 1638, in read_spq
t = int(chomp(tmp))
ValueError: invalid literal for int() with base 10: ''
siever terminated

C:\ggnfs\example>

I tried changing the composite to see if starting fresh would help. Exact same error. I don't have enough experience in Python to make much sense of the error message. Any ideas?[/QUOTE]
It appears that factmsieve.py has successfully started four sieve threads and is in a loop waiting for these threads to complete. When they do so they are supposed to write a file '.last_spq<n> where <n> is the thread number that should contain a single line containing an integer. The script seems to have found and opened such a file but the line where it expects to find an integer is either missing or empty.

Can you see the .last_spq<n> files where <n> is 0, 1, 2 and 3? If so, what do they contain?

Just opened them up. All four files 0, 1, 2, and 3 - have null eight times, all on one line