MACE input parameters questions

[turbosonics]

1. Some input parameters are ignored.
   I'm trying to run test training using my own geometry from local GPU node cluster.

I clearly put --device='cuda' and '--E0s="average" somewhere below in my job submission file. But when I check log file, training used cpu, not gpu. Plus, the training job couldn't recognize my E0s setting, so the log file shows E0s=None, and the training crashed.

Also, I set

    --r_max=6.0 \
    --num_channels=64 \
    --max_L=1 \

in the middle of input parameters in my job file, but for some reason they are ignored in the log file as num_channels=None, max_L=None.

I really have no idea why this happens, I can only guess the order of input parameters matters. Is this correct? If this is true, where can I find the proper order of input parameters? Or am I doing something wrong in other parts?

2. Training with multiple loss functions
   I have extxyz file that I converted from VASP OUTCAR using ASE, which looks like following:

192
Lattice="13.23607 0.0 0.0 0.0 13.23607 0.0 0.0 0.0 12.701706" Properties=species:S:1:pos:R:3:forces:R:3 energy=-1377.94922141 stress="0.038239342157800636 6.865660038471585e-08 7.115320403506914e-07 6.865660038471585e-08 0.03823900511630784 -2.995924380423964e-07 7.115320403506914e-07 -2.995924380423964e-07 0.03594279135795014" free_energy=-1377.94922141 pbc="T T T"
Li       6.61803000       0.00000000       9.52628000      -0.00001600      -0.00001000       0.00003200
Li       6.61803000       0.00000000       3.17543000      -0.00000800      -0.00001800       0.00001600
Li       6.61804000       6.61803000       6.35085000      -0.00000600       0.00000700       0.00000000
Li       0.00000000       0.00000000       6.35085000      -0.00003500       0.00000700      -0.00001300
...

Using that extxyz input file data, can I train the model from the scratch using energy, force, and stress as loss functions, while using loss coefficient scheduler? Problem is, it looks like I can set up only single value in loss parameter, so I don't know how can I achieve that... For example, I tried:

    --compute_stress \
    --compute_forces \
    --energy_key="energy" \
    --forces_key="forces" \
    --stress_key="stress" \
    --loss="weighted" \
    --energy_weight=1.0 \
    --forecs_weight=1.0 \
    --stress_weight=1.0 \

But this does not work, as I see those from log files:

...
compute_stress=False, compute_forces=True
...
Selected the following outputs: {'energy': True, 'forces': True, 'virials': False, 'stress': False, 'dipoles': False}
...

I want the training to print out rmse and mae of energy per atom, forces, and stress. How can I achieve this?

In the same way, if I want to use four loss functions (energy, force, stress, and charge per atoms), how should I set up the input parameters?

[pobo95]

1. I think you should check your Pytorch and CUDA. When CUDA isn't working, MACE tries to train use CPU.

2. How about change
   --compute_stress
   to
   --compute_stress="ture"
   it works for me.
   and you can check the options uisng 'help' option.

[turbosonics]

Thanks! First issue was made by wrong order of input arguments. For second issue, the question is, how can I use multiple loss functions of my interest, for MACE training, like if I want to train with energy, forces, virials, stress, and charges.

[bernstei]

First issue was made by wrong order of input arguments.

Except that argparse doesn't care about option order

[turbosonics]

Thanks to notify. Hmmm then maybe I think I forget some input arguments. Since I follow the arguments of "--help", the training works.

[ilyes319]

Hey,

1. For your first question, can you please share your full log file.
2. You can do all of these things. To train on stress, use the following options:

    --loss="stress" \
    --compute_stress=True \
    --stress_weight=100 \
    --stress_key='stress' \
    --error_table='PerAtomRMSEstressvirials' \

MACE currently does not support charges.

[pobo95]

@turbosonics

1. For me, I tried to use same volume of cell when training and calculating isolated energy. (around 15 x 15 x 15 cubic cell)
2. Maybe you sholud code what you want.

[bernstei]

FWIW, I think I'm much less worried that @gabor1 about this.

1. I think you should always do gamma point only for isolated atoms. You want a nonperiodic system, so any overlap of wavefunctions from periodic images is unphysical anyway, so you might as well ignore it. Also, unless you actually have examples of atoms spanning the range from bonded to fully in the vacuum elsewhere in your fitting data, the potential is going to be seriously extrapolating when it goes to isolated atoms, and I don't think sub-meV differences in the isolated atom energies will make a difference. And even if it wasn't, I doubt there's any way you could keep perfect k-point consistency between those configurations.

2. The same is essentially true for spin. I think the only sensible things you can do is keep the spins consistent, which I think means in practice always keeps to spin=0, or always try to get the minimum spin for any configuration. And in either case, as I argued in 1, the potential will be extrapolating between the bonded configurations and the isolated atoms, and I don't see how it'd care if it's going from several eV of cohesive energy in the fully bonded case to precisely what much smaller number it's going to for the isolated atom (which lacks any bonding - the spin will probably only change the energy by of order an eV at most, I guess, although this should be easy to check).

[turbosonics]

@gabor1 @bernstei @ilyes319 @wcwitt @pobo95 Thank you for great answers and discussions.

And I have a question/suggestion for MACE.

I have a little experience with parameterization of other empirical force fields. From there, to include the reference state energy of single atom, I used geo opt of monocrystal, and divide the potential energy by number of atoms. For example, I optimized unit cell structure of the most stable Si monocrystal phase and divide the potential energy by number of atoms in the unit cell, then include it in the training set as reference energy of Si. Same goes to molecules, I can get optimized structure of F2 or H2 in the box, then divide it by 2.

I wonder, would it be possible for MACE to use such ways to get the reference energy of target atoms from molecule or monocrystal structure? Instead of using a single atom in the box, IMO this looks a little better way...

The feature of "divide energy" can be useful for other features, if someone wants to provide heat of formation of specific molecules or structure, or reaction barrier, to the training set. Though the current MACE can't include those features in the training set, but maybe there could be an easy way to implement them in the training set, with features like "dividing energy"...

But anyway, thanks for all answers and suggestions!

[bernstei]

By construction (I believe) MACE will return E0 for an isolated atom. You can use whatever reference you want (and people do), but if it's not the isolated atom you'll get the wrong result if you evaluate the single atom. MACE will fit the "bonding" energy, i.e. relative to the sum of the E0s, and those can be "true" cohesive energies or energies relative to some reference.

[gabor1]

@turbosonics it's not as simple as for empirical potentials. Those functional forms are designed to be smooth and to go to a constant that is higher than the ground state when atoms are far away (think of an EAM with an exponential density function and a quadratic embedding function). What you chose as reference doesn't matter very much, it ends up as an additive constant that has no consequences for your simulation. In contrast, highly flexible MLIPs behave very differently. Lots of people fit them with data only in the condensed phase. the highest accuracy is obtained when the fitted function is small in absolute magnitude, so for this reason it is natural to take as the target function the difference between the actual energy and the average energy of the training set (this is called "mean shift" in the ML literature, or "normalisation"). But in this case there is no reason for the isolated atom to have a much higher energy. This can be OK, if you never simulate high temperatures, atoms are never far from the training set. But we found that it leads to lots of instabilities when you go further away (which is the interest of my group), for example you can easily have a situation that isolated atoms can have a significantly lower energy than the supposed lowest energy phase. why wouldn't they? there is no data to say otherwise. So we found a neat way of preventing this kind of thing, without having to incur any other expensive data fitting. We do not do mean shifting, but require analytically that MACE gives a set energy back on the isolated atom, which we provide (by computing it with the target method as discussed above). The fitting is thus a bit harder, because we require the MACE model to reproduce the entire binding energy (not just the deviation from average) for condensed phase configurations and smoothly go to the set E0 value for isolated atoms. We find that such models are extremely stable for MD. Of course this property does not depend on the exact value you give for E0, you can give anything that is many eVs higher than the binding energy, and it would still work, and as long as you never study processes that lead to isolated atoms, you will not be harmed by the discrepancy. there can be other consistent strategies for setting these reference energies, but when you have many elements (and nowadays we are interested in making models that apply to many elements, in principle to all elements), requiring the isolated atom to be correct is simple and very physically motivated.

the behaviour of the MACE code that it analytically returns the E0 for the isolated atom is controlled by the "model" keyword, and "MACE" setting does this. If you use "ScaleShiftMACE" that will not do this, but allows the shifting to the mean of the data and will give slightly lower loss values, but lead to less stable potentials, I don't recommend it.