Bug: MPSet/MagneticStructureEnumerator: different Magmoms/Spins in INCAR than those in the Structure/POSCAR

[fraricci]

I noticed this bug while ago while using the MagWF in atomate and discussed it with @mkhorton at that time. I see that this bug is still present in the last pmg version.

Here is an example of what happens with Mn₂FeWO₆.

st = rester.get_structure_by_material_id("mp-107827")
mo = MagneticStructureEnumerator(st)

#some magnetic elements do not get spin assigned
In [36]: [sp.spin for sp in mo.ordered_structures[7].species]
Out[36]: [5, -5, None, None, None, None, None, None, None, None]

In [21]: MPRelaxSet(mo.ordered_structures[7]).incar['MAGMOM']
Out [21]: [-5, 5, 5, 5, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6]

#all magnetic elements have a spin assigned
In [36]: [sp.spin for sp in mo.ordered_structures[6].species]
Out[36]: [-5, -5, 5, 5, None, None, None, None, None, None]

In [21]: MPRelaxSet(mo.ordered_structures[6]).incar['MAGMOM']
Out [21]: [-5, -5, 5, 5, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6]

This affects the atomate MagWF and potentially the new one in atomate2 (https://github.com/materialsproject/atomate2/pull/432): some of the magnetic configurations won't be actually computed and some will be computed multiple times.

I think the issue comes from the fact that the spin of magnetic elements is defined only for some of the sites. Therefore the MPRelaxSet.incar() is assigning the default to those without spin. Probably, a fix should be added in the enumerator. For the FM order, it explicitly sets the other elements spin to zero, but this does not happen for the other ordering. Whereas the incar(), since it does not find a spin, it does what it normally does: assigning the default.

I'm tagging here @mattmcdermott. Having these things fresh in his mind could comment and help finding the best fix.

[mattmcdermott]

Hi @fraricci,

Thanks for bringing this up. Can you confirm this only applies to compositions with 2 or more magnetic species, and only for orderings of the type afm_by_XX? Regarding this:

some of the magnetic configurations won't be actually computed and some will be computed multiple times.

I see from your example why there will be duplicate orderings computed. Specifically, when running afm_by_XX with default magmoms the same in both the input set and enumerator, this will cause afm_by_XX to resolve to one of the afm orderings. I'm not sure I would call this an "error" in pymatgen or atomate, though. I could see, for example, a user's default magmoms to be different than what is currently provided, such that afm_by_XX will not reduce to afm when input sets are created. If we wanted to fix this in the new atomate2 workflow, however, we could catch duplicate orderings to save some compute time.

I still do not see why this would result in certain magnetic orderings NOT being computed, though. I may be missing something... if you have an example, please let me know so I can investigate further!

[fraricci]

Thanks for commenting on this.

I'm not sure if this only applies to afm_by_xx. Potentially to fim_by_xx as well? But, I can confirm that this happened to me with compounds (corundum family) with more the 2 magnetic species. Also, I'm considering a case where only default magmoms and automatic mode for selecting the strategies are used.

The example I showed above actually shows better why certain magnetic ordering are NOT computed. The MagneticStructureEnumerator returns the following magnetic order:

In [36]: [sp.spin for sp in mo.ordered_structures[7].species]
Out[36]: [5, -5, None, None, None, None, None, None, None, None]

with only the Mn having a magnetic moment, the others set to None (Note: I'm assuming this means that they should be ~0)

I would expect to have the above configuration to be computed, but the following one is computed instead, because the not assigned/None MAGMOMS are set to default by the incar():

In [21]: MPRelaxSet(mo.ordered_structures[7]).incar['MAGMOM']
Out [21]: [-5, 5, 5, 5, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6]

Therefore the configuration with index 7 is not computed. Incidentally, in some case this configuration could be equivalent to another one in the list provided by the MagneticStructureEnumerator, hence we end up with duplicates.

Now, I'm assuming that if the MagneticStructureEnumerator returns None it means "no magnetic moment" or "0". Is this assumption wrong? And instead, a None means "replace with a default"? The latter sounds weird to me. Also because, if I well remember, the "FM" strategy explicitly set to zero the other species. Behavior that I'd expect from the other strategies as well.

Hope this clarify better my concern.

[mattmcdermott]

Now, I'm assuming that if the MagneticStructureEnumerator returns None it means "no magnetic moment" or "0". Is this assumption wrong? And instead, a None means "replace with a default"?

Yes, "replace with a default" is my interpretation as the intended behavior, hence why I didn't think of this as a bug. Furthermore, if the default magmoms for generating the INCAR differ from the default magmoms for the enumerator, then you would not end up with duplicate orderings. For example, one can imagine that the default magmom for the second magnetic element in your example is actually defined to be 4.9 in the input set, giving:

In [21]: MPRelaxSet(mo.ordered_structures[7]).incar['MAGMOM']
Out [21]: [-5, 5, 4.9, 4.9, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6]

^ which is not technically an exact duplicate of the ordering indexed 6 in your original post, although I suppose it may relax to the same thing...

Anyway, I think the overarching question here is this: in the afm_by_XX configuration, is it desirable to have the other magnetic elements with magmoms of zero? My thinking is that it wouldn't be. Perhaps @mkhorton can provide his viewpoint on the intended behavior, as I am only a casual user of this code and just wanted it available in atomate2 :)

[fraricci]

Ok cool, I think we are on the same page now.

To put it in a different way, the overarching question is: what does None really means for the MagneticStructureEnumerator.

To me it should mean zero. Otherwise leaves to much arbitrariness to the resulting spin configurations, depending on the user's default. My assumption is that the user can only define a custom magmom but for those species that "receives a spin" from the MagneticStructureEnumerator.

Quickly made up examples here: same AFM configuration from MagneticStructureEnumerator: [5, -5, None, None, None, None, None, None, None, None]

User 1 has MAGMOMS Fe=0, W=0: he ends up having a AFM [5, -5, 0, 0, None, None, None, None, None, None]

User 2 has MAGMOMS Fe=5, W=0: he ends up having a FiM: [5, -5, 5, 0, None, None, None, None, None, None]

I'm also not an expert user of this code, so I could misunderstand how it works and should be used correctly.

I think @mkhorton can help us here.

Thanks!

[mattmcdermott]

@mkhorton not sure if you are busy, but do you have any thoughts on the difference between None and 0 in the enumerated orderings?