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

[Marcin Dulak]

On 01/24/13 10:47, Jussi Enkovaara wrote:
> On 2013-01-23 17: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.
> Hi,
> I give below also some comments.
>
>>> 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 think the k-points density parameter is closest one can do here.
> That should take care of the different boundary conditions and cell
> sizes, however, the different requirements for metals, magnetic systems
> etc. are something that the user has to know.
>
>>> * 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.
>
> As a personal preference :-), I do not like that heavy calculations get
> run when one creates an object (even though some GPAW functionality
> behaves this way), but that user has to explicitly request calculation
> by calling a function.
>
> Also, I think that the above approach brings up the question whether
> one attaches atoms to a calculator, and asks calculator to determine
> physical quantities for this atomic configuration, or attaches
> calculator to atoms and asks physical quantities from atoms object, i.e.
> which comes first, atoms or calculator? There is already some
> controversy as some quantities are requested from atoms (energy,
> forces), and some from the calculator (wavefunctions, densities).
> Personally, I do not have strong feelings over this matter, asking atoms
> is maybe a little bit more physics oriented (calculator is just black
> box providing numbers), on the other hand asking calculator would unify
> things in the sense that everything is requested from calculator
> (quantities available from MD calculator are of course quite different
> than the ones availabe from DFT calculator).
>
> One question that should maybe also discussed is if there should
> standard way to specify the command/binary to be executed when
> calculator is run. Some calculators (e.g. Siesta) request a python
> script containing the actual command to be executed, while other
> calculators (e.g. Castep) ask for a shell command. I prefer the shell
> command, as it is easier to specify e.g. number of CPUs within a batch
> job script (at least for casual user who is used to do something like
> 'mpirun -np 8 siesta'). People wanting to script everything may prefer
> the first option...
i think the best way is to have a choice here.
For example aims interface 
(https://trac.fysik.dtu.dk/projects/ase/browser/trunk/ase/calculators/aims.py) 
offers you the choice of
providing the run command as an init argument *run_command*
or reading the AIMS_COMMAND environment variable.
Some run commands may get quite involved: 
https://listserv.fysik.dtu.dk/pipermail/ase-developers/2012-November/001601.html

I like the related idea that there is a standard calculator method that 
verifies if the code
has been installed and configured (i'm using *get_command* - see again 
the aims interface).
In the tests one calls this method and raises NotAvailable to skip the test
(see 
https://trac.fysik.dtu.dk/projects/ase/browser/trunk/ase/test/aims/aims_cmdline.py)

>
> Best regards,
> Jussi
> _______________________________________________
> ase-developers mailing list
> ase-developers at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-developers
>
>