[gmx-users] more than 2 step*.pdb files?

Berk Hess gmx3 at hotmail.com
Fri Jun 6 16:44:01 CEST 2003


>On Fri, 2003-06-06 at 09:13, Anton Feenstra wrote:
> > Berk Hess wrote:
> > > > > I thought that was not possible, but I see now that some time ago
> > > David changed the code to pass the error status form the constraint > 
> > routines and removed the fatal_error in the LINCS code.
> > > A call to fatal_error should now be added at a higher level in the 
>code,
> > > as such a simulation is probably not reliable anymore.
> > > To get that straight: does this mean that there is a chance that a 
>simulation
> > keeps on running, when it should actually have crashed? But, that in 
>that case
> > there are also (many) step*.pdb files written?
>no I don't think so, since it will die on the communication in the next
>step. Maybe it's time to make a new todo list... We do want killing of
>simulations to be coordinated at the highest level (even if shake
>fails), so it should be fixed there (md.c / mdrun.c).

It will not die directly in the next step on the communication, since none 
of the processes
willl terminate. But if a bond deviates more than half it's length in LINCS, 
or SHAKE
does not converge, of SETTLE does not have a solution, it is almost certain 
that
the system will explode and NaN's will be generated within the next few 
steps,
which will make the simulation die on the communication.
It is indeed much better to terminate using fatal_error with a nice error 
message,
so people see immediately where the problem was.

Maybe it is a good idea to let all routines return an error flag (which is 0 
for no error),
which can then be OR'red, so the calling routine can than take appropriate 
measures
based on all the errors that occured.
This would require an array of error flags and a corresponding array of 
error strings.

Berk.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail




More information about the gromacs.org_gmx-users mailing list