Testing Fix GCMC - full energy feature

Hi Lammps community,

I have previously posted the problems i was having with the new full_energy feature of fix gcmc, so i decided to create a test case for this purpose.

First i have taken the following work as a reference work to repeat;

http://pubs.acs.org/doi/abs/10.1021%2Fj100015a050

I have chosen an ethane molecule so that it would not have partial charges, as before the latest patch, insertion of charged molecules with no full_energy enabled was bugged.

I am using 5May version of lammps, and if i didn’t missed any, no patches after that should change the results of this work.

As result, with full_energy feature disabled, one can obtain close results to the reference work. Meanwhile, i was not able to insert any single ethane molecule into the structure with full_energy enabled.

Any help would be appreciated.

Thanks in advance
Marcel

ethane.txt (254 Bytes)

inputgcmcnofull.in (1.4 KB)

MFI.data (410 KB)

nofull0.1.lammps (3.37 KB)

nofull0.5.lammps (3.37 KB)

nofull1.lammps (3.37 KB)

inputgcmcfull.in (1.41 KB)

full0.1.lammps (3.42 KB)

full0.5.lammps (3.42 KB)

Not sure this even relates to your case but there was the exchange below very recently regarding gcmc.
http://sourceforge.net/p/lammps/mailman/message/34274105/

Carlos

Hi Marcel,

My initial thoughts are that your issue has to do with intramolecular energies. When using ‘full_energy off’, the intramolecular energy is hard coded in gcmc to be zero (see lines 1923-1924 of fix_gcmc.cpp). However, when using ‘full_energy on’ the intramolecular energy is not turned off. With your defined LJ potential, there will be a large and positive intramolecular energy which causes insertion events to have a very low probability of acceptance. This was an issue I brought up when Aidan first became the new owner of fix_gcmc. To fix the problem, he added the intra_energy value option to gcmc. My suggestion is you read the info in the doc page about this option and then use it in your simulation to see if it fixes your issue.

-CBL

Also, I forgot to mention that the ‘intra_energy’ option was added after 5May15, so make sure you update to the latest version (or at least after 11May).

-CBL

I tried it with 8Jul15 version of the Lammps. There was no difference and no insertion attempt was succeded.

Marcel

What value did you use for the intra_energy? You obviously need to first calculate the intramolecular energy for your molecule using lammps, so hopefully you did that. Please provide an updated input script with your attempt at using intra_energy.

-CBL

After your warning, i have checked my calculations and you are right, i had made a mistake in units.

With 24.02426 as intra_energy value, the gcmc with full energy acts exactly same with no full_energy.

Thanks for solving the mystery :slight_smile:

But still i will not be able to use lammps for my gcmc simulations as the gcmc with full_energy takes about 200-300 times more cpu time comparing with no full_energy. In my simulations i will need to model the sorption-relaxation cycles of polymers, and considering i will have to do about 700 gcmc runs for each polymer and it takes about 20 hours for every gcmc run in that system, it is sad news for me. I also cannot leave using ewald summations :slight_smile:

Thanks for all the help.
Marcel

In what mode do you compile/run your gcmc incarnation of LAMMPS?
I resorted to build only small single-core executeables for this
purpose and, at least in my cases, it appears to be much more
efficient to put 12 different single core runs at a time on a
single cluster node (6-core nodes w/hyperthreading).

On my "personal" 6-node cluster, that results in 36 results
dripping in simultaneously from this "poor man parallelization" :wink:

YMMV

Regards

M.

Just a heads up that there was a subtle problem using fix gcmc with
bonded molecules and full energy, but not SHAKE or RATTLE. This
typically manifested itself by a failure to delete molecules, but it
could also generate memory errors, like segmentation fault. A
correction has been added to neighbor.cpp which will be released
shortly, and is attached. No other calculations are affected by this
i.e. atoms, and not full energy.

neighbor.cpp (72.4 KB)