[ase-users] [ase-developers] ASE calculator interface proposal

[John Kitchin]

Here are a few of my thoughts. They are based on my experiences with Jacapo
and jasp, and how I like/want to run my calculations. Some of them may be
somewhat controversial ;)

* Behavior
  I agree that a calculator should be aware of when a change has occurred
that makes the last calculated values inconsistent with the current state
of the calculator.

* Standard parameters

* kpts
1. Should there be a k-point density parameter? Maybe kpts=3.5 as in
   3.5 \vec k-points per Å^{-1}?

I think this is a good idea. We often use kpts per reciprocal atom instead
of per reciprocal angstrom. maybe (n1) or n1 could refer to one case, and
(n1, 'kppra') to another case. We have a function that calculates this for
us.

a. [(k11,k12,k13),(k21,k22,k23),...]: Explicit list in units of the
   reciprocal lattice vectors

You should also be able to specify cartesian coordinates for kpts.


2. Should there be a way to get a reasonable number of k-points for
   the given cell?

It is hard to see how this is possible. How would the way know if you had a
slab, or atom, non-periodic boundary conditions in some dimension? The
requirements for metals are very different than insulators.

I have been interested in building a "heuristics.py" module that would
attempt to codify that knowledge, and would be able to determine for
example what your geometry is, guess what type of material it is, etc...

* xc
I think you should specify explicitly every time the functional. But a
compromise could be a user-defined default.

* smearing_method
I think you should specify explicitly every time the smearing method.
Different choices are relevant and sometimes inappropriate for different
systems. But a compromise could be a user-defined default.

Would the tetrahedron method with or without Blochl corrections fall in
here?

This should be flexible, in VASP for example there are 6 discrete options,
and a 7th Methfessel-Paxton order N, where you specify N.

* width
I think it is typical to use 0.1-0.2 eV as a default width, but at
http://cms.mpi.univie.ac.at/vasp/guide/node159.html it is suggested the
appropriate value depends on k-points and the material. At
http://cms.mpi.univie.ac.at/vasp/guide/node172.html they suggest sigma
should be as large as possible while keeping the difference between free
energy and total energy (the electronic entropy) below a few meV.

* nbands
I don't see a reason to require this. many codes need it, and would include
it. Maybe some don't use it. Optional sounds fine. It is worth discussing
the difference between a general set method, e.g.:

calc.set(nbands=5)

vs.

calc.set_nbands(5)

The first is nice because it is easy to say

calc.set(**pars)

But the set function is harder to write.

We also wrote our nbands set function to take an additional parameter f
that calculates nbands as:

nbands = int(nelectrons/2 + nions*f)

* ranks
No comment

* Restart
There is another use mode worth discussing. In the following example:

myatoms = Atoms(..., ideal positions)

calc = MyCalculator(arg1, atoms=myatoms, kwargs)
# I greatly prefer this to myatoms.set_calculator(calc)
atoms.get_potential_energy()

1. The first time you run this, a calculation get run.

The question is what should happen the second time you run it. The way I
have written Jacapo, and the jasp calculator is that when output exists
from a previous calculation, it is read in during the creation of
MyCalculator(arg1, atoms=myatoms, kwargs), so that after that line, myatoms
will have the properties of the previous results, and not of the original
definition. After that, the total energy is simply returned, with no
additional calculation. This allows me to write one script for running a
job and getting the results.

An alternative approach would be that the calculation is rerun every time
you run the script.


* Implementation
Common base class for all calculators: Calculator. Takes care of file
read/write logic, handles setting of parameters and checks for state
changes.

I have a hard time seeing how to generalize this. I have worked on two
calculators where I spent a lot of time tracking state changes. It works
different ways in each calculator. Jacapo has one large dictionary that
holds most parameters, but I still found it necessary to have a whole
module of code to test for changes. Vasp.py has a handful of dictionaries
for different classes of parameters, strings, ints, float, exp, etc... I
have found I need specialized code for comparing list-like and dictionary
parameters and it is fragile, but getting more robust.

* Additional thoughts
1. I would like to see a framework for pre and post-run hooks in
calculators. This would enable us to have some sanity checks, search for
similar calculations, etc... before running, and do error checking after
running, or database entry, integration with version control, report
writing, etc...

2. I would really like to see the standard way to run a calculation be:

with MyCalculator(...) as calc:
    calc.do_something()

For calculators that run in a directory, this is a very nice way to
automate changing into the directory, running your code, and ensuring that
you change back to the working directory when it is done, or if there is an
exception.

This would also solve some problems with open file handles if it was
standard to do:

with open(myfile, mode) as f:
    do some file io

I admit, this is a python 2.6+ feature. I did not use this feature in
Jacapo, but if I did it would have avoided many instances of open netcdf
file handles. I use this feature in jasp extensively. It serves my needs
there well; however, there may be disadvantages I have not seen yet.

3. The run mechanism was not discussed. Maybe every calculator should have
a calculation_required function, which returns True or False, and a
calculate function that actually runs the calculation. I often like to
modify the calculate function, e.g. to automatically submit a job to a
queue system. I currently do this by monkey-patching, but maybe there is a
better way. I have never figured out if a decorator is the way to do this.

4. .calculator.rc ?
Since users may have preferred default settings that reflect their own
work, could we have an rc file, perhaps calculator specific, to set
defaults?

I use this in jasp to modify how calculations are run and submitted to the
queue. you could even have a hierarchy of local, user and system rc-files.

5. uuid/metadata
I think each calculation should have some metadata stored with it that
includes at a minimum the user, date created, and a uuid. Maybe other data
is relevant too. The reason for a uuid is to tell later if one copy of a
calculation is the same as another calculation, and also perhaps to create
an index of all your calculations.

6. A calculator should have a function that only writes out input files (if
they are needed).

John

-----------------------------------
John Kitchin
Associate Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu



On Wed, Jan 23, 2013 at 4:54 AM, Jens Jørgen Mortensen
<jensj at fysik.dtu.dk>wrote:

> Hi!
>
> I wrote a proposal for how I think a good ASE calculator should behave.
> Please take a look:
>
> https://wiki.fysik.dtu.dk/ase/development/proposals/calculators.html
>
> All ASE calculators should behave similarly if there is no good reason
> for them not to. This should make it simpler for both users and
> developers. The goal is to have ASE calculators that share more code and
> are more uniform to use and test.  Also it should be a lot simpler for
> someone to write a new interface for his or her favourite DFT-code.
>
> The proposal is at an early stage - it currently contains a lot of open
> questions (there are 14 questions).  I'd like to hear your comments and
> your answers to the questions.  If you feel a responsibility for one or
> more of ASE's calculators then try to think about how the proposal will
> fit to "your" calculator.
>
> Jens Jørgen
>
>
> _______________________________________________
> ase-developers mailing list
> ase-developers at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.fysik.dtu.dk/pipermail/ase-users/attachments/20130123/2edfe436/attachment.html>