Missing rule (warnings emerge in the latest version of EMC)


Due to the expiration of the EMC 2022 version, I switched to the latest 20230801. However, using the same input file (*.esh, build.emc) which successfully generated LAMMPS files by EMC 2022, now it’s terminated by Warning: missing rule.

Based on the log file, the atom causing problems is

ATOM:0 ^6c(:^6c(:^6c(:^6c(:^6c)(S))(H))(H))(:^6c(:^6c(:^6c(:^6c)(S))(H))(H))(S(^6c(:^6c(:^6c)(H))(:^6c(:^6c)(H))))

Adding this exact rule to my opls-aa.top didn’t fix this warning.

Could you please give me some suggestion on this issue? Besides, is it possible to reactivate the 2022 version of EMC?


Can you provide the .esh for which you are experiencing this problem? This helps in finding a solution. Thanks in advance!

Hi veld,

Of course. Please see my .esh settings as following. Thanks for your help!



replace true
field opls
density 0.4
pdb_unwrap false
number true
seed -1
field_debug reduced
field_increment ignore



PPS *c1ccc(S*)cc1, 1, PPS:2
ter1 C*,1,PPS:1
ter2 *c1ccc(C)cc1,1,PPS:2



poly alternate, 1 



1 PPS,10,ter1,1,ter2,1


Dear User,

Thank you for your input script. Stricter rule interpretation was used in the EMC version I released end of July, which clashes with older force fields such as OPLS. After repairing this issue, I noticed, that you are trying to type a diphenylthioether, which was not part of the rule set in 2022. Also, certain angle and dihedral parameters were missing in 2022. I added the missing rule and parameters and updated the emc_v9.4.4.20230801 versions on https://montecarlo.sourceforge.net/ to reflect these changes.


Dear Pieter,

Thanks for the prompt action. It is working for me now.

Besides, would you consider adding some tutorials on how to add functions for new fragments to the documentation? It would be very helpful in cases of uncommon chemicals.


Dear Pieter,

in the previous version of EMC it was indeed possible to add the exact rule to the opls-aa.top to fix the missing rule warning. In this way it was very comfortable to create your own *.top and *.prm files specific for the molecule(s) considered in the simulations. Is there the workaround in the new EMC version with stricter rule interpretation to add the missing rules such that we can still type the molecule(s) which are not part of the rule set, but for which we do have all necessary parameters ?

I was testing the issue and realized that in particular there is a problem with aromatic carbons like “^6c(:^6c) …”, which are not recognized/accepted by EMC. For other atom types adding the exact rule identified by EMC solves the missing rule warning.

Thanks a lot in advance!

Hi Sergii,

The strict interpretation of rules is governed by the FFSTRICT option in the .prm file. It is set to false for most force fields (including OPLS), with the exception of certain CHARMM force fields. You could turn strict typing on for OPLS. However, you might have to check the other rules as not to create unexpected conflicts.


Dear Pieter,

thanks a lot for you answer. I have prm/top files for different polymers which were working with the previous version of EMC and after update to the new version they don’t work anymore.

I have checked the other rules for unexpected conflicts and in fact I decided to make everything simpler and created the test opls.top/opls.prm files for toluene. I still have the same issue that all atoms are typed well but not the aromatic carbons. Below is the ESH file:


replace true
mass true
density 0.8
number true
field opls-aa
field_name opls
field_location .
build_dir .
pdb_compress false
temperature 300
focus true
#system_charge false


# Groups


TOL Cc1ccccc1


# Clusters




I also uploaded simple PRM and TOP files. The charges are omitted for the moment and the SMILES strings in the TOP file are the ones which were identified by EMC itself. So, the aliphatic carbon, aliphatic hydrogen and aromatic hydrogen are typed well by EMC, but the aromatic ones are always raise the missing rule warning.

Thanks a lot for you help !

opls.prm (1.8 KB)
opls.top (1.1 KB)

Hi Sergii,

I am somewhat confused about what kind of problems exactly you are experiencing. Could you share your output? I used your force field files with the following input

#!/usr/bin/env emc_setup.pl

# Options section


replace		true
density		0.1
number		true
field_location	.
field		opls
field_debug	reduced
build_dir	.
focus		true
emc_execute	true


# Shorthand section


TOL		Cc1ccccc1,1


and created the following snippet out of the PSF output:

      15 !NATOM
       1 TOL  1    TOL  C    c3                 0        12.011       0
       2 TOL  1    TOL  H1   hc                 0        1.0079       0
       3 TOL  1    TOL  H2   hc                 0        1.0079       0
       4 TOL  1    TOL  H3   hc                 0        1.0079       0
       5 TOL  1    TOL  C1   ca                 0        12.011       0
       6 TOL  1    TOL  C2   ca                 0        12.011       0
       7 TOL  1    TOL  H21  ha                 0        1.0079       0
       8 TOL  1    TOL  C3   ca                 0        12.011       0
       9 TOL  1    TOL  H31  ha                 0        1.0079       0
      10 TOL  1    TOL  C4   ca                 0        12.011       0
      11 TOL  1    TOL  H41  ha                 0        1.0079       0
      12 TOL  1    TOL  C5   ca                 0        12.011       0
      13 TOL  1    TOL  H51  ha                 0        1.0079       0
      14 TOL  1    TOL  C6   ca                 0        12.011       0
      15 TOL  1    TOL  H61  ha                 0        1.0079       0

This output to me seems to be in line with the definition as used for your rules, i.e. c3 defines the methyl group, hc its protons, ca the phenyl carbons, and ha their protons. I did noticed, that – for this particular example – your rules are somewhat over-defined. On top of that, instead of

0	ca	C	0	0.0	^6c(^6:c)(^6:c)(C) ^6c(^6:c)(^6:c)(H)
1	c3	C	1	0.0	C(^6:c(^6:c)(^6:c))(H)(H)(H)
2	ha	H	2	0.0	H(^6c(^6:c)(^6:c)) 
3	hc	H	3	0.0	H(C(^6c(^6:c)(^6:c))(H)(H))

the following rules would also work,

0	ca	C	0	0.0	c(:c)(:c)(C) c(:c)(:c)(H)
1	c3	C	1	0.0	C(:c(:c)(:c))(H)(H)(H)
2	ha	H	2	0.0	H(c(:c)(:c)) 
3	hc	H	3	0.0	H(C(c(:c)(:c))(H)(H))

since you did not set FFSTRICT in the ITEM DEFINE section in opls.prm (default is FALSE). When turned on, the latter enforces the checking for the number of ring members, i.e. the ^6 part of your rules. You will have to set FFSTRICT to TRUE, if you want EMC to check on number of ring members. Note that EMC orders rules internally, where it automatically checks more complex rules first. Checking order can be influenced by the ITEM PRECEDENCE section.


Dear Pieter,

indeed the rules you propose are somewhat similar to what I was defining before with the previous version of EMC.

I did tested both over-defined rules and normal rules you proposed. I also used the input you posted above. Unfortunately the result is the same with the only difference that for normal rules definitions all atoms raise the missing rule warning and for over-defined rules only aromatic carbons raise the missing rule warning. Attached are two output files after executing your input file.

output_normal_rules.log (25.4 KB)
output_overdefined_rules.log (40.1 KB)

I did a following test as well: I run the example from “/examples/setup/chemistry/field/opls/aa” for water/alcohol and everything is working fine, but if I substitute alcohol by toluene it immediately raises the missing rule warning.

Thanks a lot for your support !

Dear Sergii,

I noticed you are using an older EMC build version of this year:

version 9.4.4, build Jul 24 2023 10:41:59, date Fri Aug 25 16:53:13 2023

The current version was actually built on August 8:

version 9.4.4, build Aug  8 2023 07:32:29, date Sun Aug 27 09:34:40 2023

Due to issues I had to rebuild and upload a new version. I would suggest to download a new version from https://montecarlo.sourceforge.com/. Let us know, if this fixes your problem!


Dear Pieter,

after updating to the version 9.4.4 (build Aug 8) everything works as intended. Thanks a lot for pointing out to the wrong version.


Hi Sergii,

Great! Thanks for your feedback.