[ghemical-devel] about gnome2, and moving to a single "project" class.

[Tommi Hassinen]

On Wed, 8 May 2002, Geoff Hutchison wrote:

> Actually, Adam Tenderholt, an undergrad here at Northwestern has been
> hired to do this very thing. He has some code for a "UniModel" that's
> already assembled, based on a "Monomer" as an intermediate structure
> between the molecule and the atoms. So a collection of atoms (e.g. an
> amino acid) could be a "monomer" and treated together.

Ok, it's fine that we have chosen a same direction.  :)  We just should
have informed about our plans a bit earlier. I have been working with the
changes for 2-3 weeks, but kept silence until the work now ended into a
reasonably-looking end result.

> Yes, we definitely agree, but hopefully with multiple people working on
> the same direction, it might go faster. I thought that Adam had contacted
> you about his work in this direction, but I guess not. Hopefully you two
> can pick up and collaborate some?

Yep, I think we have much to do, and there certaily is something for
everybody. And please note that I'm not going to "push" my modifications
into CVS or v1.0 (althought I'm quite enthusiastic about them right now :)
and all of my own other works are still dependent on the code in CVS.
At the moment I see my "preview" version more as a candidate for v2.0
development version, rather than a last-minute change to v1.0.

But now I think I need to explain more precisely what changes I have made
in the "preview" version and why.

At all earlier versions, we have kept those different versions of
"model" classes, because the requirements for different types of models
(MM, QM, and that simplified stuff of my own) have seemed different.
Earlier I have seen this as a best (and safest) approach but now it seems
that

	1) the current versions of the "model" classes explained above are
stabilized; they are not changing anymore and now it looks that we know
all their requirements.

	2) the old "divide and conquer" approach has lead to multiple
versions of classes, also of those classes related to user interface.
Therefore, in the future it will be more and more expensive (in terms of
work) to maintain and develop these multiple classes and multiple user
interfaces. For example, the "tree/list view" should be made in three
separate versions in future (ouch!).

	3) in the "preview" version I have sketched a new set of engine
classes (that do the computational part) that I believe could handle the
mixed models as well (but it's not working yet). In a qm/mm mixed model
one has a MM model with some part described by a QM model:

	+----------------------+
	|                      |
	|     -----    MM      |
	|    /     \           |
	|   |  QM   |          |
	|    \     /           |
	|     -----            |
	+----------------------+

what is needed for qm/mm is:
	- MM model for the MM part (similar than that we have now)
	- QM model for the QM part (similar than that we have now)
	- "glue code" that joins these parts:
		- present the charges of MM part as point charges in QM
			model so that MM charge distribution can polarize
			the QM model electronic structure.
		- if there are bonds across the qm/mm model boundary,
			terminate the bonds in QM model (with H atoms?)
		- also handle the boundary-crossing bonds at MM side
			(by adding some extra energy terms).
		- also add the van der waals interactions across the
			qm/mm model boundary.

For my own work, I also plan to make a mixed model between by simplified
force field and conventional all-atoms molecular mechanics:

	+----------------------+
	|          simplified  |
	|     -----    model   |
	|    / all- \          |
	|   | atoms  |         |
	|    \  MM  /          |
	|     -----            |
	+----------------------+

what is needed for mm/simplified_model is:
	- simplified model for the main part
	- MM model for the all atoms (similar than that we have now)
	- "glue code" that joins these parts:
		- again handle the bonds across model boundary.
		- again add the nonbonded terms across model boundary.

In the following I show the classes that should be able to do the above
trick in a (relatively) straightforward way. In the current system, the
"engine" class is done directly using the "model" class, and it covers the
whole content of the "model" class:

	model -> engine

In the new plan, I have added a "setup" class in between:

	model -> setup -> engine

Now, the "setup" class tells to "engine" class what should be included
into the calculation; it can be all of the model (producing a stand-alone
class like the ones we have now) or it can be some part of the model
(producing a part of a mixed-model calculation) and the new engine class
does not know/care about it. We can make many different "setup" classes
like

	setup_all_mm
	setup_all_qm
	setup_mixed_qm_mm

and so on. For the engine classes, we would have

	engine_mm
	engine_qm
	engine_simplified

just like we have now, but created using a "setup" class so that they can
contain all or a part of the model. Now, we could make the mixed models
just by combining the normal classes:

   class engine_qm_mm : virtual public engine_mm, virtual public engine_qm

and then adding the extra "glue code" needed in this derived class. This
way we could use the same code to do the mixed and normal calculations.

So, as you see above, most of my changes actually affect the calculations
and therefore the "engine" classes are changed the most. For the
"model" class, I have simply joined the "model" and "mm1_mdl" classes
together. Now there is also only one "atom" and "bond" classes, that are
the old "mm1_atom" and "mm1_bond" classes. In graphics code side, I have
joined the "docview" and "mm1_docv" classes together, and renamed the
result as "project" just for conveniency. As a result of these changes, we
would have in future

	- only one user interface
	- only one file format

Ok, during the next weeks/months, I try to bring my new "engine" classes
to a state where they not only compile but also actually work.  :)  We
certainly should discuss with Alan to see where we could collaborate.

	Tommi