pppm energy inconsistency

363 views
Skip to first unread message

John Williams

unread,
Sep 15, 2016, 7:28:03 PM9/15/16
to hoomd-users
Hi, I am a new user of HOOMD-BLUE with some previous LAMMPS experience. I have read the HOOMD documentation and it seems it is very straightforward to translate many concepts and commands from LAMMPS to HOOMD-BLUE.

I am interested in simulations of charged systems, so I tried first to calculate the electrostatic interaction between only two particles using pppm in HOOMD. According to the manual, the use of analyze.log in version 1.3.3 allow us to know several properties of a system such as pair_lj_energy, pair_ewald_energy, and pair_pppm_energy. They are the total energy of Lennard Jones interactions, and the total short-range and long-range parts of Coulombic interactions using Ewald sums, respectively, with the PPPM method.

I have checked that the total energy per particle associated to pair_lj_energy in HOOMD is indeed the same that one obtains with LAMMPS for two particles, and for several particles.

However, for the case of only two charged particles (separated by a given distance) the energy per particle obtained in HOOMD is exactly a quarter of the energy per particle obtained in LAMMPS. I have used different pairs of +q,-q charges (to maintain the electroneutrality of the system) with the same result.

I also performed some simulations of an electrolyte keeping the same simulation box, valences, temperature, etc. and varied only the number of ions. In all cases the ratio between the HOOMD energy per particle and the LAMMPS energy per particle was different. That is, it was not possible to find the same scaling factor for the energy (like 4 as occurred in the case of two particles) for different electrolyte concentrations. On the other hand, the ionic profiles obtained using both programs for one particular system (under the same conditions) were very similar in a case I checked. This is very puzzling.

I wonder if somebody has calculated the Ewald energy of a simple crystal (like NaCl) or a simple electrolyte with HOOMD and LAMMPS, and knows how to relate these energies assuming both quantities are given in K_B*T and have the same parameters. According to the HOOMD documentation, I understand that the sum of the pair_ewald_energy and pair_pppm_energy (in K_B*T units) divided by the total number of ions in the simulation box should correspond exactly to the energy per particle reported in LAMMPS (in K_B*T units) for the same sigma (Lennard Johnes parameter of distance) in both programs.

Any comment or suggestion is very welcomed. 

John Williams




Jens Glaser

unread,
Sep 15, 2016, 9:45:10 PM9/15/16
to hoomd...@googlegroups.com
Hi John

> On Sep 15, 2016, at 7:26 PM, John Williams <nuwillia...@gmail.com> wrote:
>
> Hi, I am a new user of HOOMD-BLUE with some previous LAMMPS experience. I have read the HOOMD documentation and it seems it is very straightforward to translate many concepts and commands from LAMMPS to HOOMD-BLUE.
>
> I am interested in simulations of charged systems, so I tried first to calculate the electrostatic interaction between only two particles using pppm in HOOMD. According to the manual, the use of analyze.log in version 1.3.3 allow us to know several properties of a system such as pair_lj_energy, pair_ewald_energy, and pair_pppm_energy. They are the total energy of Lennard Jones interactions, and the total short-range and long-range parts of Coulombic interactions using Ewald sums, respectively, with the PPPM method.
>
correct

> I have checked that the total energy per particle associated to pair_lj_energy in HOOMD is indeed the same that one obtains with LAMMPS for two particles, and for several particles.
>
> However, for the case of only two charged particles (separated by a given distance) the energy per particle obtained in HOOMD is exactly a quarter of the energy per particle obtained in LAMMPS. I have used different pairs of +q,-q charges (to maintain the electroneutrality of the system) with the same result.
>
ok. Neutrality is indeed important. HOOMD 2.0 reports the PPPM energy for non-neutral systems incorrectly, as found here
https://bitbucket.org/glotzer/hoomd-blue/pull-requests/249/adding-ewald-summation-for-yukawa/diff

This will presumably be fixed in 2.1

> I also performed some simulations of an electrolyte keeping the same simulation box, valences, temperature, etc. and varied only the number of ions. In all cases the ratio between the HOOMD energy per particle and the LAMMPS energy per particle was different. That is, it was not possible to find the same scaling factor for the energy (like 4 as occurred in the case of two particles) for different electrolyte concentrations. On the other hand, the ionic profiles obtained using both programs for one particular system (under the same conditions) were very similar in a case I checked. This is very puzzling.
>
Hmm. This sounds indeed puzzling. It would help if you could provide your python script, so I (or someone else) can help you debugging.

Note that it matters which splitting factor (kappa) is chosen, that may be different between the two codes. Additionally, grid dimensions
and r_cut should be the same too. To obtain kappa, do

pppm = md.charge.pppm(...)
pppm.set_params(…)
kappa = pppm.ewald.pair_coeff.get(‘A’,’A’, ‘kappa’) # or any other type pair
print(kappa)

> I wonder if somebody has calculated the Ewald energy of a simple crystal (like NaCl) or a simple electrolyte with HOOMD and LAMMPS, and knows how to relate these energies assuming both quantities are given in K_B*T and have the same parameters.

> According to the HOOMD documentation, I understand that the sum of the pair_ewald_energy and pair_pppm_energy (in K_B*T units) divided by the total number of ions in the simulation box should correspond exactly to the energy per particle reported in LAMMPS (in K_B*T units) for the same sigma (Lennard Johnes parameter of distance) in both programs.
>
HOOMD units of charge are documented here:

http://hoomd-blue.readthedocs.io/en/stable/units.html

It may be there is a difference 1/(4 Pi epsilon_0) in the energies. Not sure about lammps.

Jens

Jens Glaser

unread,
Sep 16, 2016, 11:33:55 PM9/16/16
to hoomd...@googlegroups.com
John,

there were two critical bugs in charge.pppm() in 2.0.x, which led to invalid forces either when
running on the CPU, or when group.charged() was a subset of group.all(). These bugs were undetected by the unit tests.

If you want to know more, see these two pull requests for more info
https://bitbucket.org/glotzer/hoomd-blue/pull-requests/258/fix-pppm/diff
https://bitbucket.org/glotzer/hoomd-blue/pull-requests/256/fix-bug-in-chargepppm-on-cpu/diff

We are working on having these changes in maint and providing an upcoming bug fix release.

Jens

John Williams

unread,
Sep 18, 2016, 8:22:40 PM9/18/16
to hoomd-users

Dear Jens

Thank you so much for all your detailed comments. 

I was comparing HOOMD pppm with LAMMP's Ewald sums. I think it would be better to check pppm forces between HOOMD and LAMMPS under analogous conditions, using for example the same damping constant in the k-space you mention, etc. 

As you found two bugs in the force calculated using pppm in the newest 2.0.3 HOOMD version, I decided to compile the branch yukawa_ewald, commit  b5dba95.

However, when I try to compile I get the following errors below. In particular, I do not understand why: 

1.- "MPI<->CUDA interoperability does not appear to be available."

When I type 
% mpirun --version
mpirun (Open MPI) 1.6.5

2.- "CUDA version >= 7.5, looking for cusolver library
-- Could not find cusolver library, constraints will be slower, perhaps old CMake?" 

%cmake --version
cmake version 2.8.12.2

3.- -- Updating git submodules
fatal: Not a git repository (or any of the parent directories): .git
CMake Error at CMakeLists.txt:68 (message):
  Libgetar was not found in hoomd/extern/libgetar.  Please pull the libgetar
  source, i.e.  via `git submodule update`.
-- Configuring incomplete, errors occurred!

I was able to compile successfully the version 1.3.3 but not 2.0.3, 
what libraries or paths do you think could be missing?

Thanks

John


%pwd
glotzer-hoomd-blue-b5dba9500a95/build

cmake ../ -DENABLE_MPI=ON 
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring HOOMD 2.0.3-unknown
-- Found MPI_C: /usr/lib/libmpi.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libhwloc.so  
-- Found MPI_CXX: /usr/lib/libmpi_cxx.so;/usr/lib/libmpi.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libhwloc.so  
-- MPI<->CUDA interoperability does not appear to be available.
-- Found PythonInterp: /usr/bin/python (found version "2.7.6") 
-- Found PythonLibs: /usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7.so  
-- Found CUDA: /usr/local/cuda (found version "7.5") 
-- Found Thrust: /usr/local/cuda/include  
-- CUDA version >= 7.5, looking for cusolver library
-- Could not find cusolver library, constraints will be slower, perhaps old CMake?
-- Overriding CMake's default CFLAGS (this should appear only once)
-- GCC_ARCH env var not set, setting -march to native
-- Found numpy: /usr/lib/python2.7/dist-packages/numpy/core/include
-- Updating git submodules
fatal: Not a git repository (or any of the parent directories): .git
CMake Error at CMakeLists.txt:68 (message):
  Libgetar was not found in hoomd/extern/libgetar.  Please pull the libgetar
  source, i.e.  via `git submodule update`.


-- Configuring incomplete, errors occurred!

Jens Glaser

unread,
Sep 18, 2016, 10:23:26 PM9/18/16
to hoomd...@googlegroups.com
John,


On Sep 18, 2016, at 8:22 PM, John Williams <nuwillia...@gmail.com> wrote:
I was comparing HOOMD pppm with LAMMP's Ewald sums. I think it would be better to check pppm forces between HOOMD and LAMMPS under analogous conditions, using for example the same damping constant in the k-space you mention, etc. 

As you found two bugs in the force calculated using pppm in the newest 2.0.3 HOOMD version, I decided to compile the branch yukawa_ewald, commit  b5dba95.

However, when I try to compile I get the following errors below. In particular, I do not understand why: 

1.- "MPI<->CUDA interoperability does not appear to be available."

When I type 
% mpirun --version
mpirun (Open MPI) 1.6.5

yes, that’s fine it just means that your OpenMPI does not have CUDA support. This
functionality is optional and disabled by default anyways.

2.- "CUDA version >= 7.5, looking for cusolver library
-- Could not find cusolver library, constraints will be slower, perhaps old CMake?" 

%cmake --version
cmake version 2.8.12.2

cusolver is also optional and only needed to accelerate pairwise distance constraint.


3.- -- Updating git submodules
fatal: Not a git repository (or any of the parent directories): .git
CMake Error at CMakeLists.txt:68 (message):
  Libgetar was not found in hoomd/extern/libgetar.  Please pull the libgetar
  source, i.e.  via `git submodule update`.
-- Configuring incomplete, errors occurred!


This seems critical. I haven’t seen it before. But could it be you’re not using (a recent version of) git?

Did you checkout hoomd using git (I suppose so, how would you have otherwise obtained the source code).

Just for definiteness, try starting from a clean build directory.

Jens

--
You received this message because you are subscribed to the Google Groups "hoomd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.
To post to this group, send email to hoomd...@googlegroups.com.
Visit this group at https://groups.google.com/group/hoomd-users.
For more options, visit https://groups.google.com/d/optout.

John Williams

unread,
Sep 19, 2016, 12:18:17 AM9/19/16
to hoomd-users

Dear Jens, 

Thank you again for your kind comments. 

I will update my git version and try a clean build as you suggest. 

Best regards,

John

Joshua Anderson

unread,
Sep 19, 2016, 7:01:34 AM9/19/16
to hoomd...@googlegroups.com
Also try to manually run 'git submodule update --all' in the source directory prior to running cmake in the build directory.

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan
Phone: 734-647-8244
http://www-personal.umich.edu/~joaander/

To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages