Output file fixes in HyperDAG backend

[papp-pal-andras]

Two updates needed:

• The number of pins in the first non-comment line seems to be displayed incorrectly, it does not match the number of pin lines in the files below. To be fixed.
• For the lines represented vertices, an extra 0 needs to be added in the third place ("x y z % role of the vertex" -> "x y 0 z % role of the vertex"), in order to sync up with the current file converter/reader of OSP, which interprets the third integer as vertex type.

[anyzelman]

Sorry, what do x y z (and 0) signify in the last bullet?

[papp-pal-andras]

Sorry, what do x y z (and 0) signify in the last bullet?

The current format of the vertex lines is 3 integers and a long comment: "x y z % role of the vertex". x is vertex ID, y is vertex weight, and z is some internal ID of the operation in ALP. Then comes a comment about the vertex's role.

The third integer z is never needed in OSP, but it was still OK to keep it in the file format: previously OSP just read the first two numbers and ignored the rest, & file format allowed to put whatever further info we want afterwards.

Since recently the OSP file reader also looks for vertex types (vector/tensor operation) as the third integer. In order to not have this unneeded ID be misidentified as a vertex type, the row should be replaced by "x y 0 z % role of the vertex", so all vertices have default type 0, and z gets ignored as before.

[djelovina]

@papp-pal-andras can you provide more info to reproduce this error.

I checked hpcg_hyperdags cmake target, which is disabled in the CI.
I have found these related infos

• commit (e91f68d): Modified the test to filter output with sed because "HPCG unit test for the hyperdag backend, which is likely what causes the GitHub CI to fail at present" - suggesting the HyperDAG output was massive
• commit (607475b): Completely disabled the test on GitHub Actions with the excuse: "The real culprit seems to be going out-of-memory on the GitHub runner"

But what I have noticed that this code crashes immediately on startup with a segmentation fault in the argument_parser destructor before any GraphBLAS code even runs.
@anyzelman