Regarding KUSP integration

[ipcamit]

Hi,
I was going through my notes from previous meeting, and I am little unclear on what Matsciml specific enhancements/functions @laserkelvin wanted to see in KUSP. Can we concretize the idea here so that I can test and contribute those enhancements in the repo? (I could not find you on slack!)

[melo-gonzo]

Hey @ipcamit, what we need most would essentially be a translation layer to align the initial data format, KUSP input format, and matsciml model input. For example, we support DGL, PyG, and point cloud based models in matsciml, which require different conversions depending on the dataset being used. Internally to matsciml, we have various transforms that convert between the different representations, as well as options for applying periodic boundary conditions, and some other data transforms such as frame averaging.

As far as moving forward goes, I can plan to look at an initial implementation for the conversions as this is matsciml specific. It would be helpful to have you help review to make sure the standards align with what KUSP expects once it's implemented.

It would be helpful to know more about what data types are expected to initially start with. The KUSP example here starts with an xyz file and outputs energy and forces. Is there expected to be a scenario where we simply load single samples from a dataset to predict energy/forces in a static configuration? Also, where can I find more information on how to run verification checks pragmatically? I have found good overviews here but am unsure how exactly the checks are run. I see there is some more information here but again I am not sure exactly what the commands are doing.

[laserkelvin]

Sorry I'm completely bandwidth starved these days - I'll need to read both your messages and my notes again to circle back on thsi.

[ipcamit]

No issues, I think it is now much more clear to me. Will make first draft as soon as possible and update you both

[melo-gonzo]

I updated the example kusp/example/serve_matsciml_models.py to use our built-in transforms and data utils. What I've done is just one way of going about this, and could be reworked in the future. This should make swapping between DGL and PyG models straight forward.

I've also updated the example to use ForceRegressionTask, which handles both energy and force predictions, and I've added in a FAENet example (PyG model).

[ipcamit]

That looks great. I will go though it more thoroughly next week when I get back from conferences. I think it might make sense to add more LAMMPS support, as it is most common use case. Let me mull it over and discuss it with my group. Then I can comment on above changes and we can integrate them in both KUSP and matsciml.