Great work on LAMMPS. However, in my case, I have a few suggestions to the
thanks for making suggestions.
commands in order to facilitate restarting a simulation since I have to deal
with a job submission system.S1: add 'start' 'end' to variable style loop, since I may not want to start
with 1 and my end might be fixed. This is to facilitate restart scenarios.
S2: allow for appending to fixes that write to a file (or for that matter
any cmd that can write to a file, if applicable)
appending to a file, while seemingly convenient, is a bad idea, particularly in
a batch environment and especially with (parallel, networked, high-throughput)
filesystems that only implement a subset of POSIX functionality. it would be
better to write the output from each job to a new file. my preferred way to do
this is by extracting the job id from the environment in the job (shell) script
and then use the -var jobid $JOBID command line syntax to define a variable
and then use this variable in all generated file names. this way all file names
are guaranteed to be unique and also one does not have to manually remove
pieces from the middle of a file in case one job iteration crashed or was
canceled before the job was completed and one had to restart from an
intermediate restart file.
S3: throw error for variable id loop 0
Now, there are workarounds but that's what they are: workarounds.
--
..And for a related question: have you thought about writing a python
wrapper for lammps which can at least access running data?
people have thought about it, but the nature of volunteer supported
scientific software is, that only those things get implemented that somebody
has a need for, or finds interesting enough to be curious to implement it
or there is sufficient other incentive to do it.
you would be most welcome, if you would give it a try yourself.
cheers,
axel.