Dispersion without PBC

[trdurrant]

Summary

At the moment, I am seeing errors when I try and use a dispersion correction, when the system is not periodic. The following would be an example:

from ase.io import read
from ase.build import molecule

from janus_core.calculations.single_point import SinglePoint
from janus_core.calculations.geom_opt import GeomOpt


h2o = molecule('H2O')

sp_mace = SinglePoint(
    struct=h2o,
    arch="mace_mp",
    device="cpu",
    model="small",
    calc_kwargs={"default_dtype": "float64",}
)

energy = sp_mace.run()["energy"]

print("Energy without D3", energy)

sp_mace = SinglePoint(
    struct=h2o,
    arch="mace_mp",
    device="cpu",
    model="small",
    calc_kwargs={"default_dtype": "float64", "dispersion":True},
)

energy_with_d3 = sp_mace.run()["energy"]

print("Energy with D3", energy_with_d3)

Which produces the following output for me:

Arch mace_mp
/home/tom/test/venv_test/lib/python3.12/site-packages/e3nn/o3/_wigner.py:10: UserWarning: Environment variable TORCH_FORCE_NO_WEIGHTS_ONLY_LOAD detected, since the`weights_only` argument was not explicitly passed to `torch.load`, forcing weights_only=False.
  _Jd, _W3j_flat, _W3j_indices = torch.load(os.path.join(os.path.dirname(__file__), 'constants.pt'))
cuequivariance or cuequivariance_torch is not available. Cuequivariance acceleration will be disabled.
Using Materials Project MACE for MACECalculator with /home/tom/.cache/mace/20231210mace128L0_energy_epoch249model
Using float64 for MACECalculator, which is slower but more accurate. Recommended for geometry optimization.
/home/tom/test/venv_test/lib/python3.12/site-packages/mace/calculators/mace.py:197: UserWarning: Environment variable TORCH_FORCE_NO_WEIGHTS_ONLY_LOAD detected, since the`weights_only` argument was not explicitly passed to `torch.load`, forcing weights_only=False.
  torch.load(f=model_path, map_location=device)
Using head Default out of ['Default']
Energy without D3 -14.047933366728303
Arch mace_mp
Using Materials Project MACE for MACECalculator with /home/tom/.cache/mace/20231210mace128L0_energy_epoch249model
Using float64 for MACECalculator, which is slower but more accurate. Recommended for geometry optimization.
/home/tom/test/venv_test/lib/python3.12/site-packages/mace/calculators/mace.py:197: UserWarning: Environment variable TORCH_FORCE_NO_WEIGHTS_ONLY_LOAD detected, since the`weights_only` argument was not explicitly passed to `torch.load`, forcing weights_only=False.
  torch.load(f=model_path, map_location=device)
Using head Default out of ['Default']
Traceback (most recent call last):
  File "/home/tom/test/venv_test/new_test.py", line 30, in <module>
    energy_with_d3 = sp_mace.run()["energy"]
                     ^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/janus_core/calculations/single_point.py", line 367, in run
    self.results["stress"] = self._get_stress()
                             ^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/janus_core/calculations/single_point.py", line 297, in _get_stress
    return self.struct.get_stress()
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/atoms.py", line 918, in get_stress
    stress = self._calc.get_stress(self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/calculators/abc.py", line 35, in get_stress
    return self.get_property('stress', atoms)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/calculators/calculator.py", line 519, in get_property
    self.calculate(atoms, [name], system_changes)
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/calculators/mixing.py", line 99, in calculate
    self.results = self.mixer.get_properties(properties, atoms)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/calculators/mixing.py", line 54, in get_properties
    get_property(prop)
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/calculators/mixing.py", line 35, in get_property
    contribs = [calc.get_property(prop, atoms) for calc in self.calcs]
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/torch_dftd/torch_dftd3_calculator.py", line 145, in get_property
    dftd3_result = Calculator.get_property(self, name, atoms, allow_calculation)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/test/venv_test/lib/python3.12/site-packages/ase/calculators/calculator.py", line 524, in get_property
    raise PropertyNotImplementedError(
ase.calculators.calculator.PropertyNotImplementedError: stress not present in this calculation

Platform

Linux 6.6.87.1-microsoft-standard-WSL2 x86_64 GNU/Linux

Version

0.8.5

Python version

3.12.3

[ElliottKasoar]

SinglePoint defaults to calculating the energy, forces and stress, but the D3 calculator hasn't implemented stress for this sort of system, so I'm not sure there's much we can/should do.

(Different MLIPs also handle this differently - mace used to return NaNs, but now returns almost 0s)

You can pass properties="energy" to fix this.

[trdurrant]

I guess there are a few workarounds for this problem, but it would be more user friendly to have a uniform solution for all the calculators janus-core can call. Otherwise it is a bit confusing that it works for some but not others.

Is there a problem that would be caused by modifying the _get_stress function to return 0s for the case of a system with isolated boundary conditions?

(When you say "the D3 calculator hasn't implemented stress for this sort of system" I am a bit confused. I thought it doesn't have a meaning to calculate stress for a non-periodic system in this context, but perhaps I'm misunderstanding)

[ElliottKasoar]

(When you say "the D3 calculator hasn't implemented stress for this sort of system" I am a bit confused. I thought it doesn't have a meaning to calculate stress for a non-periodic system in this context, but perhaps I'm misunderstanding)

Yes, sorry, I mean not implemented in the sense of it not being a valid property within the code, as opposed to other calculators which have "implemented" the property to return 0s, NaNs, etc.

I guess there are a few workarounds for this problem, but it would be more user friendly to have a uniform solution for all the calculators janus-core can call. Otherwise it is a bit confusing that it works for some but not others.

Is there a problem that would be caused by modifying the _get_stress function to return 0s for the case of a system with isolated boundary conditions?

I'm generally pretty hesitant to directly change values a calculator returns. Even if it's well intentioned, you don't want to surprise someone who is used to how a particular calculator behaves for a given system.

[alinelena]

I will catch this in a try: and issue an warning and replace it with zeros and hope the user knows what is doing.