Stress kernels and other kernel related changes

[jonpvandermause]

This is a step toward NPT on-the-fly training with the GP. Summary of major changes/additions:

mc_simple

• 2, 3, and 2+3-body stress kernels (stress/energy, stress/force, stress/stress)
• Simultaneous calculation of energy, force and stress kernels to accelerate prediction (i.e. no d1, d2 arguments; see efs_energy and efs_force functions)
• "efs self" kernel to facilitate the calculation of uncertainties on energies and stresses
• To do (in a future PR): implement efs kernels in mc_sephyps, mc_mb_sepcut; eliminate d1, d2 arguments from all kernels

test_stress_kernels

• Careful test of all mc_simple energy, force, and stress kernels, including tests of the fractional pre-factors.
• TODO: apply this test to all existing kernels

two_body_mc_simple, three_body_mc_simple

• This is a first draft for the future kernel class. It hasn't been integrated into the rest of the code base yet.

predict

• Simultaneous energy, force and stress prediction (serial and parallel) without redundant kernel calls (see predict_on_structure_efs)
• GP uncertainties on energies and stresses
• To do: accelerate predict_on_structure and predict_on_structure_en

gp_algebra

• efs_kern_vec: computes kernel vectors for energy, force, and stress prediction without redundant kernel calls

ase/calculator

• get_stress method added to the gp calculator
• DFT stresses and energy are now written to structure

ase/otf

• Velocities, temperature and KE are now based on ASE atoms attributes
• Tighter coupling between atoms and structure
• Units corrections (time now reported in ps in the output file)

output

• Periodic cell, stress tensor (with uncertainties), and pressure are now reported in the OTF output file

struc

• positions, cell, and related arrays are now properties. When the positions or cell attributes are reset, all the related arrays (e.g. wrapped positions, cell transpose, etc.) are automatically changed.

[YuuuXie]

I think adding structure to the args here is because the predict_on_structure function assigns energy, forces etc. to the structure.
But I feel we need to re-consider the interface here. Since for other ASE calculator, people just do something like atoms.get_force() etc., if structure is needed to input to the function, the interface will not be consistent with other calculators.

To address this, I think of 2 ways, but there might be better approaches.

1. we can have a separate function like (just give a rough idea)

def set_struc_attr(structure, forces, energies, ......):
    structure.forces = forces
    ....

Then we just call set_struc_attr after predict_on_structure if the structure needs modifying

2. we can add a new function like predict_and_write_to_structure

[jonpvandermause]

The interface as implemented is consistent with the general ASE calculator template described here. Note that our get_forces, get_potential_energy, and get_stress methods take in an atoms object only; the structure object is introduced as an optional input to the auxiliary get_property method.

[YuuuXie]

Actually all the get_forces, get_stress etc. calls get_property, the reason atoms.get_forces() works in otf is that the line 144 (ase/otf.py)

        self.atoms.calc.calculate(self.atoms, self.structure)

called the calculate function, so there is a dict self.atoms.calc.results which has been written the FLARE calculated forces, energy etc. Then when the atoms.get_forces is called, it will just get the value from the results dict without re-calculating of GP, so it's ok at this time if structure=None.

This means that it only works in the otf context. If we want to create a FLARE_Calculator without OTF, and try to use get_forces, the structure has to be input, because at this time results dict is empty, and calculate function needs calling.

But I notice that structure and ASE Atoms are very similar, so probably a better way to do this is just in ASE_OTF let

    self.structure = self.atoms

since they have a lot of common attributes like positions, cell etc. so there should only be some minor changes. may have to think about this. I will try to deal with this in another PR

[jonpvandermause]

Hmm I actually think get_forces, get_stress etc. should still work without giving a structure. If a structure isn't given, the calculate method creates a structure based on the atoms object (see lines 69-73 of ase/calculator, and note that calculate is called by get_property, which sets structure to None if none is given). But I agree this isn't a perfect solution, and it would be better to completely eliminate structure from the ase calculator. This would require adding some extra calculator properties (energy, force, stress uncertainties) and then writing them to the structure somewhere else, probably in a method of ase/otf.