[Nauty-list] malfunction of listg

[Brendan McKay]

Hi Susanne,

Near the end of listg.c you will see a line 
   FREES(g);
Immediately after that line, add this line:
   if (ferror(outfile)) gt_abort(">E listg output error\n");

Then recompile.  It will write an error message in the event of
an error.  This will be default in the next edition.

I don't understand what problem you are having on a 64-bit system.
For me it looks fine.  Why don't you use the "head" command to 
examine a little of the file to see if it looks ok?  And the "wc"
command can count the lines; the output of listg -Atq should have
11 lines for each 11-vertex graph.

Frankly I find it strange that you want to convert and store so many
graphs in "human readable" format since you can't humanly look at
so many graphs. It probably takes your next program longer to read
these big files than geng takes to make the graphs. This suggests
it is better to make the graphs as you need them. You can use the
res/mod parameter of geng to make the graphs in smaller portions.

Brendan.


* Susanne Nieß <niess at ma.tum.de> [110315 21:01]:
> The catg problem and the listg problem are two seperate problems. For the catg problem, I found the workaround to use the bash command cat instead (this should work because my files have no header) but the listg problem is still open and giving me headaches. As I am using the -A option with listg (precisely: -A -t -q), the size of the output files should be exactly proportional to the size of the input files. The size of the truncated output files is approximately 2.1 GB so you are must be right with this. I would appreciate an error message in this case in the next version because it took me some time to realize that those files were not correct. I will try to attach some of the input files that I used (the files that caused the problem are of course very big) so you can see if the size of output with "listg -A -t -q" is proportional to the size of the input or why it is not. The number of vertices is 11, the number of graphs is very big because I used geng to make ALL graphs with 11 vertices and the number
> of edges that forms the end of the file name. Apart from the size, the output files from the 64-bit system showed no traces of insensible output as far as I could see but of course it is not very easy to see much in such huge files. Thank you for your help.
>
> unfortunately the mail server refuses to attach my files because they  
> are too big.
>
>> Please clarify: is this the catg problem mentioned in other mail
>> or a separate problem?
>>
>> What was the size of the truncated output files? If it was
>> approximately 2.1 GB, you have probably met the limit of 32-bit i/o
>> functions.
>>
>> Depending on your operating system, you might be able to bypass the
>> problem by piping the output through "cat".
>> Instead of
>>      listg file>outputfile
>> use
>>      listg file | cat>outputfile
>>
>>
>>> Unless you are using the "-a", "-A", or "-W" flags with listg, the
>>> size of its output will depend on the density or sparseness of the
>>> input graphs, since most of the output formats use adjacency lists
>>> instead of adjacency matrices. If you have some files with very sparse
>>> graphs and some files with very dense graphs, the former will have
>>> smaller listg output-sizes than the latter.
>>>
>>> Are there other indicators of insensible output on the 64-bit system,
>>> i.e. strange-looking file contents? (Does the above resolve your
>>> concern?)
>
>
>
> _______________________________________________
> Nauty-list mailing list
> Nauty-list at cs.anu.edu.au
> http://dcsmail.anu.edu.au/cgi-bin/mailman/listinfo/nauty-list