[ase-users] New Calculator Philosophy

[Ask Hjorth Larsen]

Hi Ben,

Am Mi., 26. Feb. 2020 um 22:25 Uhr schrieb Ben Comer via ase-users
<ase-users at listserv.fysik.dtu.dk>:
>
> Hello all,
>
> I'm looking at updating my psi4 calculator and adding new features right
> now, but I want to make sure that what I do falls in line with the new
> philosophy on how calculators should be written. Psi4 has lots of stuff
> built in that only requires simple calls (dipoles, quadrupoles, internal
> geometry optimization, vibrational modes, ect...) that I could easily
> build in ase interfaces for. My question is do we want any of these
> included, or are they outside of the scope of what we want ase
> calculators to do? Particularly, I'm wondering what the status of the
> `get_dipole_moment()` method is, as I know the IR modules depend on it
> but not many calculators have it implemented.

Good questions.

Right now there are many ASE calculator classes that do a lot of code
specific things.  The class has to both communicate with the code,
*and* be an ASE calculator, *and* do any additional convenience things
that someone found to be practical.  Experience shows this is too much
responsibility for one class, so calculators become big and
inconsistent, and often buggy.

The solution is to write components (functions or classes) that only
do one thing each.

For example it's probably useful to have separate functions for these things:

 * Convert atoms into a data structure suitable for the code (let's
call it the "input datastructure")
 * Convert special ASE parameters like kpts/xc into input datastructure
 * Search for pseudopotentials or anything like that
 * Format input datastructure as an actual inputfile (presumably not
applicable to psi4), as an ase.io format if possible
 * Call external program or otherwise trigger calculation
 * Parse/convert outputs to dict (normally also as an ase.io format)

And all those should be independently useable without a calculator.
But the calculator can probably unify them with just 50 lines of code
in total.

As for specific questions like optimizer, vibrations, dipole moment,
this depends...  In general, do the simplest thing.  As long as it is
simple, it can be adapted later.

Functions without side effects are simple, and so are classes which
are initialized once and never change state anymore.  (So calculators
are not simple, which is why they should be as absolutely short as
possible.)

All this text is probably way to general to be truly useful but I felt
compelled to write something.

Best regards
Ask








>
> Thanks,
> Ben Comer
> Georgia Tech
>
> _______________________________________________
> ase-users mailing list
> ase-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users