Defining new rules for PCFF - amide/imide functional group example

EMC
1

Hello all!

I am currently trying to build a polyimide system that contains imide functional groups using the PCFF force field:

RN(C(=O)R’)(C(=O)R’')

and based on going through the force field typing rules I am pretty sure that the nitrogen here should be the atom type n (generic sp2 nitrogen (in amides)). Currently I’m just trying to build a single monomer unit as a test. When building these systems, the N is classified erroneously as either na (sp3 nitrogen in amines) or as n_2 (nitrogen in carbamate).

I have attempted to add a new rule for classifying it to pcff_templates.dat in the following manner:

type: n
! nitrogen in imide group (added by SJL)
template: (>N(-C(=O))(-C(=O))(-))*
atom_test: 1
hybridization: SP3
aromaticity: NON_AROMATIC
end_test
atom_test: 2
hybridization: SP2
end_test
atom_test: 4
hybridization: SP2
end_test
atom_test: 6
allowed_elements: C, H
end_test
end_type

But based on the output of the build process, it seems like it does not even go through the test when trying to classify it:
**
core/field/apply/rules.c:353 [seg1] site = 4, connect = 0

core/field/apply/rules.c:88 [3] N {0, 4} {-1, -1} 0 -2 -1 0
core/field/apply/rules.c:88 [2] C {0, 3} {0, 4} 0 0 -1 0
core/field/apply/rules.c:88 [1] C {0, 2} {0, 3} 1 1 -1 0
core/field/apply/rules.c:57 [0] C {0, 1} {0, 2} 1 1 -1 0
core/field/apply/rules.c:57 [0] C {0, 7} {0, 2} 1 -2 -1 0
core/field/apply/rules.c:88 [1] O {0, 6} {0, 3} 0 -2 -1 0
core/field/apply/rules.c:88 [2] C {0, 0} {0, 4} 0 0 -1 0
core/field/apply/rules.c:88 [1] O {0, 67} {0, 0} 0 -2 -1 0
core/field/apply/rules.c:88 [1] C {0, 1} {0, 0} 1 1 -1 0
core/field/apply/rules.c:57 [0] C {0, 2} {0, 1} 1 1 -1 0
core/field/apply/rules.c:57 [0] C {0, 12} {0, 1} 1 -2 -1 0
core/field/apply/rules.c:88 [2] H {0, 5} {0, 4} 0 -2 -1 0

core/field/apply/rules.c:364 depth = 3

seg1:4 ^5N(^5C(^6c(:^6c)(:^6c))(=O))(^5C(^6c(:^6c)(:^6c))(=O))(H)

core/field/apply/rules.c:212 [na, n4]
Debug: core/field/rule.c:446 -1 na 0 N()()()
Debug: core/field/rule.c:446 -1 n3m 0 ^3N()()()
Debug: core/field/rule.c:446 -1 n4m 0 ^4N()()()
Debug: core/field/rule.c:446 -1 n4m 0 ^4N()()()
Debug: core/field/rule.c:446 -1 n_2 0 N(~[C|H])(C(=O))(H)
core/field/apply/rules.c:215 match =

{type → 121, comment → “nitrogen in carbamate”, element → “N”, test → {
flag → {aromatic → exclude}},
connect → {
{element → {“C”, “H”}},
{element → “C”,
connect →
{element → “O”, test → {flag → {bond → double}}}},
{element → “H”, test → {flag → {bond → single}}}}}

core/field/apply/rules.c:378 match = 0x1461310
core/field/apply/rules.c:444 type[4] = n_2
**
I think it’s likely I just am missing something as far as the rules of writing new classifications are concerned. Is there a reason why EMC would ignore the new rule I’ve written? Based on the build.out print it seems like it is only testing the atom types na, n3m, n4m, and n_2.

2

A follow-up. After deciding to arbitrarily switch the atom type associated with the rules between na and n (i.e., I said that the original rule for type na is now the rule for n and that my new rule for the imide n is now the rule for na), the nitrogens in my system are still being classed as na and passing the template tests I made.

This tells me that the issue is not about the rule I wrote but more about the names of the atoms whose rules are being checked. I am trying to dig into the source to find the place where EMC decides which rules to check, but not having much luck.

3

Dear User,

Without knowing the extent of your solution, I can give you the following advice. Besides the definition of the typing rule, you also have to consider the right precedence. Precedences are defined at bottom of the template file. Precedences function such, that the simpler rule should precede the more complex rule in a tree-like manner. Considering the general type c for a carbon for which the first precedence entry is

(c(c1(c_a(c3m(c3h))(c4m(c3m)(c4h(c3h))))(co(coh))(c3m(c3h))(c4m(c3m)(c4h(c3h)))))

The above could be considered in a tree-like manner as follows:

(
  c (
    c1 (
      c_a (
        c3m (
          c3h
        )
      ) (
        c4m (
          c3m
        ) (
          c4h (
            c3h
          )
        )
      )
    ) (
      co (
        coh
      )
    ) (
      c3m (
        c3h
      )
    ) (
      c4m (
        c3m
      ) (
        c4h (
          c3h
        )
      )
    )
  )
)

In this tree, typing rule c only has one direct dependent: typing rule c1. Typing rule c1, however, has four dependents: typing rules c_a, co, c3m and c4m. In order for typing rule c_a to be considered, both typing rules c1 and c need to be satisfied. The same typing rule can appear in different precedence branches, as is the case for e.g. c3m.

4

Dear Pieter,

A-ha! I did not realize that that information was all the way at the end of the template file - this does solve my problem! Thank you so much for your response.

Best,

Sam

1 Like
5

Dear Sam,

Very good. Thank you for the feedback!

Best,
Pieter