Creation of surface species with charge separation more than one atom apart.

[kirkbadger18]

Hello,

I have been starting to work with nitrogenous surface species and have been seeing something odd and unintentional happening. It seems that RMG is applying reaction templates that do not fit which results in charge separated species with the charges more than one atom apart.

If I work on the main branch of the database and rmg-py, and run RMG with the following script, I see it predict this reaction:
input.zip

This reaction violates the reaction template of Surface_Monodentate_to_Bidentate. My thought is that somehow RMG is finding a resonant structure of the monodentate, where the O has a negative charge and the N has a positive charge, and is then applying the template to that species?

If this is the case, is there a way to turn this off? As I am starting to work with nitrogen species, I am building my own recipes that are able to create/remove charge separation for some species (*NO2 --> *NO + *O), but my recipes are clashing with these species where the charge separation exists over more than one atom.

If it is important to keep these resonant forms of adsorbates, then we will need to find a way to create recipes that can preform surface transformations on them. If we take the species the above reaction produces:

We would need a recipe that could dissociate the bidentate bond, or dissociate the oxygen, dissociate a hydrogen, or any number of operations. Each would need to be able to move loan pairs around to remove or create these charges.

I am curious what path we should go down. Should we remove this type of resonance for surface species, or keep it and figure out how to manipulate charge separated adsorbates more generally where the charges can be separated by more than one atom? At least for the meantime it would be useful for me to disable this type of resonance (assuming resonance is doing this). Would anyone have an idea of how to do this at least locally?

Thank you,
Kirk

[mjohnson541]

There's a lot of smaller issues here that probably warrant more discussion.

However, I think your more fundamental issue is that the Surface_Monodentate_to_Bidentate template allows the participating atoms to have any charge, which makes this a reaction. If you require the participating atoms to be uncharged in the template the charge separated resonance structure will not react with that template.

[bjkreitz]

I made a PR that fixes this issue.

#2717

[rwest]

In discussion today, Kirk described an issue with using this recipe (noted in the comments to PR #2717)

recipe(actions=[
['BREAK_BOND', '*1', 1, '*2'],
['FORM_BOND', '*2', 1, '*4'],
['CHANGE_BOND', '*2', 1, '*4'],
['LOSE_PAIR','*2','1'],
['GAIN_PAIR', '*1', '1'],
])

Currently using the top level node

entry(
index = 1,
label = "Combined",
group =
"""
1 *1 N u0 p0 cx {2,S} {3,[S,D]} {4,[S,D]}
2 *2 R!H u0 px cx {1,S}
3 *3 Xo u0 p0 c0 {1,[S,D]}
4 R!H u0 px c0 {1,[S,D]}
""",
kinetics = None,
)

entry(
index = 2,
label="VacantSite",
group =
"""
1 *4 Xv u0 p0 c0
""",
kinetics = None,
)

I think this is what's happening:

Ideally the atom *1 is labeled as having a charge +1 and atom *2 is labeled as having charge -1, to restrict when this template can apply:

1 *1 N u0 p0 c+1 {2,S} {3,[S,D]} {4,[S,D]}
2 *2 R!H u0 px c-1 {1,S}
3 *3 Xo u0 p0 c0 {1,[S,D]}
4 R!H u0 px c0 {1,[S,D]}

But then when the recipe is used to create the reverse template, it doesn't know to decrement or increment the charge on the wildcard atom types, so the reverse template is still looking for charged atoms. And it never finds the reverse reaction.
That is why Kirk changed it to use cx for both *1 and *2. But this leads to other problems with the forward reaction being applied too broadly.

The recipe should probably have INCREMENT_CHARGE and DECREMENT_CHARGE actions, which would hopefully then generate the correct reverse template, when the forward template has specified charges.

If this turns out to be correct analysis, then I suggest we try to add tests to RMG-Py/test/database
/databaseTest.py so that other recipes are checked for this problem.