Open breecummins opened 9 years ago
It seems there are several kinds of mix-ups that can result in seemingly inconsistent output.
cd
) to a folder with a different dsgrn.session
file, inadvertently switching which network is being analyzed.I view (2) as being the biggest of these issues, since that seems like a pretty major gotcha. For (1) & (3) perhaps it is possible to make the output contain additional data making mix-ups less likely. It is unclear if this is always desirable though.
Actually, point 1 was not the problem. I index by 0 routinely, not by 1. The problem was confusing the poset value with the index. I still think this is an outstanding issue:
{"poset":[[1],[]],"annotations":[["FC"],["FP"]]}
In the above output, I want the FC Morse set. Its index is 0, but its poset is 1. It is confusing which number I want for the Morse set.
The interpretation of
{"poset":[[1],[]],"annotations":[["FC"],["FP"]]}
is as follows:
There is a partially ordered set (the Morse graph) with two vertices, indexed 0 and 1. The "poset"
value gives us a list of adjacency lists: [[1],[]]
Vertex 0 has one out-edge, pointing to vertex 1. This is the information of the first adjacency list, [1]
.
Vertex 1 does not have out-edges. This is the information in the second adjacency list []
.
The "annotations"
value tells us:
Vertex 0 has the annotation "FC".
Vertex 1 has the annotation "FP".
Interpreting the adjacency list information attached to vertex 0 as instead being a label for vertex 0 leads to typing
dsgrn analyze morseset 1 4689
instead of
dsgrn analyze morseset 0 4689
in order to analyze the Morse set annotated "FC"
, which doesn't work.
I will consider this a bug in the documentation and change it to be more explicit about the list of adjacency lists representation of the poset.
Hey Shaun, here's the full command history and input file that produces the bug.
Command history from brand new terminal:
Input file 6D_TwoWayForcing.txt: