[ase-users] [ase-developers] ASE calculator interface proposal
Jens Jørgen Mortensen
jensj at fysik.dtu.dk
Wed Jan 23 16:43:14 CET 2013
Den 23-01-2013 15:51, John Kitchin skrev:
> 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 ;)
Thanks for your comments and ideas. I don't think they are that
controversial. My comments are below.
>
> * 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.
What do you mean "kpts per reciprocal atom"?
> 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.
I don't see how we can make that work also with the kpts keyword. Are
you suggesting another keyword? One could just do
kpts=np.dot(atoms.cell, cartesian_kpts.T)/(2*np.pi).
> 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 agree. This is too difficult.
> 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.
Maybe each calculator could have its own default. I don't like user
defined defaults - unless you put those in you script.
> * 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?
Yes - definitely.
> This should be flexible, in VASP for example there are 6 discrete
> options, and a 7th Methfessel-Paxton order N, where you specify N.
We could name those 'methfessel-paxton-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()
I like that way of attaching the calculator to the atoms. I'll put that
idea in the proposal.
> 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.
I think that is a good way to do it.
> 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.
As you say, it can be done, so let's do it once and put it in the base
class. I'm sure we can find a solution for Vasp also.
> * 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.
I think we should soon drop support for Python 2.4 and 2.5. As soon as
our Niflheim cluster moves to 2.6 :-)
I have to run now. I'll comment on the rest of your email later.
Jens Jørgen
> 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 <mailto: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
> <mailto:ase-developers at listserv.fysik.dtu.dk>
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-developers
>
>
>
>
> _______________________________________________
> 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/b240a343/attachment.html>
More information about the ase-users
mailing list