Wrapping cp2k

Toon Toon.Ver... at gmail.com
Fri May 4 16:19:36 UTC 2007


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




More information about the CP2K-user mailing list