Re: printing and global variables within TclBC script

From: Leandro Martínez (
Date: Wed Oct 24 2007 - 02:55:55 CDT

HI Peter,
Thanks for answer. The problem with printing (which is not the most important)
is that I don't know how to print information outside the calcforces procedure
for only one processor. But that's not so important, since it limited
printing only.

I made some tests and the information is not persistant between time-steps, in
the case that one atom that was assigned to one processor is changed to
other processor. Something simple as

for { set i 1 } { $i <= $natoms } { incr i } { set test($i) 0 }
proc calcforces { step unique } {
   global test
   while { [ nextatom ] } { incr test($i) }

should return, at the end, "test = number of steps" for every atom. However,
if an atom that is being considered in processor 1 passes to processor 2, the
counter is set to 0 and, therefore, I cannot use the previous
information for this
atom to compute anything.

I understand that this is an intrinsic limitation because the tcl
interpreters are
really independent, am I wrong? If I knew which atoms were going to be
exchanged between processors, at which time-step, than I could
overcome this problem, maybe writing data to a file and reading it
again, is this information anywhere?


> >
> > Another question is that within the script I update some vectors that will
> > be used in the next step for the calculations. Fortunatelly there is only
> > atom-specific information on each vector, in such a way that the
> > distribution
> > among several processes is possible. However, I'm not sure how the
> > scripts handle these updated vectors when the script finishes, I mean,
> > do all the scripts update the vectors before launching the scripts again
> > in the next step or this information is lost?
> > Thanks in advance,
> > Leandro.
> If the information is in variables defined as a global variable inside
> of the tclBCscript but outside of the calcforces routine, and brought
> into the calcforces routine as a global, it should be persistent between
> timesteps. You should probably test this yourself to verify that the
> information is being passed between timesteps the way you want...
> Best,
> Peter
> >
> >

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:45:25 CST