Concentration restricted enumeration yields equivalent structures

[magnusrahm]

Dear enumlib developers,

I have used enumlib for a while (with great joy!) but since I updated to the most recent version, enumlib does not behave as I expect when doing concentration restricted enumeration. Consider, as a minimal example, concentration restricted enumeration for an fcc lattice (just a slight adaptation of the struct_enum.in.fcc.fixed_concentrations script in the support folder):

fcc
bulk
0.50000000     0.50000000      0.0000000        # a1 parent lattice vector
0.50000000      0.0000000     0.50000000        # a2 parent lattice vector
 0.0000000     0.50000000     0.50000000        # a3 parent lattice vector
 2 -nary case
    1 # Number of points in the multilattice
 0.0000000      0.0000000      0.0000000    0/1   # d01 d-vector
    1 2   # Starting and ending cell sizes for search
0.10000000E-06 # Epsilon (finite precision parameter)
full list of labelings
# Concentration restrictions
0 2 2
0 2 2

The output file looks like this:

 # <fortpy version="3" revision="247"></fortpy>
fcc       
bulk
 0.50000000      0.50000000       0.0000000        # a1 parent lattice vector
 0.50000000       0.0000000      0.50000000        # a2 parent lattice vector
  0.0000000      0.50000000      0.50000000        # a3 parent lattice vector
    1 # Number of points in the multilattice
  0.0000000       0.0000000       0.0000000        # d01 d-vector, labels: 0/1
 2-nary case
   1   2 # Starting and ending cell sizes for search
 0.10000000E-06 # Epsilon (finite precision parameter)
Concentration check:
    T
Including only structures of which the concentration   of each atom is in the range:
Type 1:    0/   2 --    2/   2
Type 2:    0/   2 --    2/   2
full list of labelings (including incomplete labelings) is used
Equivalency list: 1
start   #tot      HNF     Hdegn   labdegn   Totdegn   #size idx    pg    SNF             HNF                 Left transform                          labeling
          1         1       1        0        0           1   1    48   1  1  1    1  0  1  0  0  1      1    0    0    0    1    0    0    0    1   1
          2         2       1        0        0           2   1    48   1  1  1    1  0  1  0  0  1      1    0    0    0    1    0    0    0    1   0
          3         3       4        0        0           1   2    12   1  1  2    1  0  1  0  0  2      1    0    0    0    1    0    0    0    1   11
          4         4       3        0        0           2   2    16   1  1  2    1  0  1  0  1  2      1    0    0    0    1    0    0   -1    1   11
          5         5       4        0        0           3   2    12   1  1  2    1  0  1  0  0  2      1    0    0    0    1    0    0    0    1   01
          6         6       3        0        0           4   2    16   1  1  2    1  0  1  0  1  2      1    0    0    0    1    0    0   -1    1   01
          7         7       4        0        0           5   2    12   1  1  2    1  0  1  0  0  2      1    0    0    0    1    0    0    0    1   00
          8         8       3        0        0           6   2    16   1  1  2    1  0  1  0  1  2      1    0    0    0    1    0    0   -1    1   00

Note that I get multiple structures with just one of the elements. This happens also for larger supercells. If I remove the last three lines of the input file (the concentration restriction) I get the expected output, i.e., only one pure structure. It does not seem like this behaviour is restricted to the pure structures, because among the mixed structures, there seems to be groups of structures that are equivalent.

I'm quite sure that this was not the behaviour in a previous version of enumlib, because I happened to have an old enumeration around that I could run again, and the output was different. Unfortunately, I failed to track down which version that was. I did some attempts to check out to previous versions of enumlib to obtain the expected behaviour, but that was in vain, which makes me a bit suspicious that there could be something weird with my system rather than the code (but I thought it could be worth notifying you if it is indeed a bug). I've compiled the code with gfortran on Ubuntu 18.04.

Best regards, Magnus Rahm

[glwhart]

Thanks Magnus, we'll take a look at this.

[wsmorgan]

Found the bug. The problem was introduced by an improper setting of the number of arrows to be used in the enumeration. In this case it was clearly meant to be 0, however that wasn't being set properly so the code was treating the enumeration like it had an extra degree of freedom. This will be fixed in the next push.