Preventing atomic overlaps or unphysical high-energy configurations in production melt–quench runs for glass formation

[tanmoy_paul]

I’m training an on-the-fly ML force field for a melt–quench glass-formation workflow where, at each temperature, I run NVT (Nosé–Hoover) then NpT (Parrinello–Rahman + Langevin) for ~10 ps each (60 atoms system), training completed for 300–1500 K and extending to 3000–5000 K. When I transfer the trained model to a 2×2×2 supercell for production—melt at 5000 K followed by NpT quench to 300 K—the 5000 K melt exhibits atom overlaps/unphysical bonds. What minimal, proven practices prevent these high-energy unphysical configurations in production? Concise tag ranges/recipes that consistently stabilize high-T melts on larger supercells would be very helpful.

[andreas.singraber]

Hello!

Unfortunately, we cannot provide a "on-size-fits-all" solution (i.e. list of INCAR tag values) for training which will always result in a stable and reliable force field for all possible application cases. However, we try to collect all our knowledge on our best practices Wiki page (which admittedly is somewhat convoluted now and is already scheduled for restructuring). Please have a look, you will probably find some hints that should be helpful in your case. What I would immediately suggest is to further increase the temperature within your training data. Since you intend to run production MD simulations at 5000K you should aim at an even higher temperature in your training data. This should improve the stability of the force field at the production temperature, in particular, if you move to larger supercells. The reason is that the larger the simulation box is the higher are the chances that locally the temperature exceeds anything already seen in the training data and your force field runs into extrapolation, leading to unphysical artifacts.

All the best,
Andreas Singraber

[tanmoy_paul]

Hello,

Thank you for the helpful guidance.

I have a quick clarification regarding high-temperature sampling. As I push the on-the-fly training to higher temperatures (above ~4000 K), I observe that the on-the-fly “ERR” metrics in the MLFF log tend to increase steadily, e.g.

ERR … 8.57E−02 5.82E−02 1.01
ERR … 8.68E−02 5.83E−02 1.03 (…)

My understanding is that this is expected as the phase space broadens at high T, and that what ultimately matters for reliability is the refit accuracy/validation error (and subsequent stability tests), rather than keeping these on-the-fly “ERR” values small at all times. In this context: is it acceptable to allow a higher on-the-fly ERR at high T if the goal is to collect more rare/high-energy configurations to improve stability at the production temperature?
and another thing to clarify taht is, for production MD at a given temperature, should I keep the same thermostat/barostat parameters (e.g., LANGEVIN_GAMMA, LANGEVIN_GAMMA_L, PMASS) as used during training at that temperature, or can/should these be tuned independently for production once the MLFF is finalized? I’m trying to understand how strongly these choices affect stability vs. the underlying MLFF quality.

[andreas.singraber]

Hello!

Yes, you are correct, it is expected that with increasing temperature the RMSEs will also increase, basically, because there is more "spread" in the data. Therefore, it is often useful to also compare the line STDAB between lower and higher temperature runs. There, you will find the standard deviations of energies, forces and stress of the training data (see definitions here). The next VASP version (6.6.0) will include "normalized" RMSEs in the ML_LOGFILE (see here) which lets you monitor this more easily.

Hmm, I am not aware that the effect of modified thermostat/barostat parameters on stability was ever investigated. My initial guess would be that there should be (almost) no effect if you perform some moderate tuning. However, the situation may change if you make large changes: imagine the parameters would change in such way that lattice degrees-of-freedom oscillate much more than in the training data. Then this could maybe give rise to instability issues due to more extrapolation.

Hope this helps!

All the best,
Andreas Singraber

[tanmoy_paul]

Hello, thanks! this makes sense. I now checked the STDAB lines at high temperature and they also increase gradually (e.g., energy/force/stress STDAB ≈ 3.08E−01 / 5.88E−01 / 3.98E+00 and rising). In practice, should I simply continue the high-T on-the-fly runs to collect diverse/rare configurations even if STDAB (and the reported RMSE) grow, or does this indicate I should modify the training protocol? If modification is recommended, could you suggest a simple high-T strategy (e.g., splitting into shorter fixed-T chunks, adjusting the Bayesian threshold/selection aggressiveness, or other settings) that helps keep the on-the-fly training stable and avoids drift while still capturing rare events?

[andreas.singraber]

Hello!

We generally recommend to use "heating" runs (TEEND > TEBEG) instead of multiple runs with a fixed set of temperatures. So I would suggest to use your latest training data set (copy last ML_ABN to ML_AB) and continue training with a heating run using a target temperature well above the desired temperature of production runs. The best practices Wiki page mentions as a rough guideline to pick 30% above application temperature, i.e., this would correspond to 6500K in your case. This sounds a lot to me, maybe even 5500K is enough to stabilize the force field. Since you have already included 3000 to 5000K in your data you could continue training the remaining 500K in a heating run from 5000 to 5500K. Errors and standard deviations will most likely increase but should not show an abrupt change (which would hint at a phase transition or something worse happening in your MD simulation). If the resulting force field is better but still not as stable as hoped I would increase the target temperature once again. Only if this also does not help I would advocate for tuning some of the ML-related parameters (see here).

All the best,
Andreas Singraber