towhee-users Mailing List for MCCCS Towhee

On Thu, March 30, 2006 4:24 am, Stefan Henninger wrote:
> If any framework is present, I have different volumes for insertion and
> deletion.
> Insertion of a molecule with an overlap due to a framework atom will
> always be rejected, but this trial move will be counted !
> So the volume for the insertion trials is the box-volume.
>
> But in the deletion case, you can only remove molecules which have been
> succesfully inserted. So therefore you have an reduced volume in this
> case.
>
> Don't I have a bias in my acceptance rule due the effectivly reduced
> volume ?
>
> How does towhee handle this ?

  I don't think rejection of an insertion move due to an overlap can be
considered as biasing. If an overlap occurs (which is controlled by rmin
keyword) towhee rejects the move without calculating the energy of the
new state, since we already know that the energy will be a huge value
and have an insertion weight almost equal zero. This procedure just
saves you time and speeds up the execution. So nothing needs to be
corrected.


> Some programs are able to compute an excluded volume map, so the volume
> for insertion and deletion will be the same. But I found no reference
> wether this is the right way !?
>

Starting from version 4.15.0 towhee has a new feature similar to what you
describe. It is energy biasing. Although in this method energy profile of
a zeolite or any crystal structure is created, it can be also considered
as creating a volume map. Because as a result of energy mapping,
insertions are biased to the pores. Here, as you mentioned earlier,
acceptance rule is  modified to balance the biasing. However, I don't
recommend you to use this feature right now as there are some limitations.
Hopefully it will be fully functional with in a few weeks.


--
Ozgur YAZAYDIN
Department of Chemical Engineering
Worcester Polytechnic Institute
100 Institute Rd.
Worcester, MA 01609-2280 USA

The answer is (4) - you don't have to correct anything.  The reason is
simple - say that half of the box volume is inaccessible to insertions.
Then half of the insertions are immediately rejected; however, in the
removal step, the acceptance condition is proportional to N/V; since the =
box
volume (double the "real" volume) is used in this, it balances exactly =
the
extra rejections on attempted insertions.  The only overall effect of =
this
is on reduced acceptance ratios, not on the equilibrium state. However, =
the
closer the box volume to the "real" volume, the more efficient the
simulation.

Hope this helps.

Prof. A.Z. Panagiotopoulos
Dept. of Chemical Engineering, Princeton University =20
Princeton NJ 08544  http://kea.princeton.edu  (609)258-4591


-----Original Message-----
From: tow...@li...
[mailto:tow...@li...] On Behalf Of Stefan
Henninger
Sent: Thursday, March 30, 2006 4:24 AM
To: tow...@li...
Subject: [Towhee-users] Reduced Volume in MC steps


Hi,

I have a question regarding simulation of adsorption in zeolite or other =

frameworks and the acceptance rule.
If any framework is present, I have different volumes for insertion and=20
deletion.
Insertion of a molecule with an overlap due to a framework atom will=20
always be rejected, but this trial move will be counted !
So the volume for the insertion trials is the box-volume.

But in the deletion case, you can only remove molecules which have been=20
succesfully inserted. So therefore you have an reduced volume in this =
case.

Don't I have a bias in my acceptance rule due the effectivly reduced=20
volume ?

How does towhee handle this ?
Some programs are able to compute an excluded volume map, so the volume=20
for insertion and deletion will be the same. But I found no reference=20
wether this is the right way !?

In my opinion there are several possibilties

1) calculate an excluded volume map
2) simulate with some sort of "early rejection scheme", overlapping will =

be detected and not accepted without counting this trial move
3) change the volume in the acceptance rule !?
4) you don't have to correct ...


Possibility 1) and 2) should give the same results, except of the=20
computing time

I'm not quite sure if poss. 3) will give the same results.....

If poss. 4 is the right way, can anybody explain me or give me some=20
references on this ?

Thanks a lot !

Stefan

--=20
------------------------------------------------------
Dipl.-Phys. Stefan K. Henninger
Dept. Thermal Systems and Buildings
Fraunhofer-Institut f=FCr Solare Energiesysteme ISE
Heidenhofstr. 2, 79110 Freiburg, Germany
Phone : +49 (0)761 4588 5104 Fax: +49 (0)761 4588 9000
ste...@is...
http://www.ise.fraunhofer.de
------------------------------------------------------



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language
that extends applications into web and mobile media. Attend the live =
webcast
and join the prime developer group breaking into this new coding =
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
_______________________________________________
Towhee-users mailing list
Tow...@li...
https://lists.sourceforge.net/lists/listinfo/towhee-users

Hi,

I have a question regarding simulation of adsorption in zeolite or other=20
frameworks and the acceptance rule.
If any framework is present, I have different volumes for insertion and=20
deletion.
Insertion of a molecule with an overlap due to a framework atom will=20
always be rejected, but this trial move will be counted !
So the volume for the insertion trials is the box-volume.

But in the deletion case, you can only remove molecules which have been=20
succesfully inserted. So therefore you have an reduced volume in this cas=
e.

Don't I have a bias in my acceptance rule due the effectivly reduced=20
volume ?

How does towhee handle this ?
Some programs are able to compute an excluded volume map, so the volume=20
for insertion and deletion will be the same. But I found no reference=20
wether this is the right way !?

In my opinion there are several possibilties

1) calculate an excluded volume map
2) simulate with some sort of "early rejection scheme", overlapping will=20
be detected and not accepted without counting this trial move
3) change the volume in the acceptance rule !?
4) you don't have to correct ...


Possibility 1) and 2) should give the same results, except of the=20
computing time

I'm not quite sure if poss. 3) will give the same results.....

If poss. 4 is the right way, can anybody explain me or give me some=20
references on this ?

Thanks a lot !

Stefan

--=20
------------------------------------------------------
Dipl.-Phys. Stefan K. Henninger
Dept. Thermal Systems and Buildings
Fraunhofer-Institut f=FCr Solare Energiesysteme ISE
Heidenhofstr. 2, 79110 Freiburg, Germany
Phone : +49 (0)761 4588 5104 Fax: +49 (0)761 4588 9000
ste...@is...
http://www.ise.fraunhofer.de
------------------------------------------------------

As this might be of interest to the wider Towhee community, I'm 
forwarding this email to the towhee-users list.

I did a number of performance tests for a system I am interested in 
(essentially, TIP4P water) to evaluate:
1) compilers -- gcc 3.4.4, gcc 4.1.0, ifort 9.0
2) various compiler flags/optimizations
3) recent performance optimizations by Alan, and changes specific to the 
Scaled Lennard Jones potential.

Summary: for the system of interest, Alan's changes result in a run time 
55%-60% of the previous value (~175% improvement); calculations of 
derivatives in Scaled Lennard Jones is essentially free (major 
improvement); compiler flags have a small effect on performance; and the 
best compiler, by a considerable margin, is Intel's iFort.

Here is a description of the changes, as written by Alan Chen himself:
Towhee now autodetects atoms with zero-VdW or zero charge at startup,  
sets a array of logicals, and then prevents calls to mimage / vtwobody / 
vcoulomb
from engmolec.F unless both sites are nonzero.   This only activates if 
you are using Lennard-Jones or Scaled-Lennard Jones because I'm not 
familiar with
other forcefields work and don't want to mess them up.  The VdW checking 
is also disabled if classical_mixrule is set to "explicit" (it took me 
forever to figure out why the Dubb example was giving me a hard time 
until I looked at the unusual parameters it uses).


The test system consisted of a 216 TIP4P water box with an immobile 
solute (essentially, this is the Scaled_Formamide example), minimum 
image coulomb style, run for 500 cycles of rotations and COM 
translations.  Initialization times (run of nstep=0) were subtracted 
from the total time, to investigate only the production part of a run.  
Results reported below are for this system, but with a Lennard-Jones 
(rather than Scaled Lennard Jones) potential, which should be more 
relevant to other developers/users.

The two versions of Towhee tested are the 4.13.3 version (which does not 
have the recent Alan's patch, nor the Scaled Lennard Jones changes), and 
what is effectively the 4.14.0 version, with both changes added.

Flags tested for the GCC compilers were:
* no flags (implicitly, '-O2 -g', [-g is a flag which puts debug 
information in executable])
* '-O3'
* For GCC4.1.0, tested tree vectorization with the flags,
      '-O3 -ftree-vectorize -mtune=pentium4 -msse2'

For Intel compiler, only the following flags were considered:
* '-O3 -axP -ipo'

Flags were passed to both the C and Fortran compilers; specifically, 
./configure was run as follows for all tests:
./configure F77=/path/to/fortran/compiler CC=/path/to/C/compiler 
FFLAGS=f CFLAGS=f
where f is the flags string as described above.

Tests were performed on a dual-processor Intel Xeon 3.2GHz machine.  
Scores, in number of cycles (216 water moves) per second are reported 
for both the 4.13.3 and 4.14.0 versions:

Compiler/flag            v4.13.3    v4.14.0
GCC 3.4.4/none            3.83        7.25
GCC 3.4.4/-O3             3.95        7.35
GCC 4.1.0/none            4.52        7.63
GCC 4.1.0/-O3             4.50        7.63
GCC 4.1.0/vectorize       ----        7.77
iFort 9.0/-O3 -axP -ipo   5.44        9.82

Again, the values reported are number of cycles per second; the higher 
the number, the better.  Conclusions:
* GCC 4.1.0 is somewhat faster than GCC 3.4.4
* iFort is significantly faster than either GCC versions
* Alan's improvements show a significant speedup for Lennard-Jones 
calculations in TIP4P water
* Compiler flags have some effect on performance, although this effect 
is slight.

Results for Scaled Lennard Jones not reported, but are similar to 
Lennard Jones numbers above for v4.14.0.

Best,

matt

-- 
Matt Wyczalkowski
Doctoral Candidate, Biomedical Engineering
Pappu Lab: http://lima.wustl.edu
Washington University in St. Louis
ma...@ce...

On Mar 7, 2006, at 12:17 PM, Gale, Ella wrote:

>  I have been playing with the UFF and DREIDING minimisation examples 
> in that come with towhee-4.12.1. As far as I understand these 
> simulations work by doing a MC simulation at low temperature so that 
> the system finds the energy minimum. Firstly, I was rather confused as 
> to why the UFF example is set at 300K, surely it should be at a low 
> temperature ie 10 K like the DREIDING example is?

Towhee does not find energy minima, it samples the conformations of 
atoms in the system according to the Boltzmann weight at a certain 
temperature.  By setting a low temperature you get results that are 
generally close to an energy minima, but is not truly a minimization.

>  I have been plotting the block averages over time to see how the 
> minimsations progress. For the DREIDING example the system is 
> minimised as would be expected (a drop to a plateau in energy), but 
> for the UFF example, run at both 300K and 10K, the energy does not 
> descrease during the simulation. The difference between the two 
> examples seems to be that the UFF examples using the 'coords' 
> initstyle, has two benzene molecules and uses the UFF forcefield, the 
> DREIDING example has 1 benzene molecule, uses the 'fullcbmc' input 
> style and the DREIDING forcefield. When I put the DREIDING force field 
> into the UFF example input file (at 10K) the energy is minimised.
>
>  Can anyone help? I want to be able to minimise a structure with UFF, 
> but first I need to minimise the example!

If you want to search for low energy conformations then set a lower 
temperature.  If you were doing a multi-molecule minimization (such as 
from the UFF example) then you would also want to turn on the 
center-of-mass translation and the rotation about the center of mass 
moves in order to better sample the interactions between the molecules. 
  Keep in mind that you will only find local minima by performing a 
simulation at low temperature.

Marcus
-------------------------------------------------------------------
Marcus G. Martin
Senior Member of Technical Staff
Multiscale Computational Materials Methods
Sandia National Laboratories
PO Box 5800 MS 1110
Albuquerque NM 87185-1110
v. 505 284-6355
f. 505 845-7442
http://www.cs.sandia.gov/marcusmartin/
http://towhee.sourceforge.net

Hi,

I have been playing with the UFF and DREIDING minimisation examples in =
that come with towhee-4.12.1. As far as I understand these simulations =
work by doing a MC simulation at low temperature so that the system =
finds the energy minimum. Firstly, I was rather confused as to why the =
UFF example is set at 300K, surely it should be at a low temperature ie =
10 K like the DREIDING example is?=20

I have been plotting the block averages over time to see how the =
minimsations progress. For the DREIDING example the system is minimised =
as would be expected (a drop to a plateau in energy), but for the UFF =
example, run at both 300K and 10K, the energy does not descrease during =
the simulation. The difference between the two examples seems to be that =
the UFF examples using the 'coords' initstyle, has two benzene molecules =
and uses the UFF forcefield, the DREIDING example has 1 benzene =
molecule, uses the 'fullcbmc' input style and the DREIDING forcefield. =
When I put the DREIDING force field into the UFF example input file (at =
10K) the energy is minimised.=20

Can anyone help? I want to be able to minimise a structure with UFF, but =
first I need to minimise the example!=20

Regards

Ella Gale