[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo] random number generator problem

Subject: Re: [ESPResSo] random number generator problem
Date: Sun, 28 Feb 2010 14:24:26 -0800

Dear Axel:

Thank you very much for all the comments. They are really really helpful. One suggestion, is it possible to add a search bar for the mailing list? This will make users benefit more from other people's questions and also avoid asking duplicated questions.


On Thursday 25 February 2010 18:31:20 you wrote:
Hi, Axel

That makes more sense. Thank you very much. Looking at the manual more
carefully, this is actually well documented (sorry about this). Also
by going through the manual, I found another *equivalent* command
bit_random. I guess they differ in the platform dependence? Then if
I'm going to work on the same platform, is bit_random preferred?

Actually, no. bit_random is as platform-independent as random, which both are self-coded. Bit_random is a different RNG favored by Duenweg et al, but it is computationally much more expensive, and usually I would not think it is necessary for standard MD simulations. Moreover, because of its computation time costs, bit_random can only be used to generate random numbers from Tcl, but you cannot use it for the thermostat during the integration. There at
present the plain random-generator is hard-wired.

I have another question:
In my understanding, there could be two ways to do a number of steps
of integration, one by looping in tcl, and one by looping internally,
1: for {set i 0} {$i <$num_steps} {incr i} {
        integrate 1
2: integrate $num_steps
My question is: do you expect a big difference in efficiency for these
two cases?

Yes, unfortunately. The Tcl-interpreter is rather slow, so even with a couple of 1000 particles, a timestep is faster to propagate then the Tcl loop.

The reason I ask this is I'm planning to implement some new analysis.
But this analysis has to be run on the fly at every time step, so that
I can have a sense how the system is evolving. If there won't be much
difference for these two cases, then I can simply write a tcl script
rather than hack into Espresso code.

For the same reason as above, an analysis written in Tcl is typically rather slow, so you will slow down things dramatically. However, I suggest that you first implement your analysis in Tcl, to see how it properly works, and only after that recode it in C. The latter is not too difficult, if you are not going to run in parallel. Just look at integrate.c: integrate(int), which is the main loop. For how to access particles, best look at particle_data.c, but essentially, on a single processor, you can use the local_particles[id]-Array to get a pointer to particle with identity id, and then get all properties
from there.


Dr. Axel Arnold Tel: +49 711 685 63593
ICP, Universit├Ąt Stuttgart      Email: address@hidden
Pfaffenwaldring 27
70569 Stuttgart, Germany

reply via email to

[Prev in Thread] Current Thread [Next in Thread]