Machine-learned forcefields: one engine, chosen by configuration

Notes for the campaign that made a machine-learned forcefield run reach its engine without the plug-in knowing which engine that is, and that settled xnns as the single mechanism for them.

The starting point was a job that hung for four hours and died on a torch.load. Getting from there to a working MLFF run turned up a chain of faults, most of which were only reachable because the one before it had been fixed. The notes below record the design that came out of it, and the reasoning that is not visible in the code.

Contents:

• NOTES A – How a model reaches its engine
  • The question
  • What the code used to do
  • What it does now
  • Why not detect the model type
  • The decision: xnns is the mechanism
  • What this leaves
• NOTES B – GPUs, tasks, and what the scheduler is telling us
  • A GPU in the allocation is not a reason to use gpu-code
  • GPU indices are not the scheduler’s indices
  • An MDI run needs two tasks
  • Configuration consequences
• NOTES C – The LAMMPS environment, and what belongs in it
  • LAMMPS must be built with MDI
  • PyTorch is not in the environment file
  • What does not belong here
  • Scripts are deployed, not imported