Hello everyman!
Is it possible to use “dump_modify pbc yes” option with “boundary p p f”? When I was trying to start simulation, I’ve obtained “illegal dump_modify” message.
Best regards,
Michael
Hello everyman!
Is it possible to use "dump_modify pbc yes" option with "boundary p p f"?
When I was trying to start simulation, I've obtained "illegal dump_modify"
message.
yes it is possible. your quoted command is missing the dump id.
axel.
Thanks for answer. I’m so sorry, but didn’t provide all informations. My problem (I think) is in code:
dump water_trj water atom {Ndumpw} water_s{step}_${Tstop}K.lammpstrj
dump_modify water_trj scale no flush yes pbc yes
because simulation can’t work and an error occurs: “Illegal dump modify command”. All variables are OK, because when I use this version:
dump water_trj water atom {Ndumpw} water_s{step}_${Tstop}K.lammpstrj
dump_modify water_trj scale no flush yes
it works. I’ve checked that “pbc yes” applies to all the dump styles.
Thanks for answer. I'm so sorry, but didn't provide all informations. My
you *still* don't provide all recommended pieces of information.
problem (I think) is in code:
i don't think so.
dump water_trj water atom \{Ndumpw\} water\_s{step}_${Tstop}K.lammpstrj
dump_modify water_trj scale no flush yes pbc yesbecause simulation can't work and an error occurs: "Illegal dump modify
command". All variables are OK, because when I use this version:dump water_trj water atom \{Ndumpw\} water\_s{step}_${Tstop}K.lammpstrj
dump_modify water_trj scale no flush yesit works. I've checked that "pbc yes" applies to all the dump styles.
have you also checked, whether the manual you looked this up in,
applies to the specific version of LAMMPS that you are using?
not to mention, that there are extremely few cases, where the
enforcing of PBC in the dump output is really required (or flushing
it).
axel.
I use version of LAMMPS from 14 May 2016; the documentation is from 17 Dec 2016.
I had to use “flush yes” option because there is NFS filesystem in my cluster, so I sometimes had illegible data in my dumps.
I had also some positions in my dump outside the simulation box, so I used “pbc yes”.
I use version of LAMMPS from 14 May 2016; the documentation is from 17 Dec
2016.
well, there you go. the feature you are trying to use was introduced
more recently. as i mentioned before, it works fine for me (with the
latest version of LAMMPS which *does* match the version of the
manual).
I had to use "flush yes" option because there is NFS filesystem in my
cluster, so I sometimes had illegible data in my dumps.
i would be surprised if, flushing cures that. corrupted files are
usually due to multiple processes trying to write to the same file or
forced reboots (via power cycle or unstable power) on the NFS server.
I had also some positions in my dump outside the simulation box, so I used
"pbc yes".
yes, but why is that a problem?
LAMMPS has been writing trajectories without the enforced PBC wrapping
for 20 years and - as i already mentioned - the number of cases where
this (tiny) difference mattered were *extremely* small.
axel.
> I use version of LAMMPS from 14 May 2016; the documentation is from 17
Dec
> 2016.well, there you go. the feature you are trying to use was introduced
more recently. as i mentioned before, it works fine for me (with the
latest version of LAMMPS which *does* match the version of the
manual).
ok, i have to upgrade lammps on the cluster. thanks.
> I had to use "flush yes" option because there is NFS filesystem in my
> cluster, so I sometimes had illegible data in my dumps.i would be surprised if, flushing cures that. corrupted files are
usually due to multiple processes trying to write to the same file or
forced reboots (via power cycle or unstable power) on the NFS server.
so is there any other solution of this problem?
I had also some positions in my dump outside the simulation box, so I used
> "pbc yes".yes, but why is that a problem?
LAMMPS has been writing trajectories without the enforced PBC wrapping
for 20 years and - as i already mentioned - the number of cases where
this (tiny) difference mattered were *extremely* small.
yes, it could be a problem, because i simulate a droplet on a surface, not
a bulk system. particle (position) outside the box cause invalid input into
a droplet density profile.
> I use version of LAMMPS from 14 May 2016; the documentation is from 17
> Dec
> 2016.well, there you go. the feature you are trying to use was introduced
more recently. as i mentioned before, it works fine for me (with the
latest version of LAMMPS which *does* match the version of the
manual).ok, i have to upgrade lammps on the cluster. thanks.
> I had to use "flush yes" option because there is NFS filesystem in my
> cluster, so I sometimes had illegible data in my dumps.i would be surprised if, flushing cures that. corrupted files are
usually due to multiple processes trying to write to the same file or
forced reboots (via power cycle or unstable power) on the NFS server.so is there any other solution of this problem?
whether you have multiple processes writing to the same file or not,
is up to you. you have to make certain, that no two jobs run in the
same folder and would write to the same file.
whether there are forced reboots depends on the folks running your
cluster. file servers should be supported by uninterruptible power and
reboots, especially forced reboots via power cycling machines, should
not be done while the cluster is in use.
> I had also some positions in my dump outside the simulation box, so I
> used
> "pbc yes".yes, but why is that a problem?
LAMMPS has been writing trajectories without the enforced PBC wrapping
for 20 years and - as i already mentioned - the number of cases where
this (tiny) difference mattered were *extremely* small.yes, it could be a problem, because i simulate a droplet on a surface, not a
bulk system. particle (position) outside the box cause invalid input into a
droplet density profile.
this doesn't make sense. you have periodic boundaries in that
direction and thus a reasonably programmed post processing tool would
have to take PBC into account anyways.
more importantly, a properly set up droplet would stay in place or
would have to be tethered for have a meaningful density profile in the
first place. how should atoms leave the box?
if you want it to be mobile and compute the density relative to it
COM, then the previous case applies.
please note, that the dump_modify pbc flag applies *only* to the data
being written to the dump file. the internal data in LAMMPS is
unchanged. if you want that data to be perfectly inside the box
boundaries, you have to tweak your neighbor list settings to align
your neighbor list updates with your analysis.
axel
... and perhaps i should emphasize, that "dump_modify <dumpid> pbc
yes" is unrelated to writing out wrapped or unwrapped coordinates.
this is handled by different settings. this dump_modify flag merely
compensates for the optimization of not rebuilding neighbor lists on
every step.
axel.