Something about MC project
Matt McGrath
obfis... at gmail.com
Wed Mar 2 07:02:18 UTC 2011
Hello Igor.
I have looked a little more closely at the MC section of your input
file, and I've noticed a couple things.
First, it's strange that everything dies without an error message.
Can you run the tests in tests/MC/regtests? In particular, try to run
MC_QS.inp. If you can't, there is something wrong with your
installation. If you can, try changing MC_QS.inp to be the input file
you want (for example, first try to change the electronic structure
part, then change the molecules, and then change the MC section).
This will help narrow down where the problem is arising.
Secondly, I noticed that the ensemble you have chosen is GEMC_NVT. No
doubt you choose that because of the NVT in the name, but this isn't
the ensemble you want. GEMC stands for Gibbs Ensemble Monte Carlo,
which is a method that uses at least two simulation boxes to simulate
phase equilibria. So, you're telling MC that you want to do something
with two simulation boxes, but it's only finding the file for one
simulation box. This would cause it to crash. "traditional" is the
one you are looking for (this allows you to run both NVT and NpT...the
only difference is the percentage of volume moves tried). Take a look
at the canonical.inp regtest, which is also a single box run in the
NVT ensemble.
Something that is also very important is these _MOL keywords you
alluded to. There are a number of input keywords that don't really
have good default values, and so I made them "required" in the input
file (CP2K should die if they are not there). These _MOL keywords are
among them. If you have more than one molecule type, the MC routines
need to know how often you want to sample each type with each move.
For example, PMROT_MOL. If you are doing a simulation of water and
argon, you don't want to waste time trying to rotate argon. So, if
water is molecule type 1 and argon is molecule type 2, the PMROT_MOL
line would look like
PMROT_MOL 1.0 1.0
Now when MC chooses a random number to perform a move on, if it's less
than the first number, it will select a molecule of type 1. If it's
between the first and the second number, it will choose type 2. In
this case, nothing is between 1.0 and 1.0, and all random numbers are
less than 1.0, so it will always choose molecule type 1 to perform a
rotation on. In your system, let's suppose you want to rotate water
30% of the time and glycine 70% of the time. Then, you would have a
line that looks like this:
PMROT_MOL 0.7 1.0
These _MOL keywords are required, because there really is no good
default value, and it can really impact the efficiency of your
simulation. Does that make a little more sense? I would recommend
starting with MC_QS.inp, since it has all the required keywords. You
can look at one of the other input files that has two molecule types
to see which keywords require a value for each molecule type (there's
a few of them).
I hope this helps!
Cheers, Matt
On Mar 1, 10:59 am, Igor Ying Zhang <wenx... at gmail.com> wrote:
> Hi Matt:
>
> Thank you for your kindly and quick reply!
>
> I adopt your suggestion to split the psf file. However the situation
> doesn't change. The seperated psf files and the corresponding input and
> output files could be found in the attachment.
>
> By the way, what does difference between the keywords of "PMTRANS"
> and "PMTRANS_MOL"? I
> could not understand them clearly based on the brief information in the
> CP2K_INPUT manual.
>
> Best wishes!
>
> Igor
>
> On 03/01/2011 03:42 PM, Matt McGrath wrote:
>
>
>
> > Hello Igor. It seems to me that the problem is arising because you
> > have two molecules in the PSF file. Due to some of the quirks of MC,
> > each molecule must be in its own PSF file (see some of the example
> > inputs in tests/MC/regtest to see how multiple molecules are dealt
> > with). In addition, there should be only one molecule in the .psf
> > file even if there are multiple types of that molecule in the
> > simulation (NMOL tells CP2K to use the molecule specification in
> > the .psf file NMOL times). The TOPOLOGY section should be something
> > like this:
>
> > &TOPOLOGY
> > CONNECTIVITY MOL_SET
> > &MOL_SET
> > &MOLECULE
> > NMOL 1
> > CONN_FILE_NAME topology_atoms_GLY.psf
> > &END
> > &MOLECULE
> > NMOL 1
> > CONN_FILE_NAME topology_atoms_H2O.psf
> > &END
> > &END
> > &END
>
> > where the glycine molecule comes first in the COORD section, followed
> > by the water (if you have multiple molecules of water, they all come
> > after the glycine...if you have multiple glycine molecules, they all
> > come before the water). This is so that MC knows which coordinates
> > belong to which molecule number (since MC moves choose a molecule type
> > at random, and then a molecule number at random, it cares much more
> > about molecules than MD). The molecule name in the .psf file should
> > match the molecule name in the title of the psf file. The psf file
> > will not change, no matter how many molecules of that type you have in
> > the simulation.
>
> > I hope this helps.
>
> > Cheers, Matt
>
> > On Feb 28, 10:22 am, Igor Ying Zhang<wenx... at gmail.com> wrote:
> >> Dear all:
>
> >> Recently, I want to use the Montecarlo module of CP2K to do some
> >> comformation analysis. At first time, I try a system only contains 1
> >> glycine and 1 water. However, the cp2k terminated abnormally without any
> >> error information. The attachment pleas find the input file and the
> >> corresponding psf file.
>
> >> Any suggestions are wellcome :)
>
> >> Best wishes!
>
> >> Igor Ying Zhang.
>
> >> gly_h2o_1.psf
> >> 3KViewDownload
>
> >> gly_h2o_1_mc.inp
> >> 2KViewDownload
>
>
>
> PBE_DZ_PP.inp
> 2KViewDownload
>
> PBE_DZ_PP.log
> 42KViewDownload
>
> topology_atoms_GLY.psf
> 2KViewDownload
>
> topology_atoms_H2O.psf
> < 1KViewDownload
More information about the CP2K-user
mailing list