Your suggestions are good, although I'm not always sure the best places to put the code either. A few comments...
> 1. Dipole moments and higher order multipole moments. It is straightforward > to compute these once a molecule is assigned a charge distribution using any > method. I've found this is a bit tricky. While it's trivial to compute the dipole moment and higher-order multipoles, people expect them to approximate experimental or quantum mechanical moments. So if they use your charge model on water, they get upset if the assigned dipole moment is 1.0D. So I'd suggest that we add these to the OBChargeModel class, and allow particular methods to apply a scaling factor based on linear regression. (I say scaling factor because it must be a regression through the origin. Users also get upset when you use y=mx+b, and assign a non-zero dipole moment to benzene. :-) My suggestion would be to pick a test set with, say B3LYP/6-31+G(d) or similar quality and correlate with the QM results. If someone is aware of experimentally-determined values, that would also work. One reason I suggest B3LYP is that I already *have* such a test set, and can enter scaling factors for MMFF94 (fairly good) and Gasteiger (horrible). > 2. Dipole polarizabilities, which can be computed with QEq and QTPIE. In > principle this is also computable with Gasteiger charges, but would require > writing code that I do not have right now. > > 3. Condensed Fukui functions, which are the probabilities that charge sites > will build up charge when the total charge on the system is changed. These > can be computed using an analogous equation to the charge response equations > of QEq and QTPIE, but with a different vector on the right hand side. > > 4. Molecular electronegativities and molecular hardnesses. The molecular > electronegativity is a byproduct of solving the QEq or QTPIE equations, and > the molecular hardness is a byproduct of solving the corresponding equations > for the condensed Fukui functions. > > 5. Further reactivity indices such as those proposed by Geerlings, de Proft > and Langenaeker (Chem Rev 103, 2003, 1793) which can be computed without too > much additional effort given charge and charge response data. These are tricky. For certain charge models, like QEq and QTPIE, these are fairly trivial to implement. Other "EEM-like" matrix methods are also fairly easy to handle. I'm not entirely sure how you'd handle #3 through #5 with MMFF94 or Gasteiger, since these methods don't actually directly solve the matrix equations. I think your suggestion about adding some OBDescriptors would be a good technique, since molecular electronegativities, hardnesses, and reactivity indices would be useful descriptors for some people. > Based on my understanding of the OpenBabel code structure, it seems that some > kind of corresponding OBDescriptors would be appropriate for doing the > bookkeeping of figuring out if the charge model requested is capable of > producing the respective quantities and making the appropriate > OBChargeModel::ComputeProperty() calls... Right now, OBDescriptor can't take options, but I'd suggest that we either add this feature, or we'd have to create multiple OBDescriptors for each charge model (e.g., with plugindefines.txt). I'd probably go with the latter. > and assigning them to appropriate OBVectorData or OBMatrixData containers > under OBMol. Alternatively, the code in qeq.cpp or qtpie.cpp could assign > such data directly. This seems appropriate for molecular electronegativities > and hardnesses, which are byproducts of solving the equations and are > currently being thrown away. The general policy of the library is to perform lazy evaluation. So I'm happy to save properties which are currently thrown away, but other properties should only be generated if requested by an OBDescriptor. > Also, one minor thing: it would seem useful to expose these properties (if > requested using "-add" or already read in from an input file) to the report > format, which currently does not output any perceived or read-from-input > properties data. This seems like an omission that runs counter to the spirit > of making as complete of a report as possible. Feel free to enhance the report format as you see fit. The spirit hasn't necessarily been to make a complete report, only that it provides some useful information not always available in other formats. It's essentially a custom format, so we can certainly enhance to add things like dipole moment, etc. If properties such as dipole moment and other information are added using OBPairData, OBVectorData, etc. they will also likely be output in the SDF format by default. Thanks for the suggestions, and feel free to ask more questions. Hope that helps, -Geoff ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ OpenBabel-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbabel-devel
