]]
where "RW" stands for the random walk statistics (unchanged from
previous versions as it is working properly), "SAW" for the newly
implemented proper method to obtain a polymer with self-avoiding walk
statistics (this is also the new default), while the old method is now
accessible as "PSAW" (which stands for "pseudo self-avoiding walk" and
has been the old default). The latter was done because in some cases the
statistical difference between both methods might not be extremely
essential such that the user might prefer to benefit from the
considerably faster execution of the old one, particularly if merely the
spatial exclusion is of interest (i.e. to speed-up the equilibration
process by being able to skip the LJ-push sequence). The other options
are the radius of the shield around already place particles, and the
maximum number of attemps to re-place the polymer (for mode SAW) or a
monomer (for mode PSAW). Please note that while the latter still
defaults to 30000, the shield is now automatically set to 1.0 (instead
of the former 0.0) if the user did not specify something else.
For more informations on this subject please refer to the literature,
e.g. J. Lyklema & K. Kremer, J. Phys. A: Math. Gen. 19 (1986) 279-289.
In case of questions do not hesitate to reply or to contact us.
Best regards,
Bernward.
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: "Nils Binz,1.404,Tel. 481" <binz[4]> on 2005 06 03 16:18 CEST
to: despintr[4]
cc:
subject: release-notes tags in cvs-submit text
Dear Despressis!
Within the next 2 weeks a script will start running which builds the
RELEASE_NOTES out of special entries you are supposed to leave when
submitting a file into the cvs repository.
If you consider a bugfix or a new feature worthy of being mentioned in
the RELEASE_NOTES, simply put a [ ]-tag in front of the
description-line in your cvs-text !!FROM THIS DAY FORTH!!.
This is how one of our future-cvs-texts could look like:
------------------------------------------------------
fixed an unworthy bug here
[BUGFIX] Espresso wont crash anymore when bla.bla.bla
[NEW] added new force here
[CHANGE] important change there
added unworthy new feature
.
.
.
The script is supposed to be quite generous regarding the text within
the squared-brackets, meaning: quite a lot of different formats will
work, for example:
[new feature] = [NEW feature] = [NEW] = [feature] ...
[bug] = [BUG] = [fix] ...
Greets,
Nils
P.S. from Bernward: If you don't use these nice tags Nils provided,
then you will be severely punished! ;-)
top of page
From: Axel Arnold <A.Arnold[0]> on 2005 05 30 22:02 CEST
to: despresso[4]
cc:
subject: 2D electrostatics, neutralization and plates
Hello all,
this mail is for those using MMM2D or ELC for nonneutral systems. First of
all, there was a bug in the energy calculation for charged plates, so if you
did use plates so far, forget about the energies, if you ever calculated
them. If you use ELC with plates, this did not work so far, since for
nonneutral systems, P3M automatically adds a neutralizing homogenous
background. Now ELC takes care of properly removing this contribution again,
if you give it the option "-noneutralization", which allows to neutralize the
system for example by a charged wall. If you don't use this option, the
background is not removed. It however excerts a force on the particles
driving them away from the surface, so be careful with that.
Happy simulating,
Axel
--
Dr. Axel Arnold
Frankfurt Institute for Advanced Studies
Max von Laue-Str. 1 Phone: +49-69-798-47502
D-60438 Frankfurt E-mail: A.Arnold[0]
top of page
From: Axel Arnold <A.Arnold[0]> on 2005 05 04 12:06 CEST
to: despresso[4]
cc:
subject: Binning tool
Hello all,
there is a new command bin, which allows to analyze distributions by binning
particle coordinates, or estimating functions.
Examples:
bin -linbins 0 10 10 {0 0 2 3 1 7 3 1 1}
gives the distribution of the numbers in the list into 10 bins [0,1],
(1,2],...,(9,10], normalized to a weight of 1.
bin -linbins 0 10 10 {{0 1} {0 2} {2 1} {3 4} {1 1} {7 9} {3 4} {1 0} {1 1}}
gives instead the the average of second entries for each bin, where the bin is
determined by the first entry. If you want to for example measure the force
as a function of the distance from a set of particles, the first coordinate
would be the particle coordinate, the second one its force.
bin -linbins 0 10 10 -binctrwdth returns the centers and widths of the bins
for pretty printing.
Instead of -linbins you can also use -logbins or simply -bins, which takes a
list of bin boundaries as argument and allows for arbitrary bins.
For more documentation, rts.
Axel
--
Dr. Axel Arnold
Frankfurt Institute for Advanced Studies
Max von Laue-Str. 1 Phone: +49-69-798-47502
D-60438 Frankfurt E-mail: A.Arnold[0]
top of page
From: Axel Arnold <arnolda[4]> on 2005 04 11 17:28 CEST
to: despresso[4]
cc:
subject: Domain decomposition, not Verlet bug
Hello Despressies,
this is just to inform you that the bug reported by Bernward is fixed, and did
not influence any results. The only incorrect thing that could happen was
that either Espresso bails out with error 004 or goes into an endless loop.
You probably would have noticed either one. The problem is actually more or
less the same as the one I fixed a few weeks ago, just at a different
position in domain_decomposition.c.
Details: Due to rounding errors, coordinates can be slightly out of the
simulation box even after folding, but when calculating the corresponding
cell, the cell index is out of bounds, since the cell size is much smaller.
This leads to a better resolution of the multiplication necessary to
determine the cell, so that it gets the correct result, but the folding not.
The solution is a relaxed particle allocation, which will keep particles on
the node even if they are slightly off bounds (ROUND_ERROR_PREC).
In short, the bug is fixed, but even if you don't update, there is no harm to
your results. And just a remark: the folded position may be out of the
simulation box by at most skin/2, since it really represents the internal
coordinates, which only get updated on a rebuild of the Verlet list.
Axel
--
Dr. Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Axel Arnold <arnolda[4]> on 2005 04 09 10:19 CEST
to: despresso[4]
cc:
subject: configure bug reporting
Hello Despressies,
if you find something not working as you expect in the configure scripts,
please always attach the config.log and Makefile.??? files, because these
tell me exactly what configure has (not) found.
By the way: At the beginning of the config.log there is also the line with
which you called configure the last time. If your configure lines are longer,
e.g. because of self compiled libraries, this is quite convenient for
reconfiguring.
Many regards,
Axel
--
Dr. Axel Arnold
Frankfurt Institute for Advanced Studies
Max von Laue-Str. 1 Phone: +49-69-798-47502
D-60438 Frankfurt E-mail: A.Arnold[0]
top of page
From: "Limbach,Hans Joerg,LAUSANNE,NRC-FS" <Hans-Joerg.Limbach[6]> on 2005 04 01 11:35 CEST
to: <despresso[4]>
cc:
subject: Dihedral Interactions
Hi,
I fixed some bugs for the dihedral potential. The new Routines for =
calculating the dihedral angle, forces and energies are based on =
routines written by Arijit Maitra. I only adapted them to the new (ok, =
its not so new anymore) force interface. This will definitally affect =
all simulations using this type of potential.
Please check this conflicts with your work!
Hanjo
Dr. Hans J=F6rg Limbach
Research Scientist
Nestl=E9 Research Center
P.O. Box 44
Vers-chez-les-Blanc
CH-1000 Lausanne 26
Phone: +41 21 785 8175
Fax: +41 21 785 8554
top of page
From: Ira Cooke <cooke[4]> on 2005 03 31 13:09 CEST
to: despresso[4]
cc:
subject: .espressorc
Just to let you know that init.tcl has been changed so that now if you
want to define some user settings for the espresso tcl interpreter you
can create a .espressorc file in your home directory and add tcl
commands to it which will be sourced on startup.
Ira
top of page
From: mann[4] on 2005 03 26 23:08 CET
to: despresso[4]
cc:
subject: Bug in the Verlet lists
Dear Despressies,
there seems to be a bug in the Verlet lists which we are currently trying to
pinpoint and subsequently exterminate. You can try it out for yourself by
setting up nothing but two like-charged particles with mere electrostatic
interactions between them in a periodic box using P3M for the coulomb
calculations. Once one of the repelled charges returns via the boundary
conditions, you'll see it suddenly displaced into a neighbour box, with ESPResSo
crashing soon thereafter. Using "cellsystem domain_decomposition
-no_verlet_list" to disable the Verlet lists prevents this otherwise
reproducable event. As far as we can tell right now, it occurs in both old and
current releases (tested with e.g. v1.8.2x from December and the newest v1.8.7x
top of page
From: Axel Arnold <A.Arnold[0]> on 2005 03 25 17:12 CET
to: despresso[4]
cc:
subject: part <p> bond
Hello despressies,
the part command output for a bond was not properly formatted, i.e. there
was no keyword before the output. Therefore, particles with bonds could not
be read in from the output. I fixed this by allowing a new, second input
format to part
bond, which is just the output format, i.e. {{t1 p11
p12...} {t2 p21 p22...}...}. Moreover, the output of part
now also prints
a "bond" before the bonds list. Therefore, if one did parse the list in a
script (also I wonder how one did find it), the corresponding parser has to
to adapted.
Second, the molecule property is no longer printed, if it is -1 (which is also
the case for all other properties which are not set, such as fixes, external
forces etc.).
If someone feels to complain, come up with a better CONSISTENT way of handling
this.
Many regards,
Axel
--
Dr. Axel Arnold
Frankfurt Institute for Advanced Studies
Max von Laue-Str. 1 Phone: +49-69-798-47502
D-60438 Frankfurt E-mail: A.Arnold[0]
top of page
From: Axel Arnold <arnolda[4]> on 2005 03 24 13:42 CET
to: despresso[4]
cc:
subject: dd_position_to_cell
Hello despressies,
just a quick update on the bug that I mentioned yesterday. Basically, what
happens is that it is possible that due to rounding position_to_node and
position_to_cell had different ideas to which processor a particle belongs.
Without ADDITIONAL_CHECKS, this leads to lost particles, since they will be
put into ghost cells. Mehmet's nve_pe.tcl was an excellent example since it
places particles exactly on the processor boundary. Under normal
circumstances, this is highly unlikely, and whether the effect occurs
actually depends massively on the used compiler, OS, CPU, moon time and what
ever else.
In other words: The fix is necessary, but it is highly unlikely that the
problem ever hit any production runs.
BTW: Since on the alphas the newest available tcl version is the stone old
8.2, I installed tcl8.4 for OSF1 in my home directory (under OSF1/include and
OSF1/lib). If you want to run Espresso on the alphas,
configure CC=cc CFLAGS="-I/people/thnfs/homes/arnold/OSF1/include" \
LDFLAGS="-L/people/thnfs/homes/arnold/OSF1/lib"
is probably the optimal solution.
Axel
--
Dr. Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: "Dr. Axel Arnold" <arnolda[4]> on 2005 03 23 15:29 CET
to: despresso[4]
cc:
subject: Lots of new stuff
Hello guys,
there have been some major changes to Espresso, so check out the latest
version. Most importantly, there is a configure interface. In other words,
ideally Espresso can be built via "configure && make" on any platform. In
practice, this works for many platforms where includes and libraries are not
in brain damaged paths. This are most computers at MPIP and also Garching,
with the exception of our Alphas and the blade center in Garching. For these,
you have to use configure --enable-config=thalpha rsp. blade. And, configure
--help gives you a lot of additional information on controlling the
compilation process etc, e.g. activating Tk or debug information. Of course
it would be nice if the configure script would be tested on as much different
platforms/compiles as possible. Before I forget it: of course I didn't write
the configure script myself (just have a look...), but it is generated from
the various .m4 files by autogen.sh.
To better reflect different hardware, the object directories are now called
obj---. This allows to have different binaries for Linux on
AMD MP, Opteron or Pentium III, for example. The platform naming is done by
config/config.guess, which does a similar thing to the normal config.guess
used with autoconf, also it has been completely rewritten to better reflect
the different CPUs for optimization.
While switching to autoconf, I also changed the calling procedure for
Espresso. The idea is, that only the configure script (more precisely
config/mpi.m4) has to know about the MPI environment used on the present
architecture, not all of the simulation scripts as current. The Espresso
binary is now Espresso_bin, while Espresso itself is just a script with the
proper calling sequence (e.g. mpirun -np ...). For convenience, there is a
second Espresso directly in the ESPRESSO_SOURCE directory, which calls the
platform dependent part.
Finally, there is an make install option, which allows to install Espresso in
the filesystem (the location is determined by the --prefix switch to
configure). The installed Espresso script even contains definitions for
ESPRESSO_SCRIPTS and _SOURCE, so that you can start the installed version
like any other program (the same trick as for example vmd or icc use).
Apart from the configure changes, I also changed the inclusion hierarchy.
Since it is now VITAL to include config.h (it was required before, but not
all cared), now config.h is included together with debug.h in utils.h, and
utils.h and only utils.h is included in each c or h file, where necessary.
Without utils.h, MDINLINE will not work anymore.
So much to the changes, and a warning at the end: The nve_pe.tcl testcase does
not work currently on 4 nodes, because Espresso looses particles under
certain conditions. I will fix this, but of course only in the CVS version.
So if you like your simulations to keep their particles, better get used to
the current CVS version.
Happy testing,
Axel
--
Dr. Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Christian Holm <holm[4]> on 2005 03 14 11:19 CET
to: despresso[4]
cc:
subject: [Fwd: Fwd: Espresso Package]
Alles kalter Kaffee....aber mit viel Koffein
--
___________________________________________________________________
/ \
| Dr. Christian Holm |
| FIAS & MPI f"ur Polymerforschung |
| JW Goethe - Universit"at Ackermannweg 10 |
| Max-von-Laue Strasse 1 D-55128 Mainz |
| D-60438 Frankfurt/Main |
| Ph: +49-69-798 47505 +49-6131-379-268 |
| Fax: +49-69-798 47611 +49-6131-379-100 |
| C.holm[0] holm[4] |
| http://www.fias.uni-frankfurt.de www.mpip-mainz.mpg.de/~pep |
| |
\___________________________________________________________________/
ATTACHMENTS:
"Fwd: Espresso Package"
top of page
From: Burkhard Duenweg <duenweg[4]> on 2005 03 14 10:53 CET
to: Olaf Lenz <olenz[11]>
cc: despresso[4]
subject: Re: ESPRESSO: name clash
Hello,
thanks for finding this!!
It is not obvious who "was first" - at least I cannot find out
top of page
From: Olaf Lenz <olenz[11]> on 2005 03 14 10:21 CET
to: despresso[4]
cc:
subject: ESPRESSO: name clash
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
I've just stumbled across the following page:
http://www.democritos.it/scientific.php
They seem to use the acronym "ESPRESSO" for their simulation software
package as well, although they do Car-Parinello Simulations with it.
I think this may lead to confusion amongst users. P-(
Cheers
Olaf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCNVektQ3riQ3oo/oRApyPAJ9sbRAGQK6ggFYEEMqMVrgrbmV38wCfTTFT
tSgpHigYVVheY/Kf+kmn9FI=
=yYLb
-----END PGP SIGNATURE-----
top of page
From: Mehmet Sayar <sayar[4]> on 2005 03 08 10:48 CET
to: despresso[4]
cc:
subject: Bug in aggregation analysis tool
I found a bug in the aggregation analysis tool.
The distance calculation for determining which molecules are in the same
aggregate ignored periodic boundary conditions. Hopefully this is fixed
now.
If you used this tool for a system with periodic boundary conditions, the
analysis could have missed some aggregates. So please check your results
with the new version.
Mehmet
________________________________________________________
Mehmet Sayar - Postdoc MPI fur Polymerforschung
Email:sayar[4] Theory Group
Phone:+49-6131-379-166 Ackermannweg 10,
Fax: +49-6131-379-340 D-55128 Mainz, Germany
top of page
From: arnolda[4] on 2005 02 10 13:26 CET
to: despresso[4]
cc:
subject: Rentering integrator
Hello Despressos,
saving the random numbers will probably not work. If resort_particles=1, the
particles are resorted, and consequently, even if the random number sequence
is the same, the particle sequence is not.
The heating should not occur in daily use, since recalc_forces should only be
set if you it is really necessary, e.g. if you change a particle or
interaction parameter. Especially if you add a particle, the heating is the
only simple algorithm to circumvent the correlation problem.
(@ Hanjo: Do we still need the recalc_forces=1 in resort_particles? Resorting
the particles itself does not make it necessary, and we could just set
recalc_forces=1 in on_particle_change. I guess this is a left-over from the
pre on_* times...)
Probably most people are still affected by this, since the checkpoint_set uses
invalidate_system, which enforces a particle sorting and a force
recalculation. I do not know what it is good for, since even by resorting the
particles, the particle storage order is by no means predictable, so that you
still do not have a real checkpoint in the sense that you could reproduce
trajectories. At least I do not see how this should work (did anybody have
SUCCESS with reproducing a trajectory with random numbers?).
If one desperately needs checkpoints, one has to write a new (C-) routine
which also stores the particle storage information, i.e. which particle is in
which cell.
The bottom line is: I rather suggest to leave the heating, and just use it for
the insane cases (like adding a particle), where no other simple approach will
really help.
Many regards,
Axel
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
top of page
From: arnolda[4] on 2005 02 10 11:28 CET
to: despresso[4]
cc:
subject: Changes to the grid calculation and the mindist calculation
Hello Despressos,
there are two changes I have implemented/want to implement:
1. The current cell grid calculation routine will not test all possible grids
for large systems of 1 or 2 million particles (since the cell size is simply
increased by 5%). For more than 40 cells per side, this breaks the cell_tuning
script, which is really necessary for such large systems.
Bernward and I found a better solution to the problem that I already have
implemented, and it seems to work. The idea is to start with the finest cell
grid possible due to max_range and iteratively decrease the number of cells
for the coordinate with the smallest cell_size. This approach will generate
nearly cubic cells, but even in a symmetric system cells may not be symmetric
(depending on max_num_cells). E.g. for a limit of 100 cells, the algorithm
chooses 4 5 5, while the old algorithm would have used a 4 4 4 cell grid. Does
anybody think that this may break something? I guess no, since this also may
happen for multiprocessor jobs with the current algorithm. Since the new
algorithm tests more cell grids, it is better for large systems, so I will
commit my changes if nobody complains.
2. The polymer command gets incredibly slow for large systems, as well as
analyze mindist. The reason are the used n-squared loops. An alternative would
be to make use of the cell structure. My suggestion is the following:
Currently we have for the cell systems three loops: force, energy and pressure
calculation. However, only the force calculation is really crucial, the other
two are only used in analysis. Why don't we use only one routine with an
integer parameter determining the type of job to do? We could easily add
additional jobs such as the minimal distance calculation, neighborhood
determination etc. The speed loss for energy and pressure calculation should
be almost neglible, but the analysis code would bet a lot faster. Perhaps the
speed difference is so small that we could also put in the forces.
3. Since Ulf and Olaf suggested to make implementing new potentials easier, it
may be worth to collect the interfacing functions like add_non_bonded_forces
in separate files, so that for adding a non bonded force, you just have to
modify one file (bonded.h, nonbonded.h ?)
Many regards,
Axel
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
top of page
From: Ulf Schiller <uschille[11]> on 2005 02 09 13:29 CET
to: despresso[4]
cc:
subject: Re: Reentering integrator with DPD thermostat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Bernward, dear all,
Bernward Mann wrote:
| Dear Ulf,
| Dear D'Espressis,
|
| calculating the forces only at the beginning of the integration loop
| does not seem to work out IMHO, because you need them to propagate the
| velocities for the second time, so, just by looking at the algorithm I
| cannot imagine how the force_calc could be avoided.
What I meant is that you do not need to propagate the velocities for the
second time, if you only consider the scheme
Step 1) calculate f(t) as function of p(t)
Step 2) v(t+0.5*dt) = v(t-0.5*dt) + dt * f(t)
Step 3) p(t+dt) = p(t) + dt * v(t+0.5*dt)
So, while just integrating, it would be sufficient to store the
velocities at intermediate time steps v(t-0.5*dt), v(t+0.5*dt),...
If you want the velocities at full time steps v(t+dt) for some analysis,
they could be calculated outside the integration loop. The random forces
needed for that would not be reused in the integration and hence would
not change the correlations of the integrated trajectory. However, one
has to be careful to get the correlations of the observables right (I
haven't figured that out yet).
| Furthermore, it
| becomes impossible if also considering alternative integrators such as
| NpT which sort of abuses parts of the VV-integrator for performance
| reasons.
I agree. Since I don't overlook in detail what else relies on the
integrator, it might be best to keep hands off from the integration scheme.
| In other news, you definitely need the velocities v(t+dt) at the end of
| each integration cycle, if only to store them in a file for later
| recovery! Of course one could argue that in an equilibrated system the
| exact velocity distribution does not matter as long as its isotropic and
| stuff, however, that would also be true for the random number sequence.
| Hence, if one wants to have no difference between "integrate n" and
| "integrate m" with n!=m, the final velocities must be known, regardless
| of any desired analysis aspects which surely may be added on top of this
| argument.
|
| Particularly because of all the weird stuff users tend to come up with
| as soon as they gain full control of a program, I therefore still
| believe that the best way to adress this issue is to store the entire
| state of the random number generator (using the already existing
| functions and data structures in random.c to introduce local storage
| there) just before force_calc is called within the main integration loop
| for the last time, reverting the random number generator to these values
| automatically just before the forces are re-calculated at the start of
| integrate_vv. That should be fool-proof, since whatever happens after
| force_calc (thermostats, MC-moves,...) wouldn't matter, the
| re-calculated forces should _exactly_ match the originally calculated
| ones. And because there's nothing requiring random numbers in between,
| there should be no danger regarding re-using the same sequence for same
| tasks.
|
| Consequently, my opinion would be: Go for it! ;-)
I will follow this line if I find the time. There are probably some
changes that have to be incorporated into the checkpointing, namely the
states of the random number generator written to the checkpoint file.
At the moment, I'm quite occupied with other stuff...
| And what does everyone else think?
|
| Best wishes,
| Bernward.
Best regards,
Ulf
- --
Ulf D. Schiller * Room E5-117 * Phone +49 521 106-6198
Condensed Matter Theory Group
Faculty of Physics
University of Bielefeld
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCCgIutqL0QpvXQjERAnz2AJ9wD9JLQbkn8WiNhiwoEn7mjZovkwCgpEW6
Zb9OJfLAhtdOt1HwUyLUFwE=
=kIGZ
-----END PGP SIGNATURE-----
top of page
From: Bernward Mann <mann[4]> on 2005 02 08 14:12 CET
to: despresso[4]
cc:
subject: Re: Reentering integrator with DPD thermostat
Dear Ulf,
Dear D'Espressis,
calculating the forces only at the beginning of the integration loop
does not seem to work out IMHO, because you need them to propagate the
velocities for the second time, so, just by looking at the algorithm I
cannot imagine how the force_calc could be avoided. Furthermore, it
becomes impossible if also considering alternative integrators such as
NpT which sort of abuses parts of the VV-integrator for performance reasons.
In other news, you definitely need the velocities v(t+dt) at the end of
each integration cycle, if only to store them in a file for later
recovery! Of course one could argue that in an equilibrated system the
exact velocity distribution does not matter as long as its isotropic and
stuff, however, that would also be true for the random number sequence.
Hence, if one wants to have no difference between "integrate n" and
"integrate m" with n!=m, the final velocities must be known, regardless
of any desired analysis aspects which surely may be added on top of this
argument.
Particularly because of all the weird stuff users tend to come up with
as soon as they gain full control of a program, I therefore still
believe that the best way to adress this issue is to store the entire
state of the random number generator (using the already existing
functions and data structures in random.c to introduce local storage
there) just before force_calc is called within the main integration loop
for the last time, reverting the random number generator to these values
automatically just before the forces are re-calculated at the start of
integrate_vv. That should be fool-proof, since whatever happens after
force_calc (thermostats, MC-moves,...) wouldn't matter, the
re-calculated forces should _exactly_ match the originally calculated
ones. And because there's nothing requiring random numbers in between,
there should be no danger regarding re-using the same sequence for same
tasks.
Consequently, my opinion would be: Go for it! ;-)
And what does everyone else think?
Best wishes,
Bernward.
Ulf Schiller wrote:
> Dear ESPResSo developers,
>
> during my stay in Mainz I discussed with Bernward the issue of
> reentering the integrator while using a DPD thermostat. If
> recalc_forces==1, the forces are recalculated with different random
> numbers which lead to a different variance. This also arises with the
> Langevin thermostat, where the problem has been solved in v1.6.3a by
> introducing "additional heat" (the term is a bit misleading, IMHO).
> As far as I see, this solution can also be used for the DPD thermostat
> since the properties of the random noise are pretty much the same.
>
> Bernward also pointed out, that this does not lead to the same particle
> trajectories when restarting from a checkpoint. To come around this, the
> states of the random number generators have to be saved prior to the
> last force calculation before leaving the integrator. This state can
> then be restored upon reentry suchthat exactly the same forces are
> reproduced.
>
> At the moment, I am thinking about whether there might be a way to get
> around this problem at all - for example by some bookkeeping of when
> random numbers are drawn. For the mere integration of the particle
> trajectories the velocities v(t-0.5*dt) and v(t+0.5*dt) are sufficient,
> hence the new forces f(t+dt) are not always necessary at the end of the
> integration loop. Instead they could in general be calculated at the
> start of the loop.
> However, it is very likely (if not sure) that v(t+dt) or f(t+dt) will be
> needed for some analysis and then again one needs the forces after the
> loop. So maybe it isn't a good idea to change the integration loop at all.
>
> Anyway, it would be interesting to hear what the core developers think
> about this.
>
> I'd be happy about your comments.
> Cheers,
> Ulf
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Mehmet Sayar <sayar[4]> on 2005 02 04 15:02 CET
to: despresso[4]
cc:
subject:
Hi,
I made some bug fixes for the comforce potential and analysis tools for
the moment of inertia and principal axis calculations.
In the old version the moment of inertia calculation was wrong, and
therefore the principal axes was wrong. Now hopefully moment of inertia
calculation is working correctly. But the pricipal axis is still buggy.
So DO NOT use comforce and momentofinertia yet.
Mehmet
________________________________________________________
Mehmet Sayar - Postdoc MPI fur Polymerforschung
Email:sayar[4] Theory Group
Phone:+49-6131-379-166 Ackermannweg 10,
Fax: +49-6131-379-340 D-55128 Mainz, Germany
top of page
From: limbach[4] on 2005 02 04 11:16 CET
to: despresso[4]
cc:
subject: part print connectivity
Hi,
I added a new functionality to the part command which returns the connectivity
of a particle with other particles.
Documentation:
\verbatim part print connections [] \endverbatim
Returns the connectivity of the particle up to a certain number of
bonds specified by \ (defaults to 1). For particle 5 in a linear chain the
result up to range = 3 would look like:
\verbatim { { 4 } { 6 } } { { 4 3 } { 6 7 } } { {4 3 2 } { 6 7 8 } } \endverbatim
The function is useful when you want to create bonded interactions to all other
particles a certain particl is connected to. Note that this output can not be
used as
input to the part command. Check results if you use them in ring structures.
I also realized that other people added things to the part command without
documenting it, namely:
auto_exclusions
delete_exclusions
As you probably all use the documentation of the additional tcl commands as
reference for your daily work it is absolutely mandatory to update the
corresponding files. In this case doc/text/part.doc !!!
That's not a joke!
Greetings from Switzerland,
Hanjo
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
top of page
From: Ulf Schiller <uschille[11]> on 2005 02 03 16:54 CET
to: despresso[4]
cc:
subject: Reentering integrator with DPD thermostat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear ESPResSo developers,
during my stay in Mainz I discussed with Bernward the issue of
reentering the integrator while using a DPD thermostat. If
recalc_forces==1, the forces are recalculated with different random
numbers which lead to a different variance. This also arises with the
Langevin thermostat, where the problem has been solved in v1.6.3a by
introducing "additional heat" (the term is a bit misleading, IMHO).
As far as I see, this solution can also be used for the DPD thermostat
since the properties of the random noise are pretty much the same.
Bernward also pointed out, that this does not lead to the same particle
trajectories when restarting from a checkpoint. To come around this, the
states of the random number generators have to be saved prior to the
last force calculation before leaving the integrator. This state can
then be restored upon reentry suchthat exactly the same forces are
reproduced.
At the moment, I am thinking about whether there might be a way to get
around this problem at all - for example by some bookkeeping of when
random numbers are drawn. For the mere integration of the particle
trajectories the velocities v(t-0.5*dt) and v(t+0.5*dt) are sufficient,
hence the new forces f(t+dt) are not always necessary at the end of the
integration loop. Instead they could in general be calculated at the
start of the loop.
However, it is very likely (if not sure) that v(t+dt) or f(t+dt) will be
needed for some analysis and then again one needs the forces after the
loop. So maybe it isn't a good idea to change the integration loop at all.
Anyway, it would be interesting to hear what the core developers think
about this.
I'd be happy about your comments.
Cheers,
Ulf
- --
Ulf D. Schiller * Room E5-117 * Phone +49 521 106-6198
Condensed Matter Theory Group
Faculty of Physics
University of Bielefeld
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCAklCtqL0QpvXQjERAjM+AKCfANso0T/aWclDX2ta/fy8h7ZuEgCglcCG
GGdbtXSZoOdklgsKRWNC7os=
=3rLM
-----END PGP SIGNATURE-----
top of page
From: Vladimir Lobaskin <lobaskin[4]> on 2005 01 31 15:31 CET
to: despresso[4]
cc:
subject: Lattice Boltzmann code
Dear Espressors,
The lattice Boltzmann code for simulating hydrodynamics has been
implemented in Espresso. The objective is to model solvent-mediated
momentum transfer between solute particles.
__________________________________________________________________________
It works as an alternative thermostat. To invoke it please use
thermostat set lb
where
* temperature - desired temperature
* friction - microscopic friction coefficient (20 corresponds to some LJ
fluid, the value of the same meaning as the Langevin gamma)
* viscosity - desired solvent viscosity (I take 3.0, which is pretty
viscous)
* tgrid - time step for updating solvent velocities. Must be integer
number of MD time_step's. Larger values save CPU time for the expense of
accuracy.
* density - solvent mass density with respect to the solute (1.0 is a
good choice)
* gridsize - self-evident. The values smaller than solute particle size
do not make sense. (box_l/gridsize) must be integer. 1.0 is a good
choice but larger values could save some time for the expense of accuracy.
So, a resonable call would look like
thermostat set lb 1.0 20.0 3.0 0.01 1.0 1.0
_________________________________________________________________________
Important comments:
1. The code runs only with periodic boundary conditions in 3D. The
results are subject to physical PBC effects (like slower diffusion due
to hydrodynamic interactions with the periodic images).
2. The code is momentum conserving: once introduced center-of-mass drift
never disappears.
3. The code can be used with temperature = 0.0. It models then just the
viscous friction.
4. The code usually runs slower than Langevin MD or DPD as the number of
additional invisible degrees of freedom is roughly
18*(box_l/gridsize)^3, which makes an additional CPU effort comparable
to (box_l/gridsize)^3 LJ particles.
5. As of now, the code might be not stable with respect to nasty
parameter settings, so be careful.
6. The current version does not respect masses. Will be fixed soon.
7. I would be grateful for any reported bugs/instabilities.
Happy simulating!
Vladimir
top of page
From: arnolda[4] on 2005 01 21 11:07 CET
to: despresso[4]
cc:
subject: P3M bugs
Hello Espresso users,
Igor, Vincent and I found several bugs in P3M, which by now are fixed:
a. The charge sums were not recalculated if particles were added after setting
up the coulomb interactions, resulting in wrong energy and therefore pressure
values. Unfortunately, this is exactly the order used in checkpoints, so if
you do not retune the electrostatics after reading a checkpoint, your energies
and pressures are probably wrong.
b. Increasing the skin after tuning P3M lead to accesses outside of the real
space mesh. This may cause crashes as well as unpredictable tiny errors. This
occurs for example if you use cell tuning.
c. The squared sum of charges was wrong, so that the energy for nonneutral
systems was wrong.
d. The n_interpol=0 noninterpolating charge assignment was completely buggy,
and leads to forces only in the x-component and other funny results.
Basically, you could only run the Madelung testcase with this code. It has
been removed.
So check CAREFULLY whether any of these bugs affects your simulations,
especially bugs a. and b. if you use checkpoints.
Happy debugging,
Axel
top of page
From: Axel Arnold <arnolda[4]> on 2005 01 04 13:39 CET
to: despresso[4]
cc:
subject: error codes
Hello all,
Bernward suggested some time ago to encode all background errors with simples
codes (numbers), to simplify automatic parsing of the messages. Now Nils
rewrote all error reports such that they now have 3 digit error codes. Of
course these error codes will break any current parsing of the background
error messages (not the normal ones, rather something like
"background 0 {time_step not set}" ).
So anybodying parsing these errors has to update his scripts when Nils commits
his changes, which will probably be done on Thursday, if nobody complains.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Igor Pasichnyk <pasichny[12]> on 2004 12 09 09:04 CET
to: despresso[4]
cc: pasichny[12]
subject: error in p3m?
Servus!
It seems to me that for the case of nonzero overall charge P3M has a
small error in the calculating of energy. The variable p3m_square_sum_q
is NOT the square power of overall charge.
igor
top of page
From: Bernward Mann <mann[4]> on 2004 12 01 11:15 CET
to: despresso <despresso[4]>
cc:
subject: Bugfixing of v1.8.2b
Greetings!
After lots of small bugs have been purged (including those unavoidably
introduced by harmonization attemps), it may be a good time to remind
everyone of their advent Lent committments to Espresso: :-)
You wanted and agreed to review all the functions you added to the
program regarding their mass compatibility, checking that
mass-indepentend functions still work properly with and without masses,
and that everything depending on masses (e.g. center-of-mass or similar
issues) gives now the proper results. You wanted to make sure that all
your stuff is well documented, and that everything bigger (such as new
potentials, new integrators, new thermostats, etc.pp.) has its own
testcase (i.e. something which checks basic correctness within seconds)
and a more thorough sample script (i.e. something which may be running
for a week and will use long time averages, such as kremerGrest.tcl).
You wanted to re-run some of your scientific scripts of which you
already know the outcome, to check if with and without masses everything
is still giving the correct results.
It would be really great if you could soon find the time to fullfill
these promises. This might also be a great gift for Axel's ascension to
Ph.D. level, which'll occur in two weeks -- why not surprise him with a
new Espresso release, tested, documented and bug-free? why not show him,
that the Espresso spirit is far from being dead? why not demonstrate him
that Espresso users do not selfishly care only about their own projects,
but are willing to contribute to the package as a whole, from which they
already benefitted so much?
Hail to the spirit! ;-)
Bernward.
EDIT: Thanks to those whom I already saw starting with this enterprise!
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: "Limbach,Hans Joerg,LAUSANNE,NRC-FS" <Hans-Joerg.Limbach[6]> on 2004 11 30 16:57 CET
to: <despresso[4]>
cc:
subject: ABHmath.tcl
Hi,
I have rearanged the ABHmath.tcl file and written documentation for it =
(doc/text/math.doc). I have tried to harmonize the name conventions =
therein. Old names are still available for compatibility, but there use =
is not recommendet. I hope I did not introduce errors, but to be sure =
you should check yourself.
gmake docu has some problems still in statistics_chain.h with some =
parameter names in function
analyze_rdfchain
Amazing that it does work for other functions with the same =
construction. Any idears?
See you soon,
hanjo
top of page
From: Ulf Schiller <uschille[11]> on 2004 10 29 08:29 CEST
to: Burkhard Duenweg <duenweg[4]>
cc: "Limbach,Hans Joerg,LAUSANNE,NRC-FS" <Hans-Joerg.Limbach[6]>,
subject: Re: DPD force prefactors
Hallo,
Burkhard Duenweg wrote:
> was ich nicht verstehe, ist, wieso Du gamma auf 50 gesetzt
> hast. Die Vergleichbarkeit sollte doch gegeben sein, unabhaengig
> wie gross gamma gewaehlt ist.
Es ging mir darum, dass dpd_pref1 und dpd_pref2 die gleiche
Groessenordnung behalten. Konkret ergibt sich mit der Variante
dpd_pref1 = dpd_gamma/SQR(time_step); mit gamma=0.5, time_step=0.01
derselbe Wert fuer dpd_pref1 wie mit der Variante
dpd_pref1 = dpd_gamma/time_step; mit gamma=50, time_step=0.01.
Fuer diesen Zeitschritt ergibt sich dann eine aequivalente Relaxation
fuer beide Initialisierungsvarianten (dpd_pref2 wurde entsprechend
geaendert).
> Ausserdem ist 50 dermassen gross, dass zum einen wahnsinnig schnell
> relaxiert wird, und man zum anderen einen u.U. sogar einen
> kleineren Zeitschritt braucht (eben deswegen). M.a.W.: Mit dem
> Parameterwert habe ich etwas Bauchschmerzen.
Fuer time_step=0.01 ist die Relaxation mit gamma=50 und der
_geaenderten_ Initialisierung im Prinzip genauso schnell wie mit
gamma=0.5 und der _alten_ Initialisierung. Die Zeitskala der beiden
Plots ist die gleiche.
Wir haben auch darueber nachgedacht, wieviel Sinn ein so grosses gamma
macht, aber es geht ja nicht um eine physikalische Aussage, sondern um
den Test des Algorithmus.
Ich habe das System mal noch mit gamma=0.5 und der geaenderten
Initialisierung des Thermostaten simuliert. Es relaxiert wie erwartet
wesentlich langsamer, aber fuer time_step=0.001 und time_step=0.005 ist
die Uebereinstimmung weiterhin gut. Fuer time_step=0.01 habe ich noch
kein equilibriertes System, moeglicherweise ist man hier auch schon an
der Grenze der Stabilitaet des Algorithmus.
Viele Gruesse,
Ulf
--
Ulf D. Schiller * Room E5-117 * Phone +49 521 106-6198
Condensed Matter Theory Group
Faculty of Physics
University of Bielefeld
ATTACHMENTS:
"relaxation_gamma0.5.eps"
top of page
From: Burkhard Duenweg <duenweg[4]> on 2004 10 28 12:06 CEST
to: uschille[14]
cc: "Limbach,Hans Joerg,LAUSANNE,NRC-FS" <Hans-Joerg.Limbach[6]>,
subject: Re: DPD force prefactors
Hallo,
was ich nicht verstehe, ist, wieso Du gamma auf 50 gesetzt
hast. Die Vergleichbarkeit sollte doch gegeben sein, unabhaengig
wie gross gamma gewaehlt ist.
Ausserdem ist 50 dermassen gross, dass zum einen wahnsinnig schnell
relaxiert wird, und man zum anderen einen u.U. sogar einen
kleineren Zeitschritt braucht (eben deswegen). M.a.W.: Mit dem
Parameterwert habe ich etwas Bauchschmerzen.
Viele Gruesse
Burkhard.
--
/------------------------------------------------------------------\
| Burkhard Duenweg e-mail: duenweg[4] |
| Max-Planck-Institut Phone: +49-6131-379-198 |
| fuer Polymerforschung Fax: +49-6131-379-340 |
| Ackermannweg 10 Home Phone: +49-6721-186221 |
| D-55128 Mainz |
| Germany |
\------------------------------------------------------------------/
top of page
From: Ulf Schiller <uschille[11]> on 2004 10 28 11:07 CEST
to: "Limbach,Hans Joerg,LAUSANNE,NRC-FS" <Hans-Joerg.Limbach[6]>
cc: despresso[4], schmid[11]
subject: Re: DPD force prefactors
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hallo Hanjo,
hallo ESPResSo-Team,
Limbach,Hans Joerg,LAUSANNE,NRC-FS wrote:
> Ich habe mir die entsprechenden Codeteile auch nochmal angeschaut und
> ich habe den Eindruck, dass Du recht hast. Danke also schon mal fuers
> hartnaeckige nachsetzen. Koenntest Du mal ein paar Testlaufe
> durchfuehren, in denen Du die Relaxationszeit eines einfachen Systems
> (z.B. LJ Fluessigkeit) in Abhaengigkeit des Zeitschritts misst. Dass
> heisst, ein System aufsetzen und schauen, wie lange es dauert, dass das
> System einen bestimmten Sprung in der Temperatur nachvollzogen hat.
> Diese Relaxationszeit sollte unabhaengig vom Zeitschritt sein. Ich
> dachte eigentlich, dass ich solche Tests beim Implementieren
> durchgefuehrt habe, aber vielleicht habe ich einen Fehler gemacht. Hier
> in Lausanne bin ich leider im Moment noch dabei erstmal die noetige
> Hardware zu implementieren und zu konfigurieren, so dass ich im
> Augenblick solche Tests nicht selber durchfuehren kann.
ich habe jetzt mal ein System aus LJ-Kugeln (epsilon=1.0, sigma=1.0,
cutoff=1.22246, shift=1.0) bei einer Dichte von 0.7 (868 Teilchen in
einer kubischen Box der Laenge 10.7437) simuliert.
Das System wurde mit einem DPD-Thermostaten (gamma=0.5, cutoff=1.22246)
auf eine Temperatur von 1.0 equilibriert. Dann wurde die Temperatur des
Thermostaten auf 0.5 gesetzt und gemessen.
Die Kurven zeigen die Relaxation der Temperatur fuer verschieden grosse
Zeitschritte ([setmd time_step]).
In 'relaxation_orig.eps' sind die Kurven fuer die "Original"-ESPResSo
(v1.6.5b) Implementation. Die Relaxation ist hier fuer verschiedene
Zeitschritte unterschiedlich.
Fuer die Kurven in 'relaxation_neu.eps' habe ich die Initialisierung des
DPD-Thermostaten geaendert: In thermo_init_dpd() werden die Vorfaktoren
der Kraefte jetzt so initialisiert:
dpd_pref1 = dpd_gamma/(time_step);
dpd_pref2 = sqrt(24.0*temperature*dpd_gamma/(time_step));
Um vergleichbare Kurven zu bekommen, wurde dpd_gamma=50 gesetzt.
Hier liegen die Relaxationskurven uebereinander.
Diese Kurven sprechen meiner Meinung nach fuer die zweite Variante.
Beste Gruesse,
Ulf
- --
Ulf D. Schiller * Room E5-117 * Phone +49 521 106-6198
Condensed Matter Theory Group
Faculty of Physics
University of Bielefeld
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBgLbTtqL0QpvXQjERAuOjAJ93VdAvSvAg1KZMxKHsSnGWjYnGegCfWrFY
xJ2bYYzZDO66T795WLw7aAY=
=9Q3n
-----END PGP SIGNATURE-----
ATTACHMENTS:
"relaxation_orig.eps"
"relaxation_neu.eps"
top of page
From: Torsten Stuehn <stuehn[4]> on 2004 10 26 17:51 CEST
to: despresso <despresso[4]>
cc:
subject: change of CVSROOT
Hello all,
our CVSROOT Server for Espresso and EspressoPR has changed.
If you only used cvs for Espresso, then change your CVSROOT
environment variable to the following:
# bash:
export CVSROOT=:ext:cvsth:/cvs/cvsroot
# tcsh:
setenv CVSROOT :ext:cvsth:/cvs/cvsroot
If you don't want to change your CVSROOT because you use
cvs also for other stuff (e. g. papers) you have to use
the -d option in your cvs commands each time you want to
access the Espresso stuff:
# example:
cvs -d :ext:cvsth:/cvs/cvsroot update Espresso
In any case you have to enter your password to access the
repository.
The new Espresso CVS server will be accessible from outside the
institute as soon as i know the ip-number and port that we can use.
greetings,
Torsten
--
Torsten Stuehn
MPI für Polymerforschung
Ackermannweg 10
55128 Mainz / Germany
Tel. +49-(0)6131-379262
Fax +49-(0)6131-379100
top of page
From: Bernward Mann <mann[4]> on 2004 10 25 10:07 CEST
to: despresso <despresso[4]>
cc:
subject: D'Espresso Meeting on Masses Tuesday @ 11am
Greetings!
Tomorrow we'll have another D'Espresso Meeting, starting at 11am in the
Tower Room.
As special guest Arijit, our external expert on masses from the
University of Muenster (group of Prof. Heuer), is with us today and
tomorrow, and at that meeting he'll introduce us into some of his ideas
for the near future of the code. Hence everyone whose simulation
specialities might be influenced by the introduction of masses (i.e.
users of anything related to the center-of-mass or NpT or ...) should
strongly consider to attend, while all others are of course cordially
invited, too! Although today we'll be rather busy with algorithmical
questions, there are some slots left tomorrow if you also want to
discuss with Arijit - please let me know if that's the case!
See you tomorrow (if not today as well),
Bernward.
P.S.: If that hasn't already been convincing enough, Axel will throw in
some remarks on our preliminary findings of the benchmarking comparision
between versions Icheb and Mezoti, and comment on the influence of the
change of the force interface on ESPResSo's overall performance.
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Ulf Schiller <uschille[11]> on 2004 09 30 16:35 CEST
to: despresso[4]
cc:
subject: DPD force prefactors in thermo_init_dpd()
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello ESPResSo-Team,
I am wondering why the *square* of the time step is used in
| dpd_pref1 = dpd_gamma/SQR(time_step);
and
| dpd_pref2 = sqrt(24.0*temperature*dpd_gamma/SQR(time_step));
to initialize the force prefactors of the DPD thermostat.
I'd expect something like dpd_gamma/time_step to have the random force
scaled by 1/sqrt(time_step). In thermo_init_langevin() the prefactors
are scaled this way, and I don't see why it is done differently in DPD.
Best regards,
Ulf
- --
Ulf D. Schiller
Condensed Matter Theory Group
Faculty of Physics
University of Bielefeld
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBXBmwtqL0QpvXQjERAh/nAKCSWoMCjMFbn6jR+zUObjk7vlyUsQCgnKbM
9RueG5+l8yQqXmq4488ExXw=
=BgbU
-----END PGP SIGNATURE-----
top of page
From: Bernward Mann <mann[4]> on 2004 09 24 18:14 CEST
to: despresso <despresso[4]>
cc:
subject: Christmas only three month away (Mezoti v1.7.5 released & re-tagged)!
For all of you who are not yet at Hanjo's rousing party (shame on you!)
this is to let you know that
(1) the bug in the electrostatics has now _really_ been fixed, i.e. now
also DH-, MMMnD-, Maggs- and all the other -electrostatics systems work
properly with nonbonded potentials, having their forces correctly
calculated; the P3M/LJ-dreamteam isn't affected, as that one was
(apparently the only one to be) fixed last time.
(2) the new features such as MPIFAKE etc. have been tested (see Axel's
eMail from yesterday), the (hopefully) last remaining bugs from the
three big changes error handling / force interface / Maggs
electrostatics incl. no-verlet-list-feature are now removed.
(3) therefore we re-tagged the current version v1.7.5 (Mezoti) as of
NOW, so whenever you type
cvs checkout -r Mezoti Espresso
you'll end up with today's working and bug-free (well, always only
almost) version.
So, with Christmas only three month away, consider this your first gift!
Cheers,
Bernward.
P.S.: Still reading? Still not at Hanjo's party? Hurry up!!!
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Axel Arnold <arnolda[4]> on 2004 09 23 10:27 CEST
to: despresso[4]
cc:
subject: MPIFAKE
Hello all,
there is a new option in the Makefile, currently only for Linux, which is
called MPIFAKE. If set to yes, a simple fake MPI implementation (mpi.h/mpi.c)
is used, which only works on one processor. Since most MPI calls are simply
empty, single CPU jobs run MUCH faster than before. The testsuite finishes on
LCARS within 10 secs.
I did not provide a fake mpirun, so that you have to start the scripts by
Linux/Espresso directly. The testsuite script has a flag -nompi,
which does this, so that one can test the fake MPI.
Everyone running jobs on only one CPU should definitely check it out!
Axel
PS: Of course this does not need a lamd or whatever running in the
background...
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Bernward Mann <mann[4]> on 2004 09 22 10:09 CEST
to: Christian Holm <holm[4]>,
cc: arnold <arnolda[4]>,
subject: PeP-/Espresso-Picture TODAY @ 3:30pm
--- Apologies to everyone getting this eMail twice! ---
Dear Peppies,
Dear Depress{ives | os},
before the two Godfathers of ESPResSo leave us forever, our Fearless
Leader wishes to have a group picture with everyone being either a
PersonallyEnslavedPerson (PeP) or/and a Destroyer of Espresso (D'Espresso).
So, to not conflict with the lunch schedules or lunch time activities of
some of our 3rd wing members, I'd suggest
---> TODAY @ 3:30pm <---
as date and time for the event, with our coffee room as the meeting
point (although we'll probably take the picture somewhere else) - that
way we'll be on time for Igor's party starting at 4pm! ;-)
See you there,
Bernward.
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Axel Arnold <arnolda[4]> on 2004 09 21 16:38 CEST
to: despresso[4]
cc:
subject: P3M
Hello all,
P3M now has a second tuning mechanism, tunev2, which should be faster than the
old one in general, but tests possible parameters more thoroughly. It uses a
bisection to determine r_cut, however, still the slow error estimate.
P3M can now be started without interpolation. Setting n_interpol to 0 (which
is now also a tuning parameter) switches off both the caf interpolation as
well as the saving of the charge fractions. For charge assignment orders
below 5 this is faster than the interpolation. However, higher charge
assignment orders are rarely used.
In short, instead of
inter coulomb x p3m tune accuracy 0.01
use
inter coulomb x p3m tunev2 accuracy 0.01 n_interpol 0
Depending on the system, the tuning is about 2-10 times faster than before,
while the noninterpolating version is around 5 to 20% faster, during the
simulation. Your mileage depends on the charge assignment order you currently
use. At 1 or 2, without interpolation you are like 5 times faster, but for 3
or four, it is around 5-20%, as said before. At 5 and above, interpolation is
faster.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Axel Arnold <arnolda[4]> on 2004 09 21 11:14 CEST
to: despresso[4]
cc:
subject: Fixed bug that prevented ghost updates
Hello all,
since September 16th, Espresso contains a severe bug which prevents ghost
updates in the domain decomposition. Since this bug is detected by various
tests in the testsuite, this code should never have made it into CVS. So
PLEASE run the testsuite before committing!!!!!
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Ulf Schiller <uschille[11]> on 2004 09 14 09:48 CEST
to: despresso[4]
cc:
subject: Constraints und Checkpoints
Hallo ESPResSo-Team,
soweit ich sehe, werden Constraints (wall, sphere,...) noch nicht in
Checkpoints gespeichert - oder hab' ich da was uebersehen?
Beste Gruesse,
Ulf
ATTACHMENTS:
"signature.asc"
top of page
From: Bernward Mann <mann[4]> on 2004 09 14 09:24 CEST
to: despresso <despresso[4]>
cc:
subject: Bug in electrostatics fixed, supplemental.
Hi once more,
just a quick addition to yesterday's message concerning the
circumstances under which the error occurred:
- As soon as ELECTROSTATICS were compiled in, you had been in danger.
- Bjerrum-length > 0 (=electrostatics active) led to having DPD- and
LJ-forces added twice to your particle.
- Bjerrum-length = 0 (no electrostatics on) wiped out all of your DPD-
and LJ-forces from the system, so you ended up having no effective
short-range forces whatsoever [this case I forgot to mention yesterday].
But in essence the take-home message remains: Re-run everything you
produced with v1.7.2a through v1.7.3d, and before complaining about
this, think about joining those few who actually help testing new
versions of Espresso (and without whom this bug wouldn't have been found
that quick).
Sorry for bothering you again,
Bernward.
----- Forwarded Message: -----
Dear all,
this is to let you know that the bug Mehmet mentioned has been fixed.
As assumed it was introduced in v1.7.2a with the new forces interface
(and is therefore also part of our tagged Mezoti-version -- that means
that we will re-tag it as soon as everyone of you did a re-check of the
current version).
It only occured if DPD and/or nonbonded potentials were combined with
active electrostatics, causing all nonbonded forces to be off by a
factor of 2, i.e. particle forces to be falsely calculated to f =
2*(f_DPD+f_LJ) + f_{real space electrostatics}.
It remains worrysome though that the testsuite didn't capture this error
(the 'madelung.tcl' does integrate, but can't be considered a valid test
with its supposed forces=0) which gives rise to the question what other
possible problems it might not be able to detect. Any ideas, suggestions
on this?
Now not only that error was corrected, but we also rearranged some loops
which saves 6*N memory accesses per timestep; since memory speed has
become the bottle neck of Espresso, this should therefore result in a
small speed-up.
So do upgrade to the newest version if you're already past v1.7.1c, if
not (shame on you!) upgrade anyway.
Regards,
Bernward.
Mehmet Sayar wrote:
>Hi all,
>
>I have found a bug in the latest version of Espresso. Unfortunately I
>still did not manage to find the solution or where the error is. But I
>just wanted to warn Espresso users, just in case if someone uses the
>latest version for a system with electrostatics.
>
>The bug was introduced in version 20040828-Espresso_v1.7.2b.tar.gz.
>The last bug free version that I was able to find is:
>20040826-Espresso_v1.7.1c.tar.gz
>The current version still had the bug the last time I checked.
>
>Here is a brief outline of the problem: I did a constant energy simulation
>(no thermostat, no npt, good old micro-canonical simulation) for a simple
>system. The system includes Fene bonds, angular potential, and LJ
>interactions. The energy is constant upto 5-6 digits. As soon as I
>introduce electrostatic interactions, the system energy starts
>fluctuating (~10 %).
>
>Surprisingly if the energy is calculated for a fixed configuration the
>energy seems to be correct. The error occurs when the system is
>integrated.
>
>In version 1.7.2b the force interface was changed. So probabily during the
>process this bug was introduced. Since the energy seems to be correct for
>a fixed configuration, but wrong while integrating the system, we suspect
>that the bug has to do with the force calculation.
>
>I tried using debye-hueckel and p3m for electrostatics, and it looks like
>both has the same problem.
>
>If you have more questions, or suggestions for how to fix this bug let me
>know. Otherwise until Axel comes back, use the latest version with
>extra-caution.
>
>Mehmet
>
>
>
>________________________________________________________
>Mehmet Sayar - Postdoc MPI fur Polymerforschung
>Email:sayar[4] Theory Group
>Phone:+49-6131-379-166 Ackermannweg 10,
>Fax: +49-6131-379-340 D-55128 Mainz, Germany
>
>
>
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Bernward Mann <mann[4]> on 2004 09 13 17:21 CEST
to: despresso[4]
cc:
subject: Bug in electrostatics fixed.
Dear all,
this is to let you know that the bug Mehmet mentioned has been fixed.
As assumed it was introduced in v1.7.2a with the new forces interface
(and is therefore also part of our tagged Mezoti-version -- that means
that we will re-tag it as soon as everyone of you did a re-check of the
current version).
It only occured if DPD and/or nonbonded potentials were combined with
active electrostatics, causing all nonbonded forces to be off by a
factor of 2, i.e. particle forces to be falsely calculated to f =
2*(f_DPD+f_LJ) + f_{real space electrostatics}.
It remains worrysome though that the testsuite didn't capture this error
(the 'madelung.tcl' does integrate, but can't be considered a valid test
with its supposed forces=0) which gives rise to the question what other
possible problems it might not be able to detect. Any ideas, suggestions
on this?
Now not only that error was corrected, but we also rearranged some loops
which saves 6*N memory accesses per timestep; since memory speed has
become the bottle neck of Espresso, this should therefore result in a
small speed-up.
So do upgrade to the newest version if you're already past v1.7.1c, if
not (shame on you!) upgrade anyway.
Regards,
Bernward.
Mehmet Sayar wrote:
>Hi all,
>
>I have found a bug in the latest version of Espresso. Unfortunately I
>still did not manage to find the solution or where the error is. But I
>just wanted to warn Espresso users, just in case if someone uses the
>latest version for a system with electrostatics.
>
>The bug was introduced in version 20040828-Espresso_v1.7.2b.tar.gz.
>The last bug free version that I was able to find is:
>20040826-Espresso_v1.7.1c.tar.gz
>The current version still had the bug the last time I checked.
>
>Here is a brief outline of the problem: I did a constant energy simulation
>(no thermostat, no npt, good old micro-canonical simulation) for a simple
>system. The system includes Fene bonds, angular potential, and LJ
>interactions. The energy is constant upto 5-6 digits. As soon as I
>introduce electrostatic interactions, the system energy starts
>fluctuating (~10 %).
>
>Surprisingly if the energy is calculated for a fixed configuration the
>energy seems to be correct. The error occurs when the system is
>integrated.
>
>In version 1.7.2b the force interface was changed. So probabily during the
>process this bug was introduced. Since the energy seems to be correct for
>a fixed configuration, but wrong while integrating the system, we suspect
>that the bug has to do with the force calculation.
>
>I tried using debye-hueckel and p3m for electrostatics, and it looks like
>both has the same problem.
>
>If you have more questions, or suggestions for how to fix this bug let me
>know. Otherwise until Axel comes back, use the latest version with
>extra-caution.
>
>Mehmet
>
>
>
>________________________________________________________
>Mehmet Sayar - Postdoc MPI fur Polymerforschung
>Email:sayar[4] Theory Group
>Phone:+49-6131-379-166 Ackermannweg 10,
>Fax: +49-6131-379-340 D-55128 Mainz, Germany
>
>
>
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Mehmet Sayar <sayar[4]> on 2004 09 10 09:53 CEST
to: despresso[4]
cc:
subject: Bug in electrostatics.
Hi all,
I have found a bug in the latest version of Espresso. Unfortunately I
still did not manage to find the solution or where the error is. But I
just wanted to warn Espresso users, just in case if someone uses the
latest version for a system with electrostatics.
The bug was introduced in version 20040828-Espresso_v1.7.2b.tar.gz.
The last bug free version that I was able to find is:
20040826-Espresso_v1.7.1c.tar.gz
The current version still had the bug the last time I checked.
Here is a brief outline of the problem: I did a constant energy simulation
(no thermostat, no npt, good old micro-canonical simulation) for a simple
system. The system includes Fene bonds, angular potential, and LJ
interactions. The energy is constant upto 5-6 digits. As soon as I
introduce electrostatic interactions, the system energy starts
fluctuating (~10 %).
Surprisingly if the energy is calculated for a fixed configuration the
energy seems to be correct. The error occurs when the system is
integrated.
In version 1.7.2b the force interface was changed. So probabily during the
process this bug was introduced. Since the energy seems to be correct for
a fixed configuration, but wrong while integrating the system, we suspect
that the bug has to do with the force calculation.
I tried using debye-hueckel and p3m for electrostatics, and it looks like
both has the same problem.
If you have more questions, or suggestions for how to fix this bug let me
know. Otherwise until Axel comes back, use the latest version with
extra-caution.
Mehmet
________________________________________________________
Mehmet Sayar - Postdoc MPI fur Polymerforschung
Email:sayar[4] Theory Group
Phone:+49-6131-379-166 Ackermannweg 10,
Fax: +49-6131-379-340 D-55128 Mainz, Germany
top of page
From: Bernward Mann <mann[4]> on 2004 09 02 11:57 CEST
to: despresso <despresso[4]>
cc:
subject: External/Tagged Mezoti released
Dear all,
just a quick follow-up to yesterday's meeting: As agreed upon, the
current state of Espresso has now been conserved and remains accessible
by either executing 'cvs -r Mezoti Espresso' in a superdirectory of your
choice, or by using the compressed archive stored in the usual place
(~pep/Extern_Espresso/20040902-Espresso_v1.7.2e.Mezoti.tar.gz). That
version has been tested to compile and testsuite on all our current
platforms (Tru64, Alpha, Power4, G5, Xeon, AthlonMP, AMD64, Opteron)
with reasonable combinations of config-flags.
Next in line will be the addition of Maggs electrostatics (Igor), a new
P3M-tuning (Axel), the switch to FFTW3 (Torsten), at which point we will
reach the v1.8 (Rebi) branch; from there, Matej will incorporate
Arijit's mass implementation for a final release of v2.0 (Azan). To
allow you a first glimpse of this bright future, attached you'll find
how Espresso (will) look(s) like as Mezoti, Rebi and Azan.
Best wishes,
Bernward.
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
ATTACHMENTS:
"mezoti_rebi_azan.jpg"
top of page
From: Bernward Mann <mann[4]> on 2004 08 30 16:35 CEST
to: despresso <despresso[4]>
cc:
subject: Mezoti, LCARS, and the Future
Beloved Followers,
your faith has surely got a new boost with the arrival of Mezoti (aka
v1.7.x-branch of ESPResSo) which does not only incorporate vast error
handling capabilities and a complete rewrite of the forces interface,
but which also opens the gate to the new Holy Grounds of LCARS (aka the
48x 2.0 GHz Opteron cluster) at which your prayers for numbered
(re)solutions will soon be heard with godlike speed! To strengthen your
resolution, there will be a service (aka ESPResSo-meeting) this
Wednesday, 1st of September, after lunch at 13h probably in the Tower Room.
Tentative schedule:
- Important things to know about Mezoti, e.g. how to deal with the error
handling.
- Upgrades scheduled for the immediate future, i.e. Maggs electrostatics
and masses.
- FAQ on LCARS, e.g. compiling issues, queueing system, and access control.
After most of you left the tedious task of debugging and releasing the
latest versions with their profound changes to Axel and myself despite
Axel's several eMails asking for your assistance, instead of helping us
a great deal by quickly checking out the new version to a new directory
and test-running your scripts against it, it would be highly appreciated
if you could at least show up on Wednesday to inform yourself on the
changes which are now part of ESPResSo.
Note that if you want to have access to LCARS, you'll have to attend
that meeting to be able to run jobs there later.
Best regards,
Axel & Bernward.
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Axel Arnold <arnolda[4]> on 2004 08 26 16:15 CEST
to: despresso[4]
cc:
subject: New short ranged force evaluation format
Hello all,
after the changes in the error handling, the second major change to the code
is the new force/energy evaluation scheme. The forces are no longer directly
added to the particles, but return and added in ad_(non)bonded_force.
Therefore the NPT algorithm has no longer to be built into the potentials it
is supposed to work with, and the pressure calculation is much less obscure
than before with the force saving and restoring. For details, rts.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Axel Arnold <arnolda[4]> on 2004 08 19 17:04 CEST
to: despresso[4]
cc:
subject: Error handling
Hello all,
a new error handling code has been put into Espresso. Additionally, I fixed a
lot of bugs in the parser codes, and some other bugs that ran across my way.
Using the error handling code (ok, there is no docu yet...):
Instead of the old
fprintf(stderr, "..."); errexit()
scheme, you have to include "errorhandling.h"
and call
char *errtxt = runtime_error(string_length);
sprintf(errtxt, "...");
The string_length just has to be larger than the actual error message, so
typically 128+n_i*TCL_INTEGER_SPACE+n_d*TCL_DOUBLE_SPACE will do.
Afterwards the program will go on until the runtime errors are collected, so
make sure it does not crash. Just exiting the current procedure often does
the job, but look at the examples in the code.
If you write a new Tcl command, make sure that at the end you call
mpi_gather_runtime_errors(interp, error_code). If the error_code is TCL_OK
and no runtime errors occured, it will simply return TCL_OK, but if an
runtime error occurs, it will be set as the interpreters result. If the state
was already TCL_ERROR, the background errors are appended, so the original
error message is not lost. In case of errors, the routine returns TCL_ERROR,
so in most cases you are done with
return mpi_gather_runtime_errors(interp, error_code);
Again, see the code.
For getting accomplished with the error handling, it might be useful to start
an interactive Espresso session. There are only very little parameter
combinations left, that will crash Espresso instead of giving a nice, clean
error message. Just try an integrate 1000 as your first command.
However, the new error handling affects nearly all code portions, so there
might be some strange effects left, so I would really like you all to test
the stuff.
Thanks,
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Bernward Mann <mann[4]> on 2004 07 05 11:49 CEST
to: sathish[4], Despresso <despresso[4]>
cc:
subject: Re: ESPResSo-Meeting Tue Jul 6th @ 11AM
Good point, Satish:
It's on TUESDAY at 11AM in the morning in the TOWER ROOM (i.e. the usual
place and time for PePpies).
See you there (or somewhere else),
Bernward.
sathish[4] wrote:
>is it tuesday or july 5th?
>
>On Monday 05 July 2004 08:34, you wrote:
>
>
>>Dear Developers, Friends & Foes of our beloved ESPResSo,
>>
>>this is to inform you about our next PeP-Meeting which'll be devoted
>>entirely to important and insightful background information on recent
>>enhancements and adjustments to the simulation program.
>>
>>The tentative schedule reads:
>>11:00h-11:03h Axel on the constantness of T in a Langevin thermostat
>>11:04h-11:05h Discussion
>>11:06h-11:34h Bernward on the algorithm, implementation, and parameters
>>of the new NpT-Integrator
>>11:35h-11:45h Ira on the enhancement of the NpT-integrator to tackle 2D
>>and 1D (neutral) systems
>>11:46h-12:30h Lunch Break (facultative)
>>
>>This meeting may be of interest to you, if you've ever wondered why
>>there was (and no longer is) a difference in the temperature after an
>>"integrate 1", "integrate 10", and "integrate 10000", i.e. why in
>>the first cases may be too low by up to 20something% (as pointed out
>>some time ago by Dmytro), or if you always wanted to simulate something
>>in a NpT-ensemble but never dared to ask how to choose the many
>>parameters in a meaningful way.
>>Also, if you have anything else on your mind regarding ESPResSo, or if
>>you just wanna seize the chance of meeting some of its core developers
>>in person, then you shouldn't falter but join us tomorrow!
>>
>>Bernward.
>>
>>P.S.: No free ESPResSo-questions for you anymore if you don't show up!
>>;-)
>>
>>
top of page
From: Bernward Mann <mann[4]> on 2004 07 05 08:34 CEST
to: despresso <despresso[4]>
cc:
subject: ESPResSo-Meeting Tue Jul 5th @ 11AM
Dear Developers, Friends & Foes of our beloved ESPResSo,
this is to inform you about our next PeP-Meeting which'll be devoted
entirely to important and insightful background information on recent
enhancements and adjustments to the simulation program.
The tentative schedule reads:
11:00h-11:03h Axel on the constantness of T in a Langevin thermostat
11:04h-11:05h Discussion
11:06h-11:34h Bernward on the algorithm, implementation, and parameters
of the new NpT-Integrator
11:35h-11:45h Ira on the enhancement of the NpT-integrator to tackle 2D
and 1D (neutral) systems
11:46h-12:30h Lunch Break (facultative)
This meeting may be of interest to you, if you've ever wondered why
there was (and no longer is) a difference in the temperature after an
"integrate 1", "integrate 10", and "integrate 10000", i.e. why in
the first cases may be too low by up to 20something% (as pointed out
some time ago by Dmytro), or if you always wanted to simulate something
in a NpT-ensemble but never dared to ask how to choose the many
parameters in a meaningful way.
Also, if you have anything else on your mind regarding ESPResSo, or if
you just wanna seize the chance of meeting some of its core developers
in person, then you shouldn't falter but join us tomorrow!
Bernward.
P.S.: No free ESPResSo-questions for you anymore if you don't show up! ;-)
--
_________________________________________
Dipl.-Phys. Bernward A. Mann, M.A. (USA)
Max-Planck-Institut fuer Polymerforschung
Ackermannweg 10
D-55128 Mainz
Phone: +49-(0)6131-379-481
Fax-#: +49-(0)6131-379-340
eMail: mann[4]
top of page
From: Axel Arnold <arnolda[4]> on 2004 06 11 11:53 CEST
to: despresso[4]
cc:
subject: Restart of Langevin changed
Hello all,
when recalc_forces is set, e.g. because a bond was removed, the box rescaled
or just the forcecap changed, now the Langevin thermostat has a different
prefactor in the random forces. This is necessary since otherwise the
temperature drops with the rate of force recalculations (has something to do
with missing correlations). If you experience any strange behaviour of the
temperature due to the new stuff, ask me.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Axel Arnold <arnolda[4]> on 2004 05 19 14:26 CEST
to: despresso[4]
cc:
subject: Dmytro's integrator bug
Hello all,
Dmytro's bug is actually only partially a bug. The intended behaviour of
Espresso is that when you leave the integrator, do some analysis and start
again, the forces are not recalculated. That didn't work (for developers:
recalc_forces is set by cells_resort_particles, but the force calculation in
side the integrator loop did not unset it).
Now you can leave and reenter the integrator without disturbing the thermostat
as long as you do not provoke a recalc_forces (e.g. by changing interactions,
timestep etc.). Otherwise the forces are recalculated, which actually leads
to errors, because the first step of a VV implementation is always wrong,
since you need velocities of the previous time step. This is something we
probably cannot do much about as long as no one comes up with a better
integration scheme.
Therefore be careful when leaving the integrator!
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Dmytro Antypov <antypov[4]> on 2004 05 18 18:17 CEST
to: despresso[4]
cc:
subject: integration bug
Hi All,
Before going on holiday I want to share with you my recent Espresso
experience. It started from measuring pressure, the ideal component of
which was persistently underestimated as well as the average kinetic
energy.
As a test, I took a system of 3240 LJ particles (those repulsive ones
with a cut_off of 1.122462) at \rho=0.7 and run it using time_step=0.005
and a thermostat:
thermostat langevin 1 0.1
I measured the kinetic energy for such a system every N time steps (i.e.
integrate $N and then analyze energy) and found that result depends on
N! The expected value for the kinetic energy is 0.5kT(3N-1)=4859.5 but
instead I got:
N Ekin
1000 4857.94 almost the same
100 4831.59 0.6% lower
10 4628.30 5.0% lower
1 4604.15 5.5% lower
If you increase the friction coefficient, gamma, than it slightly
improves the situation while decreasing the time step does not seem to
do anything. NVE simulations with the thermostat OFF look reasonably
well and do not have this weird N-dependency. However, even for an ideal
gas with the thermostat ON, the measured temperature is still below the
expected value. For N=100 and gamma=1.0 I had about 0.3% discrepancy.
The attached file shows 5 values of the pressure averaged over 2mln time
steps each in a 10mln run and they all are noticeably below the expected
value 0.7.
It seems like the thermostat force is not initialized properly when
starting the integrate command.
Regards.
Dmytro.
ATTACHMENTS:
"ideal_g1.ps"
top of page
From: Dmytro Antypov <antypov[4]> on 2004 05 04 14:40 CEST
to: despresso[4]
cc:
subject: velocity bug
Hi All,
This message is probably mainly to The developers of Espresso.
Apparently, if you run a new simulation starting from a saved (pos,
v)-configuration using a different time step, the velocities are
rescaled by a factor of dt_old/dt_new.
The tcl script
setmd time_step 0.01
puts "Ekin = [analyze energy kinetic]"
puts "[part 0 print pos] [part 0 print v]"
setmd time_step 0.001
puts "Ekin = [analyze energy kinetic]"
puts "[part 0 print pos] [part 0 print v]"
Save_File
gives me
Ekin = 4734.30804141
-6.45803213932 100.975047276 9.91696251486 1.26816325044 -0.896249895294
0.265870159269
Ekin = 4734.30804141
-6.45803213932 100.975047276 9.91696251486 12.6816325044 -8.96249895294
2.65870159269
So now the velocities stored into a configuration file are ten times
bigger.
If you put the integrate command in the middle like:
setmd time_step 0.01
puts "Ekin = [analyze energy kinetic]"
puts "[part 0 print pos] [part 0 print v]"
integrate 2
setmd time_step 0.001
puts "Ekin = [analyze energy kinetic]"
puts "[part 0 print pos] [part 0 print v]"
Save_File
it gives:
Ekin = 4734.30804141
-6.45803213932 100.975047276 9.91696251486 1.26816325044 -0.896249895294
0.265870159269
Ekin = 473481.691974
-6.43156996378 100.958919135 9.92254102171 13.8363507103 -7.21290552522
2.90649261946
i.e. now these wrong velocities go straight in the integrator.
The same problem may be with the forces as well, I did not check.
top of page
From: mann[4] on 2004 04 30 11:45 CEST
to: despresso[4]
cc:
subject: Pre-order now: Icheb to hit stores today!
Valued Customer,
as loyal user and/or developer of ESPResSo you might be delighted to learn that
the all-new version v1.6 has been released!
Just some of Icheb's breath-taking features:
- a new and working (!) NpT-integrator
- different thermostats to select from
- variety of new potentials
- a bunch of new analysis options
- molecular topology extensions
- NEMD, DPD, NPTISO, DD-EX, and lots of other new abbreviations
- increased performance now only limited by your system's architecture
- tons of bugfixes, better concealment of remaining bugs, heaps of new ones
- and much, much more!
Here's why you should upgrade right now:
- no support for old versions (none for the new one, too)
- read the RELEASE_NOTES for what you would miss otherwise
- be honest: Icheb sounds much nicer than Neelix (and also looks better)
So, don't hesitate, get your FREE copy of ESPResSo today!
###
### this message was brought to you by 'cvs update -d'
###
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
top of page
From: Axel Arnold <arnolda[4]> on 2004 04 29 17:40 CEST
to: despresso[4]
cc:
subject: ghost communication
Hello Espresso users,
the domain decomposition now uses a prefetch and poststore optimization. If
you don't know, what that is, it probably doesn't matter, but if you
experience anything strange which might be related to the ghost communication
(like lost interactions), blame it on me...
Otherwise things should be slightly faster.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: limbach <limbach[4]> on 2004 04 28 14:14 CEST
to: despresso <despresso[4]>
cc:
subject: New Potentials
Hi All!
The implementation of some new potentials is finished:
1) *Torsional dihedral angle potentials:* (four body interactions):
dihedral
More information: Documentation of the tcl inter command and the
file dihedral.h
2) * Tabulated bonded potentials:
*
tabulated
Types are: bond, angle and dihedral.
More information: Documentation of the tcl inter command and the
file tab.h
*
*For the other changes read the RELEASE_NOTES.
I hope that there are not too much bugs in the new features!
Hanjo
*
*_____________________________________
Dr. Hans Jörg Limbach
MPI for Polymer Research, Mainz,
Theory Group
Email: limbach[4]
Phone: +49-6131-379-145
Fax: +49-6131-379-340
_____________________________________
top of page
From: Bernward Mann <mann[4]> on 2004 03 22 15:01 CET
to: despresso <despresso[4]>
cc:
subject: Error in the Pressure
Dear Despressives,
last night I stumbled across an error in the derivation of bonded
virials, which was introduced into v1.5.Alpha by the new particle
structure's gurus: While the x-component was always correct, the y- and
z-components also contained whatever (rescaled) forces the particle
under consideration had at that time; particularly particles with more
than one bond got heavily overestimated. Note that the actual
simulations are NOT affected by this UNLESS you've used the results of
'analyze pressure' on the script-level to change some of the system
parameters. The pressure results, however, will be off by a deviation
which strongly depends on SQR(time_step): For large time_step and/or
system forces orders of magnitude larger than the bonded contributions
this error should be noticably high.
As of v1.5.7b (released today) the error has been eliminated.
In case of questions in this or related matters, do not hesitate to
contact your local dealer.
Ah yes, and maybe it's a good idea to also inform whomever you might
have sent v1.5.Alpha or later that an update is available (and stronlgy
recommendable).
Remain calm ;-)
Bernward.
top of page
From: <sathish[4]> on 2004 03 17 16:15 CET
to: despresso[4]
cc:
subject:
hello y'all,
in statistics_chain.c, the bond length calculations have been modified. it
actually calculates the average now (not the root mean square avg as was done
before, don't know why). the error is taken as one standard deviation (you
don't want to know what it was earlier).
when you call [analyze bond_l], it now returns a four member list with the
average, standard deviation, maximum value and minumum value of the sample.
the same holds true for [analyze ], however, note that now it returns
the maximum/minimum in all the configurations and the values don't have
belong to same chain. it was done this way to ensure uniformity.
the data for the test suite has been modified and it runs successfully on my
machine.
questions/compliments are most welcome.
complaints are not welcome, but send them anyway.
top of page
From: Axel Arnold <arnolda[4]> on 2004 03 10 15:19 CET
to: despresso[4]
cc:
subject: ELC, P3M
Hello Espressos,
now Espresso also can use ELC, i.e. 2d+h electrostatics with P3M. To enable
this, I had to implement the dipole term in P3M. So far always metallic
boundary conditions were used, and epsilon defaults to 0. So I use 0 for
metallic boundary conditions instead of infinity. This should not affect old
scripts as long as you did not set a value for epsilon, otherwise change it
to "metallic" or 0 to obtain the old behaviour.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: limbach <limbach[4]> on 2004 02 26 10:42 CET
to: despresso <despresso[4]>
cc:
subject: Extension of the integrate command
Hi Everybody,
The rearangements of the integrator and the thermostat are finished. The
tcl command integrate has been extended and can now be used in the
following ways.
integrate
integrate set
integrate set nvt
integrate set npt_isotropic []
Per default the integrator is set to NVT (since the integrator does not
distinguish between NVT and NVE, there is no option set nve. Use
'thermostat off' for NVE simulations).
Note that all scripts should still work in the same way as before!
Please tell me if you recognize any deviations from that!
Have a look at the RELEASE_NOTES for a complete overview of the latest
changes.
Have fun
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: limbach <limbach[4]> on 2004 02 24 10:03 CET
to: despresso <despresso[4]>
cc:
subject: thermostat and integrator
Hi
Since there are quite substantial changes going on, please read the
following mail thoroughly.
The changes affect the thermostat and its variables (temperature and
gamma) and the integrator.
For the thermostat the changes are done and described below. For the
integrator we are not ready yet, but we will extend the functionality.
With "integrate set" you will be able to chose an integrator and to set
the integrator variables. So please do not make extensive usage of e.g.
setmd piston.
We have also rearanged some parts of the integrator to make it more
readable even though there are more features and quite a number of
"#ifdef" statements in there. The testsuite is running, but PLEASE CHECK
WETHER YOUR SCRIPTS STILL WORK PROPERLY OR NOT!!!
New tcl command: thermostat to control the new thermostats:
Usage: thermostat langevin
thermostat dpd
thermostat npt_isotropic
thermostat off
thermostat
Notes: You can combine different thermostats.
At the moment they share a single temperature (if you are
aware
of any problems where one would need different temperatures,
please let us know).
thermostat off turns all thermostats off and sets all
thermostat parameters to zero.
For NVE ensemble use thermostat off.
DO NOT USE setmd temperature AND setmd gamma (:=
langevin_gamma) IN NEW
SCRIPTS! (even though they still work).
For backwards compatibility ESPResSo starts with the
Langevin thermostat turned on.
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: Bernward Mann <mann[4]> on 2004 02 14 22:55 CET
to: despresso <despresso[4]>
cc:
subject: New Integrator / Constant Pressure Simulations
Dear D'Espressies,
this is to let you know that I just finished implementing a new
(N,p,T)-integrator into ESPResSo.
Nothing should have changed for your simulations, even if you activate
the corresponding compiler flag 'NPT' - unless you specify the mandatory
parameters 'setmd piston' (piston mass) and 'setmd g0' / 'setmd gv'
(frictions for the thermostat). A good choice for playing around a bit
would be
setmd piston 0.0001
setmd g0 0.001
setmd gv 0.5
To specify the desired pressure, use 'setmd p_ext'.
To access the current instantaneous pressure, use 'setmd p_inst'.
The integrator assumes an isotropic cubic box and does not use the
tensorial pressure.
It does not work with the angle-, rotation-, mmm1d-, mmm2d-, comforce-,
comfix-potentials (reason: they don't fit into the standard virial
expression for deriving the pressure), and it won't consider external
forces.
For further background informations please refer to Kolb, Duenweg,
J.Chem.Phys. 111(10), 4453 (1999).
The testsuite runs through smoothly with both the compiler flag turned
off and on, so I assume that none of the vital functions of ESPResSo
have been damaged, despite the amount of files something had to be
changed in.
Nevertheless I'd like to ask you to have a close look at your
simulations in case something seems to differ.
Have fun,
Bernward.
top of page
From: Axel Arnold <arnolda[4]> on 2004 02 09 12:15 CET
to: despresso[4]
cc:
subject: analyze set
Hello D'Espressos,
the analyze set command changed a little bit:
Now "analyze set chains" does no longer exist.
Use "analyze set" to get the topology in a generic format.
"analyze set {type1 id11 id12 id13...} {type2 id21 id22 id23...}..."
can be used to define an arbitrary topology.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: limbach <limbach[4]> on 2004 02 05 14:19 CET
to: despresso <despresso[4]>
cc:
subject: Molecules in Espresso
Hi!
Let's try to summerize the results of our disussion on molecules in
Espresso this morning:
New structures:
* Particle property: mol_id - Integer which states to which molecule
a particle belongs
* Topology structure: topology - This structure (hold only on the
master node) will contain the topology information of the whole
system: this will be a list of molecules which will contain:
* mol_type
* List of particle identities
General concept:
* Both topology concepts are independent from each other (as well as
from the topology information stored in the bond lists of each
particle) and serve as a basis for different problems.
* The mol_id is used in the force/energy/pressure calculation.
* The topology structure is used for analysation.
Functions/Features:
* Conversion routines between the different topology concepts.
* In- and output routines (parser).
* More general concept for non bonded interactions on the bases of
topological information and 'general interaction rules'
(e.g. specific intra molecular interaction).
Please correct me if I have mixed up things or forgot anything.
The next steps are:
1. Implementing the new structures (Hanjo)
2. Implementing corresponding parsers and printout (Axel)
3. Adaption of analyzation routines (Bernward, Mehmet, Ira)
4. Generalization of the non bonded interactions (Satish, Axel,
Hanjo, ...)
So lets start working!!!
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: Mehmet Sayar <sayar[4]> on 2004 02 03 15:10 CET
to: despresso[4]
cc:
subject: Another Espresso Meeting on Thursday 11:00
Hallo D'Espressies,
Just to continue with where we left the discussion today, we would like to
have another espresso meeting on Thursday at 11:00 (05.02.2004) in the
coffee room. Please come to this meeting if you are interested in
participating in the discussion of the following topics:
1) Implementing/modifying the chain structure in Espresso.
-> How to implement a chain structure which could be used in both the
analysis and the simulation part of the code.
2) How to keep the code clean(er)?
-> Separate interactiondata.c so that print and parse functions for
each
interaction type is in isolated files.
-> Introducing a directory structure into Espresso source.
Mehmet
________________________________________________________
Mehmet Sayar - Postdoc MPI fur Polymerforschung
Email:sayar[4] Theory Group
Phone:+49-6131-379-166 Ackermannweg 10,
Fax: +49-6131-379-340 D-55128 Mainz, Germany
top of page
From: limbach <limbach[4]> on 2004 01 30 16:21 CET
to: despresso <despresso[4]>,
cc:
subject: Bond Angle Potential
Hi
The implementation of more general bond angle potentials is finished.
This should not affect any previous simulation runs / scripts. You can
now choose between different functional forms and specify an equilibrium
angle. The documentation is attached or can be created with gmake docu.
Have fun
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
ATTACHMENTS:
"bond_angle.ps"
top of page
From: limbach <limbach[4]> on 2004 01 29 11:17 CET
to: despresso <despresso[4]>
cc:
subject: Espresso meeting next tuesday, 11:00
Hallo D'Espressies
So far the new version of Espresso seems to work well. Many things have
changed and we have a number of new features implemented by different
poeple. Therefor we will have a meeting next *Tuesday, 02/03/2004 at
11:00 *in the *Tower Room*.
So far we will have short presentations of the new features:
* Tabulated non bonded potentials (Ira)
* Subt_LJ_FENE and more bond potentials (Satish)
* The MAZE (Mehmet)
* Center of mass force/fixing (Mehmet)
* Folding options for VMD (Ira)
* Changes in the pressure routine (Bernward)
* Bond angle potentials (Hanjo)
(Here short means at maximum 5 minutes per topic!!!!)
Further on we have to discuss how we deal with implementations that seem
to be specific to only one problem and therefor may be not of much use
in the future. That is we have to think of how we keep the basic parts
of the code clean and readable.
Please let me know if I forgot any topic which should be discussed also.
See you
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: Axel Arnold <arnolda[4]> on 2004 01 20 15:33 CET
to: despresso[4]
cc:
subject: ICC
Hello all,
the Linux Makefile now by default uses the icc. If you experience problems,...
feel free to fix them :-)
A Lennard-Jones system runs about 60% faster on a single node and 70% faster
for two nodes with the new compiler.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: limbach <limbach[4]> on 2004 01 16 12:24 CET
to: despresso <despresso[4]>
cc:
subject: Espresso Documentation
Hi All
I have changed most of the bugs that occured when creating documentation
with the new version of doxygen (SUSE 9.0 distribution). There are still
some warnings that I was not able to track down so far, but it should
look o.k. again and should be readable. Please correct minor errors you
find while reading yourself.
Attention:
Do not use special characters like "<" and ">" that are used in HTML
without backslashing them.
Do not use latex commands which have no counterpart in HTML.
See you,
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: Bernward Mann <mann[4]> on 2004 01 15 15:28 CET
to: despresso <despresso[4]>
cc:
subject: Ideal Gas Pressure
Dear all,
please note that the derivation of the ideal gas contribution to the
pressure has been changed since v1.5.Alpha from
> n_total_particles*temperature/volume
to the more accurate
> Sum(v_i^2)/(f*volume)
where f=degrees-of-freedom of the system (f=6 if ROTATION is compiled
in, f=3 otherwise).
This has several implications:
- The ideal-pressure-component of 'analyze pressure' and the trace of
the corresponding component of 'analyze p_IK1' should now match exactly
(this is checked by the 'analysis.tcl'-testcase) at last.
- The ideal-pressure-component of 'analyze pressure' now differs for
systems with and without ROTATION compiled in - please keep that in mind
while e.g. creating new testcases which also check the pressure; have a
look at 'intp(p)bc.tcl' as an example of how to deal with this
challenge, or use particles at rest (BTW: 'stop_particles' sets all your
particles' velocities to zero very conveniently) for p_id=0.
But most importantly:
The first implementation of p_id did not have the correct prefactor! If
you used v1.5.Alpha during the last two weeks and measured the pressure
as well, your resulting ideal contributions will have to be reduced by a
factor of 2/3 to be correct, and your total pressure will be too large
by 0.5*([setmd n_part]*[setmd temp]/[expr pow([lindex [setmd box_l]
0],3)]) which has to be deducted from your data.
Since this was found by reviving good ol' samples/kremerGrest.tcl, this
might be an encouragement as well to dust off your personal favourite
scripts to poke ESPResSo hard while checking it's output for correctness
- a bottle of beer to whoever finds the next physical error (similar to
that p_ideal deviation)!
Have fun,
Bernward.
top of page
From: Axel Arnold <arnolda[4]> on 2004 01 14 13:40 CET
to: despresso[4]
cc:
subject: pr and AVIs
Hello all,
just in the case anybody misses them: The pr folder and the two "small" AVI
files have moved to their own project "EspressoPR" were we can just forget
about them....
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Axel Arnold <arnolda[4]> on 2004 01 13 15:00 CET
to: despresso[4]
cc:
subject: Memory leak
Hello all,
at least the reported memory leaks are fixed, but there may still be some left
in strange combinations of potentials. So always take a look at your memory
consumption. For example you can use "limit vmemorysize" to set an upper
bound on the possible memory consumption.
I again want to emphasize that it helps a lot if utils.h is included in all
c-files. Since we include it already in some of the important header files,
this probably is already the case, but you should keep it in mind when
writing new files.
By now realloc and malloc are redefined to internal versions which return a
NULL pointer on 0 size allocations.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Axel Arnold <arnolda[4]> on 2004 01 12 16:44 CET
to: despresso[4]
cc:
subject: realloc
Hello all,
in utils.h there is now an replacement for realloc that ensures that regions
of size 0 are actually freed (the system realloc does not guarantee that and
in fact keeps a region of 16 bytes allocating under Linux). Basically that
should make no difference, but you should make sure that your program files
all include utils.h.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Bernward Mann <mann[4]> on 2004 01 12 09:02 CET
to: despresso <despresso[4]>
cc:
subject: Warning: Memory Leak in v1.5.Alpha
Dear all,
this is to inform you of a memory leak which currently exists in the
merged version of ESPResSo. So far it seems to occur only while using
full 3D periodic boundary conditions and the new cell structure, which
you can easily check by running $ESPRESSO_SOURCE/samples/lj_liquid.tcl
with 'set int_n_times 1000' - it will immediately start consuming up to
250MB of your RAM...
So, do not run the current version unsupervised on remote computers
right now, unless you want to suffer a slow and painful death caused by
whoever's computer you crashed with RAM exhaustion!
Reporting back once that problem is solved,
Bernward.
top of page
From: Torsten Stuehn <stuehn[4]> on 2004 01 08 16:27 CET
to: despresso <despresso[4]>
cc:
subject: vmd can be used again
Dear Espresso users,
the problem with Espresso and vmd that resulted in
a crash of the updated Linux machines could be
partly solved. Vmd still may crash but the rest of
the computer should not be affected by this.
The problem has been solved by disabling the OpenGL
hardware renderer of the Graphics card in vmd. This
means that all the rendering is done by the CPU now.
As a result vmd is slower and consumes much more
CPU time now (depending on the number of particles).
So, vmd can be used again but it shouldn't run the
whole time because Espresso will considerably slow
down, while vmd is running.
I don't know, when we will be able to reenable the
hardware renderer of the graphics card, sorry for this.
Greetings,
Torsten
--
Torsten Stuehn
Max Planck Institut für Polymerforschung
Ackermannweg 10
55128 Mainz / Germany
Tel. +49-(0)6131-379262
Fax +49-(0)6131-379100
top of page
From: Axel Arnold <arnolda[4]> on 2004 01 08 13:40 CET
to: despresso[4]
cc:
subject: Core dumps
Hello all,
after your computer was updated to SuSE 9.0 you will sooner or later notice
that you cannot raise the coredumpsize limit anymore, i.e. you can't create
coredumps at all. To enable this again, add
usegpg="no"
readonly usegpg
to your ~/.profile (probably you have to create it). This just disables a GPG
keyring, so probably not many need it.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: Torsten Stuehn <stuehn[4]> on 2004 01 07 18:56 CET
to: despresso <despresso[4]>
cc:
subject: serious problem with vmd and the new Linux installation
Dear Espresso users,
there seems to be a serious problem with vmd
if you start it on a machine with the new Linux
version 9.0.
If you don't want to crash your Computer,
do not use vmd until we have solved the problem.
Torsten
--
Torsten Stuehn
Max Planck Institut für Polymerforschung
Ackermannweg 10
55128 Mainz / Germany
Tel. +49-(0)6131-379262
Fax +49-(0)6131-379100
top of page
From: Axel Arnold <arnolda[4]> on 2004 01 06 18:30 CET
to: despresso[4]
cc:
subject: Final merge
Hello all,
the experimental branch is now fully merged into the standard Espresso.
The testsuite runs through smoothly, so I guess it might work.
So everyone try and complain!!!!
Note that the output format of the pressure functions has changed massively;
it is now the same as the energy output.
No complaints about that, please.
Axel
--
Axel Arnold
MPI f"ur Polymerforschung E-mail: arnolda[4]
Ackermannweg 10 Phone: +49-6131-379-481
D-55128 Mainz Fax: +49-6131-379-340
top of page
From: limbach <limbach[4]> on 2004 01 06 11:22 CET
to: despresso <despresso[4]>
cc:
subject: Information about the new particle data structure and the cell system
Hi All
Here the promised information about the new particle data structure:
ATTENTION:
Again please note that the changes described here do NOT affect the tcl
command part !!!
It is ONLY important if you write C code where you acces the
particle data.
=======================
PARTICLE:
All information about a particle is still stored in the structure:
struct Particle
The particle information is split up into several sub structures
ParticleProperties p
ParticlePosition r
ParticleMomentum m
ParticleForce f
ParticleLocal l
IntList bl
This is necessary to keep the structure extendable and variable without
having to worry about allocation, communication and so on.
More information which properties belong to which structure can be found
in the Particle Struct Reference.
PARTICLE LIST
A ParticleList is a container to store several particles:
struct ParticleList
pl
It contains a list with particles ( pl.part )the number of particles
stored in that list (pl.n ) and the allocation size (pl.max) of that list
=======================
CELL SYSTEM:
At the moment we have implemented two Cell Systems:
DOMAIN DECOMPOSITION:
The simulation box is divided spatially into CELLS (according to the
maximal interaction range, the node grid and so on)
NSQUARE
The particles are distributed (nearly) equally to the nodes
regardless their spatial positions.
Here all particle s on a node reside in one CELL
You can change the CELL SYSTEM from the tcl cript with the command:
cellsystem
========================
CELLS:
A cell is nothing but a PARTICLE LIST, that is a container for
particles.
All Cells are stored in a cell array called: Cell
* cells
If you want to access all Particles on a node you HAVE to use the cell
pointer list:
CellPList
local_cells
e.g.
for (c = 0; c < local_cells.n; c++) {
cell = local_cells.cell[c];
part = cell->part ;
npart = cell->n ;
for(i=0; i < npart; i++) {
// Do something with particle i of cell c,e.g. print the x coordinate
printf("%f ",part[i].p.p[0]);
}
}
If your choice of CELL SYSTEM contains so called ghost cells you HAVE to
use the cell pointer
CellPList ghost_cells
to acces the ghost
particles.
I hope this helps a bit to get used to all the new stuff!
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: limbach <limbach[4]> on 2004 01 05 15:58 CET
to: despresso <despresso[4]>
cc:
subject: PLEASE TEST THE NEW VERSION
Hi All
The new version of ESPResSo is nearly finished and is ready to be
checked out and TESTED!!!
Since I would not rely on it I recommend to check out the new version to
a different place than your actual working version.
Please report any difficulties with the new version as soon as possible!
(There are still difficulties with the pressure tensor and some related
stuff, please ignore that so far.)
Thanks for your effort
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: limbach <limbach[4]> on 2004 01 05 09:23 CET
to: despresso[4]
cc:
subject: CVS Lock - New Espresso version
Dear All
First of all I whish you all a happy NEW YEAR (Sorry, but I can't do it
in all that other languages).
With the new year we will get a new ESPResSo Version since Axel and
myself succeeded in implementing the new, more general data structure.
From today on we will start to merge the actual version of ESPResSo
with our developments. So please
DO NOT CHECK IN ANY CHANGES!!!
You will be notified when we have finished the merging process. You will
then also get information about the changes that have been made. Don't
worry the changes are only deep inside ESPResSo and will not affect the
script interface.
Hope to see you around
Hanjo
--
--
Dr. Hans Joerg Limbach email: limbach[4]
www: http://www.mpip-mainz.mpg.de/~limbach/
Office: Privat:
MPI fuer Polymerforschung
Ackermannweg 10 Hindenburgstr. 13
D-55128 Mainz D-55118 Mainz
Germany Germany
Phone: +49-6131-379-145 Phone:
FAX: +49-6131-379-340 +49-6131-676341
top of page
From: Mehmet Sayar <sayar[4]> on 2003 12 18 14:37 CET
to: despresso[4]
cc:
subject: Bug in constraint energy
Hi all,
Thanks to Hanjo and Axel, a bug (all right I take the blame for it ) has
been found in the energy print out for constraints.
If you have a system where there is a particle type number bigger than
constraint type number the energy output for the constaint is wrong. It
prints out zero, while it tries to write the energy to the wrong address.
The total energy should still be correct, just the energy output for the
constraint is wrong.
This bug will be fixed in the major update by Axel and Hanjo.
Let me know if you have any questions.
Mehmet
________________________________________________________
Mehmet Sayar - Postdoc MPI fur Polymerforschung
Email:sayar[4] Theory Group
Phone:+49-6131-379-166 Ackermannweg 10,
Fax: +49-6131-379-340 D-55128 Mainz, Germany
top of page
From: Bernward Mann <mann[4]> on 2003 12 18 12:43 CET
to: igor.pasichnyk[4]
cc: despresso <despresso[4]>
subject: Re: Error
There are different versions of tcl on the platforms you mentioned which
do have slight differences in their syntax, e.g.
> lindex $result 0 1
works on Linux, but on other platforms it must look like
> lindex [lindex $result 0] 1]
because the version there can only handle one index at a time; hence,
the latter syntax should solve your problem.
Best wishes,
Bernward.
Igor Pasichnyk wrote:
> I have got this error in Tcl script
>
> bad index "0 1": must be integer or end?-integer?
> while executing
> "lindex $result $ind"
> ("for" body line 14)
> invoked from within
> "for {set i 0} { $i < $int_n_times } { incr i} {
> puts -nonewline "run [expr $i+1] at time=[setmd time] \r"
> flush stdout
>
> integrate $int..."
> (file "pairV_ds.yukawa.4a.tcl" line 200)
>
> When I run the program on Linux everything is fine, but on Regatta it
> crashes. The script file is attached.
> Suggestions are welcomed
>
> Cheers,
>
>Igor
>
>--
>Igor Pasichnyk
>Max-Planck-Institut für Polymerforschung
>Ackermannweg 10
>D-55128 Mainz
>
>Tel.: +49-6131-379147
>Fax.: +49-6131-379100
>E-Mail: igor.pasichnyk[4] (MIME accepted)
>WWW: http://www.mpip-mainz.mpg.de/~pasichny
>
>
top of page
From: Igor Pasichnyk <pasichny[4]> on 2003 12 18 12:21 CET
to: despresso[4]
cc:
subject: Error
I have got this error in Tcl script
bad index "0 1": must be integer or end?-integer?
while executing
"lindex $result $ind"
("for" body line 14)
invoked from within
"for {set i 0} { $i < $int_n_times } { incr i} {
puts -nonewline "run [expr $i+1] at time=[setmd time] \r"
flush stdout
integrate $int..."
(file "pairV_ds.yukawa.4a.tcl" line 200)
When I run the program on Linux everything is fine, but on Regatta it
crashes. The script file is attached.
Suggestions are welcomed
Cheers,
Igor
--
Igor Pasichnyk
Max-Planck-Institut für Polymerforschung
Ackermannweg 10
D-55128 Mainz
Tel.: +49-6131-379147
Fax.: +49-6131-379100
E-Mail: igor.pasichnyk[4] (MIME accepted)
WWW: http://www.mpip-mainz.mpg.de/~pasichny
ATTACHMENTS:
"pairV_ds.yukawa.4a.tcl"
top of page
From: Bernward Mann <mann[4]> on 2003 12 02 15:09 CET
to: despresso[4]
cc:
subject: Release of v1.1.1
Dear Espresso-Developers,
inaugurating 'despresso' with this first official announcement, it is my
pleasure to inform you that the newest version
---> v1.1.1 of ESPResSo <---
has been released today, thoroughly checked and tested on all supported
plattforms (AIX, OSF1, Linux, Darwin). It can be found in your local
directory by using 'cvs update -d' there, or alternatively as
give-away-version in the usual place
(~pep/Extern_Espresso/20031202-Espresso_v1.1.1.tar.gz).
While the size almost doubled (from 1671005 to 3225791), many bugs have
been fixed and features have been added, the most important of which are
to be found listed in the RELEASE_NOTES, a file to which I would like to
draw your attention to very much, since it is there where we would like
you to place a short note whenever you added a new command,
command-option or feature, changed some major structurs etc. within the
code, and whenever you exterminated severe bugs which might have had an
impact on people's simulations or simulation results.
Have fun with all the improvements!
Bernward.
top of page
From: Torsten Stuehn <stuehn[4]> on 2003 11 14 12:37 CET
to: despresso[4]
cc:
subject: New Espresso Developers EMail-List
We have a new internal EMail-List
despresso
If you send an email to despresso[4]
the following users will receive the mail:
antypov
arnolda
cooke
deserno
duenweg
holm
limbach
lobaskin
mann
muehlbac
pasichny
sathish
sayar
stuehn
The purpose of the list is to enhance comunication
between the Espresso developers. Everything, that
the developers should know (changes, bugs, bugfixes,
new ideas, ...) can be sent to this list.
If you think, that someone is missing on the list,
please tell me.
kind regards,
Torsten
--
Torsten Stuehn
Max Planck Institut für Polymerforschung
Ackermannweg 10
55128 Mainz / Germany
Tel. +49-(0)6131-379262
Fax +49-(0)6131-379100
top of page
Last modified:
Mon Jun 18 04:01:43 CEST 2007