temperature monitor and thermostat regions

[Axel]

hi all!

here's another cp2k feature question:

it would be extremely helpful to have an option to
monitor 'local' temperatures and apply thermostats
(either a single chain or one chain per DOF) to them.
the case of QM/MM simulations is only one example
where this might be useful.

given the modular nature. it might be worth considering
a similar approach as for constraints/collective variables,
i.e. define a region (e.g. by MOLNAME or INDEX and
with EXCLUDE_QM, EXCLUDE_MM) and then assign
either an output filename and/or a thermostat or some
other way of manipulating positions/velocities in a similar
spirit as the 'fix' command in LAMMPS.
http://lammps.sandia.gov/doc/fix.html

opinions?

axel.

[Axel]

hi again,

i just wanted to bring this topic (again) to your
attention. are there any ideas? the current set of
options with thermostats is a bit limited, so any,
however little, improvement towards the description
from below, would be a big help.

axel.

[Teodoro Laino]

hi Axel,

I'm working on that.. in general on thermostats during these days.
But since this part of the code is pretty old is requiring some deep
rewriting..
Be patient ;-)

Teo

[Axel]

On Sep 24, 1:16 am, Teodoro Laino <teodoro.la...@gmail.com> wrote:
> hi Axel,

hi teo,

>
> I'm working on that.. in general on thermostats during these days.

thanks, that is all i wanted to know.

> But since this part of the code is pretty old is requiring some deep
> rewriting..
> Be patient ;-)

don't worry. i am very much aware that this is digging
deeper, than other suggestion/requests were.

ciao,
axel.

> Teo
>

[Teodoro Laino]

Hi Axel,

the last step (2) of the THEMOSTATS mail :

On 26 Sep 2007, at 14:28, Teodoro Laino wrote:
> Next thing to come in few days:
>
> (2) Possibility to have a user-defined region for thermostats..

is now completed. It is possible to define (in a similar way to
constraints (LIST, RANGE, QM, MM, MOLNAME)) regions of the system on
which apply thermostats. Please have a look at the several new
regtests added to see how this feature
works (mainly in tests/Fist/regtest-11/ and QMMM/SE/regtest).

It was a real nightmare, believe me, especially due to the particle
distribution in parallel to get an efficient
thermostat scheme.
I f you find any strange behavior, please send me a small input file
showing the problem.

At the moment the temperature that can be applied on the several
regions is always the same..

We could discuss about the possibility to have different regions to
different temperatures, but I'm quite
skeptical whether it will really work!

teo

p.s.: I will add soon also the possibility to dump on file the
temperatures of the different thermostats (tomorrow should be in)..

[Axel]

On Nov 17, 10:41 am, Teodoro Laino <teodoro.la...@gmail.com> wrote:
> Hi Axel,

hi teo,

i'm finally getting around to testing this
and it looks pretty darn good.

> the last step (2) of the THEMOSTATS mail :
>
> On 26 Sep 2007, at 14:28, Teodoro Laino wrote:
>
> > Next thing to come in few days:
>
> > (2) Possibility to have a user-defined region for thermostats..
>
> is now completed. It is possible to define (in a similar way to
> constraints (LIST, RANGE, QM, MM, MOLNAME)) regions of the system on
> which apply thermostats. Please have a look at the several new
> regtests added to see how this feature
> works (mainly in tests/Fist/regtest-11/ and QMMM/SE/regtest).
>
> It was a real nightmare, believe me, especially due to the particle
> distribution in parallel to get an efficient
> thermostat scheme.

i understand. the codes where i had so far had the (negative)
fun to mess with thermostats, were using a replicated coordinates
strategy. infinitely simpler, but only feasable for all-qm
calculations.

> I f you find any strange behavior, please send me a small input file
> showing the problem.

not so far, but i can imaging, there is a bunch of trouble
lurking when using constraints, particularly, if they cross
thermostat region boundaries.

> At the moment the temperature that can be applied on the several
> regions is always the same..

> We could discuss about the possibility to have different regions to
> different temperatures, but I'm quite
> skeptical whether it will really work!

i guess there are some people that would be interested in this,
but i would worry about this when they actually do ask.

what would be the cherry on of the cream on _my_ pie would
be that the MASSIVE flag (i.e. one thermostat per DOF) would
not be only a global option but a per region option. i assume
this would make everything a lot more complicated and it is
probably best to wait until we have seen how the thermostat
regions work with constraints. particularly for qm/mm simulations
i found it to be an excellent means to quickly dissipate the
"shock" from the transition from all-MM to have a massive
thermostat on the qm subsystem. but already the ability to
have separate thermostats down to a single atom region is
very helpful. i'll have to see how far i can get by writing
a small script that defines a separate region per qm atom...
good thing that we have VMD.

apropos VMD: how about making SEGNAME an alias for MOLNAME,
as this is the VMD (and pdb?) nomenclature for this flag?


thanks again for your efforts,
axel.

[Teodoro Laino]

>
> not so far, but i can imaging, there is a bunch of trouble
> lurking when using constraints, particularly, if they cross
> thermostat region boundaries.
>

eheh ;-)
I disabled this kind of possibility.. cp2k should stop in all cases
like these ones ;-)
If not please point me the problem.. (it would be anyway a bugged run).

>> We could discuss about the possibility to have different regions to
>> different temperatures, but I'm quite
>> skeptical whether it will really work!
>
> i guess there are some people that would be interested in this,
> but i would worry about this when they actually do ask.

It's trivial to give in input several temperatures but nowhere is
guaranteed that the
regions are really decoupled. i.e. you try to thermostat to a certain
temperature but
the real equilibrium temperature will not be the one in input.
That's something physical.. that's why I'm skeptical.

> what would be the cherry on of the cream on _my_ pie would
> be that the MASSIVE flag (i.e. one thermostat per DOF) would
> not be only a global option but a per region option. i assume
> this would make everything a lot more complicated and it is

I don't really understand that.. MASSIVE you have 1 thermostat per DOF..
This is not a global option.
Defining regions you have a thermostat per region (like a global one but
restricted to the selected number of atoms).
If you define a MASSIVE within each region you get exactly the same as
using MASSIVE (since the temperature is everywhere the same).
did I misunderstood something?

>
> apropos VMD: how about making SEGNAME an alias for MOLNAME,
> as this is the VMD (and pdb?) nomenclature for this flag?
>

Sure.. I can do that..

> thanks again for your efforts,

I will accept payments ONLY with the "delirium" ones ;-)

teo.

>>
>> p.s.: I will add soon also the possibility to dump on file the
>> temperatures of the different thermostats (tomorrow should be in)..
>>

Here we are.. I totally forgot about this point.. I will add this
print_key during the week end.

[Axel]

On Nov 29, 1:54 am, Teodoro Laino <teodoro.la...@gmail.com> wrote:
> > not so far, but i can imaging, there is a bunch of trouble
> > lurking when using constraints, particularly, if they cross
> > thermostat region boundaries.
>
> eheh ;-)
> I disabled this kind of possibility.. cp2k should stop in all cases
> like these ones ;-)
> If not please point me the problem.. (it would be anyway a bugged run).

well, for quite a few (simple) cases, you can account for them, but
allowing
a fractional number of DOFs and then removing an equal share of a
constraint
from each atom involved. i think this is how it is done, e.g. in CPMD.
but anyway,
but before discussion irrelevant problems, let us first wait and see
whether there
actually is a case where this would be useful. i'm certain your TODO
list
has many items, that are more relevant.

> >> We could discuss about the possibility to have different regions to
> >> different temperatures, but I'm quite
> >> skeptical whether it will really work!
>
> > i guess there are some people that would be interested in this,
> > but i would worry about this when they actually do ask.
>
> It's trivial to give in input several temperatures but nowhere is
> guaranteed that the regions are really decoupled. i.e. you try
> to thermostat to a certain temperature but
> the real equilibrium temperature will not be the one in input.
> That's something physical.. that's why I'm skeptical.

true. temperature has no meaning in those cases. a few
applications that i see for multiple thermostat regions at different
temperatures are:
- keeping an active center "cold" during (pre-)equilibration without
completely freezing the coordinates.
- enhancing phase space sampling by heating up a small subsystem.
in both cases you would not care about no longer being in a well
defined ensemble. but as noted before, lets worry about this
when it is actually needed.

> > what would be the cherry on of the cream on _my_ pie would
> > be that the MASSIVE flag (i.e. one thermostat per DOF) would
> > not be only a global option but a per region option. i assume
> > this would make everything a lot more complicated and it is
>
> I don't really understand that.. MASSIVE you have 1 thermostat per DOF..
> This is not a global option.

hmmm.... it is! i can specify REGION MASSIVE or REGION MOLECULE,
or REGION ..., or REGION DEFINED.

how do i enable a MASSIVE for a REGION DEFINED? as you know,
you currently (well, last time i checked, which is a long time ago in
terms of the pace of cp2k development) cannot use MASSIVE on
anything with a constraint. e.g. in a QM/MM scenario, it could be
advantageous to have a MASSIVE thermostat for the QM region
and _single_ thermostat, for the rest which usually has rigid water,
ie
lots of constraints.

> Defining regions you have a thermostat per region (like a global one but
> restricted to the selected number of atoms).
> If you define a MASSIVE within each region you get exactly the same as
> using MASSIVE (since the temperature is everywhere the same).
> did I misunderstood something?

probably. i don't want _alL_ region to be MASSIVE only some
(e.g. those that are compatible with the "no constraints" condition).

> > thanks again for your efforts,
>
> I will accept payments ONLY with the "delirium" ones ;-)

i'm working on that. in fact, the next batch is currently bubbling so
loud, it woke me up,. i'll save you a couple of "bearhugger" and
"mad axel" and your delirium tremons is guaranteed (should i aim
for pink elephants with parachutes?).

if you have a favorate style that we don't have in our portfolio yet,
please let me know. i'll start a flemish sour on the weekend
but should have time to set up another batch before i leave for
christmas. due to too many travels, production has slowed down
significantly.

cheers,
axel.

[Teodoro Laino]

>
> well, for quite a few (simple) cases, you can account for them, but
> allowing
> a fractional number of DOFs and then removing an equal share of a
> constraint
> from each atom involved. i think this is how it is done, e.g. in CPMD.
> but anyway,

Is this a cooking recipe or what?? ;-)

> but before discussion irrelevant problems, let us first wait and see
> whether there
> actually is a case where this would be useful.

Yes I agree..

>
> hmmm.... it is! i can specify REGION MASSIVE or REGION MOLECULE,
> or REGION ..., or REGION DEFINED.

Sorry Axel I cannot really understand that.. MASSIVE is one of the
possible region and it is true
that at the moment it cannot be used with constraints..
It would be like saying a want a region to be massive and at the same
time GLOBAL?!?!#%^#

> how do i enable a MASSIVE for a REGION DEFINED?

Ohhhhhhhhh yesssssssss!
I see the problem now.. You would like the keyword MASSIVE not be
specified as a region
but as an additional keyword controlling the thermostat in the
defined region..

something like: DOF_REGION (MASSIVE/GLOBAL)
right?

If this is what you were thinking I agree.. MASSIVE and GLOBAL are
not really regions but should be more property of the
thermostat..

>
> i'm working on that. in fact, the next batch is currently bubbling so
> loud, it woke me up,. i'll save you a couple of "bearhugger" and
> "mad axel" and your delirium tremons is guaranteed (should i aim
> for pink elephants with parachutes?).

well... for this label enhancement I may even give you 1/2 of my
working time ;-) (for free!!)

ciao from ETHZ,
teo

[Axel]

On Nov 29, 9:57 am, Teodoro Laino <teodoro.la...@gmail.com> wrote:
> > well, for quite a few (simple) cases, you can account for them, but
> > allowing
> > a fractional number of DOFs and then removing an equal share of a
> > constraint
> > from each atom involved. i think this is how it is done, e.g. in CPMD.
> > but anyway,
>
> Is this a cooking recipe or what?? ;-)

exactly, two chunks of a DOF in the right pot, a pinch
of a DOF in the left and you end up with a spoiled stew. ;-)

[...]

> > hmmm.... it is! i can specify REGION MASSIVE or REGION MOLECULE,
> > or REGION ..., or REGION DEFINED.
>
> Sorry Axel I cannot really understand that.. MASSIVE is one of the
> possible region and it is true
> that at the moment it cannot be used with constraints..
> It would be like saying a want a region to be massive and at the same
> time GLOBAL?!?!#%^#
>
> > how do i enable a MASSIVE for a REGION DEFINED?
>
> Ohhhhhhhhh yesssssssss!
> I see the problem now.. You would like the keyword MASSIVE not be
> specified as a region
> but as an additional keyword controlling the thermostat in the
> defined region..

yep. that is it. actually, if implementation details would not
matter, i would make the whole thermostat block a repeatable
keyword and then TYPE could be either NOSE or NOSE_MASSIVE
or CSVR or CSVR_MASSIVE, etc. etc.
this way (from the user perspective) you define a thermostat
and then attach it to something. whether this is doable without
much effort or not, depends a lot on the implementation and
that you have to tell me. as i mentioned before, you can get
pretty close (say 95%) to what i had in mind already with some
script generated input, so it is not a high priority. but you
have to admit, that MASSIVE is the odd one out in the list of
possible keywords for REGION (GLOBAL in turn does make sense:
the thermostat applies to everything).

> something like: DOF_REGION (MASSIVE/GLOBAL)
> right?
>
> If this is what you were thinking I agree.. MASSIVE and GLOBAL are
> not really regions but should be more property of the
> thermostat..
>
>
>
> > i'm working on that. in fact, the next batch is currently bubbling so
> > loud, it woke me up,. i'll save you a couple of "bearhugger" and
> > "mad axel" and your delirium tremons is guaranteed (should i aim
> > for pink elephants with parachutes?).
>
> well... for this label enhancement I may even give you 1/2 of my
> working time ;-) (for free!!)

i'll see what i can do.

ciao,
axel.

>
> ciao from ETHZ,
> teo