Updates for isbits functionals

[Technici4n]

See JuliaMolSim/DftFunctionals.jl#24.

Currently including the manifest such that I can run CI.

[mfherbst]

Generally less bad than what I expected. I wonder if we should somehow add a mechanism to conserve the functional symbols inside the xc term if we happen to know them ? Like the standard_models.jl functions (LDA(), PBE() and similar) could probably easily do that.

[mfherbst]

That can be changed ...

[mfherbst]

I don't like this because it implies that when explicitly using DftFunctionals to make a standard functional such as LDA exchang (as opposed to a DispatchFunctional) a different string results, right? Moreover I'm not sure the default returned string(f) is super nice (especially when we have dual type parameters) ... but perhaps that we should fix inside DftFunctionals by providing good show functions for all functionals ?

[Technici4n]

Here is an example:

Without duals:

PbeExchange{Float64, Float64}(0.804, 0.21951497276451704)

With duals:

PbeExchange{Float64, Dual{ForwardDiff.Tag{Main.var"##239".ForwardDiffWrappers.DerivativeTag, Float64}, Float64, 1}}(0.804, Dual{ForwardDiff.Tag{Main.var"##239".ForwardDiffWrappers.DerivativeTag, Float64}}(0.21951497276451704,0.0))

[mfherbst]

Case in point, that's not super useful. But we can fix this with a custom show in DftFunctionals. In fact what we could do is actually re-introduce the identifier function, that employs knowledge of the parameter values to return the appropriate libxc symbol ? Or at the very least something like PbeExchange(β=0.804, γ=0.2195) (note rounding).

[Technici4n]

Note that for a custom functional, we would previously report something like pbe_x_custom, which I don't find super useful, and loses part of the info. My thought process was thus:

• For exact reconstruction, JLD2 will be able to reconstruct the object exactly anyway, nothing special needs to be done.
• The identifier was mostly used to give some info to users, e.g. when printing a model or basis. So for the standard DispatchFunctional you'd see the identifiers. But if the user is calling DftFunctionals directly I expect them to be an "expert" and thus be able to deal with the raw display.

that employs knowledge of the parameter values to return the appropriate libxc symbol

Could be done as well

[mfherbst]

Could be done as well

Yes and should not be too hard :)

[Technici4n]

We could, but is it relevant if any non-standard parameter choice will just be printed as pbe_x_custom or similar?

[mfherbst]

If we have only a print function that for those we could print the actual parameter values. So you have something more specific where possible (just e.g. gga_x_pbe) and something less specific for the rest PbeExchange(β=..., γ=....). I think that would be very useful.

[Technici4n]

@niklasschmitz pointed out that we could use https://fluxml.ai/Functors.jl/stable/

[mfherbst]

If it's not too heavy as a dependency and sufficiently stable as a package, I'm happy wtih it. But in my experience there is few worse things that commiting on too many, too brittle helper packages, that we need to undo or fix later.