[WIP] Prototypes for Energy, Forces, Virials

[cortner]

This PR goes with #84 - For the time being I propose to do no more than

• define minimal prototypes as in the first commit.
• document how they are intended to be used. (to be added to the docs)
• possibly provide tests that check for correctness of output, not clear this is needed for a first PR but could be nice to have.
• some default fallbacks; cf Teemu's post below

For now I am leaving out the general calculate prototype and will add it only if there is at least partial agreement on that.

[cortner]

@tjjarvinen -- can you please add a draft documentation page that explains the interface. I think we are more or less on the same page.

[tjjarvinen]

I would actually add here that maybe the default should also include:

function forces!(f, data, calc; kwargs...)
    f .= forces(data, cal; kwargs...)
    return f
end

function energy_forces_virial(data, calc; kwargs...)
    e = energydata, calc; kwargs...)
    f = forces(data, calc; kwargs...)
    v = forces(data, calc; kwargs...)
    return (; :energy=>e, :forces=>f, :virial=>v)
end

etc.

Also, I would say that energy_forces function should be part of the interface too.

[cortner]

Yes, something like that should be added, I forgot to add this to the list at the top.

The reason I didn't yet add it to the code, is I'm not sure which should the default be? Don't we want the codes to implement forces! and then provide a wrapper

forces(sys, calc) = forces!(alloc(...), sys, calc)

[cortner]

regarding energy_forces I'm not sure, couldn't one simply do

E, F, _ = energy_forces_virial

but I dont have a strong view on this.

What about forces_virial and forces_virial!? There are so many variants.

Somehow I'd prefer to focus on a minimal set and the two

potential_energy 
energy_forces_virial!

seems to be the two natural ones to implement.

[tjjarvinen]

No. Not all methods can calculate virial and you want those to throw error. This is the case e.g. in isolated molecules, where virial is meaningless.

[cortner]

One can equally argue that the virial is simply zero in that case since the energy doesn't change when you change cell shape.

[tjjarvinen]

If you do constant volume simulation, you don't want to spend time to calculate virials. So, calling a method that calculates virials is a waste.

For me energy_forces and energy_forces_virial are the ones we should have, others are special cases.

[cortner]

If you do constant volume simulation, you don't want to spend time to calculate virials

It has essentially zero extra cost if you already compute the forces.

But ok, let's assume this. then why energy_forces and not energy_forces!? For electronic structure or large MLIPs models it doesn't matter but e.g. for a fast empirical potential the allocation might matter.

And why should potential_energy not have a separate implemenation? In many codes, evaluating only energy could be much faster than energy and forces.

[tjjarvinen]

I meant for the combinations only energy_forces and energy_forces_virial and the non-allocating ones for them.

It has essentially zero extra cost if you already compute the forces.

For our ACE code it is not essentially free. It takes a considerable amount of time to gather the final value.

[cortner]

I don’t think you are right - let’s benchmark this and stop arguing here.

[cortner]

I think this debate had become unproductive. I’m closing the PR and will open a new one with a more succinct proposal.