Here's another idea.
What if there was a compute that assigned a per-chunk value to every
atom in the chunk. We've recently talked about this for use in other
contexts. E.g. in the case of compute dipole/chunk as an input to the
new compute, it would assign the 3-vector dipole moment for one chunk
(molecule) to each atom in the water (or other) molecule.
Then the usual fix ave/chunk for spatial bins could
compute an average dipole moment for each spatial bin.
A water molecule that straddled 2 bins would have 2 copies of the same
dipole momemt summed to one bin, and 1 copy to the other. In a
weighted manner where the first bin's summed moment was divided by 2
atoms, and the second bin by 1 atom.
It's a bit different than assigning each molecule's moment to one bin
based on the COM position, but you could argue it's a reasonable
(maybe better) way to spatially average.
Steve
Dear all,
I am having a disturbing discrepancy between energies at the end of a minimization when using fix box/relax in triclinic boxes. Here is an example:
Total # of neighbors = 570502
Ave neighs/atom = 74.517
Neighbor list builds = 0
Dangerous builds = 0
WARNING: Resetting reneighboring criteria during minimization (…/min.cpp:168)
Setting up cg style minimization …
Unit style : metal
Memory usage per processor = 7.24358 Mbytes
Step Temp E_pair E_mol TotEng Press Volume
919 0 -11604.619 0 -11604.619 -0.91658651 175219.93
920 0 -11604.619 0 -11604.619 -0.91658651 175219.93
Loop time of 0.0569309 on 32 procs for 1 steps with 7656 atoms
78.9% CPU use with 32 MPI tasks x no OpenMP threads
Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-11701.1483369 -11701.1483369 -11701.1483369
Force two-norm initial, final = 6.88862 6.88862
Force max component initial, final = 1.27913 1.27913
Final line search alpha, max atom move = 1.49113e-10 1.90735e-10
Iterations, force evaluations = 1 20
The numbers highlighted in red are the source of the discrepancy. After minimizing I do run 0 and the energy that I get is the same as in the last step of the minimization (-11604.619 in this case). The problem is that as you see the difference might be pretty large and might change the results qualitatively. Which energy should I take?
I am attaching an input file, data file and output for you to check.
Thanks a lot,
Best,
Enrique
in.shear (8.21 KB)
ATT00001.htm (226 Bytes)
Mg-10-12-PopUp-17Ats-ORD.data (283 KB)
ATT00001.htm (226 Bytes)
out-Mg (45.1 KB)
ATT00003.htm (656 Bytes)
Dear all,
I am having a disturbing discrepancy between energies at the end of a
minimization when using fix box/relax in triclinic boxes. Here is an
example:
Total # of neighbors = 570502
Ave neighs/atom = 74.517
Neighbor list builds = 0
Dangerous builds = 0
WARNING: Resetting reneighboring criteria during minimization
(../min.cpp:168)
Setting up cg style minimization ...
Unit style : metal
Memory usage per processor = 7.24358 Mbytes
Step Temp E_pair E_mol TotEng Press Volume
919 0 -11604.619 0 -11604.619 -0.91658651
175219.93
920 0 -11604.619 0 -11604.619
-0.91658651 175219.93
Loop time of 0.0569309 on 32 procs for 1 steps with 7656 atoms
78.9% CPU use with 32 MPI tasks x no OpenMP threads
Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-11701.1483369 -11701.1483369 -11701.1483369
Force two-norm initial, final = 6.88862 6.88862
Force max component initial, final = 1.27913 1.27913
Final line search alpha, max atom move = 1.49113e-10 1.90735e-10
Iterations, force evaluations = 1 20
The numbers highlighted in red are the source of the discrepancy. After
minimizing I do run 0 and the energy that I get is the same as in the last
step of the minimization (-11604.619 in this case). The problem is that as
you see the difference might be pretty large and might change the results
qualitatively. Which energy should I take?
the difference is due to your use of fix box/relax. in the fix box/relax
documentation, it is mentioned, that the energy for the minimizer is
augmented by the fix. there is more information about what is happening. i
suggest you check the docs again and the referenced equations and paper
and explanations and then make an educated decision.
axel
Hi Axel,
It is indeed explained in the documentation. Maybe issuing a warning when using box/relax will help the users.
Thanks,
Enrique
Hi Axel,
It is indeed explained in the documentation. Maybe issuing a warning when
using box/relax will help the users.
the LAMMPS philosophy in general is to provide explanations and
(conceptual) warnings in the documentation rather than in the code.
however, the case of fix box/relax is somewhat different from how fix
energies are handled in LAMMPS, so i think printing a warning may be
justified here. it is conceptually not different from the warning about
resetting neighbor list parameters during minimization.
although, the _consistent_ solution, would be to have fix box/relax respond
to fix_modify energy yes and then make fix box/relax print a warning, when
it is called without this proper fix_modify setting. however, since this
breaks backward compatibility for a lot of cases, i am hesitant to
implement such a change without a detailed discussion with other LAMMPS
developers (cc: steve & aidan).
i am attaching a patch that implements an informational warning as
suggested, that can be included without changing LAMMPS' behavior.
this will change the output to something like this:
minimize 0.0 1e-4 10000 100000
WARNING: Resetting reneighboring criteria during minimization
(../min.cpp:168)
Setting up cg style minimization ...
Unit style : metal
Current step : 919
WARNING: Energy due to 6 extra global DOFs will be included in minimizer
energies
Per MPI rank memory allocation (min/avg/max) = 7.512 | 7.516 | 7.52 Mbytes
Step Temp E_pair E_mol TotEng Press Volume
919 0 -11604.619 0 -11604.619 -0.91658651
175219.93
920 0 -11604.619 0 -11604.619 -0.91658651
175219.93
Loop time of 0.1029 on 8 procs for 1 steps with 7656 atoms
please note, that you can access the energy contributed by the fix through
a global scalar property. e.g. via:
variable etot equal etotal+f_relax
axel.
fix-box-relax-energy-warn.diff.gz (1001 Bytes)
Hi Steve,
Thank you for thinking about the problem!
I think that a compute that assigns per-chunk values to every atom in
the chunk would be an extremely useful extension to LAMMPS!
It would certainly resolve the problem I was interested in, but I could
see this be helpful in other contexts as well.
Best wishes,
Peter
I’ll add that the examples/min/in.min.box shows how
to setup your thermo output so that you see the
pe (for atoms), the delta added by fix box/relax, and
the pe (for atoms + box equation) that is used by the minimizer.
The last quantity should agree with what the minimizer
stats print out at the end.
Steve
Is there a way to add the energy from the fix in a NEB calculation?
Thanks,
Enrique