about restart and log information

ahh... i asked to reply to the lammps list, but forgot to answer the mail.

Thanks, Axel.

Not using file i/o is matter to me because there will be a lot of them. For
a sake of simplicity, let say I read an restart file as initial condition.

no need to change the code for that. just use a ramdisk.
e.g., if you are runnning on a current regular linux machine,
you can use up to half the ram of the machine as ramdisk,
but writing to (and reading from) /dev/shm/
that will be only be a tiny bit slower than copying it
to an array, but will not need any source code modifications.

if those tiny differences matter yet, then you have
do to what you do differently.

After 1 simulation (invoke 2 different LAMMPS object) run it will write 2
restart files. After this step, system will do some reset and will read in 2
restart files as new initial conditions and so on. This is why I asked about
input and output via arrays of data

yes. that will work just fine with a ramdisk.
particularly, if you don't intend to keep the
restarts after the run is finished.

Let me ask another question. When I run a simulation for some reason LAMMPS
produces an ERROR (whatever it is). Without writing to log files or screen,
can I capture this information if I use function calls via LAMMPS library?

not easily. recovering from errors in a parallel
environment is tricky. you don't know what
state your communicators are in.


as an additional remark. if you cannot use a ramdisk,
you can also write a wrapper library around the C
stdio library and would intercept file i/o to specific
files (as signaled by a pattern or regular expression
in an environment variable) and then redirect those
calls to read to and from arrays. this requires some
knowledge of how your specific stdio library works
internally and requires some smart coding, but it is
not impossible. i've been using such a thing several
years ago to avoid having to buffer scratch files on
diskless machines like cray xt series.


Thanks Axel for your suggestions. From what you suggested, ramdisk seems to be an easier approach.