Modify neighbor list to handle multiple cutoffs.

[chrisiacovella]

When implement aimnet2, we found that we needed the neighbor list to have have 2 cutoffs, a short range one for the local interactions and a longer one used for the charge and dispersion.

As originally implemented, the neighbor list only supported a single cutoff. After some exploration, the output of the neighbor list is negligible in terms of memory footprint, which definitely simplifies the approach we can take (and just focus on efficiency).

The way I implemented this is that the neighbor list will take a dict of cutoff values; r_ij and d_ij are calculated as usual (from the pairlist that was enumerated already), and then we just loop over the cutoffs, calculating the appropriate masks. Since the memory footprint is so small, instead of returning a single instance of PairListOutput, I return a dict of these, where keys that match the input keys for the cutoff.

This should make it both flexible and still easily readable. The BaseNetwork constructor will populate this cutoff dict automatically from the following parameters, if defined (dispersion and coulomb are optional):

• maximum_interaction_radius,
• maximum_dispersion_interaction_radius,
• maximum_coulomb_interaction_radius.

We might want to rename maximum_interaction_radius to maximum_local_interaction_radius or something of that sort to make it more explicit.

Within the Core of the NNP itself (specifically _model_Specific_input_preparation), we can access the pair list outputs for a specific input just by giving the parameter key, e.g., :

pairlist_output = pairlist_output["maximum_interaction_radius"]

This avoided having to create any new variables that may not be used by all naps and this will be much clearer than indexing into a list (which I initially did).

Questions

• Should we rename maximum_interaction_radius to maximum_local_interaction_radius? We can do this in a non-breaking way in the pydantic model by making an alias between the two parameters (so we could use either parameter name in the input file; I just think local might be clearer internally).

Status

• Ready to go

[wiederm]

Thanks, that is great! I think that is fine for training, since we are precalculating everything anyways. Are there changes to the toml file?

[chrisiacovella]

Thanks, that is great! I think that is fine for training, since we are precalculating everything anyways. Are there changes to the toml file?

for existing potentials this won't change toml files. Toml files will only change if we define additional cutoffs.