Alby M.

I've just added a few more notes to the post above with information on how we can go about this, FYI. Regarding stress/virial @asedova, my understanding is that OpenMM doesn't...

Sure--- I think, however, that the science questions that you bring up are fairly decoupled from the software-level interfacing questions, which are fairly mechanical and binary (either they correctly transfer...

Fantastic! Thanks again @sef43 , looking forward to having this! > It shouldn't require any changes to the nequip repo. You steps in the comment above are very clear thank...

@sef43 fantastic! That was quick 😆 , thanks! Regarding the issues, sort of in order: 1. I've now removed on `develop` the explicit dependence of `nequip` on `torch` so that...

> As I understand nequip types are zero indexed and user defined. So there can be multiple types for the same chemical element. This is correct, yes. > The most...

This is great @sef43 !!! :tada: Thanks so much for putting this together. A small point--- is there a reason to always use the O(N^2) neighborlist? It looks from the...

One other piece of relevant information to: https://github.com/sef43/openmm-ml/blob/nequip/openmmml/models/nequippotential.py#L98-L100 `nequip.scripts.deploy.load_deployed_model` will call `torch.set_default_dtype` appropriately based on the metadata of the deployed model (in the current development/future stable) version of `nequip`, so...

Hi @schiotz , At one timescale does the the example training not converge? You're right about the change, which we will look into, but I want to be sure that...

Hi @giotre , Thanks for your interest in our code! Yes, that sounds correct— extxyz is our prefered input format and it supports arbitrary per-atom and per-graph fields. `nequip` supports...

Hi @yzjin , Thanks for your interest in our work! You should currently use the `develop` branch of `nequip`, any branch of Allegro, and pair_allegro [here](https://github.com/mir-group/pair_allegro/tree/multicut).