Tim, Geoff, and Jmol Developers. Thanks to Tim and Geoff for some great pointers, I have a branch of Jmol close to doing UFF minimizations. I've seen it "fix" a distorted caffeine structure, but I'm not claiming success yet. Just indicating that:
*The C++ to Java port of the OpenBabel code is now working. See https://jmol.svn.sourceforge.net/svnroot/jmol/branches/bob-minimize/Jmol/src/org/openbabel (This is a very minimal implementation -- no constraints yet, and only the UFF force field.) *I have made some substantial changes in the way the code works and how the classes are laid out. This is mainly just because classes in Java don't work quite the same as classes in C++. (And maybe just because I needed more structure.) The class structure in Jmol will look somewhat familiar to Tim and Geoff. It looks like this: openbabel 03/21/2008 02:14 PM 14,970 OBAtom.java 03/21/2008 02:17 AM 9,883 OBBond.java 03/22/2008 06:19 PM 4,592 OBMinimizer.java 03/22/2008 06:48 PM 13,524 OBMol.java 03/20/2008 06:17 AM 1,056 OBResidue.java 03/21/2008 12:53 AM 8,397 OBUtil.java openbabel/data 03/19/2008 06:17 PM 58,422 isotope.txt 03/20/2008 09:50 AM 4,686 OBGlobalDataBase.java 03/20/2008 09:52 AM 5,034 OBIsotopeTable.java 03/20/2008 09:58 AM 2,956 OBTypeTable.java openbabel/forcefield 03/22/2008 02:28 PM 2,109 OBFFCalculation.java 03/22/2008 05:47 PM 3,677 OBFFCalculations.java 03/22/2008 05:06 PM 36,592 OBFFCalculationsUFF.java 03/21/2008 10:34 AM 1,841 OBFFConstraint.java 03/22/2008 05:15 PM 11,600 OBFFConstraints.java 03/20/2008 12:08 PM 2,007 OBFFParameter.java 03/20/2008 01:32 AM 1,088 OBFFParameters.java 03/22/2008 11:34 PM 37,927 OBForceField.java 03/22/2008 06:35 PM 7,238 OBForceFieldUFF.java 03/20/2008 01:21 PM 12,304 UFF.prm openbabel/math 03/22/2008 10:35 AM 21,739 Vector3.java (I don't think I really need isotope.txt -- GetExactMass() uses it, but I never call that method, anyway. I mostly just wanted to see if I could read the data, which I can.) Basically, I spun off all the detailed calculation stuff from the OBForceField classes to make the OBFFCalculation classes. This really helped, because I was then able to consolidate all the setup, compute, gradient updating, parameter fetching, and program output business into subclasses of OBFFCalculationsXXX. See OBFFCalculationsUFF.java. OBForceField has the core methods. What's left in OBForceFieldUFF is the parameter file processing and atom typing. Tim, what I did then was to turn the calculation vectors (for example, OBFFBondCalculationUFF) into vectors of Java Object[], where the array elements are simple lists of atom pointers (OBAtom[]), atom indexes (int[]), coordinate pointers(double[]), and setup parameters (double[]). In this way I didn't have to worry about instantiating thousands of classes of calculations. Maybe in C++ that works, but it would blow Java memory sky high. The coordinate pointers (double[nAtoms*3] _c) I turned into a double[nAtoms][3] array. This made it possible to pass references to specific atom entries (_c[3], _c[10]) very simply and removed the "ncoord*3" aspect to that array. I suppose it's slower, but it sure is a lot easier to manage. Basically now _idx and _cidx are redundant. I've made some mistakes, I'm sure. But I'm fairly pleased with how streamlined it all feels now, and I think I fully understand what the code is doing. I think the speed will be OK. One nice thing is that you will be able to use "select" and "ignore" and "fix" with the MINIMIZE command to pull out and minimize just a piece of the whole molecule. So even something like a protein could in principle be run. You would just have to be careful to select "within (5.0, myligande)" or something like that. Maybe. We'll see... *I'm getting lots of data, and I suspect that I still have a few mistakes in one or more of the minimization modules. *The fact that I can see the minimization work, and it goes reasonably fast is quite reassuring. *Over the next few days I'll be testing this further. I don't recommend trying it yet. *I've included the license blocks from the C++ code -- currently stating GPL, not LGPL. I don't really know how that works when you do a substantial rewrite and code language translation. Tim and Geoff, you are willing to let us change that to LGPL for the Java? *Battery is dying here, and my laptop is running out of energy, too. G'night! Bob ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
