Hello:
I’ve made a small modification to the fix ave/spatial routine that allows users to specify “real” as an option on the command line that allows density/mass to be output in g/cm^3 rather than the correct, but cumbersome, g/mol/Å^3. (The user can specify “real” for any use of the command, but right now it only works for density/mass.)
I’ve attached the revised fix_ave_spatial .cpp and .h files.
Thanks,
–AEI
fix_ave_spatial.cpp (27.6 KB)
fix_ave_spatial.h (1.71 KB)
Sorry Ahmed, but I don't like this change. What if the user specifies the
option when using LJ or SI units? It seems to be tweaking LAMMPS output
to be inconsistent with the mass/volume units which are well defined
for every units style. No other LAMMPS output does this.
You could always define a variable formula to make this adjustment (by
0.6022 which is peculiar to converting real/metal units to g/cm^3,
but wouldn't work for other units).
Steve
Hi, Steve:
I’ve added a check to the command—if metal or real units are not specified, a warning is printed, but otherwise the command is ignored, and no changes are made. As for why such a correction is necessary, most units are reported in the literature in a lot of different units, so any reasonable set of units used by LAMMPS is probably OK. However, when real densities are reported, it’s pretty much always as g/cc or kg/m^3. The conversion needs to be done in order to make the data useful, either by the user or by the code. When the change is trivial to make in the code, why not allow it as an option?
How would you actually use the variable formula with fix ave/spatial for density/mass? Do you have to take the output from fix ave/spatial, process it, and then output it with another command? Does fix ave/spatial return an array that can be manipulated? (It’s certainly not clear from the documentation.)
–AEI
fix_ave_spatial.cpp (27.8 KB)
fix_ave_spatial.h (1.71 KB)
However, when real densities are
reported, it's pretty much always as g/cc or kg/m^3. The conversion needs to
be done in order to make the data useful, either by the user or by the code.
When the change is trivial to make in the code, why not allow it as an
option?
I just think it is not wise to go down this path. If we start
implementing different
options for each kind of LAMMPS output to let users change the units
to something more convenient, then it is a never ending path. And it makes
the code brittle. Every time a new unit style is added (e.g. as SI
and CGS recently
were), then we will have to remember to add a new check or conversion
factor in fix ave_spatial.cpp to insure the user can convert from
mass/volume to g/cm^3.
And everywhere else that we have started to add options to let the user tweak
the output units.
A more consistent choice would be to have every unit style define what it
means by a mass density, and document it like all the other units choices.
But since this is only used in one place and the conversion is so simple,
I'm inclined to ignore the issue.
How would you actually use the variable formula with fix ave/spatial for
density/mass? Do you have to take the output from fix ave/spatial, process
it, and then output it with another command? Does fix ave/spatial return an
array that can be manipulated? (It's certainly not clear from the
documentation.)
yes, fix ave/spatial outputs an array of values which can be manipulated - see
the end of the doc page for the command.
Steve