New minimal representation

[ubikpt]

Hello. Your work is very interesting, congratulations! I'm trying to understand the algorith checking the code and your paper "Identification of and symmetry computation for crystal nets" (2003, Delgado-Friedrichs & O'Keeffe) (section 4). but I get confused when we get to the 'new minimal representation' (I think in the code this is the function 'minimalImage'). In the paper this representation is:

1 2 1 0 0
1 2 0 0 1
1 3 -1 0 0
1 3 0 0 -1
2 3 -1 -1 0
2 3 -1 0 0

but when I trace the code execution, the result of the function 'minimalImage' is:

1 2 0 -2 0
1 3 0 0 0
1 3 -1 -1 0
1 2 1 -1 0
2 3 -1 2 1
2 3 -1 0 0

It's also strange that the result I get executing the program is '1 2 0 0 0 1 2 1 0 0 1 3 0 0 0 1 3 0 1 0 2 3 0 0 1 2 3 0 1 1', but in the paper the resulting key is "1, 2, 0, 0, 0, 1, 2, 1, 0, 0, 1, 3, 0, 0, 0, 1, 3, 1, -1, 0, 2, 3, -2, 0, 1, 2, 3, -1, -1, 1"

I'm probably overlooking something, but would be grateful to get any feedback you could give me.

Luis Costa

[odf]

Hello Luis! Good catch. My lazy answer would be that the paper describes a slightly simplified version of the method and thus does not come to the same result. I don't recall if that was done deliberately at the time (in which case it should certainly have been noted in the paper) or if we found a problem later on. What I do recall is that an earlier implementation would occasionally produce shift vectors with fractional entries in the final key, so a change had to be made to avoid this. I'd have to read both the paper and the code again in detail to understand the differences.

The critical parts here are the first few functions in invariant.js, up to and including triangulate(). There are a number of small decisions to be made within those functions that can influence the outcomes, and I've been very careful to ensure consistency between the different implementations of the method, but apparently lost consistency with the paper. If you have any further questions, especially about that part of the code, do not hesitate to ask.

As for the diverging result of minimalImage(), since this is only an intermediate result, I'm assuming I did not try very hard to make it match what's in the paper.

[ubikpt]

Thank you very much for your reply Olaf ! I did some more experiments with your code. For example I hardcoded the minimal image reported in the paper and the program produces the same key as with the original code. I think the different minimal image that is computed in the program is caused by a different choice of base vectors. I can follow your paper until the point it mentions finding translations of the equilibrium coordinates (these translations are defined by both a mapping of vertices and a mapping of edges). From what I understand this is implemented in the functions translationalEquivalences and translationalEquivalenceClasses. My trouble starts with the choice of 'base vectors. I think I need to review my algebra lessons from the university days :-) I also changed the code to show all the candidates for the canonical form and I get these:
1 2 0 0 0 1 2 1 0 0 1 3 0 0 0 1 3 0 1 0 2 3 0 0 1 2 3 0 1 1
1 2 0 0 0 1 2 1 0 0 1 3 0 0 0 1 3 0 1 0 2 3 0 0 1 2 3 0 1 1
1 2 0 0 0 1 2 0 1 0 1 3 0 0 0 1 3 1 0 0 2 3 0 0 1 2 3 1 0 1
1 2 0 0 0 1 2 0 1 0 1 3 0 0 0 1 3 1 0 0 2 3 0 0 1 2 3 0 1 1
1 2 0 0 0 1 2 1 0 0 1 3 0 0 0 1 3 0 1 0 2 3 0 0 1 2 3 1 0 1
1 2 0 0 0 1 2 1 0 0 1 3 0 0 0 1 3 0 1 0 2 3 0 0 1 2 3 1 0 1
I'm wondering, all the candidates for canonical form are different from the candidate reported in the paper... Do you happen to have a more recent paper explaining the algorith, maybe with a different example?