I'm working on an implementation of force field plugins for avogadrolibs but I have some conceptual questions on where to put some of the code.
Initially, I'd just put the bits into qtplugins directories, like the "workflow" scripts. (Some of the force fields will be in C++ and others can be loaded as Python scripts.)
But I can imagine wanting charges and force field energies in lots of places - particularly charges. For example, it would be great to have popup menus listing all charge models in multiple places in the UI:
- Properties -> Atom (partial charges in a table)
- Surfaces -> Electrostatic Potential (partial charges to color the surface)
- Properties -> Dipole Moment (or something like this)
There seems to be a need for these in core classes, or at least qtgui
Thus, I can imagine developing a PythonScriptLoader class that finds scripts of different types (generators, workflows, charges, forcefields, etc.) and stores them as lists/hashes. Right now, interfacescript.h and pythonscript.h live in qtgui.
Does it make sense for chargemodel.h and/or forcefield.h to live in qtgui as well? (This suggests that inputgenerator files should be moved there too.)
Thoughts? Critiques?
-Geoff
I'm working on an implementation of force field plugins for avogadrolibs
but I have some conceptual questions on where to put some of the code.
Initially, I'd just put the bits into qtplugins directories, like the
"workflow" scripts. (Some of the force fields will be in C++ and others can
be loaded as Python scripts.)
I think this is ideal when developing something new.
But I can imagine wanting charges and force field energies in lots of
places - particularly charges. For example, it would be great to have popup
menus listing all charge models in multiple places in the UI:
- Properties -> Atom (partial charges in a table)
- Surfaces -> Electrostatic Potential (partial charges to color the
surface)
- Properties -> Dipole Moment (or something like this)
There seems to be a need for these in core classes, or at least qtgui
Thus, I can imagine developing a PythonScriptLoader class that finds
scripts of different types (generators, workflows, charges, forcefields,
etc.) and stores them as lists/hashes. Right now, interfacescript.h and
pythonscript.h live in qtgui.
Does it make sense for chargemodel.h and/or forcefield.h to live in qtgui
as well? (This suggests that inputgenerator files should be moved there
too.)
This sounds reasonable, I was thinking about the molequeue library, and I
didn't want to add an extra dependency to Avogadro's GUI stuff. The
MoleQueue client code is in a couple of classes we could pull in, they just
depend on QtCore/QtNetwork. I think defaulting to adding a few new data
structures to the qtgui library would be good, and we could look at whether
any of that would be useful in core later, i.e. so that it is accessible to
file IO, server code, etc.
If we are OK with adding the QtNetwork dependency we could fold in the
MoleQueue integration classes, otherwise we could just ensure the network
code is kept separate from the input generation. I think this is the better
option, it has been a while but I can look at how much work that will be.
Charges are only valid for a force field and for the most part don’t exist without having done a calculation. There are some file formats which allow you to save this data but not many. In Pcmodel the charge is atom property that is set after a calculation and so any part of the gui that knows about atoms can display information about charges (dipole moment, charge, color by charge etc). The question is do you force a calculation if the user requests information and the charge is not set? I don’t know what you are thinking about with charge models - each force field has its own method/parameters for computing charges and this is fixed by the selection of the Force Field. I try very hard to keep gui-stuff away from compute stuff so that all the compute code can be used in command line only programs.
There are a variety of charge / electrostatic models that are independent of a force field (e.g., they attempt to reflect ESP-fitted point charges). Gasteiger, QEq and EEM models are some of the better known examples.
The point of the charge system I described is to hand off the molecule to a script/package to hand back partial charges.
For example
obabel CF2Cl2.g03 -osmi --partialcharge eem --print
0.357889
-0.275557
-0.275557
0.0966124
0.0966124