juliamolsim / atomscalculators.jl Goto Github PK

Probably a finite difference test. The test in ACEbase has served me well over the years:

https://github.com/ACEsuit/ACEbase.jl/blob/main/src/testing.jl

It is great for debugging and can also be automated. For something like DFT where forces are inherentily noisy it might be less well suited.

To implement both simple and parameterized assembly at the same time I tried to do

@generate_interface function AtomsCalculators.potential_energy(sys, calc::SitePotential, args...; kwards...)  ... 

this fails with

LoadError: Could not determine calculators type
in expression starting at ...

Similarly as with AtomsBase I find the specification of what exactly is the interface could be made clearer. In my case I missed the promote_force_type discussion. It's kind of there but very hidden and it really isn't clear that this is something that a new calculator should implement. Just an example.

No rush to address this until the interface has settled a bit but eventually I would appreciate a discussion how to make this as simple and as clear as possible.

@generate_interface function AtomsCalculators.potential_energy(...)

is accepted while

@generate_interface function potential_energy(...)

fails even if potential_energy is imported.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Can we please rename this to just Testing and not export it?

AtomsCalculators.Testing 
AtomsCalculatorsTesting
AtomsCalculators.AtomsCalculatorsTesting 

@JuliaRegistrator register

Currently the tests library cannot be used with DFTK because the error tolerances are not consistently applied. For example

https://github.com/JuliaMolSim/AtomsCalculators.jl/blob/master/src/submodules/AtomsCalculatorsTesting.jl#L46

fails for crude numerical parameters in DFT calculations. We should make a pass on that.

I suggest to add an interface for energy_difference(sys1, sys2).

For very large systems computing an energy-difference can be problematic due to roundoff errors. This arises in particular during Geometry optimization - linesearches then just tend to fail even if progress is being made. In JuLIP I had an energy difference that had a fall-back to just "energy minus energy" but for special potentials one could do something cleverer. Even summing the site energy differences is sometimes significantly more robust than the difference of the energies.

Maybe not a high priority, but I wanted to make a note.