Has anyone else been having problems running lammps in the background?

It depends on what you mean by "data files" as to whether one might expect
this behavior. If you mean the output, that's going to the null device,
but you should still see log.lammps somewhere---possibly NOT where you are
looking for it, however! Here's a thought: on the machine you are
logged in to, do a search for log.lammps (the default log file name), such
   find $HOME -name log.lammps
If it spits up anything you weren't expecting, look there and see if your
other files are also present.

One thing to keep in mind is that some MPI implementations don't start in
the current directory on startup unless you tell them to explicitly
(starting in your home directory, for example). These problems are
handled transparently by Torque, PBS, SGE, and other schedulers (if they
are configured appropriately), but if you're running manually you might
run into trouble. It may not be the cause, but it's worth exploring.
Type "man mpiexec" to see options available. For example, MPICH2 has a
"-wdir" option that tells it to cd to the directory that follows BEFORE
running the executable. OpenMPI provides a similar option, though the
default is wherever you started mpiexec.

Depending on how you are using this/these machine(s), I agree with Prof.
Kohlmeyer: installing SGE, Torque, or some other scheduler will probably
save you from over-subscribing jobs on your processes. If you're trying
to run six MPI processes on one processor, it's going to take at least six
times as long as running it on six, and definitely longer than running it
on one!

Karl D. Hammond

By data files I meant dumps, like text dumps which should go to their specified directory, no?


I just re-read your first e-mail, and I need to be sure of one thing.
Did you type this:

   mpirun -np 6 lmp_mac_mpi&<in.infile>/dev/null

or did you type this:

   mpirun -np 6 lmp_mac_mpi < in.infile >/dev/null &

...? It makes a difference! If you run it the first way, the shell
interprets it as
   mpirun -np 6 lmp_mac mpi &< in.infile > /dev/null
How your shell reacts to such constructs is not predictable, as "&<" is
not a normal shell-aware symbol. In this case, your redirections come
AFTER the shell starts the process in the background. They never get
processed (they technically belong to the next command, if there were
one), so LAMMPS runs with input from stdin (the terminal). This means it
runs forever with no input! The & (or &! if you're using Z shell's
background-and-disown operator) should always go at the end.

I suspect that will solve the problem, otherwise I'd advise running a
REALLY short simulation (~60 s) that you know will finish, then looking
for the dump file everywhere on your filesystem (find / -name [dumpname]).
It should be somewhere.

Karl D. Hammond
University of Tennessee, Knoxville
[email protected]...

"You can never know everything, and part of what you know is always
   wrong. A portion of wisdom lies in knowing that. A portion of courage
   lies in going on anyway."
"Nothing ever goes as you expect. Expect nothing, and you will not be