[Nauty-list] malfunction of listg

[Susanne Nieß]

Thank you for your help. I was already able to see beginning and end of 
a file but lacked the possibility to count the lines.

The reason why I want such big files in "human readable" format is 
simple: In fact, they are not to be read by humans but by the programs 
that I have written. As I started them long before I heard of you they 
do not read your format. Now I replaced many of my programs by programs 
from the nauty package because your programs are very much faster but 
there are some tasks for which I didn't find a suitable tool and still 
have to use my own programs (some enhanced by using nauty instead of my 
own isomorphism test function):

1. for a special set of subsets of the nodes, examine the induced 
subgraph on each subset and compare to a file of graphs for isomorphics

2. for each graph of a file, try every way to assign colors (without 
regard to the question if there are any edges in a color class) in a 
specified way (most simple: one color class one vertex, the other color 
all others), save one per isomorphism class but count isomorphics and 
save the numbers in an additional file in matlab sparse matrix format as 
a matrix where the rows are the numbers of the uncolored graphs and the 
columns the colored graphs

3. make all r-uniform hypergraphs with n vertices

4. make all r-uniform hypergraphs with n vertices and additional color 
structure and examine numbers like in 2.

The "human readable" output that listg -Atq makes is much easier to 
convert into my format than the output of geng and I thouht I just would 
not have to write a program that reads graph6 format and converts it to 
something my programs would understand.

Thank you for your help. I was already able to see beginning and end of 
a file but lacked the possibility to count the lines.

The reason why I want such big files in "human readable" format is 
simple: In fact, they are not to be read by humans but by the programs 
that I have written. As I started them long before I heard of you they 
do not read your format. Now I replaced many of my programs by programs 
from the nauty package because your programs are very much faster but 
there are some tasks for which I didn't find a suitable tool and still 
have to use my own programs (some enhanced by using nauty instead of my 
own isomorphism test function):

1. for a special set of subsets of the nodes, examine the induced 
subgraph on each subset and compare to a file of graphs for isomorphics

2. for each graph of a file, try every way to assign colors (without 
regard to the question if there are any edges in a color class) in a 
specified way (most simple: one color class one vertex, the other color 
all others), save one per isomorphism class but count isomorphics and 
save the numbers in an additional file in matlab sparse matrix format as 
a matrix where the rows are the numbers of the uncolored graphs and the 
columns the colored graphs

3. make all r-uniform hypergraphs with n vertices

4. make all r-uniform hypergraphs with n vertices and additional color 
structure and examine numbers like in 2.

The "human readable" output that listg -Atq makes is much easier to 
convert into my format than the output of geng and I thouht I just would 
not have to write a program that reads graph6 format and converts it to 
something my programs would understand.



On 03/15/11 12:32 PM, Brendan McKay wrote:
> 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.