Concerning the setting of fix mbx in lammps

[Wenjie LIU]

Dear developers and everyone,

Recently I tried to conduct a simulation of a system where water and carbon nanotube coexist. I allocate the atoms' type as follow: C-1 H-2 O-3. In the input data file. I first allocate all ids of C, then for every water molecule, O has the smallest id.

When I wrote the sentence of fix mbx like following:
fix 1 all mbx 1 h2o 2 3 3 3 2 2 json mbx.json

I think I followed the syntax of fix mbx, but I got an error saying "ERROR: The atom types in fix mbx do not match the atom types in the data file (../fix_mbx.cpp:454)"

I try to reallocate the atom id, this time the water came first then the cnt, but this error persisted.

Are there any suggestions about the input data file?

Best regards,
Wenjie LIU

[MBX-users]

Dear Wenjie,

         It looks like you are attempting to do a hybrid simulation involving a carbon nanotube with just the water processed by MBX. In order for MBX to understand this, we will need a "fix mbx" similar to this hybrid simulation example:

fix             1 all mbx 2 dp1 1 1 1 1 h2o 2 3 3 2 2  json mbx.json

This is because "all" of the atoms including the carbons are being passed into MBX, so the carbon atom type 1 must therefore be assigned the dp1 monomer type (drude particle external charges). MBX does not currently support LAMMPS groups, such as to only pass in the water molecules to MBX like you attempted, but it something we are looking into for the future.

Best regards,
MBX team

[Wenjie LIU]

Dear MBX team,

Following your suggestion I restarted the simulation, this time the
error "ERROR: The atom types in fix mbx do not match the atom types in
the data file (../fix_mbx.cpp:454)" disappeared. However, another
error saying "Inconsistent # of atoms" happened.

In my data file, every C atom has a different molecular id (for
example, C atom with id 1 also belongs to molecule 1, C with id 2
belongs to molecule 2). Thus I think the sentence "fix 1
all mbx 2 dp1 1 1 1 1 h2o 2 3 3 2 2 json mbx.json" is correct. Why
this error happens? Do I need to make some revisions on my data file?

Best regards,
Wenjie

MBX-users <mbx-...@googlegroups.com> 于2024年1月27日周六 04:50写道：

> --
> You received this message because you are subscribed to the Google Groups "MBX-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mbx-users+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mbx-users/83838e79-8dec-4e8d-9e58-b37bae12f4a1n%40googlegroups.com.

[Henry Agnew]

Dear Wenjie,

        I believe I see a typo in the fix I gave you previously. Here is an updated fix:

fix             1 all mbx 2 dp1 1 1 1 1 h2o 2 3 3 3 2 2  json mbx.json

For the h2o part, here is an explanation of what each of the numbers means:

lowest atom type = 2

highest atom type = 3

number of atoms = 3

Oxygen (previously missing) = 3

Hydrogen = 2

Hydrogen = 2

In the old fix I sent you, I was missing a "3" so that we were specifying three atoms in h2o but only providing the hydrogens. Hopefully this corrected fix works better for you!

Furthermore, if any of your external dp1 atoms are charged, you should also have the hybrid/overlay coul/exclude pair_style enabled such as in https://github.com/paesanilab/MBX-dev/blob/23f74b0599c697f520ff5ee87fb9f0472c0237a2/plugins/lammps/examples/mof_ff_lammps%2B16_co2_mbx/lammps.in#L83 and https://github.com/paesanilab/MBX-dev/blob/23f74b0599c697f520ff5ee87fb9f0472c0237a2/plugins/lammps/examples/mof_ff_lammps%2B16_co2_mbx/lammps.in#L139

pair_coeff 1 1 coul/exclude

coul/exclude make sure that bonded coulomb interactions for the external dp1 atoms are properly handled.

Hopefully this fix works better for you,

Best regards,
MBX team

[Wenjie LIU]

Dear Henry,

Thank you so much for replying to me.

Before receiving your reply, last week I kept trying to find the
origin of this error and fix it. I found that this error actually
happens when the simulation has passed several steps, which means that
it can at least start with no errors, just like the simulation for the
bulk water case.

But I found this error very strange, even not self-consistent. Here I
try to summarize some confusing points:

1. The simulation can not conduct minimization properly and fails
after at most 20 steps. (Thus, I use the same input data file to
conduct minimization and something like preliminary equilibration
without mb-pol potential)

2. After rough minimization, I introduced the data file into mb-pol
simulation. This time the simulation collapsed after several hundred
steps with no evidence of energy/velocity divergence and box
explosion(everything seems normal, but errors happen). The following
is the error message: inconsistent # of atoms (pair_mbx.cpp: 2292). I
guess this is because some specific atoms in water molecules are lost.

3. However, the following thing makes me very confused: If I
periodically write/read_restart the simulation every several hundred
steps (or periodically unfix/re-fix mbx), the simulation can survive
the specific step where it failed if I conduct it continuously and go
smoothly to several hundred Kilo steps. Besides, I found that even
sentences like "write_data xx.data" and "restart 1000" will make the
simulation fail, but if I remove such sentences, the simulation can
survive.

Maybe these errors come from MPI parallel calculation instead of the
simulated case itself? Do you have some suggestions or clews for this
situation?

For reference: My MBX and LAMMPS were compiled by openmpi(not intel
mpi), which means I used mpicxx instead of mpiicpc. Does this matter?

I am really sorry that I have so many problems. Thank you for your
time and consideration.

Sincerely,
Wenjie LIU <liu-we...@g.ecc.u-tokyo.ac.jp> 于2024年1月27日周六 10:47写道：

[Henry Agnew]

Dear Wenjie,

         Could you please share your lammps.in file so we can see if there are any obvious issues?

Based on the information you have given so far, it does seem that the simulation does survive for a few steps but quickly crashes. In order to see what specifically is causing the simulation to explode and atoms to go missing, I would recommend to dump the trajectory every step and then visualize the simulation in VMD or similar software to see which specific molecules are causing the crash in the final few steps. You should also have the thermo print frequency set to every step as well since those values will likely spike in the final step(s).

If you see in the final steps of the simulation molecules getting too close to each other or heavily distorting, those are likely the ones causing issues. This would help determine if the issue is the water, the carbon nanotube, or the interaction between them. This will therefore help us narrow down which part of the lammps.in might be causing the instability.

While there may be a speed difference between OpenMPI vs IntelMPI, the simulation stability should be the same regardless of which one you use.

Let us know what you see when visualizing the final steps of your simulation and hopefully your lammps.in will also reveal what is going on.

Best regards,
MBX team

[Wenjie LIU]

Dear Henry:

Thank you for your reply.

I have checked the every-step log file and trajectory, no energy diversion, and no overlap of atoms were found.

I upload my in.file and other files for your reference.

Sincerely,

Wenjie LIU

'Henry Agnew' via MBX-users <mbx-...@googlegroups.com> 于2024年2月15日周四 13:57写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/mbx-users/08546026-5e98-48c1-b901-04996b45b5dbn%40googlegroups.com.

[Henry Agnew]

Dear Wenjie,
        Thank you for sending those files!

I have attached a new mbx.json file for you to try. It appears you used the 2048h2o/mbx.json example, which is a bit outdated and we are actively updating for the next upcoming public release. Hopefully using "dipole_method" : "cg" will be more stable, but we shall see.

I still need to take a closer look at the in.test file that you shared. I would definitely keep your "dump mini all custom 1 dump_mini.dump id type x y z" line enabled during your testing since that should tell us which specific atoms are being lost at the end of your simulation.

Relating to the MOF hybrid example (https://github.com/paesanilab/MBX/blob/master/plugins/lammps/examples/mof_ff_lammps%2B1_h2o_mbx/lammps.in), here are some pieces that may be applicable to you:

1. We recommend having those sections involving the coul/exclude pair_style for all hybrid simulations, such as the one you are running. If your carbon nanotube is charged, you will definitely need the sections involving coul/exclude. 
2. Below, I've included a more verbose thermo_style that will give us more information:

timestep        ${dt}
compute         mbx all pair mbx
variable        e1bpip    equal c_mbx[1]
variable        e2bpip    equal c_mbx[2]
variable        e3bpip    equal c_mbx[3]
variable        e4bpip    equal c_mbx[4]
variable        edisp     equal c_mbx[5]
variable        ebuck     equal c_mbx[6]
variable        eele      equal c_mbx[7]
variable        etot      equal c_mbx[8]

#thermo_style    custom step time temp cella cellb cellc vol pe ke etotal
thermo_style    custom step time temp cella cellb cellc evdwl ecoul epair ebond eangle edihed eimp emol elong etail v_e1bpip v_e2bpip v_e3bpip v_e4bpip v_edisp v_ebuck v_eele v_etot pe etotal
thermo          1
thermo_modify   flush yes

Let us know if any of this advice helps improve things, or if you see any new error messages aside from "inconsistent # of atoms".

Best regards,
MBX team

[Wenjie LIU]

Dear Henry,

Thank you for your reply. These days I followed your suggestions and used the new version of JSON file, now the simulation can survive at least several thousand steps (and the minimization now can be conducted sucessfully). I will conduct a simulation with more than 1M steps to check its stability, but I am optimistic about it.

Sincerely,

Wenjie LIU

'Henry Agnew' via MBX-users <mbx-...@googlegroups.com> 于2024年2月16日周五 17:18写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/mbx-users/1a978630-7e14-4b8e-97fd-59eef356d3a1n%40googlegroups.com.

[Henry Agnew]

Dear Wenjie,

        I'm glad we were able to isolate and solve the likely issue, and thank you for your patience during this debugging process. Keep us posted on your progress, and of course please let us know if you encounter any additional issues.

Based on what we learned here, this past weekend I have been overhauling the lammps examples in our development branch to ensure "aspc" has been replaced with "cg" to avoid these issues in the future. Thank you for helping me correct this. I have also added/updated 256h2o, 512h2o, 1024h2o, and 2048h2o lammps examples to serve as better starting points for new MBX users.

Best regards,
MBX team

P.S. In the event that you do eventually end up publishing this project in a journal, please don't forget to cite our papers! We have them listed in the README.md, and I've also included the list below:

Please cite the corresponding manuscript whenever using MBX:J. Chem. Phys. 159, 054802 (2023)
Please cite the following manuscripts if any of the following PEFs is used: MB-pol for waterJ. Chem. Theory Comput. 9, 5395 (2013)
J. Chem. Theory Comput. 10, 1599 (2014)
J. Chem. Theory Comput. 10, 2906 (2014)
J. Chem. Phys. 145, 194504 (2016)
Acc. Chem. Res. 49, 1844 (2016)

[Wenjie LIU]

Dear Henry,

I am glad too that with your selfless help we solve such very strange errors.

Though it is still far for me to publish a paper in the current stage, I will definitely cite the mb-pol related papers, not only for my gratitude to such an accurate potential and your help, but also, most importantly, for the academic integrity and 

norms.

Sincerely,

Wenjie LIU

'Henry Agnew' via MBX-users <mbx-...@googlegroups.com>于2024年2月19日 周一17:07写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/mbx-users/17c4b11e-054e-4c57-b3e4-2f2ee61d33d0n%40googlegroups.com.