Add support for Torchsim

[orionarcher]

Summary

This PR adds support for TorchSim, namely:

• Utilities to convert the live TorchSim objects (e.g. TrajectoryReporter) into configurable schema with equivalent features
• Input and output schema for integrate, optimize and static functions
• Makers for integrate, optimize and static jobs

NOTE: this PR uses StrEnum's which are not supported in python 3.10, see #1334

Additional dependencies introduced (if any)

• torchsim>=0.5.0
• python>=3.11

Checklist

Work-in-progress pull requests are encouraged, but please put [WIP] in the pull request
title.

Before a pull request can be merged, the following items must be checked:

• Code is in the standard Python style.
  The easiest way to handle this is to run the following in the correct sequence on
  your local machine. Start with running ruff and ruff format on your new code. This will
  automatically reformat your code to PEP8 conventions and fix many linting issues.
• Doc strings have been added in the Numpy docstring format.
  Run ruff on your code.
• Type annotations are highly encouraged. Run mypy to
  type check your code.
• Tests have been added for any new functionality or bug fixes.
• All linting and tests pass.

Note that the CI system will run all the above checks. But it will be much more
efficient if you already fix most errors prior to submitting the PR. It is highly
recommended that you use the pre-commit hook provided in the repository. Simply run
pre-commit install and a check will be run prior to allowing commits.

[esoteric-ephemera]

Some general comments besides the ones on specific lines:

• The TS prefixing in makers, enums, etc. is confusing given that TS is probably more familiar as "transition state" than "torchsim" - can you change this to TorchSim?
• Are you envisioning this being added as a separate (as its currently implemented) or additive module to the existing forcefields stuff? If the latter, the schemas would have to be merged for the job outputs

[orionarcher]

The TS prefixing in makers, enums, etc. is confusing given that TS is probably more familiar as "transition state" than "torchsim" - can you change this to TorchSim?

Good call.

Are you envisioning this being added as a separate (as its currently implemented) or additive module to the existing forcefields stuff? If the latter, the schemas would have to be merged for the job outputs

I think this should be a separate module. It would be really messy to integrate it with the existing forcefields stuff. TorchSim generally expects many -> many calculations (list[structure] -> list[structure]) and has different output files and such.

[JaGeo]

@orionarcher #1196 ?

[orionarcher]

Encouraging! In that case, let me reframe. It looks like it would be possible, but I anticipate it would be a major headache, one I am reluctant to take on.

Though they both run MLIPs, ASE and TorchSim are different software packages with pretty different APIs. I don't see a major reason to have them share schema or logic. The forcefields module is hewn pretty closely to the ASE schema and embraces the paradigms of that package. While in principle I appreciate they are doing basically the same thing (take in strucuture -> repeatedly evaluate MLIP -> generate trajectory + final structure) so many of the norms and expectations of the software are different that I don't think integration would make either interface any better.

[JaGeo]

The motivation should always be the following:
If you have a similar schema people can replace their current code using forcefields easily with torchsim. This includes larger workflows.

[orionarcher]

I hear you and I am sympathetic to that argument. In this case, I feel there is a tradeoff between the immediate adoptability of the TorchSim interface and it's overall quality. After looking back and forth at the ASE and TorchSim schema for the past 15 minutes, I don't think it's possible to adapt the TorchSim API to fit the ASE schemas without adding complexity, reducing readability, and making the overall API less natural and maintainable.

I would love for users currently using ASE to be able to quickly and reliably switch to TorchSim but it's not clear to me that equating the schemas is the best way to do that. I would be happy to write a transition guide outlining the schema differences and how to transition from ASE -> TorchSim and add it to this PR.

[orionarcher]

@JaGeo @esoteric-ephemera do you have any idea why the abinit tests might be failing here? This seems unrelated to any changes I made wrt TorchSim?

==================================== ERRORS ====================================
_______________ ERROR collecting tests/abinit/jobs/test_base.py ________________
tests/abinit/jobs/test_base.py:6: in <module>
    from abipy.abio.inputs import AbinitInput
../../../micromamba/envs/a2/lib/python3.12/site-packages/abipy/abio/inputs.py:36: in <module>
    from abipy.flowtk import PseudoTable, Pseudo, AbinitTask, AnaddbTask, ParalHintsParser, NetcdfReader
../../../micromamba/envs/a2/lib/python3.12/site-packages/abipy/flowtk/__init__.py:12: in <module>
    from .qadapters import show_qparams, all_qtypes
../../../micromamba/envs/a2/lib/python3.12/site-packages/abipy/flowtk/qadapters.py:311: in <module>
    _EXCL_NODES_FILE = _ExcludeNodesFile()
                       ^^^^^^^^^^^^^^^^^^^
../../../micromamba/envs/a2/lib/python3.12/site-packages/abipy/flowtk/qadapters.py:289: in __init__
    if not os.path.exists(self.DIRPATH): os.makedirs(self.DIRPATH)
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^
<frozen os>:225: in makedirs
    ???
E   FileExistsError: [Errno 17] File exists: '/home/runner/.abinit/abipy'
================================ tests coverage ================================
_______________ coverage: platform linux, python 3.12.12-final-0 _______________

Coverage XML written to file coverage.xml
=========================== short test summary info ============================
ERROR tests/abinit/jobs/test_base.py - FileExistsError: [Errno 17] File exists: '/home/runner/.abinit/abipy'
============= 133 passed, 12 skipped, 1 error in 370.68s (0:06:10) =============

[esoteric-ephemera]

I think you can safely ignore it, can happen with parallel runners and there should be a fix for this in the next release of abipy

[orionarcher]

Other than the unrelated failing tests, I think this is ready to merge? The tests are passing locally and I think all the suggestions are addressed.

[esoteric-ephemera]

Bumped a few comments for your consideration; totally OK if you disagree with the suggestions therein

[JaGeo]

@orionarcher thanks! We now need to fix the tests.

They are failing as the installations need to much cache. We might need to do some cache cleaning after certain workflows or come up with a different idea.

[orionarcher]

Yeah, looks like TorchSim is the straw that broke the camels back. I could split the tests into a separate action but I don't know if that's the most sustainable route.

What would you propose as a solution there? Would you like me to take a swing at it or would you like to try a fix?

[JaGeo]

I don't have a good solution. Separate action sounds good for me for now. I won't be able to do much testing here myself for a couple of weeks.

@esoteric-ephemera do you have any opinion here? Also with regard to usage of action time?

[orionarcher]

I split the TorchSim stuff out into separate tests. It's dependent on torch>=2.7.0 which conflicts with the strict dependency of torch==2.2.0. Memory stuff aside, it's won't work alongside the current ff tests.

I think it should all be good to go now?

[esoteric-ephemera]

Separate workflow action / separate test sounds good to me. Also for the best given the torch version pin needed for some of the MLFFs, as you said @orionarcher

Will take another look through and ping you if I see anything, thanks for your work on this so far!

[JaGeo]

Fine from my side now. Once @esoteric-ephemera is happy, we can merge :)

[orionarcher]

Thanks @esoteric-ephemera and @JaGeo! Looking forward to having this in!

[orionarcher]

@esoteric-ephemera polite bump :)

[esoteric-ephemera]

Have it on my calendar to look by tomorrow!