Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement 'dump_modify maxfiles' feature #907
This implements a feature where a trajectory is recorded frequently but with limited history. This is implemented by storing filenames of created files with a 'one-file-per-step' setting active and one file per step being written. Once the maximum number of files is reached, the oldest file in the list is deleted.
Axel Kohlmeyer (Temple U)
new feature and off by default.
Post Submission Checklist
Please check the fields below as they are completed
I agree this is more general than #604
however, it has been quite handy to download just one xyz file with the latest timesteps
notably, in this version, during debugging, files would quickly build up as runs exited at different times
this could be mitigated by appending filenames with the integers 1-maxfiles instead of timestep (which is less important in this case, and usually included in dump file)
(implementation note: this would also involve a file 'rename' loop once maxfile is reached)
converting multiple xyz or atom style or custom dump files into a single file is trivial to do with 'cat' in combination with
as for accumulating "debug" files, it is equally trivial to put something like
there really isn't much of a need to put added complexity inside LAMMPS. one just has to make good use of existing features and combine them accordingly. i was actually surprised by the simplicity of adding the changes in this PR and how well it fits into the overall design of dump file management in LAMMPS.
i like those solutions.
however, I believe the primary use case for something like this is rapid debugging. in my case, i used this at high frequency while fine-tuning parameters. basically, i might still be tempted to have one xyz to avoid file clutter and the extra 'cat' step
at the least, i'd guess your above solutions might have to be mentioned in the docs for users to effectively use this for debugging
sorry but you are asking us now to put explanations of basic file handling workflows into the documentation of an application. next you ask us to explain how to debug with gdb or valgrind or how to back up and synchronize projects between clusters and local archives. where would this stop?
i understand your fondness for your own solution and frustrations about not being aware of alternatives to the solution you came up with (and probably spent a significant amount of effort on implementing it).