In any case, I am encountering segfaults when using this predictor with MMAPS as well. The error occurs after the second "touch" command, i.e. during the second "Finding best structure…" step. With debug flags enabled, the error is:
Array out of range: -1/0
I get this with the latest beta (with and without -DSLOWENUMALGO) and with the stable version.
has one 0.5 missing at the boldfaced character.
If your want the rocksalt structure (sorry I incorrectly guessed what you wanted) then your lat.in should be
That lat.in file was directly based on the rocksalt_lat.in file in the examples folder. Still, I tried converting it with
cellcvrt -rr < lat.in
as suggested. The output of this program looks the same to me, and gets the same segfault when used as lat.in:
Sorry for the delay (busy time)!
The problem is that your lat.in has atoms that overlap (so the code is confused about which kind atom should be on some site).
Your lat.in should be:
You can double-check for overlaps with
cellcvrt -rr < lat.in
(-rr means remove redundant) and you will see that your 2 sites get reduced to 1.
The above lat.in does not have that problem.
thank you for looking into this and spotting the error in my earlier structure. This error was mine and is not in the examples folder. However, I experience the same segfault with the lat.in you supply, and indeed every other lat.in that I have tried with the electrostatic predictor.
Can you confirm that you were able to
Initialise MAPS or MMAPS using the -ks=es argument
Generate the first structure and write an energy file
Touch "ready" and generate a second structure?
This is where it always falls down for me. I can generate multiple structures before any energies are written. The problem comes when generating structures after energy has been read.
The error seems to be caused in predes.c++ when "inlat" is set to -1 and this is used as an index for str.atom_type. This is in the ElectroStaticPredictor::get_energy function definition.
I notice that in predrs.c++ which_atom values of -1 are skipped over as spectator atoms, which is equivalent to "inlat". However, with the electrostatics predictor I get the -1 value of inlat even in a system with no "spectator" atoms.
As best as I can follow the chain backwards:
"inlat" = -1, used as array index in str.atom_type :arrow: ERROR
-1 was default return value of which_atom (xtalutil.c++) given an atom_pos of size zero
atom_pos of size zero means the lattice is empty
lattice is obtained when ElectroStaticPredictor is initiated from the ClusterExpansion object
It’s not clear to me why the ClusterExpansion object is getting screwed up on the second step but it only seems to be a problem when using -p=es. In any case, it now looks more like a bug or user error than a compilation error.