Miscellaneous TODO

[cortner]

Collecting a long todo-list for a long-overdue cleanup

• download of example potential files during build or on command
• Atoms FIO: for the time being we won't store calculators, constraints and data; this should be implemented asap; temporary workaround: write a warning if some parts cannot be serialised
• move a generic 3B implementation to nbody
• rename abstractions -> prototypes and move out anything that isn't a prototype... such as apply_defm! ... into Utils?
• use the StaticPolynomials trick to print nicer type information; or possibly resolve the show bug
• Fix performance regression for pair potentials
• fix the analytic hessian for SW
• fix EAM hessian (yet again)
• type instability in MOneBody
• test correctness of SW, EAM, ... against python-ASE implementations => add this only to non-CI tests => done for EMT
• revisit EMT and Gupta Calculators: wait for multi-species rewrite
• redesign the reuse of the neighbour list!: proposal: store each neighbourlist with a key then compare the cutoff when reading from the Dict (instead of making the cutoff part of the key)
• rewrite neighbourlist to store only indices
• for the JuLIP.MLIP IPs we should probably implement partial_energy instead of site_energy
• move evaluate, evaluate_d, grad, hess into JuLIP?
• partial_energy and partial_energy_d are not tested properly
• need another pass through build.jl and probably move quite a bit into atoms.jl; also through Constraints.jl
• general framework for allocating temporary arrays and making in-place evaluations with fall-back to the current non-! versions; this will allow to remove some boilerplate code from SHIPs.jl and is also in preparation for multi-threading / a distributed version of JuLIP
• rewrite all calculators in terms of a single Site Potential framework; all done non-allocating
• in particular we should introduce energy!, forces!, etc to be able to re-use temporary arrays. This should help fix some memory leeks in SHIPs.jl and IPFitting.jl
• rattle! should perturb the cell iff it has a VariableCell constraint
• JData has a hard-coded floating point type. this seems necessary because otherwise the kw-constructor doesn't work. probably this is not important, but could be fixed at some point (low priority)
• the Atoms kwconstructor only allows Float64, this is a bad shortcoming that needs to be fixed I think
• NeighbourLists now has site and neigs which are both the same thing!
• fix the dubious benchmark of @analytic vs hand-coded potentials
• thorough documentation and reference of FF preconditioner
• remove @protofun
• remove all strict typing
• consider adding calculator and constraint to type signature to allow type-stable energy, etc calls: DECISION: decided against it - at least for now - since type-stable calls are possible by using energy(calc, at), etc.
• move the sum-of-IPs potential from NBodyIPs to JuLIP
• define dot(coeffs, IPBasis) ??? => decided to call it JuLIP.MLIPs.combine

Redesign of Constraints -> Dof Manager

• pressure should be treated as an external potential rather than a hack into the Variable Cell constraint.
• generalise pressure to applied_stress - implement in new constraints framework
• sort our the problems arising from having a signed volume and unsigned volume; in particular the meaning of pressure will be confusing since it is multiplied by signed volume

Decisions:

• port NBody abstractions to JuLIP and rename NBodyIPs -> APIPs
• for cutoffs: use MultIP or generic wrapper types? In general - take the lessons from NBodyIPs?
• write a comprehensive test suite for all potentials that tests which properties are implemented
• should a momenta update also trigger update_data!?
• how should momenta transform under cell shape changes?
• explore a less hacky implementation of robust energy differences from core JuLIP.
• create functionality to download data files; or create a separate repository for data files
• add fields for charges and magnetic moments for the Atoms => should this go into the generic data? type-stability issues can be easily circumvented with type asserts.
• move fdtests into package?
• Revisit AD again -> checkout zygote!
• add a uniqueZ field to Atoms to enable z2i and i2z maps => it seems for now it is better to keep this in the calculator; it is implement by the ZList and SZList types
• should introduce type parameter into SitePotential{T}, possibly even AbstractCalculator{T}??
• evaluate_dd vs hess => retire hess
• explore allowing arbitrary order of splines?; or move away from splines to polynomials? => LEAVE AS IS
• hessians and preconditioners for VariableCell => moved into separate issue
• Give AbstractCalculator, SitePotential and PairPotential a type parameter T which will usually be Float64; but this will prepare for more effective AD, the possibility of using Float32, and in general make the type signatures in the code much clearer. We need to enforce that T in Atoms and in the calculators in the same. => this is now a separate issue