[CP2K:37] Wrapping cp2k

[Juerg Hutter]

Hi

it is implemented, see

MOTION%MC ENSEMBLE : PROGRAM (TRADITIONAL|GEMC_NVT|GEMC_NPT|VIRIAL)

GEMC = Gibbs Ensemble Monte Carlo

For published applications see

  McGrath MJ, Siepmann JI, Kuo IFW, et al.
Simulating fluid-phase equilibria of water from first principles
JOURNAL OF PHYSICAL CHEMISTRY A 110 (2): 640-646 JAN 19 2006

  McGrath MJ, Siepmann JI, Kuo IFW, et al.
Vapor-liquid equilibria of water from first principles: comparison of 
density functionals and basis sets
MOLECULAR PHYSICS 104 (22-24): 3619-3626 NOV-DEC 2006

It should now work with most methods (Fist/KG/QS), but
Matt can certainly give you more information.

If you still want to use an external wrapper you can use
the F77 interface to CP2K by Fawzi.

best regards

Juerg

----------------------------------------------------------
Juerg Hutter                   Phone : ++41 44 635 4491
Physical Chemistry Institute   FAX   : ++41 44 635 6838
University of Zurich           E-mail: hut... at pci.uzh.ch
Winterthurerstrasse 190
CH-8057 Zurich, Switzerland
----------------------------------------------------------


On Fri, 4 May 2007, Toon wrote:

>
> Hi,
>
> I would be interested in using the Gibbs ensemble technique of
> Panagiotopoulus to study first order phase transitions with cp2k. I
> have no clear idea of what the mc capabilities in cp2k are, but as far
> as I can see, the Gibbs ensemble is not implemented. Instead of adding
> yet more lines of code that implement such a feature, I would like to
> consider another option.
>
> Would it be difficult to let cp2k read coordinates (, velocities, cell
> parameters, changes in connectivity, added molecules, removed
> molecules, ...) for each time step from the stdin, and let it
> calculate on the fly the corresponding energy, gradient, temperature,
> virial, pressure, ...? This would make it easy to move the md/mc part
> to an external program which would offer many advantages:
>
> * The external program does not have to be written in the most
> efficient way, because it is only doing a minor part of the
> computational job. It could be any high level scripting language with
> a good array support (e.g. python with numpy). This would hugely
> facilitate the implementation of complex MC/MD/Whatever schemes and it
> offers a flexibility that can never be obtained with any kind of input
> file syntax.
>
> * The external program could feed more than one cp2k program at the
> same time, which is particularly useful for the Gibbs ensemble
> technique.
>
> * Moving parts of cp2k (in this case the motion part) to a higher
> level language is in general good idea since the same algorithm in a
> higher level language counts less lines. (read: less bugs, easier to
> maintain, platform independent, no compiler misery.)
>
> The implementation should not modify anything to the existing code, it
> only adds a new RUN_TYPE. The external program could still call cp2k
> with a conventional input file, but with RUN_TYPE set to 'IO' or
> something similar. This should imply that cp2k reads the
> configurational changes from the input and writes the energy-related
> information to the output, with a well-defined and compact protocol.
> This protocol should somehow be flexible towards future extensions,
> without becoming a bottleneck.
>
> What do you think of this idea? To make things easier, you are invited
> to reply, quoting one of the following lines, followed by your
> comments:
>
> * Good idea, I'll implemented this right now.
> * Good idea, but do it yourselves. We would be happy to include your
> contributions in the main code once it works.
> * Good idea, but do it yourselves and it might take a very long time
> before this will be a part of cp2k.
> * Bad idea. :-(
>
> have a nice weekend,
>
> Toon
>
>
> >
>