[ase-users] [ase-developers] ASE calculator interface proposal
Marcin Dulak
Marcin.Dulak at fysik.dtu.dk
Wed Jan 23 17:25:19 CET 2013
On 01/23/13 16:43, Jens Jørgen Mortensen wrote:
> 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.
i prefer no defaults: different programs disagree even to LDA: currently
we have VASP uses PZ LDA, FLEUR MJW LDA,
ELK program provides PZ LDA, but only spin-paired implementation, most
other physics programs use PW92 LDA,
and most chemistry codes VWN LDA (available as VWN5 in gaussian
http://www.gaussian.com/g_tech/g_ur/k_dft.htm).
I think the only one we could agree on, if we have to, is PBE.
Dropping a default for xc would help to accommodate other methods
present in other programs, like Hartree-Fock, etc.
The way aims interface works now: one must specify a functional and the
keyword must be exactly as specified in aims manual.
>
>> * 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.:
i prefer nbands optional; many programs just don't have that concept.
It is also difficult to set the number of bands automatically because
they depend on the number of valence electrons
in the pseudopotentials codes. One would have to run the program once,
limiting it somehow to one iteration, extract the number
of valence electrons from the output (if printed), set the number of
bands according to the needs and run the calculation again.
Alternatively we would need to parse the pseudopotentials and calculate
the number of valence electrons.
For programs that set the number of bands automatically it is usually
better not to touch that, VASP gives
for example unstable total energies with respect to the number of bands:
http://cms.mpi.univie.ac.at/vasp-forum/forum_viewtopic.php?4.9673
Marcin
>>
>> 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
>
>
>
> _______________________________________________
> 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/a997ee79/attachment.html>
More information about the ase-users
mailing list