Charge indicators on atom names seem to have no effect.

[paulsaxe]

The documentation at http://openmopac.net/manual/index.html says the following:

Charges on individual atoms for use in MOZYME can be specified by the symbols "+", "0", and "-" in the atom labels. When the symbol "+" is present, the atom is given a unit positive charge, when "0" is present, the atom will be given a zero charge, and when "-" is present, the atom is given a unit negative charge. The zero charge option is useful when metal ions in enzymes are being modeled, thus the MoO2 moiety should have MoIV, but by default, Mo is MoVI, i.e., [MoO2 ]2+. To specify that MoIV should be used, after Mo add a "0" to give Mo0. Avoid using these keywords unless necessary. Thus if the ethyl group, C2H5, is run with [CHARGE=1](http://openmopac.net/manual/charge.html), then the CH2 carbon will automatically be given a positive charge, if CHARGE=-1 is present, the it will be given a negative charge.

However, adding a zero to the Zn atoms in a MOF seems to have no effect. However, the METAL(Zn) keyword does work. Nonetheless using atom names could be useful for e.g. 4-coordinate oxygen atoms where most oxygen atoms are fine, but one or two need tweaking.

The attached tar file has 3 inputs and outputs illustrating the problem. The simple output has no special handling and fails due to charges on the Zn atoms. The files labeled _metal use the METAL keyword, and succeed. That using _atomnames adds the zero charge to the Zn atom names. And fails.

mof.tar.gz

[godotalgorithm]

After some examination, it does not appear that the atomic charge labels function as advertised at http://openmopac.net/manual/Labels.html, but they do work for select elements as discussed at http://openmopac.net/manual/mozyme_example_charges.html.

There were some obvious input parsing errors associated with this feature, and I've repaired those in a test branch, but the underlying logic still isn't functioning as intended. It doesn't seem like this feature was fully implemented. Using the METAL keyword with atomic indices does seem to be working, and so ideally I could pair its logic up with the atomic charge labels. However, I presently do not fully understand how METAL is implemented - I can identify where it is ionizing specific elements, but I cannot find where it is ionizing specific atoms. It feels a bit like an obfuscated code challenge, and I can't fix this until my understanding of how MOPAC assigns Lewis structures improves. The actual fix might be quite simple, but it will require this higher level of understanding to proceed.

[godotalgorithm]

I've now discussed this matter in more detail with Jimmy Stewart. He has defended the status quo that the METAL and CVB keywords are sufficient for fine-tuning MOZYME's Lewis structure assignment, and my present inclination is to remove the discussion of this incompletely implemented feature from the online manual. There is no fine-grained logic for assigning atomic charge states in the code to connect up with a general-purpose atomic charge label - it either allows an atom to participate in the sigma-bond network or not (as controlled by the METAL keyword), and then it makes pi-bond assignments in a second pass (as controlled by the CVB and SETPI keywords and the extremely limited atomic charge labeling that is presently implemented) before assigning local atomic charges to complete its accounting of electrons. Thus, while there is an assignment of local atomic charges, it is only performed at the end and is not capable of constraining the sigma and pi bonding assignments. The present input syntax for adjusting the Lewis structure is a bit clunky, but it is well-matched to what the code is actually capable of doing.

[paulsaxe]

As long as the METAL keyword works with atom numbers so one can pick out specific atoms, that would be OK. A bit painful, but OK. It seems possible that one might one specific atoms, not all of an element, e.g. “O”.

[godotalgorithm]

Yes, the METAL keyword can either be used globally (when specified without any arguments), or it can be specified with a list of elements and specific atoms.

If I were to further hijack the atom labels for the purpose of Lewis structure adjustments (and I'm willing to entertain that possibility), the natural set of information, in order of priority, would be:

1. Sigma bonding radius of the labeled atom (this is internally set to a negative value for fully ionized atoms)
2. List of atoms with pi bonds to the labeled atom
3. Target charge state of the labeled atom

While this information would include a charge assignment, it has the lowest priority and is only considered when the sigma and pi bond assignments are compatible with a desired charge state.

As a counterpoint, MOPAC's system for parsing keywords is already extremely clunky, and this type of feature would effectively turn every atom label into its own atom-specific keyword statement that needs special parsing. I suspect that's what turned Jimmy away from going any further down this development path.

What limits my appetite for changing this stuff is that the entire point of QM simulations is that this information is supposed to be determined by the computational search for the electronic ground state. Of course, this process can get trapped in local minima, and I think that it is a very good idea to allow for some kind of "guiding" assignment of atomic spins and charges (e.g. my own semiempirical modeling plans include this concept). Unfortunately, the more natural/intuitive assignments of atomic spin/charge have the lowest priority in MOZYME's current process of preparing a trial ground state and cannot be used to drive/constrain the process without a major overhaul of the Lewis assignment code.

[godotalgorithm]

I've revised the manual page to remove any incorrect statements about this feature. I'm now relabeling this Issue to a feature request rather than a bug report. I'll re-evaluate whether or not I'll act on this and with what priority as I eventually attempt to apply MOZYME to an increasingly diverse set of systems. Specifically, I will be mindful of problems or inconveniences that I encounter to understand if new ways of adjusting the Lewis structure would improve user convenience in practice, and if the Lewis assignment code itself needs some revisions or enhancements to resolve problematic cases.