generalize dump_exyz and remove other dump commands

[brucefan1983]

Not urgent, but need to do this at some point.

[brucefan1983]

Any suggestion for the syntax? @erhart1
Currently, it is

dmp_exyz <interval> <has_velocity> <has_force>

How about if we want to dump other quantities, such as per-atom virial, per-atom heat current, per-atom charge (in the future), and also want to do it only for a group of atoms?

[erhart1]

I think this is good change.
Why not start with this version and make it more complex as demand arises?

[brucefan1983]

I propose these:

1. dump all atoms

dump_exyz <interval> [quantity_1 quantity_2 ...]

2. dump a group of atoms

dump_exyz <interval> <grouping_method> <group_id> [quantity_1 quantity_2 ...]

quantity can be velocity, force, virial, jp, mass, ...

[erhart1]

Looks good.
Will it be possible to provide multiple such commands per run?

[brucefan1983]

Currently, all commands will only have at most one (the last) instance for each run. Do you have good reasons to use more within a run?

[brucefan1983]

I have discussed with a few guys and we want to make it this way:

dump_xyz <interval> [list of quantities]
dump_group <grouping_method> <group_id> # to choose a group for the dump; default is to dump all atoms
dump_file <single/multiple> # using a single file for all the structures or using one file for each structure (needed for very large systems)

[brucefan1983]

That is, dump_group and dump_file can modify the behaviors of the dump_xyz in the current run. Is this a good way?

[erhart1]

The reason for asking about multiple commands was that I imagined wanting to dump both basic information for all atoms and additional information for a subgroup of atoms.
I think your revised suggestion would cover this case.

[erhart1]

Or does it?

[brucefan1983]

ok, all my proposed forms have not considered multiple instances of the command within a run. the dump_group was just used to modify the behaviors of dump_xyz. Now based on your suggestions, it would be good to have two separate (unrelated) keywords: dump_xyz for dumping all the atoms, and dump_group for dumping a group of atoms. Both keywords can dump any quantity as asked by the user. Is this good?

[ZKC19940412]

Hi, on a similar note for the dump command. Would it be possible to add an option to dump unwrapped trajectories? This is particularly useful for computing diffusion coefficients via MSD and thermodynamic property calculations like surface tensions. To do that, one will equilibrate the liquid water and then unwrap the equilibrated trajectory to insert a vacuum region. I am currently doing that with other codes as postprocessing. It will be nice if there is an option from the dump commands and everything step comes within the GPUMD ecosystems.

Hope this suggestion is somewhat useful.

Best，
Zekun

[brucefan1983]

Yes, unwrapped coordinates are now available inside the code and it can be added to this dump. I am still thinking about the syntax of this keyword, and asking for suggestions from different people.

[erhart1]

Are you open to the possibility to allow multiple instances of, say, the dump_xyz keyword?
In that case, one could include all the relevant parameters on one line.
For example

dump_xyz <interval> <filename> [group <groupid>] {<property1> <property2> ...}

which would allow one to write, e.g.,

dump_xyz 100 movie.xyz all position
dump_xyz 1000 movie-with-velocities.xyz all position velocity
dump_xyz 10 movie-for-subgroup1.xyz group 1 position force velocity force charge
...

[brucefan1983]

OK, I agree with this plan, but it will take more time to do it. I have not imagined to have the same action invoked multiple times within one run before, and it requires some refactoring for the run part.

[brucefan1983]

A natural question is, do we allow other commands to be invoked more than once or just the dump_exyz command?

[erhart1]

This starts to take on the character of the fix keyword in lammps.
It should depend on the keyword, doesn't it?

The "global" ensemble keywords, for example, should only be allowed once per run.
Then in the future, if you want to allow thermostating (or barostating) by group one could consider even that option.

[brucefan1983]

So far, any keyword will only have at most one instance within each run. If there are more and the code does not complain, only the last one will take action (the previous ones will be overwritten by the last one). This is the current behavoir and we might need to state it in the documentation.

Then I agree to make the dump_xyz keyword special, allowing for multiple instances of it within one run. Is this ok for you?

[erhart1]

Sounds good.

[AdamsGo]

Have this been implemented?
The dump option of per-atom virial would be very useful and neccessary for mechanical property-related simulations.

[brucefan1983]

Not yet. For per-atom virial, if you need time-averaged values, there is a better option: using the comupute keyword to output time-aveaged values for a "grouping method" in which each atom is in one group. Spatial-averaging can also be achieved if you use another "grouping method".

[AdamsGo]

Not yet. For per-atom virial, if you need time-averaged values, there is a better option: using the comupute keyword to output time-aveaged values for a "grouping method" in which each atom is in one group. Spatial-averaging can also be achieved if you use another "grouping method".

Thank you very much for this.

[erikfransson]

generalize dump_exyz and remove other dump

I think dump_netcdf is very useful as it is so fast to read the netcdf trajectories when analyzing large trajectories with e.g. millions of atoms. Are you thinking of removing this?

[brucefan1983]

generalize dump_exyz and remove other dump

I think dump_netcdf is very useful as it is so fast to read the netcdf trajectories when analyzing large trajectories with e.g. millions of atoms. Are you thinking of removing this?

No I was referring to dump_position, dump_velocity, and dump_force, which you even might have not used any more.

For dump_netcdf, I count on you to maintain it!