Binary gas problem with fix gcmc

---------- Yönlendirilen ileti ----------
Gönderen: “Marcel Balçık” <[email protected]…24…>
Tarih: 09 Nis 2014 20:27
Konu: Re: [lammps-users] Binary gas problem with fix gcmc
Alıcı: “Axel Kohlmeyer” <[email protected]>

Sure i did. Yet I tought (obviously I was wrong) that as my gcmc’s use different template molecules they would not delete each others molecules. Yet I could not understand if the statement
“An existing template molecule will need to be referenced by the user for each subsequent fix gcmc command”
states a solution or just the situation.
I also wonder if the problem would be solved if I had defined methane as atom, not a molecule.

09 Nis 2014 17:54 tarihinde “Axel Kohlmeyer” <[email protected]…24…> yazdı:

---------- Yönlendirilen ileti ----------
Gönderen: "Marcel Balçık" <[email protected]>
Tarih: 09 Nis 2014 20:27
Konu: Re: [lammps-users] Binary gas problem with fix gcmc
Alıcı: "Axel Kohlmeyer" <[email protected]>

Sure i did. Yet I tought (obviously I was wrong) that as my gcmc's use
different template molecules they would not delete each others molecules.

a quick review of the source code (if the documentation is not clear,
there always is the source code as the ultimate reference!), reveals
that things are not as trivial as that. in fact there are two problems
that i could identify with the current implementation.

1) the fix defines a group for the gas molecule atoms. unfortunately,
the name of this group is not made unique and thus the atoms from the
second template molecule will be added to the group that is now
referred to by both fixes. this is what leads to the segfault that you
saw and can be corrected.

2) the fix does not keep track of which molecule id was inserted by
which fix and thus some operation (rotation attempts most likely) will
refer to the "wrong" template molecule and thus create the segfault
due to not enough atoms in the template.structure. this requires some
significant programming effort.

i am attaching a patch that will include the fix for case 1) and a
suitable check for incompatible multiple fix gcmc definitions.

Yet I could not understand if the statement
"An existing template molecule will need to be referenced by the user for
each subsequent fix gcmc command"
states a solution or just the situation.
I also wonder if the problem would be solved if I had defined methane as
atom, not a molecule.

that is easy to find out. it should not trigger any of the problems
mentioned above. perhaps some other...

axel.

lammps-fix-gcmc-safer.diff.gz (744 Bytes)

will release this as a patch today - thanks Axel!

Steve

Hi Axel and lammps community,

I have applied your patch a while ago (Thanks for it) yet i did not respond in order to collect some data about the new problem i have.

Using a ‘molecule’ gcmc with an ‘atom’ gcmc works well. Also as a feedback i have checked the results of alone gcmc for mixed gas with Accerlys MS and they have matched well.

Yet i have an another problem right now. I recently saw the following discussion in mail group;

http://lammps.sandia.gov/threads/msg43716.html

As i need a GCMC+NPT run, i decided to make a cylcle like that for myself. However, there occured an error like this at the gcmc part of the second cylce;

3 atoms in group FixGCMC:rotation_gas_atoms:1
ERROR: Fix gcmc could not find any atoms in the user-supplied template molecule (…/fix_gcmc.cpp:1063)

This occurs as the template molecule to insert was erased during the first cycle. So as a solution i have inserted 2 CO2 molecules, one for the gcmc group while the other is for insertion and will not be deleted. So i had an input file like this;

matrimidnew21CO2.data (1.72 MB)

[...]

The problem i had with this cycle system was, starting from the second
cylce, lammps output stated that;
"6 atoms in group FixGCMC:rotation_gas_atoms:11

It works in this way, yet i am not sure if it is a correct way to do.

it is pretty straightforward when know some of the internals of the
LAMMPS program design.

I have concluded that this was due to the same fix ID being fixed and
unfixed. So i have created a new loop for Fix ID's.

yes and no. it is not the creation of the fix itself, but the fact
that the fix also creates a group and that this group is not cleaned
up as the fix is deleted. the "6 atoms in group ..." message is an
indication of that. this is why it is so important to have careful
people like you to test new and improved features, as this is the only
way to find and eliminate oversights like this.

the correction should be pretty straightforward and something like the
code below. mind you, this is untested. i only made sure it compiles.
but i am fairly confident that it should work. this way you should not
need to loop over fix ids. please give it a try and let us know.

diff --git a/src/MC/fix_gcmc.cpp b/src/MC/fix_gcmc.cpp
index 38c54d4..bbf9578 100644
--- a/src/MC/fix_gcmc.cpp
+++ b/src/MC/fix_gcmc.cpp
@@ -237,6 +237,16 @@ FixGCMC::~FixGCMC()
   if (regionflag) delete [] idregion;
   delete random_equal;
   delete random_unequal;

added this clean-up - will be in next patch

thanks,
Steve

The patch (2 of them combined) seems to work well for now ( i have made 60 cycles).

Thanks a lot for it.