Fixing 2nd order IFCs on ALM Python code

[RicardoCecconello]

Dear Dr. Tadano,

How do we set/fix 2nd order IFCs from an external .xml file on the ALM code for Python (like the FC2XML tag of ALAMODE)?

I've found a way, but it's giving weird results. I optimized only the harmonic case and extracted the IFCs values with

fc2_values, elem2_indices = alm.get_fc(1)

and saved them to .npy files for later use with

np.save("fc2_values.npy", fc2_values)
np.save("elem2_indices.npy", elem2_indices)

For comparison, I saved the .xml file with alm.save_fc("harmonic.xml", format="alamode"). With this, I got the same results (almost identical IFCs and exactly the same residual error) as with the ALAMODE code, for the same structure, data, and conditions. I even ran the ANPHON part and got the same phonon spectrum.

However, when I ran the calculation for a 4th-order model, fixing the 2nd-order IFCs with

alm.freeze_fc(np.load("fc2_values.npy"), np.load("elem2_indices.npy"))

I got a residual error far superior than the one obtained with the ALAMODE code, for the same conditions. With ALAMODE the error was about 3%, while with the ALM code, it was bigger than 200%.

Another thing: if I run the 2nd-order calculation again, with alm.freeze_fc(np.load("fc2_values.npy"), np.load("elem2_indices.npy")), the error becomes 50 times bigger, and the .xml file generated is different from the previous one.

One thing that I discovered is that on every run of the harmonic case, the fc2_values, elem2_indices = alm.get_fc(1) part gets DIFFERENT results, although the .xml files are identical. For instance, elem2_indices gets different pairs of indices each time. Could this be the cause of the problem with the 4th-order calculation?

[RicardoCecconello]

I've found the issue: on alm.define() one should set symmetrization_basis="Cartesian". This way we can read the .npy files and the results are the same.