[CP2K:3119] Re: Something about MC project

[Igor Ying Zhang]

Hi Matt:

    Of course, your detailed explanation help me greatly! I will try it 
following your suggestion right now.

Best wishes!

Igor Ying Zhang



On 03/02/2011 03:02 PM, Matt McGrath wrote:
> 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