Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Starting point for one potential solution to #240
MultiCalc
s, e.g. for MD with one calculator, this become a huge number of unnecessary calls, although maybe extra operations have a minimal impact?The main issue this approach has is some built in functions, such as
get_stress
, check the shape of the value returned by the calculator, which means currently this throws an error.Without overwriting this, I'm not sure this is possible to avoid.
The main other alternative I can think of is to create copies of the
Atoms
objects, each of which has its own calculator.The disadvantage of this would be duplication of potentially quite large amounts of data, but it would ensure all results from calculators are returned in their expected forms, so remain useable by ASE functions.
This implementation would also make it much more readily available for distributed calculations using any of the calculations e.g. MD for MACE and CHGNet with the same settings, if we wanted to offer that, eventually.
In terms of
singlepoint
, we'd want to recombine the twoAtoms
objects when writing out, but it would allowgeomopt
structures to diverge, for example