Hello,
I'm interested to know if anyone is using the following "feature" of lammps?
If lammps is invoked such that it reads input from the stdin stream, then it is possible have a program work "interactively" with the running lammps executable. For example, the program could keep the stdin stream open, send commands to lammps, and wait for some flag in the output to indicate that lammps has completed the supplied commands. Then, the program could act on the output results and send lammps additional input on the (still) open stdin stream... This would avoid the overhead of "starting up" lammps multiple times.
I'm wondering if this mode of usage is common, rarely used, or not used at all.
I ask because (as part of the OpenKIM project) we are considering a scenario where lammps would read the entire input script on launch and perform some preprocessing of the script before it executes any of the script. (This is incompatible with the "interactive" usage mode described above as it would cause lammps to simply wait forever for the stdin stream to be closed.)
Thanks,
Ryan
Hello,
I'm interested to know if anyone is using the following "feature" of
lammps?
If lammps is invoked such that it reads input from the stdin stream, then
it is possible have a program work "interactively" with the running lammps
executable. For example, the program could keep the stdin stream open,
send commands to lammps, and wait for some flag in the output to indicate
that lammps has completed the supplied commands. Then, the program could
act on the output results and send lammps additional input on the (still)
open stdin stream... This would avoid the overhead of "starting up" lammps
multiple times.
I'm wondering if this mode of usage is common, rarely used, or not used at
all.
people with that usage pattern usually use the C library interface, or
create a LAMMPS object from C++ and then use lmp->input->file() or
lmp->input->one() to issue individual commands or a group of them from a
file. these can be called multiple times.
that said, the kind of processing you describe should work as well. it is a
bit tricky to get the terminal settings right, so that you actually catch
the output without buffering creating trouble. e,g, in the past people
would use this kind of approach in combination with the "expect" program to
automate console tasks (e.g. logging into remote accounts) before we had
ssh and public key authentication.
I ask because (as part of the OpenKIM project) we are considering a
scenario where lammps would read the entire input script on launch and
perform some preprocessing of the script before it executes any of the
script. (This is incompatible with the "interactive" usage mode described
above as it would cause lammps to simply wait forever for the stdin stream
to be closed.)
there are some recent efforts to make LAMMPS more friendly to be embedded
into other tools, e.g. anders' atomify, so we would need to take a closer
look at what it is exactly what you need and how this is best implemented.
this is probably a discussion best done on either the github issue tracker
or in private e-mails off-list, since this is likely to become very
technical and very specific quickly.
axel.
Thanks Axel,
This is helpful.
We'll be in touch (as suggested, through another venue).
Ryan