The Ribosome Builder Project
A software project to simulate the ribosome

Developer Log - willkn


Created development page for the project home page. Continuing to read the Autotools book to learn about the GNU make process.

Found crashing bug while mapping a sequence from E. coli to 1fka.A in release version: Runtime error R6025: pure virtual function call.

This occurred running the following script: 'script run C:\PROJ\RBO\lua\SeqMap_16S_Ecoli_1fka.lua'

In updating the makefiles in the project, I tried substituting the hardcoded path separator with a macro, but MS Tools are so brain-dead that they get too confused in parsing it ("\\"). Will just have to hardcode the backslash separator for all paths.

Finished changes in makefiles, can now build relative to the src directory. Also added the option to specify a different build path, but that is not tested yet. Also added the option to specify a different install path, but also not tested.

The intent of the reorganization is to be able to define a module in CVS, called 'src' that can be checked out, and then the user can cd into the src dir, type 'nmake /f' and build from there. Also, all recursive makefiles are designed to build from their local path, independently of a recursive call.

A second intent is to have the 'src' module be independent of the 'pdb' and 'exp' modules. The 'src' module contains all the files needed to build, install and run a working core application.

Then, there can be a higher-level makefile at the rbuilder dir level, which can do a (build/install/dist) and incrementally use the 'src', 'pdb', and 'exp' modules, as found.

After a little more thought, I will rename 'src' to 'bas'. The 'bas' module contains code for the basic functionality of the program. This seems less confusing than 'src', because other modules such as 'exp' can contain source code (lua scripting code) as well. Also, 'bas' can be thought of as a complement to 'exp' (expansion, experiments, etc.).


Applied astyle with --style=ansi to all .cpp and .h files in rbuilder code. Did brief test and the program compiles and runs.

Did first submission of code to sf CVS: imported 'bas' module. Did test checkout, build, install and run of bas module on ribo4. It works.

Checked out bas module on beryllium (Mandrake Linux 8.1, Kernel 2.4.8, gcc ver. 2.96). Created first working Makefile for lib/qhull.

Created linux porting progress table for project home page.

Did bug fix and quick release of ver 0.3.1.


Added history logging to CVS, prior to creating first tag of release 0.3.1. Created first tag on 'bas' module: 'Release-0_3_1'. Tried to list tag info using the cvs history command, but couldn't get it. Spent an hour researching tags, history and logging info in CVS. Looked at CVSROOT files on a number of other sf projects (pymol, python, gaim, astyle, Scumm), didn't see any 'history' files or tag logging info.

Added 'LogHistory=TMAR' to rbuilder CVSROOT/config file, but there is no history file and couldn't find any documentation of what all the flag meanings are for 'TOEFWUPCGMAR'. I guess I will just have to keep track of tags in my own files for now.

Imported 'exp' module from ''. Arg, forget to add 'exe' to cvswrappers! The exe files in exp/tools simply failed to go in. I'll just leave them out of the CVS module for now.

Imported 'pdb' module from ''.

In doing further development of the Win32 version on ribo4, I'm experimenting with moving the working copies of 'exp' and 'pdb' INTO the 'bas' working directory, so that they will function as up-to-date checked out versions that are used by a running version of the program that has been installed into the 'bas' directory itself. I will create a .cvsignore file in 'bas' to ignore the 'exp' and 'pdb' directories, as well as other files copied to the 'bas' directory during the install. I don't think this should cause any problems. It allows me to have separate modules at the top level in the CVS repository that can be checked out independently, and also located in a suitable nested manner on the local host. I just have to remember to go into the 'exp' and 'pdb' directories explicitly to do any needed updates. I have seen references to doing things with nested modules and aliases with the 'modules' file in CVSROOT, but I don't see a need to do that at this time.

Fixed path separators in VC60 project workspace file in bas/app/rbq/mak. Added VC60 project files to build htsrv and dependency libs (now name 'mmlibs' to distinguish them from the app-specific libs rbqUtil.lib, rbqLua.lib, frameWk.lib). 'frameWk' should really be renamed 'rbqFramewk'.

Also added an rbq_Install VC60 project, so the entire thing can now be built, installed and run from the IDE, eliminating the old batchfile install step.

Added ssh keys and figured out how to get ssh authentication for cvs working on GNU/Linux. It was nearly all straightforward:

The only hangup was that the default protocol on the host was RSA1. Trying 'export CVS_RSH='ssh -2'' didn't work, or using an alias. Finally, found out that the way to go is to create ~/.ssh/config file with 'Protocol 2' line. Then it worked.


Started on scripts to do unit testing of rbq - lua api functions. Made tst, tst/rbqlua subdirs in 'bas'. Immediately noticed that astyle format has broken the current html doc script app/rbq/tools/doctools/ because the extern C { bracket caused all the rbq_XXX funcs to be indented. This is fairly easily fixed by trimming ws at start of line.

Tested VC IDE full build of program on inga, found that rbq.opt file is also needed. I considered adding it to CVS, but it is a binary file and has undesired hardcoded paths in it, typical of poor tool design. Instead, I'll just post text instructions on the build.html page to add the Executable and Working Dir to the rbq_Install settings. Done.

Create scripts and in app/rbq/tst/rbqlua. HTML report of progress of unit test definition added to web page docs.


Updated developer page on project web pages, with info about rbqlua, linux porting, contributors.

Fixed bug in project makefiles: made sure /F switch preceded all files because new linux Makefile broke qhull build.

Added intra-doc hrefs for rbq_XXX lua funcs in app/rbq/tools/doctools/ script.

Created first rbqlua unit test app/rbq/tst/rbqlua/funcs/rbq_InsPdbFile.


Updated app/rbq/tst/rbqlua/utReport to include information about existing unit tests (creation date, authors).

Redesigned TestUtil.lua functions to better support test cases. Added test driver to run all rbq-lua unit tests.

Added source and include folders for low-level libs in mmlibs project in VC IDE project workspace.

Added support to glob directories from filespec in wkFileUtils::GetFilenames() and rbq_GetFile(), rbq_GetTotalFiles().


After adding the 2nd case to the 1st rbqlua unit test, I find that the current implementation of the script processor causes all script execution to fail if an invalid parameter is given in a call to one of the rbq_XXX API functions. This is desirable in certain situations because it gives a stack dump of the lua functions in the app status window. However, it is not desirable for unit testing because it halts all subsequent script execution by the test driver. So I'm adding an option to simply report a bad parameter instead of doing a 'lua_error()'. Probably call it 'enableLuaError()'. Done.

Added second test case to rbqlua unit test rbq_InsPdbFile, which called the function with a missing parameter, after disabling lua_error(), and it worked. The error was reported to app stdout, but termination of lua execution was bypassed, allowing the script to continue running.


Added test case 3 to rbqlua unit test rbq_InsPdbFile. Added new unit test for rbq_DeletePdbObject. It works. Created rbqlua ut rbq_GetTotalPdbs. It works. Updated rbqlua ut progress page on web.

Next: write ut for rbq_OpenPdbFile() and add code to bypass 'save current doc' dialog.

An interesting press release at Syrrx ( leads me to think about the possibility that x-ray crystallography could be accelerated past the current bottleneck of trying to get molecules to form good crystals. Syrrx received a grant for a proposal to develope nanoscale structural frameworks that may provide better conditions for the formation of hard-to-crystallize molecules (such as membrane proteins). Should this prove successful, one can envision a whole new field devoted to the design of such structural frameworks, where a framework is customized to support the crystallization of a particular target molecule. More info on the Syrrx grant is located in the project brief at NIST


Added another unit test script, 'rbq_OpenPdbFile'. This required adding an option to bypass the 'save current doc' dialog that pops up in the main window when the current document with unsaved data is closing. Also added extra logging and checks to the previous unit test scripts. All 4 scripts run and pass.

After noticing a bug in the movie code, and doing a fix, tried to run the mRNA wrap demo and found that the program is not picking up script run request files in the input directory after they are submitted there by htsrv. Found the bug: because of the change to 'wkFileUtil::GetFilenames()', the '.' directory is now being returned. I was going to make the default exclude arg to GetFilenames() be the A_SUBDIR, but I changed my mind for some reason. Oh, it was because I didn't want to include <io.h> in the wkFileUtils.h header file.

After looking, it seems like the input dir filescan is the only other place in the code that uses GetFilenames(), so I'll just put the exclude subdirs param there. Fixed. Movie export also works.

In addition to the rbqlua unit tests, should probably create tests to check browser interface and run demos.

Created another unit test: rbq_GetPdbName(), added more cases to previous tests. Created another unit test: rbq_GetPdbIndexFromName().

possible order of next unit test definitions:
rbq_GetPdbFileName(), rbq_GetObjectIndexFromName(),
rbq_GetTotalChainsInPdb(), chain data access functions,
res access
atom access
object access
selection ops
geom ops:
rbq_GetPdbBoxCenter(), rbq_GetPdbMassCenter(), rbq_GetPdbTransformMatrix()

Started 'app objects' page in whitepaper.


Created unit test: rbq_GetPdbFileName().
Created unit test: rbq_GetTotalChainsInPdb().
Created unit test: rbq_GetChainDescrip().

Created a menu item to run a sub-set of unit tests (so the user doesn't have to keep running through the entire list each time, just to verify a few new tests).

Created unit test: rbq_GetChainName().


Created unit test: rbq_GetChainIndex().
Created unit test: rbq_GetTotalResiduesInChain().
Created unit test: rbq_GetResidueName().
Created unit test: rbq_GetResidueIndex().

Created unit test: rbq_GetTotalAtomsInResidue().

next: rbq_GetTotalInterResidueBonds().

Created guide for writing unit tests.


Found the first serious bug in the unit tests with rbq_GetInterResidueBond(), as I suspected it might. The problem is in the CRbqPdbMol::GetInterResBondIndexList() function, it tries to be helpful by letting the iRes and jRes parameters be in either order of (prevRes, curRes) or (curRes, prevRes). However, this creates a mismatch with the return result, which is always (iAtom, jAtom) where iAtom is always in curRes and jAtom atom is always in prevRes, so iAtom may belong to either iRes or jRes, depending on the order. I need to look through the project log and code to see why I allowed this ambiguity and see what it will take to get rid of it.

In looking through the code, this particular function appears only to be used in the following rbq_XXX lua api functions:

In turn, rbq_GetInterResidueBond() is only called once in the lua code, inside of its wrapper getInterResidueBond() in _PdbUtil.lua. Finally, getInterResidueBond() does not appear to be called by any other lua code.

Next, rbq_GetTotalInterResidueBonds() is called also called just once by its wrapper getTotalInterResidueBonds() in _PdbUtil.lua. Finally, getTotalInterResidueBonds() does not appear to be called by any other lua code. Which is strange.

Perhaps I was just trying to make it a general-purpose function. If so, it needs to be redefined to avoid the ambiguity. Done. Added swap code in CRbqPdbMol::GetInterResBondIndexList( iChain, iRes, jRes ), and some additional specifications in the rbq_XXX functions.

All current 18 rluts run and pass.


Continuing with unit tests for pdb functions, found an inconsistency in function names between rbq_GetAtomIndex() and the lua lib wrapper func getAtomIndexFromFull(). Currently, another lua lib function has the expected wrapper name 'getAtomIndex()', but this function is distinctly different in parameter and return signature. It should be renamed, but I will need to do another usage check to head off possible bugs resulting from such a change. I think this misonomer function is actually fairly extensively used. Yes, it is, and in some demos, but now is the time to make the change, with a fairly good replacement name, getResAtomIndex().

Changes were made in the following scripts:

Changes in the corresponding func getAtomIndexFromFullName() => getAtomIndex():

The corresponding function rbq_GetAtomName(), and its PdbUtil.lua wrapper getAtomName(), are also misnamed because they actually return just the PDB atom name, with spaces. This is inconsistent with rbq_GetPdbName(), rbq_GetChainName(), and rbq_GetResidue(). Might as well rename this function now, to rbq_GetAtomPdbName(), and create a new function rbq_GetAtomName(), with the consistent behavior.

After a little more thought, the new name should be 'getAtomParName()' where 'Par' stands for 'PDB ATOM record', as this allows for an associate function 'getAtomPartName()', which returns the PDB ATOM record 'trimmed' name. Done.


Did a 'cvs log' on bas module and it is hanging up on pdb subdir. Don't understand why.

Fixed doxygen target in top-level makefile in bas module.

Added independent c-o-m calculations to unit test rbq_GetPdbMassCenter()


Finished what is hopefully the final draft of the Ribosome Builder paper for JMGM journal.

Finally learned to use the '-d' option with update in cvs to get new directories.


Started on a more complex unit test for composite function rbq_GetForceObjProperty(). Finished initial version, it works.

Noticed a drawing bug where selecting the background in the graphics window causes part of chain 1tra.a to be drawn with a light brown color.


Got wi-fi on ribo4 in the UC!

Added another test case to rbq_GetTotalForceObjectsInDynamicSegment.

Read some of the project development pages on the Python home page. Great background info for how to do collective project development.

Interesting reading of Will Ware's nanocad mailing list back in 1995.

Created rlut rbq_GetElementMass.


Created rlut rbq_GetElementMass.

More reading of the nanocad mailing list ( Starts off with discussions about goals of nanocad and some initial work on energy minimization and how to represent the data, using Lisp. Then around Feb 1996, a lot of talk about how to extend the core chem computational part with a scripting language and gui and what language to use (Java, Python, Tk/Tcl, etc.), and the reasons why (elegance, portability, efficiency, availability, capability, etc). Very interesting to me as it leads me to think of my own choice of C++ and Lua, and the benefits/drawbacks of that. Konrad Hinsen appears to have exceptionally good insight into both the chemistry and programming end of things, and is a proponent of Python. The subsequent success of PyMOL provides confirmation of his inclinations.

Investigating MMTK.

Created rlut rbq_RotateForceObject.


Created rlut rbq_TranslateForceObject. Created rlut rbq_TransformForceObject.

Adding retrieval of node children and parent info to rbq_GetForceObjProperty().

Created rlut rbq_GetObjectIndexFromName.


Working on rlut rbq_RotateForceObjectNode.

While doing some debugging involving rotation of a point around a rotation center through multiplication by a homogeneous transform matrix, I browsed a little of the CGrTransform3f code and how its implemented and used by CRbqNodeBsjForce in timestep movement and one blatant inefficiency is the code

        // update group atoms pos
        for( int iAtom = 0; iAtom < pNode->GetTotalAtoms(); ++iAtom )
            CTorAtom *pAtom = pNode->GetAtom( iAtom );
            CGrVector3f txPos = pAtom->GetUnmovedPos() * txFrame;
            pAtom->SetPos( txPos );

Because this results in a huge number of unnecessary operations being repeating for each atom inside of CGrTransform3f::TransformVector() where GetMatrix() is called:

// GetMatrix - float
void CGrTransformT::GetMatrix( float rgd[16] ) const
    // produce the hmTr = hmR * hmT
    float hmR[16];
    m_mRot.GetMatrix( hmR );

    float hmT[16];
    SetIdentityMatrixf( hmT );
    hmT[12] = m_vTrans[0];
    hmT[13] = m_vTrans[1];
    hmT[14] = m_vTrans[2];

    MultiplyMatrixOpenGLStyle( hmR, hmT, rgd );

}// GetMatrix - float

As soon as I finish the unit tests and can start doing some profiling, this may be one of the bottlenecks.

Added rbo test module to rbuilder exp module as 'tst' subdir. Got exp/tst/testGrtRot.lua working, after writing multiplyVectorAndHMatrix() in VectorUtil.lua. Hopefully this will put a nail in my ever-recurring rotation matrix confusions.

In rlut rbq_RotateForceObjectNode(), calculation of expected node positions using VectorUtil functions is now matching rotation produced by CRbqNodeBsjForceObject, with the proviso that the degree argument to getGrtRotation() is negated.


Trying to finish rlut rbq_RotateForceObjectNode, which requires addition of c-o-m checks for preceding and subsequent force objects, I realized that I needed inter-residue bond info for force objects (to get node rotation axis for root node of a force object, which has an atom bonded to a previous residue atom). This requires addition of 2 more rbq-lua functions, or perhaps, just 2 more properties in rbq_GetForceObjProperty(), 'intraResBonds' and 'prevResBonds'.

Added CBnd::GetAtomIndexPairs() to return a flat list of bonds defined by pairs of indices from the packed multilist representation. Also starting documenting bond representation design in the whitepaper docs.

In trying to get baseline data on intra-res bonds before adding property to rbq_GetForceObjProperty(), tried to run lua/ForceObjectReport.lua and found that it was broken in my dev copy of the bas module because the perl and gnuplot subdirs were not added to cvs (need to update the cvswrappers file in CVSROOT so they can be added).

TODO: update blog with split-brain realization.


Trying to finish up rlut rbq_RotateForceObjectNode() after adding access to intra and inter-residue bonds for force objects via script API. After adding a test case to do node rotation for multi-residue dynamic segments, it looks like there may be a sign bug in the rotation code somewhere, as the expected rotation position appears to differ from the actual position of node 1 of 1tra.a$.C2 for a rotation of of node 0 of -339.7 degrees in foward dir. The difference seems to be one of direction only.

Debugging rotation in rlut, it seems that a positive rotation fails for node 1 of res 0, and a negative rotation passes for res 0 and fails for node 0 of res 1. Strange.


Created html doc 'BondRotation.html' to discuss design of rotation about dynamic nodes. Looking over the code in CRbqDynamicSegment::RotateNode(), the two main branches are 1) rotation at node 0 (root node), and 2) rotation at other nodes. In the case of rotation at node 0, all nodes in the force object are rotated, and so the CRbqNodeBsjForceObject::Rotate() function is called, both for the force object containing the node, and for all subsequent force objects. The vector about which rotation occurs is determined by the vector from the atom in the force object residue to its bond partner atom in the previous force object residue.

In the other case, the CRbqNodeBsjForceObject::RotateAboutNode() function is called. In this case, the vector about which rotation occurs is determined by CTorNode::GetDir(). That explains the problem. In CTorNode::GetDir(), the direction is defined from the atom in the parent node to the atom in the node. We don't want to change that definition, because of all the possible problems in forcefield calculations that may result, so the one in CRbqDynamicSegment::RotateNode() will be changed, the one for doing rotation of node 0.

Done. Rbq-Lua unit test rbq_RotateForceObjectNode() is fully passing now.

Created index page for web/wp.


Still working on the never-ending rlut rfon. Added checking of downstream force objects back in. After test failure, realized that the assumption that downstream force objects are always rotated is wrong. That only happens for descendant nodes that included the downstream inter-residue bond.

Straightened out documentation of linkage status of adjacent residues during forward and back node rotation.

Added testing of back-rotation of force object nodes. The rfon rlut is finally passing with full testing of nodes and force objects in both foward and back node rotation.


Added links page to project web pages.

Started getting ready to do rluts for graphics functions. Created command 'dev dumpGraphicsWin' to output current graphics buffer to a bmp file. However, will also need to add additional support functions to adjust the main window and graphics window sizes to a specific size so that the graphics dumps will match a reference file.


The Ribosome Builder paper has been officially submitted to the Journal of Molecular Graphics and Modelling!

Downloaded multiple papers on forcefields for whitepaper references.


JMGM has rejected the Ribosome Builder paper immediately, saying that papers about computer programs are no longer accepted. The paper has been submitted to JCC (Journal of Computational Chemistry).

Trying to get unit test rbq_DrawBitmapText to work. The problem is that after resizing the main window to a fixed known size, and then doing a write of the graphics window buffer, the graphics child window has not been resized. After a call to resize the main window, the CRbqGraphicsWindow::resizeGL() method is not being called.

Created some documentation for the main window and child widget layouts while working on the graphics window resize problem. Been reading through the Qt interest mail archives, but no enlightenment yet. I think the problem is that the status window and toolbars are rapidly turned off and then shortly afterwards, turned back on again, so perhaps some messages are being combined in an event message queue to prevent the graphics winodw from being resized as desired. The way to figure it out will probably involve overriding some event methods in the Qt classes and doing some printfs during the sequence.

Before doing that, I think I may see the cause of the problem: all of these hide() and show() events are happening sequentially inside of a single script function, and the re-layout/ resize() events that must occur in Qt will naturally happen after the script function has completed. It seems that I'm wanting some 'immediate', non-queued calls of the re-layout/resize and code.

After adding a resizeEvent() override in CRbqGraphicsWindow, the above hypothesis has been confirmed.


After yesterday's time-consuming debugging with Qt resize events, I've come to a final decision on how to deal with the problem. Instead of trying to hack things to get 'immediate' behaviour from the windowing code, I'll just extend the current unit testing methodology by defining an additional type of test which will be called 'tickTest.lua'. The current testing method uses a test driver that iterates all subdirectories in the tst/rbqlua/funcs directory and calls each 'test.lua' script in a directory and then procedes to the next one. This method requires immediate behaviour from the application during script execution.

By defining an optional 'tickTest.lua' script within a unit test directory, a unit test can be executed by a script object test driver, using timer ticks in the application main event loop. This will allow a script to initiate operations and then check for the expected application behavior in subsequent blocks of execution code, after a particular block of script code has completed. This will solve the graphics window resize problem above, as well as allow for testing of forcefield behavior across multiple timesteps, which is not possible in the current testing scheme. Will also create associated drivers, 'runAllTickTests.lua' and 'runSubsetTickTests.lua'.

Added documentation of main window architecture to wp.

Created first draft of wp outline. Created first draft of goals doc in wp. Reading (MacKerell, 1995).

Creating some more screenshots.

Note: nice sky bgcolor: .64, .65, .88


As a good way of building resources for schematic simulations, reviewing ribosome-specific journal articles and getting more familiar with the landscape of the ribosome I am resuming creation of annotations of journal articles, starting with the classic (Ban, 2000) paper.

Trying to fix resizeMainWin() to set size of frame instead of client area (not as easy as it should be because apparently in X11, the frame decoration can be inconsistent, so Qt is weak in this area).

By having working move and resize functions for the window frame, this will save a lot of time because it allows scripted setup of the window position for working with the browser interface, instead of the continual manual resizing and positioning that I have been doing up until this point. Move and resize funcs are working. It is good.

Working on 'lua/CircleObject.lua' script, it is currently drunk. I think I will rewrite it and do it a little differently, without the pitching. Just some simple turns, up/down and forward/back moves.

Actually, simplified it even further by chucking the initial code that sets the view while moving to the circle radius. New version of 'CircleObject.lua' is working.


TODO: update toolbar descriptions in the User Manual.

Starting on creation of tick unit tests. This requires creation of some scripted way of deleting script objects.

Implementing new command 'script so sdelObj' (schedule delete script object). In doing so, I reviewed my earlier log entry about script object deletion (projectLog_2000-2004.html, 2004-02-24), which gives some further explanation of why deletion of script objects from within script object executing code must currently be prohibited (one reason is to prevent document closing, which causes deletion of all script objects and other annotations). At present, there will be some duplicated code with regard to deleting script objects and deleting annotations, but no time to worry about that right now.

Created test script 'exp/dev/tst/testDeleteSo.lua'. Scheduled deletion of script objects appears to be working.


Rotamer-covariation idea: in reading (Walberer, 20003) this morning, I got to thinking about a dynamic version of isomorphism and covariation, where one could start with two separate strands of RNA that are docked together (close complementary fit), and each strand has its own rotameric conformation, and then try to generate a range of new rotatmeric conformations for each strand separately, and then from this pair of very large conformational sets, try to identify the very small subsets in which a conformation from strand A was still complimentary to a conformation in strand B. This would be a 'complementary covariation', which could be highly indicative of a possible movement motif.

Finally added a helper function for creating script objects, 'constructScriptObject()', to _ScriptUtil.lua.

Initial version of app/rbq/tst/rbqlua/funcs/rbq_DrawBitmapText/tickTest.lua is working.


Actually, no, it isn't. Hit a snag where the dump of the graphics buffer is not showing the expected drawn text, even when the draw is being done in a 'draw()' event script and is checked in a subsequent tick in a tick event script. Need to do more debugging.

Created 'exp/dev/tst/testWriteGraphics.lua', which defines a tick script and a draw script for a script object. The draw script calls rbq_DrawBitmapText() for each tick, and the tick script does a graphics buffer dump and a redraw for each tick, for 10 ticks, but the text never shows up in the output files.

Looking at the output of the event scripts, it seems that the draw() event is called after the tick() event, for each tick. Also, it is necessary to call redraw() from within the tick event in order for the draw event to be called each tick. However, very strangely, if a second exportGraphicsWinBuffer() call is done in the tick event after the redraw(), the draw event is not called! That doesn't make sense!

Wait, calling the exportGraphicsWinBuffer() function does cause a 'renderPixmap()' function to be called. Is this clearing the 'redraw' flag?

Ah, think I see the problem: the paintGL() is being initiated by the renderPixmap() call, but all this is happening from within a tick() event call, and the script manager must be preventing the call to the draw script. If so, at the very least, a warning should have been reported. Yup, that's the problem.

Added warning to CRbqScriptObject::RunScriptFile().

This current restriction appears to prohibit testing of graphic contents through script object tick and draw events. One workaround may be to add a 'post message' hack to allow a tick event to request a graphics dump from outside of its executing code (similar to the recently-added 'scheduled delete' of script objects).

Was about to add command 'dev schedDumpGraphicsWin', and associated function in CRbqMainWindow() 'ScheduleDumpGraphicsWin()', when I realized that I could generalize it to a submission of a list of commands to the command processor instead. This allows script object tick event code to submit arbitrary commands for execution after the event code execution has completed, eliminating potential problems where one of those commands would result in the need to run some other script object event code (not sure, at this point, how much that would be needed, but the functionality will be in place). Currently, only the 'dev dumpGraphicsWin' command requires this functionality. In retrospect, the function to do scheduled deletion of script objects could have made use of this more generalized function.

Added command 'dev appendPteCmd' and associated functions. A fortunate bug in the cmd processor code also revealed the need to add a reentrant check for CRbqMainWindow::RunPteScheduledCommands().

Whew, after adding the 'dev appendPteCmd', the tick-driven graphics draw and write is finally working in exp/dev/tst/testWriteGraphics.lua!


The only remaining strange thing about testWriteGraphics.lua is that the appendPteCmd in the final tick doesn't appear to result in a call to the draw event script. Ah, no big deal, just a bug setting the done flag in the tick script.

rbq_DrawBitmapText unit test is finally passing! Wow, a new world record, 11 days (2004-05-25 to 2004-06-04), over the previous winner, rbq_RotateForceObjectNode, which took 6 days (2004-05-17 to 2004-05-22).

Created new unit test rbq_DrawOrthoText. To avoid code dup, will create a helper script object that will do the setting up of the graphics window to a specific fixed size. This will also simplify the test case code for the unit tests, as the tick function will just wait until the helper object has completed the setup.

Created helper so script 'rlutSetGraphicWin.lua'. Also, for the first time, in adding another function to the 'TestUtil.lua' module, I decided to make the function a member of a 'TableUtil' object, requiring qualification of the function call: TestUtil.getRlutDir()', because at some point, name clashes will start to be a real problem with the current 'global' function scheme. However, a transition to this better way will require huge code changes, although Lua appears to have many mechanisms for adding global names, local names, and putting module names in the global namespace (Lua book, Chapter 13).

However, this change also has consequences for the documentation scripts (alphabetical ordering), but that may not be too big of problem. We'll try it and see.

Changed rlut rbq_DrawOrthoText to use new graphic setup scheme. The test is working.


Adding test driver for tick unit tests.

Added documentation of tick unit tests to Guide for Writing Unit Tests.

Created StringUtil.parseOptions().

Created 'tickTestDriver' script. Created 'runSubsetTests-postTtd.lua'. There is now a heavily duped-code problem between runAllTests.lua and runSubsetTests.lua. Probably will ditch 'runAllTests.lua' and create an 'all.testNames' file and call 'runSubsetTests.lua' with that file as a param.

'immediate' and 'tick' unit tests are both being run from 'runSubsetTest.lua'.


There is a bug in the new 'compareFiles()' function in _FileUtil. It is failing to spot the difference between two png files. The problem seems to be that the lua readfile() function is reading in text mode instead of binary mode. Ah, after looking at the lua docs on file modes, I noticed that it says you can add a 'b' to the mode flag. Fixed.

Added another test case to rbq_DrawOrthoText, to fill up the screen.

Created rlut 'rbq_DrawBlockArrow', 'rbq_DrawBox', 'rbq_DrawCylinder', 'rbq_DrawCylinder', 'rbq_DrawSphere'.


Modifying rlut script 'runAllTests.lua' to use 'runSubsetTests.lua' so that tick tests will be included. Done.

Ack. Graphic unit tests are failing now because the png format doesn't appear to be invariant. A file of a different size is being produced today compared to yesterday, pretty sure the actual image is the same. Not a major show-stopper, just more time spent doing research on png format and possible alternatives.

Spent gobs of time downloading, compiling, running sng (scriptable network graphics) to output sng versions of differing png files, and writing a little perl script to give the diff lines and offsets. Then, tried to spot the individual pixels in photoshop but couldn't. sng files appear to show a numerical difference of a single digit, indicating some kind of round-off error.

A brief search on the web didn't bring enlightenment. The next step should be to save as bitmaps to see if this error occurs again, though how often it will occur is not certain to me. If the error is resulting from some kind of processing in the png, the test could be changed to output as bmp, though it would be desireable to add some kind of compression with that because the files would be much larger than necessary otherwise. Another nice option would be if someone has written a graphical diff tool. If so, it might be possible to do a compare with that which would disregard diffs due to round-off error.

No luck on image-diff. However, I suppose I could write a dedicated program to do that on the images without too much trouble. Although it has already been too much trouble.

Downloaded png2bmp, compiled, it works. Now I can just call that from the test script and then do a binary compare on the bmp files. They currently differ by just 1 for 11 bytes in the file. Will write a small c utility to do a fast check: 'minDiffByteVal' or something like that, which will return a result code to the test script.


Hmmph. As I suspected, the graphics tests are passing today. Wonder if that round-off error is due to some subtle memory bug or something? Only did a subset test with the 5 current graphics tests though. Previously, the error happened when they were run at the end of an 'all test' run. Will do that again to see if the error repros. No, all tests are passing now. Oh well, I won't worry about it for now, but I have a solution to be applied if the problem recurs.

Updated the links page with some more molecular modeling mailing archives.

Submitted a project report to the Lua website about Ribosome Builder.

Did a little research on GUI libs for lua. wxLua looks interesting. One possible problem is that support for Lua 4.0 is disappearing. wxLua 1.4 still supports it, I will grab that one for the present time. Also, wxWidgets may be a good alternative to Qt to escape the current VC 6.0/Qt 2.3 bind.

Rotamer covariation!! Do it!!

Created rlut rbq_GetAtomTypeVdwRadius().

Working on more atom type-related rlut funcs. But there is a problem with nomenclature. I noticed that there currently is not a function to return the actual 'atom type' id for a particular atom of a dynamic residue. We need the function 'rbq_GetAtomType()', similar to the existing function 'rbq_GetAtomElement()'. But there are already several functions 'rbq_GetAtomTypeFromName()', 'rbq_GetAtomTypeName()' and 'rbq_GetAtomTypeVdwRadius()'. In all of these functions, the 'Atom' in the 'rbq_GetAtomTypeXXX' refers the 'AtomType' type, not the actual atom that possesses a particular 'atom type'. It's very confusing, but I'm not sure how to sort it out. The term 'AtomType' should probably be changed to something else, like 'ChemType' or something. But can't do that right now. Will have to think about it. For now, will just have to try to deal with it by putting sufficient comments in the api docs.

So this work will involve actually adding two more rbq-lua funcs, pushing the rlut progress back somewhat! Needs to be done, though. This also brings up an additional problem that I've noticed in the rbqlua api, that a number of current functions only info for static atoms, not dynamic atoms. Of course, the force object atom properties are provided indirectly through rbq_GetForceObjProperty() and the high-level lua lib functions getForceObj_XXX. Actually, probably only one for now, don't strictly have to add rbq_SetAtomType() at this time.

That can be done in a non-runtime way by adding more definitions to the atomType files, though that really must be documented in the whitepaper soon.


Added some more documentation of atom types to whitepaper. Added 'rbq_GetAtomType()' to rbqlua api. TODO: add test cases to existing static-atom-only rluts that try to use dynamic atoms instead (isn't this the same as passing an invalid index?).

Created rlut rbq_GetAtomType(). It works.

Create rlut rbq_SetAtomTypeVdwRadius(). In so doing, it becomes apparent that there needs to be a way of restoring the compiled default values. Currently, there is no way of doing this. If this unit test fails during a run, it will continue to fail until the program is restarted.


Created more drawing rluts, 'rbq_DrawLine' and 'rbq_DrawBackbone' and ran into another potential problem where turning off display of the rotation axes changed the bitmap image of rbq_DrawLine slightly, even though the rotation axes are not visible when the view is centered at the origin. However, they are affecting the rendered image by changing the value of several pixels. Not a big deal, but it may mean updating the reference images for previous graphic rluts. No, that isn't the problem. Ran the test again with the rot axes off and the test image became different again! Arg.


Did full rlut test with the app window in the fore-ground and all tests pass. When running a subset of tests, rbq_DrawLine rlut appears to consistently fail, but it seems to be the only one doing so, so I won't worry too much about it right now.

Adding rbq_DrawOrthoQuad, which is needed for transparent billboard display in the schematic sims. This caused me to review why I had to implement a separate transparent drawing pass in the main render function. After reviewing the code in CWkSmoothColorMesh::DrawTransparentTris(), it's because I had to disable the depth mask by calling glDepthMask(GL_FALSE), prior to calling glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ). I did this because I didn't know much about transparent rendering and didn't have a lot of time to learn about the best way to implement it. It seems that a whole separate rendering pass is the wrong way to do it, and it doesn't even work properly with multiple transparent surfaces.

A brief search showed some posts on where people are doing it this way (a separate, subsequent rendering pass for transparent objects). Also, the sorting of transparent triangles from far to near in drawing (painter's algorithm) is mentioned. I am doing this for individual pdb objects, but not globally, so that is why my transparent rendering is not always correct. And given the existence of transparent drawing for script objects, implementing a global draw ordering of triangles will be more difficult.

Read a nice paper on transparent rendering. It makes the clear point that if the depth buffer is turned on, then an opaque object that is farther from a transparent object, but rendered later, will not show up. It also mentions the 'draw solids first, then depth off, then draw trans objects'. So the current method does not seem totally wrong , except that somehow global sorting of triangles needs to be done for the transparent pass. The only way that I can think of at present is to change the actual drawing code to some kind of 'submit these triangles to a drawing list' operation, and then the top-level draw trans function does the sorting and actual drawing of triangles that were submitted by the object hierarchy. I suspect however that with the newer graphics cards and engines and dynamic lighting and such, that this whole line of talk may be completely archaic and irrelevant. Time will tell.

Added some notes on transparent rendering to the whitepaper.

rlut rbq_DrawOrthoQuad is working.

There is a bug in OutputCurSelTorsions.lua, when run on 1tra.pdb. Wow, the similarity of getAtomParName() and getAtomPartName() is totally confusing. Arg. Renaming: 'getAtomParName()' renamed to 'getAtomPdbName()'. Thought about renaming getAtomPartName() renamed to 'getAtomTrimPdbName(), but reconsidered because there needs to be a function that returns the partial 'atom-only' part of an atom name, in contrast to 'getAtomName()', which returns the full name.

Fixed bug in getAtomPartName(), dihedral/torsion scripts are working again.

TODO: create a script in the 'Geometry', 'Torsion' menu to create an html report for dihedral angles of current selection (just need a driver for the exp/dev/report/


Adding 'TorsionFreqReport.lua'. There is a bug in the generation of html docs for the lua_lib api functions, the qualified function name 'ScriptUtil.parseOptions' is showing up in its own section in the column-based list of names in the indexes. This could also be considered a feature, but looks bad. Also will get worse as more qualified functions are created/converted. The current perl script the generates the docs is a mess and should probably be rewritten at some point.

Updated ScriptUtil.parseOptions to handle short options, long options and non-options.

Torsion Angle Frequency Report script 'lua/TorsionFreqReport.lua' is working. I think the next step after this was something I was thinking about a while back, a way to generate a frequency report from a list of objects. This would allow the accumulation of statistics for a larger pool of conformations.

Thinking about how to implement this 'cumulative' version of torsion frequency calculation, this shouldn't be too hard. The current version creates a 'torsion angle' file from the current selection, which has a line for each residue, containing the torsion angles for that residue. In the cumulative version, we can just define a 'torsion angle' file that we append residue records to, for all residues of all models in the source model list. This file should be able to be input to the existing perl script '', without any modifications. The only change would be that column 1 would have the full dotted name of a residue instead of its numeric index, but that shouldn't be a problem. The only remaining issue is what to name the new script. Something like 'multi-model torsion freq report', 'mmTorsionFreqReport.lua'. That works.

This work is preparatory to taking another shot at accumulating g-rotamer stats (general rotamers, 324 possible compared to the 42 proposed by (Murray et. al, 2003)). This involves all possible combinations of (P1, z, a, b, c, P2) where P1 and P2 are 3' and 5' pucker and (z, a, b, c) are the 4 torsion angles that can be in one of 3 states: m, t, p (gauche minus, trans, gauche plus). The only thing that bothers me is that the Murray table gives a constant value for epsilon, but the frequency stats I just generated for epsilon for 1fka show quite a bit of variation. It makes me curious what feedback there has been to the Murray paper. 0 hits on Usenet. You know, it's pretty damn sad the way the Usenet has completely disappeared with respect to scientific discussion.

Added a little about torsion angle anaylsis to the whitepaper.


Added new rlut 'rbq_GetViewCenter'. Added more xrefs to lua_lib view functions. Finished 3 more rluts.

Created script 'lua/mmTorsionFreqReport.lua'. Starting to get a better idea about where I want to go with the rotamer thing. An immediate project would be to try to produce torsion-directed conformational change of 2 linked residues from one rotamer to another, for every possible combination of the 42 m-rotamers (and possibly, some additional well-represented g-rotamers). This would be 42 * 41 = 1722 simulations if bi-directional changes are investigated, or only 861 simulations if only uni-directional transitions are done. The relative difficulty or ease with which a subset of the transitions may occur can then form the basis for further investigation, especially the coordinated transitions involving multiple successive residue suites.

mmTorsionFreqReport.lua script is working, with only minor changes to exp/dev/report/'.

So, before proceeding with this project, I need to get solid g-rotamer and m-rotamer stats from a large source of nucleic acid structures. This will require a rotamer version of the mmTorsionFreqReport script that has just been created. There are existing rotamer perl scripts in exp/dev/report. I need to create another lua marshall script, 'mmGrotamerFreqReport.lua'.


More work on g-rotamer frequency calc and reporting. mmGrotamerFreqReport.lua is working. Ran it on 6 large ribo pdb models, 4 30S and 2 50S. One notable point is that in the top 11 g-rotamers, 6 of them are non-m-rotamers. Strange.


Adding selection and highlighting of inter-subunit bridges to Features menu. 1gix 30S bridges defined and working. Added 1giy 50S bridges.

Started writing a script to automatically convert bridge scripts for 1gix/1giy to other pdb models, but I think it will be too much work and will be faster to just manually create scripts for additional models such as 1ffk, 1fka (at least for now).

Creating bridge-select scripts for 1ffk. Note: L19 (involved in bridge b6) is radically different in size and location in 1ffk compared to 1giy. Instead, L24E is the 1ffk version of 1giy L19.


I realized today that the way I implemented the isu bridge selection scripts is quite wrong. Creating a script for every bridge results in far too many scripts and redundancy. It's much better to put all the bridge definitions in a single script and select according to params. Don't know why I didn't do it that way in the first place.

This changes requires adding arg support to the ScriptDefs.ini file. Hope that won't break anything. Actually, it doesn't. The current mechanism already supports additional arguments after the script file name.

New version of bridge selection is working. Also added functionality to select all bridges.

Looking for newer models of ribosomes, found 1pns, a model of E. coli 30S, stated as 8.70 A resolution, but the model used full-resolution atoms. Nice. Of course, Ribosome Builder should have a similar full-atom capability.


Created exp/dev/sub70/Bridges html docs. Created helper script 'lua/selCgiRanges.lua'.


Working on modelling results from Scott Hennelly's kinetic probing. One thing that I noticed yesterday was his use of Rasmol to view the 16S, with covalent bonds displayed instead of backbone, and how the depth-cueing worked well to convey the 3D illusion. It might be worthwhile to consider adding depth-cueing to rbq, if not too difficult. Also need to check to see how PyMOL and VMD handle it.

Created a dynamic portion of 1j5e.A helix 27 and looked at the initial forces. There appears to be a bug in covalent force calculation because the initial structure shows a lot of covalent force arrows, all aligned in the same direction. There should be no initial covalent force on a newly-created dynamic structure which has not been allowed to move. I wonder if it is just a round-off error? Started initial control sim of selected portion of helix 27 on ribo4. After 140 frames, looks fairly stable.


Trying to improve torsion spring usage by adding better graphical indicators. Added annotation function 'drawWireArc(). It works.


Almost had nice indicators in drawing torsion spring dials, but then ran into a problem where the current implementation of 'rbq_DrawWireArc()' doesn't specify the proper 'up' vector. Not sure how to fix it.

Redefined rbq_DrawWireArc() to take explicit ptCen, vLook and vUp. It appears to work.

Drawing of torsion dials is finally working.


Now drawing of torsion dials to correctly reflect applied torques is really working (excepting special iUserGAD mode). One problem however, for some strange reason the frame rate drops dramatically when the delta angle goes to zero. The slowdown is in drawWireArc().

Found the problem. Was calculating fraction of 360 degrees inversely in rbq_DrawWireArc(). Fixed. Now there is another bug where the arrows flip direction. Actually, this looks like a bug in the DihedralUtil.lua code, because when the flip happens, the reported torsion angle flips from 0 to 180. I thought that was an old bug which had been fixed! Arg! Looking at old log, on 2004-03-26, the description of that old bug seems to be exactly the same problem. The cause was a zero cross-product. In this new bug, the problem seems instead to be from vectorAngle().

Fixed. Hope this is the last of the dihedral bugs! Torsion dials appear to be working. They appear to be very successful in indicating what the torsion springs are supposed to be doing.

Working on ribo5 to simulate inter-subunit bridge interactions for Hennelly paper. Will simulate all bridge residues dynamically by creating inter-residue meshes using new script object 'interResSpring.lua'.

Along the way, needed to add support for dynamic residues to script 'lua/ReportSelResDistance.lua', but in so doing, found bug in getSelectedForceObject(). Arg. Has something to do with the fact that there are multiple dynamic segments with the same chain name. Failure is in CRbqDoc::GetDynamicSegmentIndexFromName(). Actually, it's in CRbqPdbMol::GetDynSegMhIndexFromName(), which doesn't even consider multiple dyn segs per chain!! TODO: add creation of multiple dyn segs per chain to dynamic model unit tests!!!

Note: the bug above doesn't show up during mouse selection, because that is by index instead of name.

Hopefully fixed bug by adding 'CRbqPdbMol::GetOrdinalDynSegName()' fixup in CRbqDoc::GetDynamicSegmentIndexFromName(). Bug appears fixed. ReportSelResDistance.lua is working for dynamic residues in multi-segment chains.


Added labels to bridge residues ('CreateBridgeLabels.lua'). In so doing, fixed some bugs in _GeomUtil.lua where the function wasn't check for nil values returned from rbq_FuncXXX and in creating a table of nil values that was returned, the table was not nil, but getn( table ) returned 0.

I've worked out a way to systematically create the inter-residue spring-bonds for the subunit bridges. Adapting from 'initTorsionSpringsFromFile.lua' and the associated .ta file, I will create the script 'initLoopMeshFromFile.lua' and an associated .loopMesh file, which is simply a list of records where each record specifies the start and end static residue full names for dynamic segments that will be the loops. The script will create all the dynamic segments and then define inter-res spring bonds that connect the endpoint residues of each dynamic segment with the N nearest neighbor endpoints. This should produce a fairly stable yet efficient mesh.

Finished 'initLoopMeshFromFile.lua', defined bridge and adjacent residues in subunits, started first inter-subunit mesh sim on ribo5.


Found and fixed bug in CPovRayExportGraphics_PdbSurf::OutputSurfGraphics().


After input from Scott H. that display icons to turn off backbone/covalent/spacefill were not obvious, changed the icons to have a red circle with slash through them, and also changed ordering from reflective ordering wrt to 'on' icons to same ordering.

Next work on modeling bridge interactions is to produce some kind of quantitative analysis of bridge residue proximities over time. A way that this could be done is to define an approach vector of one subunit relative to another, then incrementally move the subunit along this vector and calculate the steric energy between bridge residue pairs. Will create a script called 'bsa.lua' (for bridge steric approach).


After a suggestion from Scott H., added file drag-and-drop. It was trivial to implement because of Qt support.


Working on improving export of graphics to POV-RAY. The current implementation can only export backbone or surface, as two separate files. Need to integrate them, and possibly add covalent and spacefill generation.

The way that things are currently done is that, for backbone output, a function, 'ExportGraphics()', opens a new .pov file from param filename, outputs some common boilerplate povray code, which does required includes for povray functions such as, sets the background color, camera location and orientation and light source. Then, after declaring the start of a union block, the file handle, along with a param export graphics object, is passed to the document object, which traverses the pdb object hierarchy to output triangle meshes and cylinders to represent the nucleic acid backbone (proteins are not currently supported).

The same thing is done for surface mesh output, except that the pointer to the 'CExportGraphics' object is pointing to a CPovRayExportGraphics_PdbSurf object instead of a CPovRayExportGraphics_NucleicChain object when entering the CRbqCmdProcessor::ExportGraphics() function.

The document object just iterates each pdb model object, passing the param output stream and CExportGraphics ptr. Inside the CRbqPdbMol function, a dynamic cast is done to detect whether it is a CPovRayExportGraphics_PdbSurf object, in which case the pdb surf object member function 'OutputSurfGraphics()' is called. Otherwise, each chain in the pdb model is iterated, calling the 'OutputGraphics()' function of the param CExportGraphics object, which in this case is a CPovRayExportGraphics_NucleicChain object.

This current implementation is quite messy and needs to be redesigned.

Combined surface mesh output with nucleic chain backbone output. Also fixed some other things in the POVRAY code, such as the view problem that existed before, where the position of the graphics in the OpenGL window didn't quite match that in the POVRAY image. I found that an angle of 75 in the POVRAY camera seemed to produce a good match.

The POVRAY export is much more usable now. One more thing to add would be transparency to surface meshes.

Did unit test run, all passed. I think it may be time to do a new file release, perhaps after adding transparency to povray export.

Added transparency to surfaces in povray export, it works.


Built some distribution files for 0.3.2. Also, trying to get pictures out ASAP for Scott H. Thought that I had got the POVRAY export to a workable state and now find that it isn't doing colors for each residue correctly in nuc chain backbones. Arg! Oh, it's because I changed the code to apply a global texture for the entire chain.

Added coloring of each residue to povray nuc chain graphics. However, the problem with that is that the current implementation defines a nurb ribbon segment from the backbone atom of the current residue to the backbone atom of the previous residue, and when a single residue is colored differently from the adjacent residues, it looks weird. The expected coloring should go from the midpoint between cur res and prev res to the midpoint of cur res and next res. So this would require calculation of nurb segments involving the next residue. More work.

Actually, because the phosphorus atom is the first atom in the residue bb chain, setting the color using the previous residue color should work (nurb seg is from current phosphorus to prev phosphorus).

This is still a problem with missing bases (backbone atoms only), because the backbone ribbon requires an orientation. I may implement a second version of backbone export using povray sphere_sweep, which would also work for proteins.

Added new version of backbone rendering in povray export using sphere_sweep object, it works! Added covalent output, it works. Added spacefill output, it works.

Generated another picture of the 702 region in 1j5e for Scott, it looks much better now.


Ack. In trying to get out a new file release, am finding a bad bug that is release-version only. It happens during export of graphics to povray, where degenerate cylinders are produced. Examining the diff in the povray outputs, it looks like a bug in the inter-residue bond code. In the release version, the atom of the previous and next residues is being returned for both the i and the j atoms in the inter-res bonds involving the current residue. Crap! It's a goddamned Heisenbug!!!!!! I think it may be related to some kind of temporary involving CAtm.GetPos(). Yes, of course. That is it, I think. Wonder how many other places that is done? Fortunately, 'GetPos().' is a good search pattern.

Installed winzip8 on ribo5 to create a distribution there using the personal self-extractor. TODO: replace with a free sfx version.

Fixed GetPos() bugs.

Building and testing rel can 0.3.2 on ribo5. One big problem: the 'Error: already running script...' message (and companion 'Error: failed running script...' message in CRbqScriptObject) is slowing things down when running the translation init demo. Need to change warning so that it is only given once per a particular currently-running script.

Done. Trans init demo re-runs without problems now.

Downloading povwin3.6 to ribo5 to test rb povray export. It works on a test render of 1fka and 1j5e, but there is a strange little artifact in part of the image. I think I will release this version.

Also ran the unit tests, and all non-graphics tests appeared to pass, and a check of the final graphic image appeared ok. At some point, when there is time, I will add the .bmp image check because I think the diffs are just do to math roundoff errs.

Did file release of version 0.3.2.


Experimenting with doing surface mesh on selected helices (currently have to export them to their own pdb file to do that) and 'dev setSurfVdwExpand' set to 1.5 and 'draw surf createForPdb 1.5' are giving good results for showing the true vdw surface boundaries between adjacent stacked helices.

Trying to get a better feel for how helices pack against other helices. It's hard to see things with full vdw radii, but otherwise, it's hard to tell exactly what is packing against what. It would be really nice to discover some simple motifs or patterns of stacking, involving individual atoms. One way to start with that might be to write a script that, for any given atom of a residue, will output the nearest three atoms of a neighbor packing residue. Then correlations could be done between pairs of atoms, and their 'tri-nabor' pack atom pairs, and so on. Also, could output pairs of atoms that are actually 'touching', though this depends on how the vdw radii are defined.


Did a brief ff sim to investigate helix packing between 1j5e.A helix 44 (partial) and helix 27. One thing that I noticed is a bug in the hbond vector code. Hbond acceptor vectors are not being created for the 3' oxygens in nucleic acid residues. Also, really need to lock down the exocyclic amines in base rings so that they stay in the plane of the ring.

I wanted to look at more examples of helix packing, and this led to the problem of trying to align additional models of the 30S, which requires sequence maps and helix alignments. After adding a little discussion of sequence and structural alignments to the whitepaper, I am thinking that some scripts should be created to automate the current process, which is a manual and time-consuming one. The first step would be to create an unaligned sequence file of a pair of chain sequences. This would be done by running a script in the program that has the desired models loaded. Something like 'OutputPairChainSeqs.lua'. This would then serve as the input to a pair-wise sequence alingment program such as globals.


Ribosome Builder manuscript rejected by JCC. :(

Created function 'getNucleicChainSequence()' in SeqUtil.lua. Starting on 'lua/CreateSeqMap.lua' script.

Fixed bug in povray export for invalid residue sequence number (-1 in 1giy, chain 1, residue 0).

Finished initial portion of 'CreateSeqMap.lua' script, but then, in using the 'globalS.exe' program that I had compiled on 2004-10-13, it is crashing. The third-party code seems a bit of a mess to me, and I don't want to take any time to clean it up. Added some exit() statements to bail out instead of crashing when arguments are missing. Also, I had forgotten that I had written a script, '', to convert the output of the globalS alignment into a fasta alignment. Fortunately, all of these 'manual' steps will be encoded into the 'CreateSeqMap.lua' script. Still, the entire operation appears rather brittle at this point because so many disparate command-line tools are used. In GNU/Linux, the error-handling and chaining could probably be handled just fine, but in DOS it will probably fail miserably in edge cases.

Well, there is already a problem using the brain-dead DOS command-line. The current implementation of globalS outputs to stdout, which I cannot redirect in the current implementation of runProcess(). Rather than trying to hack a redirect, I think I will just hack the globalS code to output to a param filename.


Found output flag in globalS, so I don't have to hack it. 'CreateSeqMap.lua' script is working, added support for reference E.coli sequences as well. This allowed me to create a sequence map between E. coli 16S and 1ibk.A. Then, to create an alignment between 1gix.A and 1ibk.A, I needed to run 'GenHelixFileForChain.lua' on 1ibk.A, but because the helix files are still hardcoded in _SeqUtil.lua, it was a little problematic. Finally, after creating the helix file, I was able to run 'FindBestHelixAlign.lua' to get the best alignment. The alignment of arbitrary subunit RNA chains is improving, but still not quite there yet.


Trying to keep the progress of unit tests going, in spite of many other things to do. Started on rlut rbq_GetSelectionCenter. Finished rlut. And it found a bug. Tried to translate all dynamic segments created from 1tra, and chain a$ was translated, but not chain b$. Fixed.

But now the 'run all tests' test driver is broken. Ah. Because I changed StringUtil.parseOptions(). No problem.

TODO: update graphic unit test code to check diffs, get rid of hard-coded .hlx file refs in _SeqUtil.lua.

Idea: ligand-receptor docking using the 'single contact sphere-rotate, two contact axis-rotate' strategy.


Starting work on getting rid of hard-coded helix data and sequence-map data in SeqUtil.lua. Instead, the code should just do file lookups in the seq subdir.

Currently, the following SeqUtil functions reference 'f_HelixData':

Currently, the following SeqUtil functions reference 'f_SeqMapData':

Changing these refs shouldn't be too much of a problem in this particular case, but it leads me to consider adding tests to verify the continued function of scripts, in addition to the existing unit tests for the rbq-lua api. These wouldn't be called unit tests. Instead, they might be organized by category, and called 'feature tests'? Such as 'sequence feature' tests for sequence-related scripts. Should these be called 'regression tests'? Or 'scenario tests'? Or 'category tests'?

Using the rbqlua test driver structure as a template, created new feature test subdir 'app/rbq/tst/seq'. Created test 'app/rbq/tst/seq/tests/CreateSeqMap/test.lua'.


Added feature test 'app/rbq/tst/seq/tests/SelectHelix'.

Added rlut rbq_GetSelectionExtent.


Added rlut rbq_GetSelectedPdbs.


Added rlut rbq_GetTotalSelectedChains.


Finished feature test 'app/rbq/tst/seq/tests/FindBestHelixAlign'.

Wrote a description of the Helix Alignment Algorithm for Scott H..


Did full test run for rbqlua tests, 88 tests run and passed.


  • Added rlut rbq_TranslateSelection.
  • Added rlut rbq_RotateSelection.

    While coding the rlut rbq_RotateSelection, I noticed that there is not any current specification of the requirement for vector normalization for any of the rotation functions in the class hierarchies and libraries. Tracing it all the way back to grCommon::GetRotatedMatrixOpenGLStyle() in the wkGrMatrix lib, I see that the vector is normalized inside the function. Adding an explicit specification that the vector need not be normalized would be a lot of work. And perhaps the current absence of this is the expected behaviour. If a param is required to be normalized, it should be stated explicitly in the specification. In addition, for possible optimization, there perhaps should be another version of the function that doesn't do the normalization, or, to avoid a zillion function dups, perhaps a state, such as that in OpenGL, which enables auto-normalization (I believe in OpenGL, it doesn't check for normalization by default).

    Also, that would be a nice thing to add to all rluts which use vectors that possibly might need to be normalized: test cases which pass non-normalized versions of the parameters.

    Finally finished rlut rbq_RotateSelection. Disturbingly, the inverting atom position error in rotating a dynamic segment by 180 degrees about a vector orthogonal to the atom position vector is greater than 0.001. It does pass with an error limit of 0.01 however. Presumably, this is an accumulation of numerous small errors in the vector, matrix and center-of-mass calculation code, but it should probably be checked at some point.

    90 rluts running and passing.



    Testing export of a selected dynamic segment, it appears that it is not exporting the created hydrogens. In looking at the code, it is explicitly skipping created hydros. Why? This is because calls are made to the embedded CFastPdbObj with ptrs to atoms, which are expected to be component atoms of that object. So, for created hydros, we should just add a separate block of code to export them with default pdb info. Done. It works.

    Next is the issue of supporting only a selected portion of a dynamic segment for export. The current implementation only supports the export of the first fully-selected dynamic segment. It should be easy to add a flag specifying that dynamic atoms should be exported only if they are selected. Done. It works.

    The reason that I added this capability was to enable export of single atoms to a PDB file, with the intention of using them for testing of the forcefield. However, I'm not sure if the current implementation of force objects permits creation from partially-defined residues. If so, it should be added, because single atom-pairs would be the best way to test the forcefield functions.

    BUG: when a single node of a dynamic model is selected that doesn't rotate, or when multiple nodes are selected, they will not rotate, but no error message is displayed to the user.

    I'm also modifying export of dynamic segments to support composite (multi-model) export. At some point, the static model export should be updated to support this as well, but that will be a little more complicated because the current implementation of static model export supports exporting chain descriptions. The dynamic model export has the flexibility of composite export, but this isn't compatible with maintaining existing chain descriptions for 'all-or-nothing' static model export.

    I should add an 'export' section to the feature tests in the 'tsts' subdir.

    After these changes, did rlut tests, 94 run/pass.

    Looking at the requirement for creation of dynamic residues, in CRbqDynamicSegment::ValidateForDynamicResidue() it requires that atoms in the 'extra-bond-definitions' must be present. Why was this made a requirement for dyn res creation? Looked back in the old dev log, on 2003-11-13, the reason for this was that hydrogen atom addition would fail because some atoms were missing. If extra bonds were not added to an atom because its partner atom in an 'extra-bond-definition' record was not present, then the correct valence of the atom would not be determined, and hydrogens might be added incorrectly. So, currently, if this validation fails, the code just drops this residue completely. I'm thinking that it should be fairly straightforward to just drop hydrogen atom addition instead, for 'incomplete' residues.

    However, would it be even better to do the enabling of hydrogen addition on a 'per' atom basis, so that we could have a singly-defined hydrogen bond for testing? This is more problematic, and since there is a current capabilitie to disable individual hydrogen bonds in the forcefield, that could be done instead. Note: currently, only the DEBUG version supports this, and it isn't available in rbq_SetForceObjProperty().

    Adding code to just skip hydrogen addition instead of dyn res creation if missing atoms. However, in creating for a test residue with just two atoms, there is now a failure in creation of CRbqTorsionGraph This is due to non-bonded atoms in a residue. Trying one P atom per residue, and trying to create 2 dyn residues, now getting a failure in CRbqNodeBsjForceObject::SetPrevResBondData(), so we have to handle that as well (dynamic segments with adjacent residues that are not bonded to each other). Though, for testing, could have 2 separate dynamic segs with one atom each?

    Successfully creating 2 dyn res in separate segments, each with a single P atom.


    Working on fixing ff param read/write bug. Re-organized params in CRbqTimestepContext so vars are alphabetized, and so the getter function is used from the param set/get map instead of duped code, which became out of sync.


    In adding the rlut rbq_StepForcefield, and improving the reported node total force, I notice that some nodes in the test force object have zero total force on them after 1 timestep. This doesn't seem right, as there should be some small, non-zero force due to vanderwaals interactions with the other atoms. Oh wait, it's probably the hydrogens, which are currently skipped in vdw calculations. Yup, that's it.

    However, in devising this test, this brings up another interesting thing in that the total force on the single force object should be zero, and the deviation from this is a good indication of the numerical errors. Currently, for the test object 1tra.a$.G1, the total force after 1 timestep is reported as (-0.00000009 0.00000009 0.00000021), which is fairly close to zero (nearly within the expected precision of a 16 bit float (is it 16 bit currently?).


    Rlut development progress now at 50%!



    Finished calculating the theoretical number of intra-residue steric interactions for 1tra.a$.G1. I get 174 atom pairs after excluding hydrogens, 1-2, 1-3 and 1-4 interactions. In doing a timestep and checking the reported stats, there appears to be a bug as only 1 steric interaction is reported, only 1 torsion interaction, and the cumulative stats also appear broken.

    Tracing into CTorsionBodyIteFcon, the pair count is 172 instead of the predicted 174. That may be a distance threshold effect, retrying with larger threshold. No, that didn't do anything. That threshold value is a residue-level param anyhow.


    Loryn and I are married!


    Reading Cantor and Schimmel Biophysical Chemistry, about how the in-vivo environment of biomolecules may have complex and unknown effects on them, that become lost when the molecules are extracted for analysis and experimentation. It caused me to imagine the ribosomal complex embedded in some heterogeneous matrix of stuff that might play important parts in the process of translation in various contexts.

    Then, reading Lowe's Pipeline blog entry about biochemistry processes that are modelled with mathematical equations that have these high-exponential terms with tiny coefficients that only affect the result in unusual circumstances to reveal some buried biological effect, this led me to try to imagine a way to connect some particular environmental context of a macromolecular system to these low-weight exponential terms of an abstract mathematical equation.


    Back to rlut rbq_GetTimestepInteractionCount. After writing script exp/dev/tst/, to analyze the atom interaction data output by CTorsionBodyIteFcon, and generate an exclusion list from it, the descrepancies with the rlut are revealed as errors in the predicted values in the rlut. Verified 172 atom-atom interactions.


    Manually enumerating the torsions for 1tra.a.G1, I only get 46 of the 48 reported torsions from ff stats. Should I add detailed reporting to torsion calc code?

    Did the command 'ff fo report torsionTorque' and got a listing of 96 torques, as expected for 48 torsion interactions. Could just add the command 'ff fo report torsionBonds' to list the torsion bonds for the selected force objects. Done.

    Looking at the report, I found some missing torsion bonds, but there are also some extra ones! These are bonds where the endpoint atoms A and D are the same, but atoms B and C are different. For example, in the 6-ring of Guanine, there is (C5 C6 N1 C2) and (C5 C4 N3 C2). The existing torsion code must be ignoring a torsion bond if one with the same endpoints already exists, but this is incorrect behaviour, because torque should be applied about both torsion bonds for those pair of atoms. This is a good bug find from developing an rlut.


    Fixed code in CRbqNodeBsjForceObject::CreateTorsionBonds() to check all 4 atoms for existing bond instead of just atoms A and D. We now have 51 torsion bonds in both the rlut and the program for 1tra.a$.G1.

    For covalent interactions, there are 39 single covalent bonds visible. 44 are reported, so there must be 5 additional double bonds. Verified.

    We finally have a working version of rlut rbq_GetTimestepInteractionCount, although only for a single forceobject. Enumerating the theoretical counts for multi-residue tests will take a bit more work.

    Fixed ff cumulative interaction stats. Ran rluts, 100 run and pass.


    After skipping a date header in this dev log, I tried to use the 'cvs log' command to find out exactly when I did what in the last few days. Had a little trouble using the cvs log command because it reports headers for all files, including those with the desired log entries in the specified date range (which has the format 'cvs log -d "5 Aug<now"'). And, of course, redirection is useless on Windosed systems, so I have to do it on GNU/Linux. Then, I found out about, which I am investigating. It works beautifully, generating a ChangeLog file for all changes newer than a desired date with command: [perl -l "-d'>2004-08-04'" -f clog.txt].

    Note: steps for ssh on GNU/Linux:

    Starting doing some thinking again about the schematic sims and how to design the simulation portion and the annotation portion in the best way (model events vs. presentational events). Currently, there is an interpolated presentational event script object (spIpe), but this seems rather kludgy. I'm thinking that there needs to be a clean separation between the code that implements the model simulation and the code that implements the presentational stuff.

    We also need an easier way to crank out a lot more schematic sims. I think that a good way to go about this is to create some tools that can help to generate the needed files. Such a tool would let the user define which models are to be loaded, then to define a set of interpolated sequences, then to define camera shots and billboards, and ultimately, to do much more sophisticated presentational events during the model simulation.


    Back from Honeymoon/vacation. Thinking about working on schematic sims, one thing that needs to be added (I may have discussed this before) is internal interpolation of static models from one conformation to another. I beleive that the proper combination of an interpolation of a static model position and orientation from one state to another, in conjunction with a conformational interpolation, may be able to reproduce any desired change of state for components of a macromolecular process such as ribosomal translation.


    Started on the 'Ribosome Builder' game, exp/games/rbg, a little script to learn the structure of the ribosomal components through guided movement and docking of fragments.


    Continuing on rbg game, the script is loading differently-colored fragments. Now I need to add a 'difference' check to insure that colors of adjacent fragments are not too similar (as well as distance from selected color and background color).

    Added 'diffColor' functions, they work.

    My plan of how the game should work has been evolving. Initially, I envisioned a rather complicated requirement of the user aligning each fragment until it is nearly in the complete correct position and orientation, but now I realize that it could be a lot easier, and still educational, to require the user to choose a fragment and then just put one of its endpoints in proximity to an endpoint of the correctly-assembled portion, and then do a 'submit' action. If it is the correct fragment and endpoint, the game will then do an animated alignment of the fragment, with accompaning sound at some point, for a nice 'reward', or play an annoying buzz for failure. The scoring can be simply based upon the number of correct successive submissions.

    Next: starting on 'dock' script object.


    Redefined funcs.lua file in rbg game to RbgGame.lua, made all game functions and data as members of an RbgGame object. Created random placement of fragments, it works. Then I wanted to reset all frags to initial position, but when I tried, I got the 'multiple selection' error for 'pos sel resetTransform' command. I wonder why I prevented this for multiple selection? Looking at the code, I think that it is just because I initially implemented it with the assumption of applying to just a single pdb. I believe that I can safely remove that restriction for this command.

    Created the docker script object, which is currently docking and setting color of docked frags each timer tick. But I have encountered a problem, where the selection coloring mode is staying locked. It results from the selection that the script object is doing each timer tick, but I don't understand why. It's annoying, and potentially time-wasting, so for now, I will just do conditional dock and selection/coloring for fragments that are not in the docked position. That fixed that problem, but still worrisome.

    Interpolation works! Just a simple cut and paste from the simpanel interp code. We almost have a game!

    More evolution of how the game should work. Found that a black background works much better, and also setting the orig model as a transparent surface to show the envelope. Also, it seems too hard to expect correct sequential assembly, especially for newbies such as myself. So instead, I am allowing all submitted fragments for docking, in any order, and will just calculate the score based on proximity to destination. Finally, as far as creating helix annotations as clues, I think for now we can just draw annotations for helices that are fully contained within fragments. This will lower the current performance hit for lots of annotations, and also solve the problem of having to add 5' or 3' side designators to the annotations.


    Finished initial version of the game.

    In developing the Rbg game, I started making extensive use of a module-level object (RbgGame) to hold data instead of in script objects. It caused me to realize that this could be a better alternative to the cumbersome script object variables for all script objects. Each script object could be created as a table object, held in an array in a module-level lua variable. Data access could be much easier and powerful. Possible downsides include somewhat less visibility and access from the user level compared to script object vars, although presumably inspection routines could compensate. Also, there might be some problems in freeing unused data after script objects are deleted.

    Added new game function to rbg game. Now it is fully functional. Also, realized that I didn't add random rotation to frags, just random translation. This actually makes it easier. Need to hook random rotation to higher difficulty levels. Also need to add helix labels soon, as this will help the user to learn the structure. Also, add mrd color (most recent docked frag color, as distinct from remainder docked color).


    Been thinking about how to make a more flexible and general purpose framework for schematic sims as well as animated narrations of journal articles. One idea is to define a sequence of items in a lua table, where each item is a step in the narration or schematic sim. Each item defines an init() event, a tick event, an interpolation rate, and optionally, draw and drawTransparent events. The events of an item will be called until they complete, and then the driver will process the next item in the list. This should provide for a general-purpose animation where models can be loaded, interpolated, drawn, camera positioned, text displayed, all in an interpolatable manner.

    Added semi-transparent backgrounds to text messages in rbg game. Added some helper functions to do some of the calculations, but the process is still kludgy, requiring separate 'matching' functions called from the 'drawTransparent' event for each text function called from the 'draw' event.

    Added helix labels to fragments in rbg game.


    Added interp rate adjustment script, more help info and random rotation of frags to rbg game. Getting ready to release next version of rbuilder. Got rid of kludgy CalibrateInterpRate.lua script, the manual adjustment one works much better.

    Released version 0.3.3.

    Looking at the directory structure, I'm thinking changes need to be made. First and foremost, the distribution and install mechanism should result in the creation of a subdirectory with the program and version name, e.g 'rbuilder-0.3.3'. Second, we should ditch the 'bas' directory on the development machines. The base directory is implicitly the 'rbuilder-XXX' subdirectory. Second, the 'app' and 'lib' subdirs, which are src directories, should be explicitly moved into a new 'src' subdirectory. Finally, the 'exp' directory should be maintained explicitly as a subdirectory of the base directory.


    Wrote scripts 'exp/articles/', 'web/wp/ref/' and 'web/wp/ref/' to export journal article references to text files and html docs. Started in earnest on writing the dissertation.


    Have obtained 3 excellent books as guides and inspiration for writing the dissertation:


    Still working out the general outline of the paper. It is necessary for me to organize and create a more comprehensive summary of the existing literature for RNA, ribosomes and molecular modelling.

    Adding keywords to my existing database of references.


    While accumulating more literature on ribosome termination, it has been motivating me to try to quickly create some more schematic simulations. Also, came across a fantastic picture (Fig 2) while reading (Brodersen 2003): it is a composite of 2D cross-sections of 3D structures that gives a very nice 2D schematic view of a particular state. It had never occurred to me before to do this. I had realized the need of some kind of 2D illustrations or cartoons to accompany 3D schematic sims, serving as reference annotations in 2D media such as a web page. But I had assumed that to produce such a 2D cartoon would require manual illustration work. This cross-section approach should prove to be a much more convenient way of producing such 2D schematic pictures, once the right tool for producing a 2D cross-section is obtained.

    Added 'command reference' html files to project web page, as User Manual and other pages referenced those, and were showing a broken link. However, need to come up with a more comprehensive way of updating these kinds of files on the project web page so that they are in sync with the latest build, as the current manual method is not good at keeping everything up to date.

    Videogame boxing is a great caffeine burner-offer.


    Created '' script in web/wp/ref to generate list of references organized by keywords.


    More refs and html docs.


    After reading a couple of papers on RNA-protein structure (Jones, 2001), (Draper, 1999), I am looking at the structures in rbuilder with some new eyes. Taking a fragment from the ribosome builder game, containing helix 44, and rendering its surface at 2 A, I obtain a nice visual appreciation of the narrow, deep major groove and the shallow minor groove, and note how irregularities in the A-form helix result in widenings, twistings and other irregular alterations of the groove structure, providing the opportunity for sequence-specific recognition by RNA-binding proteins.


    Created AnnUtil.runSim() and supporting sim driver code, created initial schematic sim in exp/articles/Ban-2000, it appears to be working.

    Added AnnUtil.setBillboard() and supporting billboard code.


    To continue with the new implementation of schematic simulations, as supported by AnnUtil.runSim(), it is clear that some form of object-oriented programming is needed, to avoid massive amounts of duplicated code. This is because there are lots of common operations needed for all schematic sim objects, such as the initial Ban2000 object, which does an animated annotation of the (Ban, 2000) journal article. An example of a common operation is sim.incInterp(), where the fInterp variable is incremented by the current interpolation rate. This is typically done in each tick() function call. The code to do this is fairly simple: function incInterp( self ) self.fInterp = self.fInterp + self.getInterpRate(); end. However, defining this function in every schematic sim script file, along with other related functions, is a bad duplicate coding practice.

    So the time has come for me to use some of the object-oriented capabilities of Lua. I am comfortable enough with the language not to be bothered by this additional complexity. Read the old version of the Lua book (around when Lua ver. 4.0 was used). This version mentions two ways of creating objects: cloning a table and using settagmethod(). The table cloning method is simple, but uses more memory. The settagmethod() is fairly simply to use for the specific situation of adding delegation for table element indexing, but I believe that because it is a global effect, it could have a significant slowdown of the existing code because after setting a delegate function, every table index operation for all the current Lua code will go through this function. So I think I will stick with the clone method for schematic sim objects for now. Read a little bit of the newer version of the 'Programming in Lua' book, which is for post 4.0 versions, and it talks about doing things a little differently, using metatables, which I suspect allows for more specific, localized overriding of table index lookups, but I am not about to upgrade to a newer version of Lua at this time.

    Ack. For the first time, I am running into lua file load conflicts, where ScriptUtil.lua needs to load AnnUtil.lua and vice versa. Why is this only happening now? Is it because I am doing a dofile() at top of _AnnUtil.lua to separately load AnnUtil.Sim.lua?

    Ok, hardcoded the path for the dofile(), which is really ugly. Now having problems with function declaration ''. Can we not nest package names? Changed to '', did 'AnnUtil.Sim = AnnUtil_Sim;' at top of file. Is this the way to do it or is that a hack? Anyhow, now it compiles.

    AnnUtil Billboards are working.


    Adding lua function 'rotateViewAroundCenter()' to ViewUtil.lua. There is a bug when using the console view commands 'view setCenter' and 'view lookDir'. After setting the view center to (200, 0, 0), then setting view look dir to (-1, 0, 0) changes the view center to (0, 0, -200). I am surprised that there are still bugs in the view code, what a PITA.

    Since the console commands are used to implement the lua lib commands, then the bug should show up there as well. Why didn't the unit tests catch this? Answer: the currently defined unit tests only cover the rbq_lua interface functions, not lua_lib functions. Verified that setting the view up dir to (-1, 0, 0) will also change the view center.

    Traced the code to CSimpleView::SetLookDir(), which does the actual setting of a new direction of the view. Rather than mess with this function, for now, we could just do a hack in CRbqCmdProcessor::Cmd_View() to adjust the view center to maintain it after changing view look dir / up dir. This should be a good solution because it is similar to what setView() in ViewUtil.lua does, where first the look dir is set, then the up dir is set, then the view center is set.

    Did fix, it appears to work. Also, all non-bitmap rbq_lua unit tests are still passing.

    Added 3 steps to Ban-2000 Journal Article Annotation, I think the new scheme will work. It will require periodic enhancement and creation of support routines as the annotation tasks are encountered, but as a result, the work of creating Journal Article Annotations should become faster and easier over time.

    Added a parameter to the AnnUtil.Sim.incInterp() function so that each step in the sim can adjust the amount of time that is needed, relative to other steps. This is still a little ad hoc, use of an explicit real-time value like '2 seconds' would be better, but in general, most steps will involve a constant static delay of a few seconds so that the observer can read the billboard text and the associated graphical highlight events.

    After adding a few more steps, we will be needing RTT functionality soon.

    Adding a Camera to AnnUtil. Done. It's incredibly simple (2 functions), took only a few minutes to do, and it works beautifully. Such a contrast to the struggle in coding camera movements in the first schematic sim.


    Implementing RTT for AnnUtil.Sim. This involves adding a new command menu, 'ann sim', and also, for the first time, a need for C++ code to access data from Lua objects (the Ann.Sim object). I hope this will not be trouble to do.

    After a bit of thought, I realize that it should be simpler than that, all we need to do is a simple lua_dostring() or lua_call() from CRbqCmdProcessor::Cmd_Ann_Sim() and call a function in AnnUtil.Sim.

    Adding code to load a sim at a param step.

    'Goto Sim Step' is working!


    Ironing out bugs in GSS. Previous code used 'sim:getInterp()==0' for intialization ops in tick() functions, but that is skipped in 'goto step N' code, so it needs to be replaced by something like 'sim:isFirstTick()'. Also will rename 'sim:infoDelay()' to 'sim:isFirstInfoDelayTick()'. Over time, a number of subtle adjustments should be added to the step definition in order to better convey the flow and highlighting of information, such as small pauses between information highlighted in the previous step and new information highlighted in the current step. Example: 'sim:isFirstDelayTick()'.

    Proper naming is hard. Trying 'sim:isFirstMatureInfoTick()' instead of 'sim:isFirstInfoDelayTick()'.

    Adding display of interp state in graphics window, should have been simple, but there appears to be a bug in the Billboard display, the text and background quad are out of sync. Arg.

    Ok, found the error, just wasn't noticeable until a bb with enough rows were being displayed, so that the row position error could accumulate enough to be noticeable.

    Working on exp/dev/tst/testBillboard.lua to try to debug the problem, one part of the problem is that the command 'edit delAnnotations' is not truly re-initializing the AnnUtil.Billboard table of boards.

    Added a fix for that where if the Billboard has to create the associated script object, it will also re-init the Board table.

    Did one change of changing the hardcoded char height in CRbqLua.cpp : rbq_GetBitmapTextMetric() from 8x15 to 8x13. That helps.

    After creating a working test of the Billboard to display all chars, it looks like the background quad just needs to be dropped down 3 pixels relative to the text. Not sure why, but we'll just hardcode that in AnnUtil.lua textAreaToPixels(). Ok, that fixed it.

    One annoying effect: display of the interp info every tick messes up the playback rate. With a graphics update every tick, the sim doesn't need the 0.01 slowdown that was done there before, so I might just have the sim.tickStep() function do a redraw every tick. But this is still pretty ad hoc, what is really needed is some code to pace things to a fairly constant frame rate.


    Addding more miscellaneous controls to AnnUtil.Sim, such as 'stop at end of step'. Also creating html control page for Ban-2000 sim.

    More tweaks to to sim controls. One small problem: the camera interp appears to have a slight inaccuracy, the destination point is slightly different from the specified one. This is actually a problem in the Ban-2000 runSim.lua script, and the Sim class, which terminate the step before calling the full fInterp = 1 value.

    The obvious fix is to move the incInterp() to the beginning of every tick() function. Since we are no longer detecting first tick with sim.fInterp value (using sim.isFirstTick() instead, which uses sim.iTotalStepTicks), this shouldn't cause any problems.

    Did it, sim works fine and camera interp is now ending at expected position.


    More work and refinements in schSim. The most recent problem found was in jumping to a late step in the current Ban-2000 sim, the full interp of previous steps didn't work for one of the steps, because instead of using the explicit fInterp value, it used the sim:getInterpRate() instead, which remained at the default small value of 0.01, so only an incremental amount of rotation was done. This was a step that did a 'rotateViewAroundCenter()' call.

    The solution is probably to add another function to the AnnUtil.Camera class and have it do the actual positioning, because it will calculate each position independently, using an interp value. So we must remember to avoid the use of any 'relative movement' schemes that do not make explicit use of the interp value.

    Renamed AnnUtil.Camera.setInterp() to AnnUtil.Camera.setLinearInterp(), added AnnUtil.Camera.setArcInterp().

    camera arc interpolation works!

    Now, we are needing multiple pauses for the events of a step. For example, in the current step 18 of Ban2000 sim, the first thing that happens is to throw up the new billboard describing a new domain, domain II of the 23S rRNA. Then, after a brief pause, the region is selected and appears to the viewer highlighted in yellow. Then, after another pause, the view begins moving, in an interpolated manner, to best show the user the domain. So there are, at minimum, two pauses required during this step, and possibly more will be needed in the future. So, there needs to be a better mechanism than the current 'sim:isFirstMatureInfoTick()'. One possibility is the more general 'isFirstTickOfPause( N )' where N is the Nth time segment defined for the step. Or, instead of pause, would a better name be 'isFirstTickOfSegment( N )'. In addition to the 'first tick' status, there also needs to be something like 'afterTimeSegment( N )', in order to properly call an interp function, only during that segment. A better name than segment is 'interval'. A set of functions should be defined, to do relational calculations of time intervals within a step, although we must be careful that all cumulative operations are performed, no matter how many ticks (and associated temporal locations in intervals) occur, as every step must work properly with just a single tick() call for interp value 1.

    No, interval is no good, because it implies something bounded on both sides. Instead, we need something like 'isFirstTickAtOrAfterInterp()' and 'isAtOrAfterInterp()'. Of course, 'AtOrAfter' is much too verbose, as is 'GreaterThanOrEqualTo'. We could just use 'isFirstTickAfterInterp( N )', but this is dangerously imprecise, implying it should not be true for the value at N.

    Other possibilities: get rid of 'FirstTickAtOrAfter' and use 'isFirstInterp( N )' for the single-shot. For the 'greater-than-or-equal-to', use 'isAttainInterp( N )' or 'isArriveInterp( N )', but neither of these is quite right. 'isPostInterp()' is better, but there still is some implication that it may not apply at the value N. 'isAtLeastInterp( N )' is pretty clear.

    Then there is the problem of how to define the paramter. Is using an explicity numerical value verboten? Probably not, because the relative ordering would be more clear within the step tick() function definition. But then adjusting the value subsequently would be an ultra-hassle. So named constants must be used. Does 'isFirstInterp( sim.fInfoDelay )' work? Seems to, in conjunction with 'isFirstInterp( sim.fHighlightDelay )', but only if we assume that these two delays are always used in the same way, which they are not. Instead, how about numeric labels, 'isFirstInterp( sim.fDelay1 )', 'isFirstInterp( sim.fDelay2 )'? Still not perfect, but better than named delays and numeric values. These values could initially be assumed to be 0.1 increments, and could also be redefined subsequently if needed.

    Ok, I think I'm going to go with 'isGainInterp( N )' for the greater-than-or-equal-to functionl. It's short and the meaning is fairly clear for a temporal context. 'Reach' is clearer, but not as mellifluous. 'isReachInterp( N )'. Hmm, maybe clarity should supercede mellifluousness. Yeah, gonna go with that.

    Arg, 'isFirstInterp()' will be confused with 'isFirstTick()'! Now it must be 'isFirstReachInterp()'.

    To do the actual 'first-time' check for a 'isFirstReachInterp( N )' call, will need to create a log of the fInterp value for each tick() call in the step. Then we would have to count of the number of log entries which have an interp value greater than or equal to the param interp value. This doesn't sound very efficient. That's assuming that the call can't have a side effect. If we allowed the call to have the side effect of setting a hash value, then determination would be easy, but then the call would only be valid once per step. This restriction seems reasonable, but might become a cause of bugs at some point. Ah, just record 'sim.fPrevTickInterp' value. Simple.

    Added function Sim:isReachInterp() and Sim:isFirstReachInterp(), changed delay refs in Ban2000 and it works. Also added some pre-defined delays. However, one thing that is apparent is that only a single interp'd event can be done in any given step. Having two different interp events in a step, such as a linear view interp and an arc interp, separated by 'isReachInterp()' logic, would not work properly for a single full-value interp. So the delays will be used to separate multiple 'single-shot' events in a step, but not multiple 'interp' events.

    Added AnnUtil.Camera:lookAtInterp().

    Ok, the other problem with delayed interps is the 'jerk' that occurs when a camera interp starts at 0.2 and then goes to 1.0.


    Added sim step control functions to html page for Ban-2000.

    Added vUpDir option to AnnUtil.Camera.linearInterp().

    Adding AnnUtil.LineLabels class. This should be very straightforward, basically just copy and slightly modify the AnnUtil.Billboard class to produce an annotation service for producing lines attached to text labels in the 3D graphics window.


    LineLabels are working.

    Working on adding line lables to the 3 protrusions of domain II of 23S rRNA for model chain 1ffk.0. Found a bug in one of the sequence map scripts: SeqMap_23S_Ecoli_Hmari.lua reports that there is no mapped base for E.coli base 'C835', but there is one, plain as day, should be 'G928'. I note in passing that there is no unit test for any seq map scripts on bas/app/rbq/tst/seq.

    This must be a bug in SeqUtil.lua translateMappedBases(). Found the bug, it is due to an implicit string to number conversion for one of the variables. Will fix by doing explict number conversion for the sequence position vars.

    Fixed seq bug. Ran seq test, all passed (but need to define more).

    Almost done defining protrusion helix callout of domain II step, but ran into a weird bug where using a fractional arg to incInterp() caused the camera arc interp to wack out towards the end. Why?

    Looking at arc interp code, I'm really hoping that it's because I am getting the current view up dir instead of the initial one. Substituting initial up dir.

    Yeah! That fixed it.


    Gave demo of program at poster session of Bio-Nano Technology conference yesterday at U of M. Not many people saw it.


    After a brief distraction of the last couple of days working on a new version of my 'origin-of-life' hypothesis (The QCH project: Quaternary Complex Hypothesis), I must get back to work on the thesis and Ribosome Builder.

    Created a new jaa: exp/articles/Carter-2000. This involves loading a new model, and at some point may require alignment with the reference models in std orientation, requiring the usual sequence of operations to create aligned sequence maps and helix files. It would be nice to have an automated process to do this.

    The script 'CreateSeqMap.lua', created 2004-07, does the work of creating the sequence map. I need to add documentation of that to the User Manual. And then, only one other script, GenHelixFileForChain.lua, needs be run. One minor bug needs to be fixed: the current implementation for selecting helices is looking at hard-coded map files listed in SeqUtil. This should be changed to just look for an existing file in the seq subdir. Added helix file auto-naming to SeqUtil.lua function findHelixFileForChain().

    Added some brief explanation of smap creation to User Manual. Testing creation of smap file for 1pns, I note that there is an ASSERT in CFastPdbObj in loading the model. This ASSERT results from an assumption in CFastPdbObj::CreateInterResCovalentBonds() that residue numbering corresponds to the residue order in the pdb file.


    I think the thing that has been hanging me up in writing my thesis is the current lack of the document in some kind of 'finalized' form. The method of defining a set of cross-referenced html files is powerful and flexible, but it lacks a nice, final form that can be read in a way that conveys the linear flow and presentation of the material.

    I want to keep the existing organization form, but I think that I can also achieve working version of the 'final' form by writing a script to process the current html files, in a sequential order as defined by 'next' links at the top of each document, and concatenate the contents into a single composite html file. This can then be read either in a web browser, or in the more traditional word processor application.

    Created script ''. First version was simple to do. It works.

    Finally took the trouble to figure out how to do manual formatting of line lengths in vim: use 'gq', after setting 'textwidth' to desired line length. That ought to save me about 10 million keystrokes.


    Making progress on the 'Methods' section of the dissertation. Finished sections for the low-level libs: Working on the wkGrChem lib. Having to go through source files and looking at the msurf project to remember how I implemented the marching cubes algorithm for CPdbSurfFactory. I wish I had been in the habit of writing a project log when I created the msurf project. There is only a very terse 'history.txt' file. Fortunately, the process is revealed both in the source code and the collection of tools. There is the case viewer lua script, which I was able to run after very minor updates to be compatible with the current lua library. Also a collection of perl scripts for solving the hole-filling problem.


    Starting to figure out what the heck I was doing to solve the hole-fill problem. I had created some nomenclature to organize the hole problem. The 6 cube faces are referred to as Nx, Px, Ny, Py, Nz, Pz. At each cube face, the conditions for a hole are 'inside' condition at two diagonal vertices and 'outside' condition at the other two vertices. When viewing the face from a certain orientation, the edges of the triangles needed to cover the 'inside' vertices would have either a 'Fwd' or 'Bak' slope, where 'Fwd' is a positive slope and 'Bak' is a negative slope.

    Actually, further examination leads me to think that the 'Fwd' and 'Bak' refer to the line connecting the filled vertices, not the triangle edges.

    The hole is at the facial boundary between two cubes. The hole has a direction in that one cube is on the outside of the hole, and the other cube defines the 'inside' boundaries of the hole. The cube on the 'outside' is the 'Begin' part of the hole and the cube on the 'inside' is the 'End' part of the hole.

    Created image 'HoleFill-130-203.bmp', which shows cases 130 and 203 adjacent to each other. Case 130 is an example of a PxFwd_HoleBegin and Case 203 is an example of a PxFwd_HoleEnd. It's starting to make sense.

    After updating the \proj\graphics\chem\msurf\cv.lua case viewer script to examine the hole fill work, getting an ASSERT in wkGraphic lib for CWkGraphicObject.h : 101. This is in the SetName() function. Must not have been overridden in the class that implemented drawing the bitmap text for command 'ann insBmText'. This is a CWkBitmapText object. That's correct, no override for that function in that class, but doesn't really matter at this point.


    Added code to '' script to embed figures. Later, will add more code to put the figures at the end, along with generating list of figures in table of contents.

    Code to add figures works well, after I realized that doing percent scaling in html img tags wasn't going to work. It's better to have the pictures in their final intended size.

    Finally finished marching cube stuff in dissertation.


    Been reading up on VRML and X3D prior to discussing work done on that in dissertation. Found a great article by Tony Parisi, one of the co-creators of VRML and a co-chair of the X3D specification. He talks about the reasons for the failure of Web 3D during the last 10 years, and why he feels that X3D is finally poised to take off in that area.

    Downloaded the latest version of FreeWrl on my linux box (version 1.08 pre 3) and tried to compile it, without success. Didn't want to put much time into it, but it looks like the same problem that I had trying to build previous versions - a bunch of dependencies for other software components that I have already spent too much time trying to co-install and build. It may also be due partially to my 'older' version of linux on that machine (Mandrake 8.1), but that shouldn't really be a problem. Looks like FreeWrl still needs some work in the user support department. That is one area why Ribosome Builder can be considered a success, at least for the platform that is supported. There is a pre-built binary that downloads and runs, with pretty much everything included (although the downloaded file is a little big, as a consequence).

    Downloaded the latest version of the Cortona VRML client (version 4.2) and tried to install it for the Firefox 1.0PRE browser on my WinME machine. Didn't work at first, and then, for some strange reason, after I went to a web site with a VRML plugin detector (, it seemed to 'activate' the plugin, and I could then successfully load and run .wrl files in Firefox, which is cool. It used the OpenGL rendered (DirectX didn't work) and the performance was not bad, although nothing to write home about.

    Did all this research on VRML only to realize that the vrml stuff in the rb project has not been used for a long time, only POVRAY export is currently done. What a dunderhead.


    Finally finished up wkGrChem discussion. Managed to talk a little about VRML so it wasn't a total waste.

    Starting on discussion of implementation of main application (and internal libs).


    Took a break for one day to create the 'tree viewer' app for Russell Parsons. This was valuable, because it resulting in an independent implementation of the Rbuilder CSimpleView mechanisms, but using the glut library and OpenGL for the matrix operations. It gave me an even better understanding of the relation between view transformations and user inputs from the mouse, which has caused me some problems in the past.

    Creating a picture for a camera frame, found a bug in rbq_DrawBlockArrow(): the polys for an arrow pointing in -x dir have incorrect normals. Looking at the code, it looks like it fails for arrows pointing in the -x direction because in wkGLutils.cpp, glxRotateCurrentMatrix() is trying to do a cross-product on vectors 180 degrees apart, which will produce a zero vector. Rather than fixing glxRotateCurrentMatrix() at this time, hacked a fix in CRbqArrow to do a manual rotation. It works. But this fix should be applied to glxRotateCurrentMatrix(), because this function is also currently used in CGrAtmUtil and CRbqForceDisplay.


    After making some good progress, got a little bogged down today in trying to remember and understand the design decision of combining the static and dynamic models within a single CRbqPdbMol object. Read quite a bit through the old project log.

    I think it just kind of 'evolved' that way, starting with the incorporation of torsion graphs into the CRbqPdbMol object, and doing some static model steric analysis with them, and then the force object and dynamic segment stuff being tacked on later. But it seems that it might have been better to design dynamic models as a completely separate collection within the document from the static pdb models, although there would have been numerous redesign issues resulting from that.


    Finally starting on the elongation schematic sim, I am faced with how to actually implement the combined conformational and positional interpolation of the mRNA as it translocates by one codon. In order for the adjacently-bonded residues to maintain a roughly-allowable stereochemistry, we must do the torsion interpolation first, for all residues simulataneously, then calculate the translational and rotational interpolation necessary to re-align the new conformation with the target model.

    Right off the bat, in trying to develop this new interpolation, I am running into a bug in saving and restoring an rbd document. Saved exp/demo/mrnaWrap/model.rbd to a new directory, then on reloading, got an assert in CRbqPdbMol.cpp:3285 and garbage in the location of parts of the dynamic model. Don't have time for this!

    Fortunately, this bug appears to be not repro. A subsequent save and load worked correctly.


    Actually, the bug is repro, if the file is saved after running the movie. This bad news is in good company today.

    In comparing the rbd files for before and after running the movie, the difference is that the after version is only saving 206 out of the 863 dynamic node transforms. Well, looking at the script that loads the demo, it is turning 'single-atom-nodes' off, because it says that the model was created that way. However, selecting and displaying indices for the loaded model indicates that the model has single-atom-nodes. At this point, don't know how much I will worry about it. Need to move on and this appears to be a bug related to that particular flag, which should not be an issue for newer models.

    Exported wrapped model to exp/dev/mrna/interp/wrapped.pdb. Now there appears to be a bug in selecting the backbone of dynamic models. But this bug is not repro.

    Created lua object DihedralUtil.Interp, to do torsion angle interpolation of dynamic residues.


    Created schematic sim html framework for exp/dev/mrna/interp/ project. DihedralUtil.Interp appears to be working when applied to a single residue in the wrapped mrna model. The ssim framework is a useful tool for development of new capabilities such as mrna interpolation. It seems that there is not an existing ForceObject script function to reset force objects to their initial transform. Curious that that hasn't come up. Created simple wrapper function 'resetSelectedForceObjectTransforms()' in ForceObjectUtil.lua.

    For development, looks like we need to 'single tick' to AnnUtil.Sim in addition to single step. Done, and it helps.

    Running into problems, it seems like dihedral angles are being returned instead of torsion angles!!???. Duh, yes, that was the problem (bug in newly-added getFoTorsionAngles() function).

    DihedralUtil.Interp interpolation of all torsion angles of G23 is working. The cumulative effect of all torsion angle changes on the downstream residues is quite dramatic. Of course, this makes me realize that I am interpolating in the wrong direction. G23 needs to be interpolated to U20, not U26.

    Interpolating to angles of U20, there appears to be a direction bug, originating from DihedralUtil.getAngleDiff(), which I just copied from torsionInterp.tick.lua. I don't know how well that script was tested. Another good candiate for unit test development. Currently, the only 'special category' testing that is done is tst/seq. 'tst/dihedral' or 'tst/torsion' would be an excellent choice for the next category. I think that the problem is that getAngleDiff() expects angles in the dihedral range [0, 360] instead of the torsion range [-180, 180]. But, would that really make any difference? Ach, dumbkopff! I was switching the params in the function call. I don't think it does make any difference. Ok, it's working now.

    Now we have to figure out the position transform. Thinking about how to do a '3 atom alignment', I realize that we can do a dynamic residue alignment that is similar to the existing static residue alignment script (AlignSelectedResidues.lua), except that instead of aligning using two subsequent backbone vectors, we use two vectors from the first 3 backbone atoms of the dynamic residue.

    Created script 'AlignSelectedForceObjects.lua'. It works.

    Now the next challenge is to extract the rotation that occurs during this alignment, and convert it to a quaternion, which should allow for a positional interpolation. Reviewed code in exp/dev/simpanel/interp.tick.lua to see how the positional interpolation is done. It works by receiving starting and ending homogeneous transform matrices, along with associated center points, then translating them to the origin, then retrieving the quaterinions for them, then producing a slerped quaternion matrix, then translating that slerped quaterinion matrix to the linear interpolated position between the two param matrix centers.

    The problem with simply applying this approach to the mRNA force objects is that the force object consists of multiple transforms, one for every atom. We need some kind of generic quaterion rotation that can be applied globally to the entire force object.

    I suppose that we could obtain the slerped quaternion matrix and lerped translation matrix from a reference node in the force object, and then apply these two transforms to all node frames in the force object.


    Running into a problem that I'm surprised has never come up before. In CRbqScriptObject::SetValue(), there is an assignment from a param string to a string in a member data string list. In the actual assignment, references are used on both sides of the statement. I always believed that when assigning to a reference, the actual result is that the value of the thing pointed to by the reference is changed. But in this case, the item in the string list appears to be changed to point to the param reference, which is certainly not desired. Very strange.

    No, something else appears to be going on. It looks like something else is modifying the actual contents of the string somewhere. Ok, this is interesting. What is happening is that there was a script object initialization script, exp/dev/tst/testQuat.lua, which defined some vars, using the 'local' qualifier, but at the main level, so that I believe these vars were actually put into the lua global namespace. This script creates a script object with a tick function script, which is run every timer tick. In this tick function script, it calls 'setScriptObjectVar()' at the end of the tick function, to update a script object variable called 'fInterp'. This stores the value in the member data list of the script object, held by CRbqScriptObject. But then, after running the tick script, from CRbqScriptObject::RunScriptFile(), the function CRbqScriptObject::GetScriptGlobalData() is called, to implicitly update modified script object data. And this is where the fInterp variable is set back to the initial value. In looking at all this, it makes me wonder why we have both the implicit update of script object variables done by CRbqScriptObject::GetScriptGlobalData() AS WELL AS the explict 'setScriptObjectVar()'???

    Also, there must be some global 'fInterp' value in the lua global namespace, though I'm not sure where at this point. It seems like the explicit setScriptObjectVar() statements are superfluous in the current scripts. Except in the precise case where we have the 'global' override problem seen here. So what could be done is to remove the 'GetScriptGlobalData()' call in the code. Hopefully, this will not cause any scripts to break. I believe that I have been doing the explicit update of all vars with 'setScriptObjectVar()' for some time now. But not 100% sure it is done for older scripts.

    Ok, commented-out the post-script-run GetScriptGlobalData() call, I don't think this is going to break anything significant, but I will run the demos and unit tests as a check.

    Quaternion-based interpolated rotation of force object G23 to align with U20 is working. Now, just need to incorporate the translation interpolation, and a scheme for doing full interpolation of mrna translocation is starting to take shape.

    Things are becoming clear. What we need is a single function, probably in the GeomUtil module, something like getInterpTransform(), which receives a center point, a translation vector, a rotation, and an interpolation scalar. The function will return a homogeneous transform matrix that will represent an interpolated orientation and position of the center point. This single composite transform can then be applied to a set of force objects. It works!


    Removed ASSERTs from CRbqPdbMol::GetOrdinalDynSegName(). This is because an invalid name can be passed in from the user, so this should be caught be validation. It is not an internal error and should not ASSERT.

    Trying to get position and torsion interpolation of mrna working together in eln001. Currently, when they are both done in a single step, the moving residue reaches correct torsion alignment and correct translational alignment, but the final rotation is not quite right. When the positional interpolation is done in a subsequent step, with full torsion alignment pre-set, the rotational alignment is correct. What's going on?? Ah, I see that I was applying the torsion interpolation after the positional interpolation. Moving it to before.

    That was it! We know have a working combined torsion and positional interpolation for a single residue of the mRNA.

    Starting on multi-residue interpolation. Doing torsion interpolation for 22 residues. It's slow, as expected. We will have to record the interpolation as a movie and do movie playback for the schematic sim, but this shouldn't be a problem. Also, it seems necessary to adjust the setTorsion tolerance, as it exceeeded 0.2 at the 16th increment of the 100 increment interpolation, for residue U31 for some reason. Hopefully, the setTorsion error will not become too large.

    Increased the tolerance to 0.3 and was able to do full interpolation without any additional errors, which is good. One looming problem, however, is that the interpolation of this large segment results in the whipping around of the mRNA chain like a caffeinated rattlesnake. The big question is whether the positional interpolation, applied simulataneously with the torsion interpolation, for such a large segment, will keep it confined within a reasonable boundary of the mRNA path. If not, the entire scheme will have to be abandoned in favor of a force-driven approach. Perhaps, one possible modification that might be done to save the scheme is the use of differential rates of torsion and positional interpolation. Also, another factor might be differential rates of torsional interpolation for different subsegments of the chain. Indeed, the use of such selective constraints, in conjunction with the mRNA path constraint, may serve to shed light on the actual conformational changes of translocation.

    It takes about 4 minutes for the entire interpolation. Will record a movie of it, but this immediately brings up the question of how to drive the movie. Currently, movies are only recorded during forcefield timesteps, but it looks like it is very simple to provide script-based access to the CRbqMovie::TimestepRecord() function, which should probably be renamed to CRbqMovie::RecordFrame(). Actually, looking over the TimestepRecord() code, there is an internal counter variable, m_iTimestep, that is used for variable-rate recording. We could either leave this function alone, and add a separate RecordFrame() function, or generalize the m_iTimestep counter to a m_iTick counter. This further indicates that the function should be renamed TickRecord(), because RecordFrame() implies that every frame will be recorded, which is not the case. Tick-based recording and playback seems like a good generalization over Timestep-based actions, but we must be careful not to introduce bugs or problems at this point. I think it is safe, because it is basically a rename, in conjunction with the opportunity for calls outside of the timestep function. Well, there is code outside of the timestep block in the timer event function in CRbqMainWindow that references movie state, so perhaps we should use a single function instead of the potentially confusing duplicates of TimestepXXX and TickXXX. There are only a few references to the movie object, so it should be pretty safe. But, there is the problem of having duplicate frame recording per timestep if both the script-based and timestep-based recording are done. So perhaps, we should just provide additional functions. No, the movie object should not have to know or care about timesteps vs. ticks. Changing the CRbqMovie terminology to use the name tick instead of timestep. Done.

    An alternative would have been to try to disable objects in the forcefield, and timestep the forcefield, but this perhaps is too much trouble?

    Added rbq_TickPlaybackMovie() and rbq_TickRecordMovie(), but rbq_TickPlaybackMovie() is superfluous, because movies are played back every tick independently of the forcefield timestep. Removed rbq_TickPlaybackMovie().

    Great, movie recording is now broken, complaining about max file size. Fixed, was an unrelated bug. Also added code to update movie toolbar icons, which for some strange reason were not being updated previously.

    Finally got a movie recorded for the full chain torsion interpolation. Unfortunately, from the way the chain tail whips around, there is no way that it is going to stay in bounds, even with position interp (I'm pretty sure). This is unfortunate, as it is a big blow to the entire scheme. And the selection interpolation, on the face of it, may severly complicate the current implementation. However, one thing that needs to be done is to verify that the final interpolated conformation does properly overlap the upstream codon. A quick manual alignment indicates that it does. What might be really interesting would be to try to apply torsion-spring forces on the mrna in conjunction with a linear shifting force and static steric boundaries from the 30S.


    So now the question is whether to use the existing torsionSpring.lua script, in conjunction with the interResSpring.lua script, to promote the codon translocation, or to implement a new version using the AnnUtil.Sim framework. The torsionSpring script already exists, and has been tested, but its method of data transfer is awkward and may impose a significant performance penalty. I think the way to go is to setup an initial SMD sim using the existing scripts, then, while running, work on a new version using the AuSim tools.

    Did initial sim of torsion springs for 3 residues and forcefield sim for all residues in chain and got good torsion alignment after less than 100 movie frames, so the torsionSpring approach may be feasible.


    Tried to run the 'shift mRNA' sim using the 'exp/dev/mrna/interp/soShift.lua' on the fast Alpha64 machine in the lab, but the machine repeatedly crashed while running the Ribosome Builder program. Developed the dsInterResSpring.lua script to drag dynamic residues to static residue targets. This script, in conjunction with the torsionSpring.lua script was used to successfully produce a translocating mRNA on Drew Kearn's fast machine. Ran several sims to find the optimal amount of friction and shifting spring constant.


    Finally figured out how to kill the incredibly annoying DDEHELP process that has been slowing down the WinME system on ribomachine4 for the last 3 1/2 years (all I had to do was to just run the MSVC 6.0 ProcessViewer).

    Prior to more work on exp/sim/eln001, tried to review the simpanel initiation and elongation sims, but they are not working now. They do not appear to be ticked. Ah, perhaps they are casualties of the recent removal of implict ScriptObject var saving. Yes, that is it. The script is doing 'setglobal()' instead of 'setScriptObjectVar()'. I forgot to check the usage of 'setglobal()' in existing scripts.

    There are 311 occurrences of 'setglobal()' in existing scripts. Nearly all of them must be changed to 'setScriptObjectVar()'. This is complicated by the fact that the caller must know the name of the script object. A new function could be created to ease this requirement, as the context would already know the name of the current script object. Adding setCsoVar() function.

    Ack, implementation of this capability is not simple, because script object event functions are called by the main program in a variety of places, not by CRbqLua. ie: Tick(), FiTick(), Draw(). It would require saving the ptr to the current script object, which is actually referenced as a time-user by the main application. Messy. Either way, in the main code, or in the scripts, there must be a way of saving a reference to the script object associated with the script.

    Ok, changed my mind. The rule is, don't mess with the core app code for this, hack it up in the scripting code instead. Will have to go through all the scripts that need persistent data and save the name of the script object itself as a persistent script object var. It is kind of like a 'this' variable for C++ objects.

    Added 'setScriptObjectVar( getglobal( "sSoName" ), ... )' to multiple script object event scripts, but not all. This fixed the currently-broken rbqlua unit tests, as well as the simpanel objects. The rbqlua unit tests are passing now.

    Simpanel interp is working, but camera and billboard objects are not working. Ok, fixed them. It's tricky though, because of the mixed usage of setglobal( [var] ) and setScriptObjectVar( [sSoName], [var], [val] ). setglobal() gives the var persistence at the script file level while setScriptObjectVar() gives it persistent between different executions of script files.

    Check Rbg game, it still works.

    Got final mRNA SMD translocation sim on inga, after adjusting the shift and dsIrs force constants to produce a more synchronous linear and torsion transition. The final result looks good.


    After housekeeping and completion of translocation movie yesterday, started in earnest on the eln001 schematic sim. It is going very well. The new scheme is a pleasure to work with, in comparison to the previous frameworks. The most gratifying thing is having full control over the view, graphical display, model positioning and captions when trying to compose an informative sequence of events.

    There is a bug in the camera arc interp. When doing the full interp for jumping to the next step, the view comes out wrong. The incremental interp works, though.

    Ok, figured it out. The problem happens when setting the optional look dir in the AnnUtil.Camera.arcInterp() function. The look dir is set, but no corresponding up dir is set. When the look dir is changed incrementally, the up dir is mostly retained, but when a large change in look dir occurs, the previous up dir is lost. So the solution is to set the look dir, then set the initial up dir, then set the look dir again. That was it. Fixed.


    Prior to adding Ternary complex to eln001 sim, reading up on EF-Tu and aatRNA. Never really looked hard enough at the tertiary structure of tRNA and correlated it with the secondary structure. Added script 'SelFeat_1tra_stmlp.lua'.


    Looking at various models of EF-Tu that can be used for eln001. Also, thinking about how to show structural differences between models, I realize that it would be pretty simple to create a script to highlight divergent residues for two aligned models. This would be useful to quickly see differences between large models such as 1fka and 1j5e. One current problem is that we need to add sequence and structural alignment support for proteins.

    Was lucky to find the (Nissen, 1995) paper for 1ttt vi UM ASP, wasn't available online through Science.

    Continuing with eln001, started on showing existing interaction between codon and anti-codon in P-site. I see that the alignedment of the bases for the codon of the 'wrapped mRNA' are not correct (they are not in-plane with the anti-codon bases). I tried doing some manual adjustment and then saving out the adjusted dynamic model as a PDB. But when I re-inserted this adjusted PDB and created a new dynamic model for it, the movie does not playback all of the nodes correctly for it, some of them are obviously out of alignment. Not sure why. The most immediate solution is to adjust the initial wrapped dynamic model and then re-run the translocation SMD sim for that.

    Added jumping to AuSim step by name. This require small changes to the htsrv url decoding to allow cgi params with spaces to be passed to the main app.


    Finally adding the ternary complex to the eln001 sim. It seems to have taken a long time just to get to the point almost to where the sim panel eseq001 sim was (TC dock, decode, accomodation). 15 steps completed so far in eln001 sim. It looks like we have most of the tools that are needed to do this sim.


    Working on 'exit Pi' step in eln001. Found a weird bug in the program doing the command 'pos sel resetTransform' with just eftu_pi pdb selected, the command caused every pdb transform to be reset. Fixed.

    In creating the steps of the schematic sim, a common but tedious operation is to shift from one viewpoint to another. I have manually defined a two-step process, where the view look direction interpolates from one point to another, then do a linear interpolation from the first view center to the next view center. But it should be possible to define an AnnUtil.Camera() function to do this automatically, after being given the begin and end view settings.

    Creating AnnUtil.Camera.viewInterp(). After creating initial version, there is a problem. I thought that I could create a 'dummy' lookAt point for each view, which I did by projecting the view center out one unit along the view look direction. But this dummy point doesn't work well as a 'destination' look point for certain view interpolations where the view centers may be fairly close together. It almost seems as if it is necessary to require an 'explicit' look point, in addition to the three view vectors.

    Taking another look at the viewInterp(), found and fixed a bug, so that it appears to work better now, although the short projection distance seems to give a non-linear shift for the lookat phase. Trying an extended shift point. This works better. The only other tweak needed seems to be an Up dir arg for lookAt interps. Added that, it works! The view interp is a success, at least in this particular case. Hopefully, it will accelerate the sim development. I have noticed that smooth camera transitions are very important from an aesthetic standpoint.

    The only question that I have about the viewInterp code is the arbitrary distance used to produce the 'dummy' lookat point from the view center and look dir. Now, I am wondering if there is a simple rule for producing the shift value by making it on the order of the distance between the begin and end view centers? Will try for now to simply make it equal to this distance. Did this, and again, it works well in this case at least.


    Added 'reverse' option to view interpolation, it works. The reverse option causes the linear interpolation to be done first. This allows for a view interpolation that is the inverse of a previous one.

    Finally staring on peptide bond formation in eln001. In so doing, I notice the failure of inter-residue bond creation between the terminal A76 and the PHE residue in 1ttt_AG. After reviewing the code in the wkFastPdb lib, I supplement the covalent bond creation discussion in the thesis by noting the current limitations (only na-na or aa-aa interesidue bonds are currently supported).


    For peptide bond formation, we need some way of showing removal and creation of covalent bonds. Ideally, there would be programmatic control of covalent bonds in the program, but there is no time at present to add this capability (it is not certain whether that would be a good design choice either). The best solution that occurs to me is to create an annotation to produce the appearance of a covalent bond between two atoms. This should not be too difficult to implement, because of the existing function CGrAtmUtil::DrawHalfCovalentBond().

    Added rbq_DrawCovalentBondImage(). This was very easy to do. However, the schematic sim needs persistent drawing of the bond image between steps. It would be messy to include the call in every step, so this motivates the creation of a script object to draw such bond images, using dynamic residues as data sources.

    Created DrawDynResBondImage.lua script. While about to test it, ran into a new problem: creating individual dynamic residues for 1ttt_D.D.A76 and 1ttt_D.PHE77 results in terminal hydrogens added where we want to display a 'fake' bond. Need to have some way to suppress this hydro creation. This will require modification of core code, unfortunately.

    Also, this script has revealed another limitation in the current implementation of dynamic objects. When adding hydrogens, only a generic 'H' is added to each hydrogen atom name, so the names are ambiguous and the call 'getObjectIndexFromName()' will fail for hydros. This should be changed at some point in the future by adding a specifier to the hydro names, such as appending the atom index to it.

    The script also revealed a bug in rbq_GetObjectIndexFromName(), which specified that the segment index is returend for dynamic object names, but instead, the multi-hierarchy chain index is being returned instead. Before doing the fix, I checked to see how many lua scripts are currently referencing this function, or its wrapper, getObjectIndexFromName(). Fortunately, only a few scripts are currently using it. There actually was a unit test that tested this function for dynamic names, but I implicitly coded the wrong expected value that corrected for the bug (specified the multi-hierarchy chain index value instead of the segment value).

    I'm thinking that perhaps I should change the spec instead of actually changing the code, because the multi-hier spec is what is actually required for doing object selection, and changing to implcit conversion to segment number could equal or greater confusion and failure for users that tried to use the index for object selection. Done.

    DrawDynResBondImiage.lua script is working. Now, just need to suppress specific hydro creation (or display?) for dynamic residues. Fortunately, there is already a flag parameter infrastructure for force object creation, so hopefully, the additional spec won't be too much trouble to add.

    Added flag '-xh<sAtomName>.<N>' to 'ff fo create'. It works!


    As ever, the change yesterday has introduced a new problem. When saving a document that contains a dynamic model that was created using the new '-xh' exclusion flag, and then reloading the document, there is currently no information in the document to reproduce the creation of the dynamic residues using the exclusion criterion, and so the document ends up with a different number of dynamic nodes from when it was saved, which causes problems when reading the saved node transform data.

    The immediate solution that occurs is to save the 'ff fo create' flags that were used to create the models with the document. However, this is not simple, as multiple creation commands can be done to produce the dynamic residues of a document. That won't work. However, a modification of that is to concatenate all '-xh' exclusion flags in a list, and save this combined list in the document file. This force object creation option problem is reminiscient of the troublesome 'singleAtomNode' creation option of the past.

    Another option is to just ignore this problem, as it currently is only used for very specialized bond making and breaking representations in the elongation schematic sim, and is not expected to be used very often for general SMD simulation in the future, although that may change.

    However, since the exclusion flag info could be saved as client data outside of the main force object data section, it could be done without breaking compatibility with existing rbd files. Change has been made, it works and does not appear to break older rbd format. The new client data tag is 'Doc_FoCreateFlags'. Updated rbd doc version to 3.1.

    Did alignment of PHE amino acid residue with formyl-methionine residue of 2fmt.D. One problem: after doing the alignment of the PHE as a dynamic residue, which was necessary because it required some intra-residue rotations, there was not a good way to save the transform state of the dynamic residue. Instead, exported it to a static pdb file.

    After aligning the amino-acids on the terminal nt residues of 1gix_B and 1gix_C, it looks like there is a steric clash between PHE77 and 1gix_C.A76. The question is what to rotate. (Moore, 2003) mentions that model 1fgo can be superimposed on model 1m90 to give aligned residues. Fig 1 of the (Moore, 2003) paper shows a completely different alignment of p-site A76 relative to a-site A76. If we align 1gix_C to 1gix_B using residue U17, the middle portion of both tRNAs has very good overlap, and there is significat divergence at the 3' ends and the ASL.

    It will be necessary to download and create sequence maps for the 1fgo and 1m90 models. Loaded model 1m90 and got a select buffer overflow when clicking on one of its residues! This was when it was loaded with the models of eln001. Loading it by itself, didn't get this error, but I need to check the OpenGL selection stack allocation and increase it. Oh, now I get it with the model by itself as well.

    Looked in code for CSelectionController::DoMouseSelection() and I see that the size of the select buffer is only for 512 objects! It is easy enough to increase this, the question is by how much? Increasing to 32767. Currently, this buffer is allocated on the stack. Should it be allocated statically? Or is that large stack size acceptable? Check VC 5.0 ref, mentions that the default stack size is 1MB, so this should be ok. Read a post on usenet suggesting to avoid a fixed limit like this. At some point in the future, when sure of where the performance bottlenecks are, I could dynamically allocate a selection buffer after calculating the maximum number of objects that could be selected.

    That buffer increase appears to have fixed the buffer overflow for 1m90.

    Great, another problem. Trying to create a sequence map between E.coli.23S and 1ffk.0 is causing globals.exe to crash! Why!?? It used to work! Didn't it? Used to use clustalw, but I think after switching to globals, I have done 23S rRNA alignments? Arg. globals is first mentioned in the project log on 2003-10-12. All the E.coli.23S* file dates in the seq subdir are 2004-04-28. Looking in the seq subdir of the older rbq project gives the newest file date for E.coli.23S* as 2002-09-30! Could it really be that I've only done clustalw alignments on those?

    Maybe it's just a dumb limit on globals that I can recompile. I hope so. Will have to debug tomorrow.


    Good news, the globalS crash was actually due to a badly formatted E.coli.23S.seq sequence file, it was not in Pearson format for some reason. Ok, that fixed the globalS crash. But now genSmap.exe is failing for some reason on test map for E.coli.23S and 1ffk.0. Ah, it's because there were numbers in the E.coli.23S.seq. Ok, alignment with 1ffk.0 is working.

    Now, the script 'GenHelixFileForChain.lua' appears to have problems with file names. I will simplify it. There are some horrible inconsistencies in the _SeqUtil.lua code when it comes to assuming whether a filename referes to a file in the 'seq' subdirectory or whether it is a relatively-qualified pathname ('seq/' added). I'm tempted to make all filename parameters treated consistently, that is, assumed to refer to a file in the 'seq' subdirectory. I'm a little worried about breaking existing script, though. But, we have unit tests for seq operations, so I'm going to do it.

    Done. Also took the opportunity to add creation of a 23S .smap file to the Seq unit tests. One minor problem that shows up with the script 'GenHelixFileForChain.lua' is that it appears to slowdown when processing the higher helix numbers, I think the current implementation is very inefficient and needs to be improved.

    All Seq unit tests pass with the change. Finally got a helix file generated for 1m90.A, but either the sequence is very divergent or the alignment is very poor, because only half of the helix definitions were created. The possibility of sequence divergence seems unlikely, because the species is H. marismortui, the same as 1ffk. For 1ffk, 81 helix definitions were generated, compared to only 49 for 1m90.A. Will have to look at the sequence alignment between these two. Looking at 1ffk.0-1m90.A.aln, the alignment has a score of 2866, and seems very good except for 12 gaps, so this seems very suspicious. Need to check E.coli.23S-1ffk.0.aln vs. E.coli.23S-1m90.A.aln. Checked, the E.coli.23S-1m90.A.aln alignment actually has a higher score than E.coli.23S-1ffk.0.aln! (1996 vs 1964). Strange. I suppose it is possible that the misalignments for E.coli.23S-1m90.A just happen to fall on more helix endpoint residues than E.coli.23S-1ffk.0. One good test would be to modify the 'GenHelixFileForChain.lua' script so that it can use any .hlx file as a reference file. Oh, it can already do that. Ran it using 1ffk.0 as the reference, and got 81 helix definitions. Much better. Added that option to the discussion of helix file generation in the User Manual. Done.

    Successfully ran 'FindBestHelixAlign.lua' to give excellent RMSD 0.220 alignment between 1ffk.0 and 1m90.A using helix pairs (21, 35).

    Ok, after aligning 1m90 to 1ffk in the eln001 sim, it looks like the A76 residue of the CCA dervivative of 1m90 is in the right orientation for peptide transfer. It is rotated back into the interface, relative to the A76 residue of 1gix_C. No, I'm wrong. The p-site aa is too far away. This must mean that the a-site A76 of 1gix_B is also wrong. Need to check the pdb model 1fgo also, as mentioned by (Moore, 2003).

    There must be some mistake in the Moore article, 1fgo is a lipoxygenase that doesn't appear to have anything to do with an A-site substrate. Yeah, it's 1fg0. Ok, downloaded 1fg0, this is going to be a little more work because it's just a small RNA fragment of the 50S and the existing helix alignment scheme may not work (but, then again, it might). Actually, it was easier than that, just used the 'AlignSelectedResidues.lua' script using 1ffk.0.A2517 and 1fg0.A.A2517. The alignment of helix 89 looks very good from that.

    The alpha-amino group of the CCA chain of 1fg0 is almost positioned to attack the carbonyl carbon of the A76-FME77 ester bond, but doesn't quite seem within vdw contact as mentioned by Moore. By aligning and rotating the 1gix_B.A76 and aa.D$.PHE77 residues, however, we should be able to get a good enought model for peptide-transfer. It might be worthwhile to do an SMD simulation of the full A-site tRNA and pull the alpha-amino atom toward the carbonyl target atom.

    Well, this really sucks. I've got a reproducible crashing bug in release mode only. Happens when I load sim eln001 and then drag and drop pdb model 1m90 onto it. Crashes during load.

    A little runtime debugging indicates that it might be due to an uninitialized variable. Doing a load of the 1m90 file first, and then new doc, and then sim followed by 1m90 doesn't crash. Oh, one thing that I forgot to do: delete the bld directory and rebuild (already tried rebuild all after reboot, but sometimes a clean build makes a difference).

    Nope, it's fully repro after reboot and clean rebuild. Did a full rebuild with WARN=W4 param, checking C4701 warnings (local variable 'XXX' may be used without having been initialized). Checking. I now see one downside of returning data via param references, these are flagged by C4701.


    Trying to do some printf-type debugging with the 1m90 crashing bug, although I don't really have time. One possible issue is that the script object code is constantly being called during file loading. One cheap hack might be to suspend script object ticks while a file is still loading. It might make this current bug go away, but not necessarily fix the actual bug.

    The file load complete and Cmd_Exit() return is reached before the crash. Well, this may be some kind of timing Heisenbug. Putting some triggered printf-type statements around the tick call, after file load, it doesn't crash anymore. I think for now, I'll just do that tick bypass during file load thing.

    Did that and it doesn't stop the crash. Modified all the makefiles to build debug version with /O2 and without /ZI and /GZ, but the bug still doesn't happen in debug version. I think it's time to leave it for now.

    Well, I couldn't leave it just yet. I tried a few more sprinkles of my dbfl() printf debug macro, and the crash is definitely dependent on the number of these calls after file load. Doing 4 or more of them suppressed the crash while only 3 allowed it, telling me it may be time dependent, perhaps involving a temporary object. Also, the actual error is 'runtime error R6025', which research on Usenet says can be caused by a bug in the VC compiler that fails to catch an illegal construct in C++ of constructing a derived class that fails to override a pure virtual function of its base class. This only occurs when the constructor statement is combined with the member function call, as in B().vFunc(), where B is the class name of the derived class and vFunc() is the pure virtual function of its base class.

    More research on Usenet shows this to be a rather infamous and horrible Microsoft-related bug, so maybe I shouldn't feel so bad.

    Wow. While searching google for discussions of this error, I find this very same project log, which discusses a previous crashing bug with this error, on 2004-04-27! Go figure. Unfortunately, I find no subsequent discussion of resolution of this bug. However, the script mentioned in the context of the bug appears to be working now. Ok, I give up for now, I need to get this sim done.

    Ok, I'm still debugging it. It definitely seems to have something to do with the script object tick event, because I can load the 1m90 file with script object tick off, then turning the tick on causes the crash. dbfl() statements show that the crash will happen before the 2000th iteration of the time user ticks, and interestingly, the counter increment must be done inside the tu iteration while loop.

    If I delete the AnnUtil_SimDriver script object, it doesn't crash. However, after adding code in the Ann_SimDriver tick script to log post load '1m90' ticks, it will still crash, even if the tick script just returns after logging, so that eliminates any specific bugs in the sim code itself. It's a bug that is very sensitive to memory context, also, as loading 1ffk before loading 1m90 will avoid the crash. I need to just let it go for now.

    Submitted the bug to the rbuilder bug database on Sourceforge.

    Ran all rbq-lua unit tests, all but two graphical tests passed (ok). Ran eln001, it worked up to the final step, translocation of mRNA, which was messed up because of additional force objects in the force field, which make the playback of movie coordinates become out of sync. This is a problem that must be addressed somehow. Deleting the additional force objects won't solve the problem as it will cause deletion of the mRNA (though I supposed it could just be recreated on the fly. That is rather a kludge, but may go with it at this point.


    Starting on an SMD sim to align the terminal residues of 1gix_C with the CCA chain of 1m90. It is a 6 nt dynamic segment with the terminal G71 residue locked in position. It appears to be working well, and runs fairly quickly because of its small size. However, also need to drag the backbone atoms to the target static residues as well. Created script 'initDsInterResSpringsFromFile.lua'. Max angle deviation was around 6 degrees after 188 frames (about an hour of real-time comp on ribo4). Next: re-run with ds springs.

    One problem with the existing dsInterResSpring.lua script: There is no backbone phosphate for 1m90_cca_std.5.C9074. We need to specify a different atom target. Could add an explicit parameter, but this might break existing scripts. Another option is to just modify the existing code so that if the bb atom is not present, it uses the first available atom instead, and then expects existence of corresponding atom on the dynamic residue. In the future, a more general-purpose script could be developed, using full atom names instead of residue names?

    Changes done, dsInterResSpring script appears to be working. Changed default lin and rot friction from 1 to 5, as done in mRNA translocation SMD sim. The inter-res-spring forces were added to the existing torsion spring sim, after the torsion springs had reached a target configuration where the maximum angle deviation was around 6 degrees. The inter-res-spring forces brought the src and target atoms almost completely together, but not quite (need to add recording of max distance to dsInterResSpring script object). The updated SMD sim was run up to 350 movie frames. Playing back the movie, the sim appears to still be converging, will probably run it a little more. One like reason for the slow convergence is that that the locked anchor residue is only 3 residues away from the driven residues. Could try a future sim with one more dynamic residue, but the current config is probably close enough to the starting configuration for the PTC sim.

    One problem trying to export the results of the sim, the current implementation will only export a dynamic selection to PDB file, ignoring an additional static selection. This is annoying. But, after a brief look at the code, not going to mess with it at this time. Will just do a manual concatenation of separately exported static and dynamic files. There should be some nice python pdb utility out there that is already able to do that.

    Bug: current movie file appeared to be deleted when force objects were. No, not a bug if the current movie file is still the default movie file. However, need to put a warning dialog in there. Done.

    Re-running the 1gix_C_aln_1m90_cca sim with a longer dynamic segment, just for fun (8 residues). One point to consider for success of convergence is whether the target configuration has slightly different bond lengths from the starting dynamic model. I believe that even very small deviations in bond lengths would make it very difficult to get close convergence. Also wonder how this factor might count against the 'shadow-point' covalent bond method compared to the conventional 1-3 angle springs? (I'm thinking that the shadow-point method may impart a strong bias against changes in bond length, relative to the 1-3 AS method). At the very least, I should run some scripts to compare the bond-length geometry between the two.

    Set lin/rot friction back down to 1 from 5 at frame 60 in new 8-dyn res cca sim. The sim is not converging. The central residue phosphorus atom looks rather tweaked. I might turn off the dsIrs and first see how well the torsion targets can be achieved. Playback of the movie is interesting. The ds springs pretty much lock down the positions of the 3 terminal residues. Then, it seems as if the torsion springs are slowly torquing the backbone towards their target conformations, but in so doing, you can see how the undriven upstream residues backbones are also be torqued. It conveys the impression of a highly-rigid chain of rotatable links that strongly resists out-of-bond-axis bending and twisting, which is the expectation.

    Looking more at that 'tweaked' phosphorus atom of residue 1gix_C.C75, I see that it was tweaked to begin with in the static model! It's way off from a tetrahedral configuration. No wonder the damn thing has a hard time converging. This is another drawback of the 'shadow-point' model, its dependence on the starting geometry as as a reference, as opposed to an internal potential energy function. We really need a good 'initial geometry' evaluator before converting static models to dynamic ones.

    A number of those bond angles in 1gix_C look a little strange, but at this point, I must not waste too much time investigating and addressing that, must get this first draft of the eln001 sim done! Just need to put the appropriate caveats and qualifications in the description of it.

    Biopython and its PDB module look pretty good, and I really want to get into python and use it, but at this point I think it would be faster for me to whip up my own PDB serial renumber scheme to combine the static and dynamic files. Created script 'app/rbq/tools/pdbTools/'. It works. Used it to renumber 1gix_C_aln_1m90_cca.dyn.pdb and then append that to 1gix_C_aln_1m90_cca.sta.pdb to produce a full tRNA model with the stem aligned to 1m90 CCA chain.


    Updating the pdb and chain name referencing in eln001 sim to make them more general. This was done because a new model, 1gix_C1 is being used instead of the existing 1gix_C model for the p-site tRNA, and I'm sure that this is just the first of numerous model name substitutions that will be done.

    Started looking at the existing mRNA model in eln001 to try to improve it, especially the base pairing between codon and anticodons. One thing I realize is that the 1gix_C model of the p-site tRNA isn't going to work very well because it is for PHE, with anticodon sequence GAA, while the mRNA has the AUG start codon in the P-site. So, aligned 2fmt_D with 1gix_C at residue 34 and considering doing an SMD sim to align the 3' ends. Then, with the tRNA aligned, can do an initial SMD sim to align the wrapped mRNA codon bases so that they hydrogen bond with the anti-codons.

    Did a quick attempt to create dynseg for 2fmt_D, right away ran into a problem with the 4-thio U residue 8. But that should be fairly easily fixed by hard-coding some dynamic residue bond definitions for that. In the future, there needs to be a good runtime way to support creation of dynamic residues for non-standard static residues.

    Added the S4U pdb residue type to CPdbRecord, but dynamic segment creation is still failing because an inter-residue bond between the static residues 2fmt_D.D.S4U8 and 2fmt_D.D.G9 was not being created. Inspection of the pdb file shows that for the S4U8 residue, the ' (single-quote) symbol was being used to designate ribose atoms instead of '*'. This is another limitation in the PDB parsing code that must be addressed at some point. Will make a note in user manual about it, then move on.

    Ok, manually change ribose designators in 2fmt_D. Now the S4U8-G9 bond is being created. Now dynamic segment creation is failing for 2fmt_D.D.U17. Ok, it looks like it is one of those 'alternate resolution' kind of residues that has two different candidates locations that the modellers include for some reason. Ok, I'm just going to chope one of them outta there and fix it up. Cut out the first res of U17, converted the second one, along with U16, to dynamic residues, then rotated backbone bonds until the 3' OH of U17 lined up with the P of U18. Then, exported the atoms for the dynamic models, renamed the serial numbers using the '' script, and pasted them back into 2fmt_D1.pdb. Finally, can successfully create full dynamic model for all 76 nucleic residues of 2fmt_D1.


    Did an overnight SMD sim of 2fmt_D1 tRNA on inga. The dsInterResSpring.lua script successfully aligned the 3' arm of 2fmt_D1 with 1gix_C1 (whose arm was previously aligned with 1m90 cca). 2fmt_D1 initially had been aligned with 1gix_C1 at residue 34, which was locked down during the sim. The alignment was done with lin and rot friction set to 5 and the dsIrs fMaxForce reduced to 100.

    Although it is good that the arm was successfully aligned, some of the hydrogen bonding observed did not appear to be as correct as expected. This is a long-existing issue. The current design of the rb forcefield hbond function places a strong emphasis on very strong linear bonds between donor and acceptor. Comparing the strong linear bonds that formed with the initial configuration of 2fmt_D1, in a number of cases it seemed that the bifurcated hydrogen bond vectors on amino hydrogens and the bifurcated nbe electron vectors on oxygens interacted in a more meshed manner, so that the bonds were not linear, but acted more electrostatically perhaps.

    This led me to consider reducing the linear component of the hydrogen bond function relative to the electrostatic component. Looked at the code and I see that the ff param 'hbondScaleForce' only applies to the linear component, as expected. Perhaps it should be renamed 'hbCovalentScale', to match the 'hbElectroScale' parameter name. In any event, this separation of scaling parameters allows for the covalent portion to be reduced relative to the electrostatic portion, as desired. I think I will do a quick ahelix sim to test the 'covalent-hbond-only' force.

    Started sim on inga, it seems to be working. One problem: noticed a bug where the terminal residues in newly-created dynamic segments are not having hydrogens added. Also, there is a bug concerning some of the ff params in that there is no command to set or view them. Added command 'ff caElectroCalcEnabled'. Re-organized ff commands so that the ff param commands come first and are in alphabetical order.

    After 600 frames of the ahelix sim with hbelectro only, it looks like that might work, but we absolutely have to find a way to stop the sp2 amino hydrogen and oxygen nbe vectors from rotating out of plane. It's a significant change, and runs the risk of breaking things at this late stage, but I think we just have to do it because the exiting rotation is just wrong wrong wrong.

    Added function CRbqNodeBsjForce::CalcSp2TerminalTorsions(). For the sp2 tt oxygens bonded to the phosphorus, I'm not sure how to calculate the right plane, so will skip them for now. For sp2 oxygens and nitrogens bonded to a non-phosphorus atom, for now we will assume that that atom is bonded to two other atoms that define a plane which is coplanar with their bonds.

    Created script exp/dev/tst/testSp2tt.lua to test calculation of projection of terminal oxy nbes onto bond plane. There is a bug in 'DrawFoTorsions.lua'. Tracked it down to ForceObjectUtil.lua function getPrevForceObjectInSeg() where the param force object index table held indices that were string values instead of numeric values, so the range comparison failed. This 'string' vs. 'number' type is another potential source of bugs in the lua lib that needs to be addressed. Added number conversion to that function, but the problem surely exists in others.

    Actually, in this case, what is really needed to validate the force object index. Created ForceObjectUtil.lua function 'isValidForceObjectIndex()' and supporting functions. 'DrawFoTorsions.lua' bug is fixed.

    Checked in changes, rebuilt release ver, all rbq-lua tests except for 2 graphic tests pass. Started work on calculating sp2 oxy terminal electron projections.


    sp2 Oxy terminal torsion torque is working! Starting on sp2 nitro. Done. It took but a paltry moment. However, it's not currently working on test residue 1tra.a$.G4 because for some reason, the test atom N2 atom is bonded to the plane atom C2 where C2 seems to be having 5 bonds! Doesn't seem right. Did a force object report, which only shows the 4 expected bonds. Oh, no big deal, just an atom indexing bug. Fixed. Sp2 Oxy and Nitro torsion forces are working.

    Built release version 0.3.4.pr2, installed on inga and started running the 2fmt_D1 - 1gix_C1 tRNA alignment sim, using the new forcefield, but I should have just run the ahelix sim instead. Also running the tetraloop folding sim exp\dev\tetraloop\tlUffo.lua on ribo4, just to verify that the torsion spring script still works as expected, as I made some minor changes to the DihedralUtil.lua file the other day while debugging the 'DrawFoTorsions.lua' script. Gotta get those lua lib unit tests happening.

    Also thinking more about the current hbond force function. Now that we may have a good electrostatic component, which works in conjunction with vdw steric limits, we may not need the previous and more complex composite hbond function that used shadow points. Also, some things need to be cleaned up in that. There is the existing kludge of multiplying the fractional potential value (modified by the directional alignment factor) to the force value, that definitely needs to go. Then there is the question of how to apply directionality to the electrostatic component, as well as updating the 'max donor' var of the CHbondAccept object, so that there can be a graphical 'dotted-line' display of strong hbonds, that kind of visual feedback is very valuable. However, we can't use the fraction of the theoretical max of the elst hbond function, as that is infinite. Instead, I think we need to create a pseudo fractional potential value for updating the max donor. Something like using optimal linear alignment multiplied by optimal donor-acceptor distance?

    Arg, I forget that there needs to be TWO scripts run for the tetraloop sim, tlUffo.lua and tlTorqueS12a.lua I see that there is a single driver script 'tlDriver.lua', but it looks like this uses the older tlRestrain.lua script instead of tlUffo. Oh well, I need to run the ahelix sim on ribo4 anyway. AND update the max donor thing.

    Made the changes. The best thing was moving the calculation the fractional potential outside of both the electro and shadow-point components of the function. In that way, we don't have to worry how component fractional potentials would be calculated and combined.

    It seems rather crazy to be modifying something as fundamental as the hydrogen bonding force function at this late in the game, but that's life. If we can get a decent ahelix sim, it will be ok. There is still that weird 'terminal dyn residues lacking hydrogens' bug that needs to be looked at.

    It's nice seeing the dotted lines back for hbonds, but now there are faint dotted lines to the other nbe pair on the sp2 oxys. They look a little weird. Of course, we can just up the min draw threshold. Changing inactive and active thresholds to 0.75 and 0.9 (from 0.2 and 0.7). Done. Looks much better.

    Restarted the ahelix sim, turned off the sp hbond component, cranked down the ring stack scale to 20 (to reduce contractions of helix as observed previously). An inactive dotted line shows that there must be a bug in alignment factor for potential, as one formed between a donor and acceptor on the same chain, acceptor one position up from the donor, and the vectors are aligned. Oh right, the new code forget the 'fAlign > 0' test. So do we completely cut-off neg alignment? That seems unrealistic, it should drop off sharply instead. And currently, the alignment is not being used at all in the electro component function. I'm thinking the alignment factor should ONLY apply to the sp (composite-covalent) component.

    Ok, changed potential calc so that it's 0 unless the alignment factor is positive. In the future, will need to use a more accurate potential calc, but current thresholds only display potentials that have largely positive alignments anyhow. Ok, this changed things, reducing min draw threshold potential back down to 0.2, active set back to 0.8.

    Even if we get a good stable ahelix sim, the real test will be reproducing helix formation in tetraloop-folding. Ok, that lack of directionality has some drawbacks for the ahelix bonding. Perhaps a very small scaled sp-component would help (currently set to zero). Or at least, we have to applied the alignment, but not as alignment of vectors because there is a strong hbond between 2 bases, 1 up 1 pos from the other. The vector alignment is perfect, but we need to be using the ANGLE between donor-hydro-acceptor! And in this case, we just define fAlign = fAngleDeg / 180, so that we don't get a total cutoff at 90. Seems perfect. And in that case, it could be applied to the electro function.

    Ok, so the problem with that approach is that it neglects the position of the non-bonded electrons. Both pairs of an acceptor atom are treated equivalently in that case. Ok, what we can do is to combine two alignments: angle( Hd, Ha ) and angle( Ed, Ea ). That should work.

    Looking at the hb electrostatic calc, and see a vdw function!! Why??! (Was it to avoid infinite force on close approach?) Probably. That explains the repulsion force arrows that I saw.

    In the current sim, we're not getting the good 'hbond' lock that the s-p method gives. Turned s-p scale value from 0 to 10 and immediately got better bonding. hbElectroScale is at 100. Maybe this is a good compromise.

    Alert! There is an out-of-plane sp2 oxy electron vector on aisle 3!! The sp2t torsion scale factor is on the same order as the hbElectroScale, need to crank it up! Set it to 1000, that fixed em. Changed ff param defaults: hbElectroScale = 100, hbondScaleForce = 10, sp2tTorsionScale = 1000. With these current parameters, ahelix sim has good wc base-pairing. Still have a little transverse potential happening, but that is probably ok.

    Just for fun, turned off lin and rot friction at frame 167. Helix looked at at frame 250.


    Bad news. Did an overnight sim on ribo4 of SMD tetraloop folding with the new hbond function and it didn't work. Did not get proper base-pairing between the bases of the folded stem. This is not good. Been trying changes in various ff parameters, such as turning off friction and hbElectroScale, no luck so far. Latest attempt is to crank UP the ringstack scale force instead of down. What has been happening is that the bases all crowd together in the middle at tilted angles instead of bonding in nice planar stacks. Also, I think the strong hbonding from the O2* atoms is interfering with formation of proper helical structure. They are especially forming strong bonds with the O4* of the adjacent downstream residue.

    You know, I was thinking about increasing the vanderwaals radii of certain atoms to address the 'collapse' behaviour and now I just realized, could it be due to the current skipping of hydrogens in the steric interaction? Should I add the hydrogens back in? It's just a simple flag change in CTorsionBodyIteFcon.

    The large ringStackScale value also makes a collapsed mess. Trying the steric hydrogen thing. Well, turning it on didn't stop the helix collapse. Still have a stable ahelix sim. Can't see much difference at all. Will also try the tetraloop fold with it, to see if that is any different. Should we really go for broke and turn on torsion interactions for hydros too?

    Turned on torsions for hydros, again, don't see much of a difference. Keep trying the tetraloop simulation again from a paritally-completed state produced by the overnight sim. Tried turning on the tlUffo torsion spring script to help drive the residues to their target torsion angles. It seems that residue G4 keeps getting stuck in the middle of the pro-stem, interacting with residues C9, G10 and G11 because G4 is in a 'tilted-down' configuration. Given this, residues C1, C2 and C3 have little chance of base-pairing with residues G12, G11 and G10. The tlUffo script reports a max angle deviation of only 6.4 degrees, so it seems to be doing its job. I should look at the conformation of G4 in the folded tetraloop to see where it's at and how it might get there.

    Looked at the comparable G residue in the folded tetraloop and its base is rotated so that it is perpendicular to the stem axis and it is base-paired with the correspondent of C9. I'm struck by the parallel orientation of the bases, I wonder if at some point a much better ring-stacking function must be developed to reproduce this tendency. Manually rotated the base of dyn residue G4 so that it can base-pair with C9, started new sim.

    So now I am trying to reproduce the tetraloop folding, and looking back in the project directories and project log, I find to my horror no trace of detailed parameters of the successful runs. They must be on ribo5, but I can't believe that I didn't copy them elsewhere.


    Found a .coord file of a partially-successfull tetraloop folding on inga under version rbo-0.1.3.alpha4/exp/new/tetraloop. However, there were no associated .sovar or .ffset files that had been saved with it. Trying to reproduce the folding result on a copy of that older version.

    Looking over some diffs for recent versions of CRbqNodeBsjForceObject:CalcHbondForce(), I not that the current version applies the new 'fAlign' factor to both the electrostatic and s-p components. But shouldn't the electrostatic function act independently of alignment? Removing fAlign factor from hb electrostatic function. The other change was reducing the attract exp from 4 to 2 in the electrostatic function. Until I reproduce the tetraloop fold, will put that back to what it was also (as well as skipping hydros).

    Started a sim with these conditions on the final folded structure of the tetraloop demo movie, without any external driving forces, with zero friction, and the hydrogen bonding appears quite stable, although there is a lot of very rapid motion of hbond hydros. After observing the movie of 200 frames, the structure may not actually be all that stable. Although the hbonding is maintained, there appear to be strong disrupting forces. I suspect that these result from the sp2tTorsion forces, but not certain.

    Looking at a longer movie, it seems quite likely that the above is the case. One of the unpaired bases started out with its O2 nbe branch 90 degrees out of plane, and the restoring torque induced very noticeable oscillating movements.

    Tracking down the 'failed addition of hydrogens for terminal dynamic residue' bug. This happens because currently, if any 'extra-bond-definition' atoms are missing, the AdjustBonds() function in CRbqDynamicSegment.cpp returns false. Why was this done? Fortunately, there are excellent project log notes about this on 2004-07-17. The reason give was that if an atom in an extra bond definition was missing, then its partner atom, if present, would not have the correct number of bonds and as a result, have incorrect determination of valence. Initially, the entire dynamic residue creation was aborted, but subsequently, only hydrogen addition was skipped. There is the option of just skipping hydrogen addition on a per-atom basis, if we can identify just those atoms associated with failed bond adjustment, and flag them for skipping, as opposed to skipping all hydrogen bond addition. Or, for now, perhaps, we could just add an option flag to 'force' addition of hydros, even if there are missing bond defs? Might be simpler.

    While doing another sim of tetraloop folding with the latest version of the program, I just happened upon the simulation while an interesting event had just occurred, which may explain the instability of the previous attempt. What happened at frame 127, as the right arm had been twisted over to the front, on its way to the folded angle, was that a full G-C base-pair had formed between two of the bases in the stem. My hypothesis about the cause of the instability is that that great deal of torsional energy is input by the driver script in order break the base-pair to complete the target angle. Because of zero friction, all of this energy will remain in the molecule. One important qualification: the current sim is significantly different from the previous tl folding sim in having a much stronger hbond force, also with fAlign removed from the elst component, and finally, an extra base with hydros because of the --force-add-hydros flag. Note: copy rbq.log file in 'savesimstate.lua' script to account for such customizations.

    This leads me to think more about in energy and how thoroughly I have neglected it in the development of the molecular dynamics engine. In other MD engines, presumably the energy in maintained in a more constant state by use of a surrounding temperature bath. There is a form of max kinetic energy clamping in the rbq md engine: the 'maxmove' and 'maxrot' parameters. Still, it would probably be quite profitable to add more explicit monitoring and control of the total energy in the simulation. A short term fix in this case would be to temporarily 'turn-off' hbonding until the target configuration is reached, but of course that is much less satisfying.


    Finally got started back to work on aligning the initiator tRNA to the P-site for the eln001 sim (still working on the tetraloop folding on inga, but that will probably take some time). Tried to do an initial backbone position and torsion angle alignment of the terminal 5 residues, with the terminal 6th residue locked in position. I chose that number because the 6th residue is the first base-paired residue of the 3' end. But because the 6th residue is too far deviant from the corresponding residue in 1gix_C, the aligning residues couldn't fully align. I either need to use a longer dynamic segment or do a realignment of the entire tRNA and start from the point where the 6th terminal residue (2fmt_D1.D$.C71) has been fully positionally aligned with its target (1gix_C1.C.G71). I think I will abort the current tetraloop sim on inga and do the latter, as I want to do a full tRNA sim using the latest hbonding function changes.

    Setup a new 2fmt_D1 - 1gix_C1 align sim on inga. Differences from previous align are 1) locked down a portion of the ASL residues instead of just a single one 2) Starting with torsion spring alignment first, then after getting good torsion align, will add the dsIrs align script object.

    The torsion alignment of the 3' end of 2ftm_D1.D$ got stuck because of a hydrogen bond between A73.O2* and C74.O4*. Reduced the hbElectroScale factor from 10 to 1. Also, locking down movements of all but aligning to speed up the process and reduce distortion while the stem is torsion-aligning.

    That worked. fMaxAngleDev is around 5 degrees. Restored movement for previous residues, added dsIrs alignment.

    Ended up getting pretty good pos and torsion alignment, but there is just too much collapse of the main body of the tRNA! The vdw radii must be too small. The question is, can I increase them without blowing up the molecule? It would be nice to have a 'global vdw factor' parameter. I think that I will add it. However, the question is how? Low-level modules obtain the vdw radius of an atom from a call to CElement. We could modify CElement to multiply an optional factor, set by a client.

    Looking through the code for current refs to element and atomtype vdw radius calls, I see a few players the GetElementVdwRadius() is called instead of the GetAtomTypeVdwRadius(). Current element vdw radii for Carbon, Nitrogen and Oxygen are 1.9, 1.82 and 1.74. Corresponding atom type vdw radii are (1.8, 1.98), (1.62, 1.8), and (1.62, 1.8). The parenthetical values are for (sp2, sp3). Perhaps, instead, the mistake is the sp2. Instead of hooking CElement, we already should have a mechanism by adjusting the vdw radii via script. Of course, that is the way to go.


    Changed all GetElementVdwRadius() calls to GetAtomTypeVdwRadiusCalls(). Did a test run with uniform larger vdw paramters on ahelix model and the results are so much better, I think I will change the defaults back to that. Done.

    The overnight sim of trna alignment on inga is no good because interactions between the locked residues in the ASL and adjacent active residues was not correct - the covalent bond interaction was not done. This is strange, may be due to a bug in the 'enable intra-residue interactions' flag. Yes, that is the case. In the current implementation, inter-residue covalent bonds and torsion interactions are done in the 'intra-residue' function CRbqNodeBsjForceObject::CalcInternalForce(). This was done for implementation purposes, but there needs to be a caveat in the built-in command reference and the user manual about that. Done.

    Still trying to get the latest tRNA sim to converge to target on inga. Had to crank up the dsIrs force constant. There is a bug in drawing the backbone atom for dynamic segments (most likely related to the recent bug fix for nucleic acid type detection). Currently, atom 2fmt.D$.OMC32.C2 is being returned as the backbone atom. Fixed.

    The tRNA align sim on inga was successful, finally got very close torsion and position alignment after increasing torsionSpring and dsInterResSpring force constants to very high values (2000), as well as bumping friction up to 5.

    There is a bug exported pdb iaa.D.FME77 (0 atom records exported).


    The bug mentioned above happens after the fully-loaded sim eln001, but not in an empty document. Fortunately, it happens in both release and debug builds. This is a minor bug in detecting partial selection. Fixed.

    Trying to work in the peptide-transfer reaction in eln001, but found yet another bug, trying to select residue '1m90_cca_std.5.PHA9077' fails, shouldn't be similar to existing bug in selecting '2pj4.a.SO4900' as mentioned in project log 2004-02-20. Looked in the PDB file, which shows the cause of the problem. There is a TER record between the previous residue and this residue, even though they both have the same chain id. This points to a larger problem about multiple chains in the file with duplicate chain id. In this case, it is easy to fix, but in general, it would be nice to emit a warning for such situations. Done.

    In trying to model the peptide transfer reaction, it's difficult because things don't line up perfectly, and other things get in the way. Also, having amino-acid residues disconnected from the 3' tRNA terminii is a real hassle. For these reasons, and also to attempt an SMD-driven sim to line up the reactants, I really want to modify the existing code so that there can be bonds between heterogenous residues (ie: nucleic-amino bonds). It shouldn't really be all that big of a deal, just add an extra function in CFastPdbObj to look for the nearest atom with available bonds to the link atom of a residue.

    Added function CFastPdbObj::CreateHetInterResBond() without too much trouble. It works. Also, force object creation even works for 1m90_cca.A9076 - 1m90_cca.PHE9077, using the -xh hydro exclusion flag. However, one thing that does not work is manual rotation about dynamic residue bonds. This is because the implicit 'ancestor-descendant' relationship doesn't work when rotating bonds of PHE9077. This brings up a design issue, in that rotating bonds for a selected atom is inherently ambiguous. There actually needs to be a way to select or specify the particular bond of such an atom.

    In the future, the design of the program should be changed so that each covalent bond can be selected individually, and then rotate the components on either side of that bond.


    Still working on peptide-transfer reaction in eln001. Creating script 'dsInterAtomSpring.lua', a modification of the dsInterResSpring.lua script. At some point, should create a very general-purpose 'interObjectSpring' script, but no time fer that now!

    dsInterAtomSpring.lua script is working, did test align of 1gix_B_aa.B$.A76 to 1fg0_ccp_std.B.PPU76.


    Finally getting down to brass tacks with the ptc sim. Have dynamic segments being created for both 3' termini of the tRNAs. Still thinking about how to drive the reaction. Will start off by creating backbone tethers to static positions.

    There is a bug in the 'dsInterResSpring.lua' script in that the static atom is different from the dynamic atom for the terminal amino-acid residues. Fixed.

    Did an equilibration sim of the 3' tRNA termini dynamic segments for 123 frames. The dsInterRes springs maintained the residues near their static positions, and even better, the carbonyl oxygen of the FME77 residue of the p-site tRNA rotated under and away from the ribose of the A76, exposing the fat, juicy underbelly of the carbon for a direct attack by the amino nitrogen of the incoming aa residue. We are finally ready to do the actual peptide transfer sim, right after I create the ddInterResSpring scripts so that I can create a spring between the nitrogen and the target carbon.

    Ok, finally started the actual peptide-transfer sim! The ddInterAtomSpring script works. The amino approaches the carbon, but had to weaken the hbondScaleForce factor and increase the ddIas force constant. It only approached to a minimum distance of 0.332 A, though, because of the steric conflict between the two atoms.

    Now, need to somehow simulate bond-removal from tRNA A76 O3*, and lose the hydrogen from the nitrogen. I think we can do the first by creating a new model of the FME77 not bonded to the tRNA, but held with a spring bond and drawing a bond image, then turn off the spring as the nitrogen approaches. Actually, we will need 'shadow-point springs' to do this. More script objects! Call it 'spInterAtomSpring.lua' ? Yeah. And we dump the hydrogen onto the O3*. The only other problem is, we need a way to selectively disable the steric interaction between the nitro and carbon.

    Got an idea how to deal with reducing the vdw radius for these two atoms, and the idea should also be useful for future forcefield definition. It involves adding 'custom' atom types to CElement that can be dynamically defined and added at runtime. Then, can just assign special atom types for these two atoms via script, and the vdw interaction will be reduced, without having to touch any of the core forcefield code.


    I had thought that the ForceObjectUtil module provided all the node data access functions required for implementing the shadow-point spring script above, but I see that we need access to the node transform. Done.

    Quickly created spInterAtomSpring script from ddInterAtomSpring script. Then, defined shadow points for the 1gix_B_aa_2.B$.PHE77.N atom and align369_iaa_1.FME77.C atom by taking a fragment of 1ttt_AG and lining up the amino nitrogen of that fragment with the PHE77 nitrogen and then recording the position of the carbonyl carbon, and then doing the same for the nitrogen shadow point on the carbonyl carbon atom.

    Having problems observing script function execution in eln001. This causes me to realize that the current scheme for controlling command and status echo to status window is no good. It shouldn't be controlled by parameters there, it should be controlled via strictly via function calls enableCommandStatus() and enableCommandEcho().

    Actually, we need an integer limit value for command echoing, it required numerous changes, but couldn't help but put it in there. Being able to debug scripts properly is vital, and a high integer value will force reporting of ALL input commands, no matter what the source. Changes appear to work without causing much trouble.

    Adding custom atom types. Done. Uh, not quite. Hammering out the rough edges is actually taking quite a few hours. Ack.

    Ok, custom atom types are finally working for real, and I had to set no less than 4 atoms with a custom vdw radius, but now the aa N and the iaa C are finally bonding. But there is still ONE MORE THING that has to be done. Although the spInterAtomSpring script successfully creates a covalent bond between the two, there also needs to be another driving force to insure that the bond lies in the peptide plane (and with orientation anti to the amino hydrogen).


    Ok, today should be the day that the PTC reaction should get nailed down. Created setupSmdPtcBond.lua script to setup the context for the SMD sim of the reaction, as a number of parameters have to be tweaked to get bond formation. Also, one thing to add: a driving script to pull the nitrogen closer to the carbon before doing the covalent SMD sim.

    Create exp/sim/eln001/ptcDriver.lua script. It's working.


    Finally got a good peptide-transfer movie and presentation of it in eln001 sim. Now we can finally move on.


    TODO: improve surface-generation algorithm to work with small, sub-angstrom resolutions.


    Developed EF-G model in docked location on the ribosome.


    Finishing PTC rxn step in eln001 prior to starting on EF-G steps. One annoying flaw in the current implementation of dynamic models and the forcefield is the inablity to remove a subset of dynamic objects from the forcefield. Currently, all dynamic models must be collectively deleted if any object is deleted. The consequence of this for schematic simulations is that 'proxy' static models must be created for each simulation sequence that uses dynamic segments. Such proxy static models are needed because the dynamic models must be deleted prior to the creation of dynamic models for a subsequent simulation sequence. This annoyance is compounded by a second limitation in exporting selections, where export of composite selections is not supported, so that individual components of a new model (such as a peptidyl-a-site-tRNA) must be exported individually and manually combined outside of the program.

    There is a bug in CFastPdbObj where an impossibly-long inter-residue bond was created between the new peptide residues at the end of the a-site tRNA. Fixed. Now, after creating new composite static model of tRNA with a two-residue peptide, we have the problem that CFastPdbObj does not create a bond between the two amino-acids because they are in reverse order. It leads me to wonder, why not just add a function to CFastPdbObj to allow a client to add an inter-residue bond? Don't think that would cause any problems because the current implementation uses std::vectors for inter-res index lists, shouldn't have any hard-coded size limitations.

    Note: for a future implementation of inter-res bonds, we should just add a pair of residue indices to the inter-res bond list (in addition to the existing atom indices). This should allow specification of bonds between any pair of atoms in a common chain of a PDB model. And perhaps, it should be extended even further to allow inter-chain atom bonds? How should that be done?

    Added CFastPdbObj::AddPrevResidueBond().

    Trying to debug the eln001 tick() code by turning command status off, but it is being turned off somewhere. While running the debug version, I finally took the trouble to drill down in the lua call stack in the MSVC debugging and I found the lua source code and line numbers! That will make things a little easier. Actually, not yet. Tracing lua call stack code is not as easy as it first seemed. Part of the problem is that there needs to be an integer level variable for command status, just like was done for command echo.

    Debug hassles. Finally betting cmd echo and sim debugging to work. There is a bug in rbq_SetMovieFrame(). No, not a bug, just user error. Function expects 0-based index. Added to lua lib doc. Ok, the freakin eln001 sim is finally working up to the current working step, 'show EF-G'. Now, just need to add the function to add prev res bond.


    AddPrevResBond functions work. Ready to start on EF-G steps in eln001. Added some initial steps. One annoying thing: one of the intermediate steps, 'prep show EF-G', is drawn during the 'goto step' sequence. This is the only intermediate step that is drawn. This may due to the 'scheduleDeleteScriptObject()' call. Or it could be because of the force object deletion. Rather than track down a zillion possible redraw calls, we could just add a 'disable redraw' function. Done. It works.

    Ran into a really weird graphic window update effect when the eln001 script failed. Wonder if it has something to do with the draw disable flag? It happened, even when all script objects and annotations were deleted. Strange. Doing a full rebuild to repro. It's repro in release build. Must have something to do with a requirement of paintGL() that is not being met when drawing is skipped. Ok, found it. In CRbqMainWindow::timerEvent(), CRbqGraphicsWindow::Draw() was being called every timer tick, which in turn was calling QGLWidget::updateGL(). Added code to skip update call if drawing is disabled. Did that, but now the damn lua code is crashing! Arrggg!!!!

    Ok, it didn't repro, and even so, it's not too bad. It was a crash in the AnnUtil_SimDriver tick() script, which was being run even though there was a lua error in the associated AnnUtil.Sim object script. It would be nice to stop the AnnUtil_SimDriver object from ticking if there is a lua_error in the AnnUtil.Sim object, but not sure if it's worth doing that right now. After investigating a little more, one thing that might be happening is re-entrancy in AnnUtil.Sim.tickStep(), being called by AnnUtil_SimDriver.tick event script. Checking...

    Actually, the flag in CRbqLua::RunScript() should prevent that, but perhaps AnnUtil.Sim.tickStep() is happening while AnnUtil.Sim.gotoStep() is being done. Added re-entrancy and conflict checks, but didn't see them. Lua is not crashing this time, so won't worry about it. Added auto-re-enable of drawing on lua error, that is working well.


    Finally completed the translocation portion of eln001! Although it is missing pieces, and needs lots of fill-in, the complete outline of the schematic simulation of the elongation cycle has finally been completed. After filling in some more parts, will do some brief unit testing and then release the new version of the program with a demo of this schematic simulation, so that I can resume writing the thesis, as I must have a first draft completed by early January. Finishing this will really help to make that happen.


    Combined a fade step with 70S approach. Started an alignment between wmrna codons and frozen tRNA anti-codons in A and P sites.


    Didn't save the dynamic segments from yesterday's alignment sim, but tried to recreate them using log files. Unfortunately, even though I'm fairly certain that the correct number of force objects were created, in the proper sequence, the coordinates played back from the movie are not in sync with the force objects. But can't understand why this is the case. The sequence of nodes should be strictly deterministic. After resetting all force objects and reloading the movie, it is now in sync. The previous decision to automatically rename and preserve existing logfiles was a very good one because it greatly helps in reproducing results.

    Finished incorporation of aligned codon model into eln001.


    Doing comprehensive list of all PDB models of ribosomal subunits. Figured out how to use VAST to list related entries. Can't list for nucleic chains, so listed using 'all sequences' option for protein L3 of pdb model 1s72. There are quite a few entries, looks like 20 entries for the lsu.


    There is a bug running script 'SelFeat_1tra_stmlp.lua' to highlight features of tRNA. Something about the residues being reported as dynamic residues - ??. Ack, it looks like some fundamental bug in lua strfind(). It's saying there is a '$' in the string when there isn't. Ok, it's because of the pattern matching 'special' characters in strfind(), because I didn't specify the 'plain' argument. Fixed. Why didn't this bug happen before, and how many other possible bugs with this strfind() usage are there? Grep on strfind() in lua\*.lua shows just a few calls, and most have the strfind( sStr, sPat, 1, 1 ) qualifier, so shouldn't be too much of a problem.


    Get an ASSERT in CElement.cpp after loading 1yfg (yeast init-tRNA). 1yfg does not align very well with 2fmt.


    Preparing for new release. There is a problem where an error in processing the ScriptDefs.ini file is not reported to the status window, so the user has no indication why the custom script menu fails to appear. Fixed.

    In creating additional line labels for the elongation sim, finally getting around to fixing the ViewUtil.lua function vec_ViewToWorld() so that I can get a good offset for the endpoint of a linelabel (created script Vector_ViewToWorld.lua). This revealed a problem with the current implementation of StringUtil.parseOptions() where a non-option argument '-1' (first param of vector '-1 0 0') is being interpreted as an option. Fixed.

    It looks like the source of the error of calculating the world vector from a view frame vector has something to do with the inversion of the rotation matrix vectors in a frame representation compared to a homogeneous matrix representation. From previous work (tv tree viewer project), it is very clear that all that is needed to convert a view frame vector to a world frame vector is to just create a 4x4 homogeneous matrix with the rotation component only (zero-out the translation), then transpose, and multiply the input view vector to get the world vector.

    Yes, doing that explicitly in the ViewUtil.lua vec_ViewToWorld() function gives the right answer. Not sure why the frame representation version is not working, and absolutely cannot change any functions related to that frame rep at this time because it would break important things such as the getInterpHTransform() function in GeomUtil.lua.

    Added an optional text offset parameter to AnnUtil.LineLabel to fix bad-looking overlap of text and line, and just realized that the explicit parameter I used indicates how to calculate a sensible default: just do about 2 * the unit vector of the line vector and it should always look good. That works.

    Work is proceeding well on adding description of the PTC binding pocket to the elongation sim.


    Added display of PTC features (base-pairing, A2602). Fixing other minor aspects. Added transition to peptide bond reaction. Added high-res display of ptc pocket, along with lua function to detect existing pdb surface.

    Changing timing of billboard text at start of many steps so that there is a small delay where there is no billboard. This helps to catch the eye when the billboard is first shown. Previously, when the billboard text was changed at the start of a step where there was already a previous billboard displayed, often the eye would not notice it. This is obvious in retrospect, unfortunately because it was realized quite late, it will require a bit of housekeeping to implement, as currently the sim is up to 54 steps. Added 'AnnUtil.clearBillboard()' function.

    Almost there. Perhaps, after adding the 16S decoding residues (530, 1492, 1493), we can ship it.


    Looking at what it will take to add the 30S contributions to decoding. At step 20 (A-site codon recognition) in eln001, it seems clear that the sim should be showing another conformational change where the ASL of the A-site tRNA changes from the 1ttt conformation to the 1gix_B_aa_2 conformation. The question is how rapidly could such a new SMD sim be created? It seems like it should be a fairly straightforward alignment similar to some of those used to align the tRNA terminii.

    Created setup script exp/sim/eln001/set_acr_smd.lua without too much time or trouble, starting intial SMD sim.

    There is a bug in updating movie position after deleting current movie file. Currently, this can be bypassed by just setting the movie outfile again.

    Another issue comes up: just as the p-site codon for wmrna was out of alignment, so to is the a-site codon (really need to redo the whole wrapping sim to align to more than just the backbone atom positions). So, for now, will need to use another proxy piece from 1jgo. For some reason, the conformation of the p-site proxy, cacAlign, is quite different from 1jgo??? And I have zero notes on it. cacAlign is the way it is because it is aligned to the p-site anti-codon (align369_iaa_1.D.34 - align369_iaa_1.D.36).

    Got excellent codon-anti-codong base-pairing with just the backbone atom SMD! This is a nice validation of the hydrogen bonding function in the forcefield. Also, the ease of doing this indicates that the ASL of the tRNA appears to have quite adequate flexibility needed to do this kind of conformational change. Also, I wonder if there was anything else unusual that contributed to the success (friction set to 20?). The conditions are mostly encoded in the setup script set_acr_smd.lua.

    Adding codon recog movie to sim. TODO: add warning when loading wrong movie infile (movie frame doesn't match ff nodes). Things were going well, and then the rbq program crashed! Arg!! That damn pure virtual function call runtime error R6025!! Will it repro? Doing a rebuild all. Reran some of the steps before the crash, not repro yet. Another problem: adding the record.coord file to cvs is now causing a huge delay getting cvs updates in the exp/sim/eln001 directory. Why? There are already a couple of fairly large binary movie files there. The addition of a third one seems to have caused an huge excess delay. Removed it, and was able to proceed with an update. Strange. I'm sure I added it with the -kb option. There must be something weird in the binary file that is choking cvs. Or it could be that recently, I've noticed that the sourceforge cvs has gotten much slower. Perhaps the overhead of this large binary combined with the recent slow is the cause of the seemingly interminable delay.

    Finally checked it after about 45 min! Resuming work on codon recognition. The anti-codon movie seems to work well. Next, recognition by the 30S. Carter-2000 mentions the helix flip for A1492, A1493 on paromomycin binding. PDB model: 1fjg. Finding best helix align between 1j5e.A and 1fjg.A: Best align (RMSD 0.597): (h13, h2). Ok, loaded the model and looked at the recognition residues and it is crying out for ANOTHER smd sim! This one to show the flip of A1492, A1493. Gotta do it.

    Got initial version of the sim setup in about 15 minutes. We'll see if it completes as easily as the ASL aligment. At the very least, a torsion alignment may require specification of the direction of certain torsion springs.

    Got good target angle convergence at only 80 frames (2 degrees), but I made the mistake of defining only the two central residues as targets. I forgot that for torsion angles, the upstream residue torsion angles are also very important in many cases. The current conformation of the central residues is still quite a bit away from the targets in 1fjg. Need to redo with more torsion springs. Added G1491. Got down to a fraction of an angle for the torsion targets, but the driven residues are still far from the target conformation. Looks like we will also need backbone atom targets. Done, started new sim.

    Had a good idea to add an option to 'ff movie writeFrames' to output the frames with an increment, so that shorter (albeit jerkier) movies can be included in the next distribution for eln001.

    Ok, the latest sim successfully flipped the residues out to where the target ones in 1fjg were. The only problem was a difference in the glycosidic angle of A1493. This is off, and one reason may be the inadequate ring stacking function. Once that is improved, I suspect the non-driven forcefield trajectories may improve considerably. Also, the backbone jerks quite a bit as it tries to meet the target. I suspect that this is because the endpoint tether spring constants are too high. Reduced them from 5000 to 200. Now the question is how quickly can a glycosidic torsion spring be defined?

    Added getFoChiAngle() to DihedralUtil.lua, added chiTorsionSpring.lua and related scripts. Chi torsion angle code is working. Ran a quick test of chiTorsionSpring.lua on a.pdb, it appears to work, but noticed some serious distortions in the base ring - seems due to the sp2Torsion force, is the existing force factor of 1000 too high? And why is it so noticeable just with chiTorsionSpring.lua? It looks like the sp2 torque and the chi torque may set up some kind of resonant oscillation in the base ring. Wonder if I should reduce the sp2 torque force constant? Hate to do that right now, but maybe it's needed. With the default friction of 1, the chi angle is not settling down to the target angle, because of these oscillations. Actually, after playing back the movie, the oscillations look like normal inertia, due to the large chi driving torque and the low friction. Not going to worry about it. I suspect that with a larger friction, this would not be noticed. Re-running with friction set to 20. Doing that makes the ring movement very smooth and stable.


    Re-ran h44 align sim using chi angle springs for both A1492 and A1493. Finally got a fairly good alignment, but not perfect. Incorporated the movie into the eln001 sim. I think the content can be considered complete for now, all that remains is a bunch of tweaking of timing and addition of text descriptions. Then we can ship it!!

    Ran rbq_lua unit tests, 8 tests out of 100 failed, 4 of these were non-graphical: rbq_GetForceObjProperty(), rbq_GetSelectionExtent(), rbq_GetFfParams(), rbq_StepForcefield().

    In rbq_GetForceObjProperty(), the error was caused by a change in the x coordinate of the box center for 1tra.a from 25.295 to 25.285. Not sure why it changed, perhaps because of a change in a vdw parameter. On casual inspection, the current value looks reasonable. At some point I suppose, there should be a rigorous definition of the expected values in unit tests. Don't have time to do that at this point. Will fix by changing the expected value. Checked the change log, and the presumption above is confirmed by the change from call of CElement::GetElementVdwRadius() to CElement:GetAtomTypeVdwRadius() on 2004-11-28.

    The failed rbq_GetSelectionExtent() is probably also related to that change, but the situation is a little more complicated in that there is a static model extent that changes after dynamic segment creation because of linkage of static model atoms to newly-defined dynamic model atom types (and thus, different vdw value). At least, I think that is what is happening.

    rbq_GetFfParams() fix is easy, just updated new reference file because of reduction of hbondScaleForce from 30 to 5 and addition of new parameter sp2tTorsionScale. Also, these same changes are probably responsible for failure of rbq_StepForcefield(), which uses a hard-coded force value.

    All the Seq unit tests pass (5/5), but one of them runs very slow! Need to fix at some point.


    Finished first version of rb manuscript for CBC. Adding final steps to sim eln001 before new rb version release. There is a bug in AnnUtil.Camera.setArcInterp(). When trying to set full interp value in a single step, the proper view is not set (thought this problem arose earlier and was fixed?). Happens in eln001 step rot h44 recogView. There is a workaround: just set the final view at the end of the step.

    Added references to sim. Added final steps and timing tweaks. I think it's time to call it done!


    Added timing auto-calibration step to sim eln001. This is important for producing a seemless, effective demo when run on much faster machines than the current dev machine. Auto-calibration appears to work, and in conjunction with the existing manual rate, which appears to fully override the autocalibration, as intended.

    Tested both older schematic sim demos of translation initiation, they still work! Moved to 'old demos' submenu. Tested rbuilder game, it still works!

    Trying to reduce size of distribution, moved some large pdbs to devpdb subdir, made rbg game pdb self-generating.

    Decided to rename the executable from rbq.exe to rbuilder.exe, this is causing some hassles in the makefiles. Fixed. Had to hard-code rbq.obj in the obj dependencies to replace the new target name that was being specified there (in app\rbq\mak\


    Testing build rbuilder-0.3.4.pr7. Fixing bugs in movie demos caused by removing some of the exp/dev subdirs from the distribution. Also, the tetraloop movie is messed up. Not sure why. Not repro, it only happened once, after fixing up the previously mentioned problems. Probably something to do with the old single-atom node flag? The bug is definitely not repro after fresh rebuild and install. I think it had to do with the failed loading of the rbd file in the exp/demo/tetraloop dir because of the previously mentioned bug.

    Testing setup file on beryllium. Schematic Sim works fine. Doing minor fixes on all the missing links on the main html index page. Trying to fill out the applications section, tried running the old steric interaction report, it is broken. This is because of ff command name changes for energyCalcEnabled. If not too much trouble, will try to get it working for this release. Act, this is actually a bug in ForceFieldUtil.lua, we really need to add lua_lib unit tests at some point.

    Fixed that problem, successfully generated a steric report, but now in the script that highlights steric interactions between pairs of atoms, there is a bug in parsing the CGI parameters from the html page. It's something to do with the spaces in the parameters. The parameters appear to be correctly submitted to the htsrv app from the web page, but when reported in the rbuilder status window, they are messed up. Now might be a good time to do some documentation of the htsrv interface in the whitepaper.

    Added documentation of html interface to thesis. There is definitely a problem with decoding CGI params that use %20 for spaces. On 2004-11-12, a change was made to the URL decoding to allow for spaces. This was when working %on the schematic sim, which also uses %20 in the param spec. Why doesn't it work with other scripts? In the eln001 script, most of the %20 delimited tokens are non-numeric, that must have something to do with it, as spaces are correctly shown for that, but not for a string such as '90%200%201%200', which is returned as '90 0%201 0' (ie: the middle substitution is not being done). Is it a bug in CRbqHtSrv.cpp function ReplaceSubstring()?

    Confirmed. The bug is in that function. Fixed. Duh. Steric reports are working for 2nt.pdb sample in exp/dev/reports. Added to applications section on local project web page. Building version 0.3.4.pr8.

    One more thing that really should be done before release is to add supplemental documentation to the command reference html docs!

    Uploaded version 0.3.4.pr8 to web for beta testing. File size is 25 MB.


    Ribosome Builder is 4 years old! (5 days ago). Investigating creation of mpg vide of elongation demo.

    Talked to Drew about what video tools to use: VirtualDub, tmpgenc.

    Wrote frameGrabber.lua script to grab frames, SetGraphicsWinSize.lua script to set window size to 720 x 480. framegrabber script exported the BMP files as the sim demo ran, but the damn ortho text is not in the grabbed image!! Why!!??

    Checking the Qt docs on QGLWidget::renderPixmap(), there is a useContext param, can try that. Tried it, doesn't work. Looked in Qt forums, tried QPixmap::grabWidget() function instead. That doesn't work either. ARG!! Tried QPixmap::grabWindow() and that does work! Building pr10, testing on Inga.

    Successfully created an mpeg 2 video from the demo. Fortunately, the quality is just barely good enough to read the text. However, it is 32 MB in size, and runs too fast. But it should work as an alternative for viewing the elongation sim without the program. However, when view this mpg on ribo4, which had different versions of real player and windows media player, the aspect ratio was changed and the text became unreadable. Had to create a 720x480 version, with minimum bitrate, to get a 37 MB file, which is better, but still doesn't show as well as with the mpg players on Inga. Strange.

    Built final release version.

    Started to upload the mpg movie to the project web page, but the net connection to sf was very slow. Aborted many times. Also read, on the sf status page, about recent download throttling of large files from project web sites. That is annoying. Guess I will have to include it in the file release. Tried to upload the latest setup file to the incoming dir on the sf ftp upload site, but the slow net torpedoed the connection and the partially uploaded file prevented subsequent attempts.

    While using filezilla to try to upload the file, found out about a security vulnerability in putty. Will have to upgrade that at some point. Many frustrating hassles today.


    Sent a support request to SourceForge about the file upload problem, got an excellent suggestion back from Burley about copying to shell server first via scp and the ftping from there. Will try to complete that when the current partially uploaded file is deleted from the incoming directory on the sf upload site.

    Finally did file release of rbuilder version 0.3.4! Tested released files, schem sim appears to work fine.


    Added cvs tag 'Release-0_3_4' to bas and exp projects.


    Created template schematic sim files in 'exp/sim/template'.


    Made a small change yesterday to echo certain selection error messages to errout, and in doing this, I noticed how doing a 'File', 'New' doesn't reset the graphic window state, it only re-initializes a new, empty document. I think to minimize possible user confusion, the graphic state should be re-initialized. Some blantant parts already are, such as making sure the selection sphere is turned off. But the graphic win bg color, world and rotation axis show state and even the view are not changed 'new doc'. They are only initialized once, on startup up. It wasn't even clear to me (for a bit), even where and how they were being initialized there, until I started up the program in the ever-handy debugger, and then it becomes clear that this initial graphic win state is set by CRbqOption from member data vars that are only defined once in its constructor. Currently, the ini file doesn't have any interior graphic window state info.

    Added appendix section to user manual, when considering addition of description of graphic win initialization state to 'program startup' section in user manual.

    I am loathe to start making changes to graphic win state on new doc. Looking more carefully, I see prior code to reset the view on new doc only if the doc is empty and 'center view on inserted object' is set, because it was annoying to lose the sense of place in the world frame when new data was being inserted. Also, there is an existing problem with respect to doing some of these operations outside of the normal command input mechanism, because when this is done, the GUI menu state indicators get out of sync with the actual program state.

    Spending a little time to test the schematic sim template by creating a journal article annotation for (Yusupov, 2001). Currently, the amount of manual work involved in defining the various details of the sim is very time-consuming, but the plan is that by continually trying to develop such journal article annotations, then shortcuts, encapsulation of common routines into higher-level building blocks and other such insights and innovations will emerge over time. One example concerns definining the camera movements to present and describe a PDB model component such as the 3 tRNAs in the Yusupov paper. A typical strategy for defining a sequence of camera movements might be: 1) fade-in or display the new component if it is somewhere in the current view, 2) shift the camera look dir from the current direction to one that is centered on the new component, 3) translate the camera center so that it is closer to the new component (these intitial steps would be modified somewhat if it was already too close), 4) Do an arc rotation around the new component. Hopefully, this 4 step presentation strategy coudl be automatible by some kind of code-generating tool at some point. Note: something like this was already done for multiple models in the first schematic sim implementation scheme, in an initiation demo.

    One way to create such a support tool would be to define a dedicated script object that could run in the context of a schematic simulation that is being developed, and the script object could interactively produce a sequence of movements, while getting feedback from the user, and then emit a block of lua code that represents the 4 steps in such a sequence.


    Noticed excessive suspicious disk activity in Firefox download manager this morning while downloading some files from Simon's computational chemistry book, started checking out the system. There are some very suspicious system files in c:\windows\system, dated 2005-01-011. They appear to have randomly generated filenames. This was during the DivX install that I did to see an RvB movie that Drew sent me. Uninstalled DivX Pro trial. The system files did not go away. Uninstalled the DivX player. The systems files did not go away. They might be related to the trial time detection, but the fact that they weren't removed is pretty bogus. Also, there are divx files in the windows system directory that were still NOT removed.

    Also removed some other suspicious files from the window system dir. Also, after reading bad things about the WBEM (Windows Based Enterprise Management) files, renamed the 'c:\windows\system\WBEM' dir to 'c:\windows\system\WBEM.tmp'. Sysinfo will not run, but I can always reenable it by renaming the dir, and feel a lot better about removing a potential vulnerability, although in Windows, there is never any end to them. I suspect the disk activity that I saw with Firefox is due to a memory allocation bug, as it resulted in a large and growing windows swap file, so won't worry too much about that right now. Can't create a windows recovery floppy, that is annoying. Need to download Knoppix soon.


    Talking on the OSMP forum and extolling the virtues of small, simple, lightweight components (such as Lua and ODE), I am now reconsidering plans to use wxWidgets as a replacement for Qt. Instead, looking at FLTK and Fox-toolkit.


    Added fixes to build instructions after user feedback. I thought that the use of QT_DIR env var was a problem, but doing a test build of rbsrc-0.3.4.tar.gz shows that it is defined as needed in the makefiles. Still, to simplify things, went through the makefiles and changed QT_DIR to QTDIR to avoid any future confusion (even though I am planning on replacing Qt with Fox or FLTK).

    There was also a problem in creating directories when building from the VC 6.0 IDE. Changed VC 6.0 workspace and project files so that the workspace file is at the top level, removed VC 6.0 project dependencies because they messed things up. They cause the top-level makefile to be bypassed. Instead, we want all building of makefiles to be driven recursively from the top. Tested new project file, it appears to work.


    I realized yesterday that a reference, (Carter, 2000), is missing from the eln001 sim references.


    Downloaded project to Win98 dev machine in preparation for port to Qt4. Uploaded rbuilder whitepaper to project web site.

    Successfully built the program and ran it. Tried to run unit tests, got error in directory app/rbq/tst/rbqlua/funcs/rbq_GetAtomParName: no test.lua or tickTest.lua. This is most likely the result of an empty directory that was created by cvs. Removed it in cvs. Next: trying to check out the pdb project in order to run the unit tests.


    Successfully checked out the pdb project, moved it into the bas dir. Then, was able to run the unit tests. Out of 89 non-graphical tests, all passed except for rbq_GetSelectionExtent. All 11 of the graphical tests failed, because we still need to handle the spurious bit differences. The rbq_GetSelectionExtent failure is a known issue, mentioned in this log on 2005-01-04. At this point, the unit tests should be sufficient to allow proceeding to the mingw/Qt4 port.


    Downloaded and installed msys and mingw files. Installed Qt4. Next, need to change the config for the current build using VC60/Qt2.3NC so that it's compatible with a Qt4 installation. This requires that the path to the Qt2.3 bin dir comes before the Qt4 bin dir.

    Started creating unix Makefiles for the project. Figured out how to do recursive makefiles using a separate build directory.

    Started getting errors compiling qhull.c because WIN32 was defined. Couldn't understand at first why it was defined, then figured out that it must be predefined in the mingw gcc compiler. Verified this by doing 'gcc -E -dD qhull.c' and observing the predefined macros.

    Created Makefile for the lua libs. It appears to work.

    Created Makefile for wklib libs. Ran into a problem with the iostream includes. Don't understand the error. May need to download STL_port. Checked the line, it had the function std::min(), and I had just defined a macro to replace the MSVC minmax.h header file, so perhaps that is the problem. Yes. Tried messing around for a little bit trying to redefine min() and max() to be compatible, but it started getting messy, so just created a new file min_max.h with MIN() and MAX() macros. Will just go through the code and replace min() and max() calls with these. Done. It appears to work.


    Makefile for wklib completed.
    Makefile for wkGeom completed.
    Makefile for wkGrMatrix completed.
    Makefile for wkGraphic completed.
    Makefile for wkChem completed.
    Makefile for wkFastPdb completed.
    Makefile for wkTorsion completed.
    Makefile for wkEncon completed.

    Compiling wkGrChem, I run into a problem where the VC compiler accepted an enum tag as a type qualifier ( DrawItem::d_iAll ), which apparently is not legal C++ code. I will have to change all enum qualifiers to their enclosing class. Not a big deal, but it will likely be an editing pain, as I have used enum type qualifiers extensively in the code.

    Ran into another case where sloppy C++ was accepted by VC60, which may mean that I will have to do a lot of little edits. This is a case where I have assigned an iterator directly to a variable that wants a pointer to the value pointed to by the iterator:

    const CGrResidue *pGrRes = it++;

    This produces an error in gcc, as the correct way to get the pointer to the object pointed to by the iterator is:

    const CGrResidue *pGrRes = &(*it);

    Furthermore, I'm not sure how to correctly specify the increment of the iterator in this construct. If I have to specify the increment op separately, this will require even more edits. Actually, it's not hard. Just did:

    const CGrResidue *pGrRes = &(*(it++));

    Makefile for wkGrChem completed.
    Makefile for wkParse completed.
    Makefile for FPSocket completed.


    Created app makefiles. Working on Makefile for rbqUtil. Needed to understand Qt4's new method for including files. Added define 'QT4' for ifdefs around QT4-specific code.

    Successfully adding updated Qt4 code. There are significant changes. I'm very glad I previously used the built-in Qt types such as QString as little as possible, otherwise porting the code would be a nightmare.
    Makefile for rbqUtil completed.

    Started on Makefile for rbqLua, then had to change over to Makefile for frameWk instead, because rbqLua has dependencies on it. Ran into version problem for ui files, created 'app/rbq/res/qt4_ui' subdir to hold newer versions of ui files. But doing 'mkdir' in msys shell gives a dir that doesn't show up in Windows!!!! Fortunately it's just some kind of cacheing bug that was fixed by closing and re-opening Windows Explorer.

    Something is acting very flaky with regard to the existence of new files. Think it's time to reboot Win98. No, my mistake, just confused the 'bas/res' dir with 'bas/app/rbq/res' dir.

    Got the CInputDlg.h header file generated from the ui file, but now including it for CInputDlg_Imp isn't working because it appears that the class is wrapped in some kind of Ui namespace in the new version hdr file. It looks like there have been significant changes in the way Qt ui classes are being implemented.


    Started reading the Qt4 QtDesigner docs. After reading for a bit, I'm starting to get the picture. In Qt 2.3, the Qt Designer and and the uic compiler created a new class that was subclassed from QDialog, such as CInputDlg. Then, the application developer would create a subclass of CInputDlg, such as CInputDlg_Imp. In Qt4 however, the user needs to create the implementation class as a subclass of QDialog and then define the uic-generated class as a component of the implementation class.


    The Qt 2.3 moc compiler cannot handle #ifdefs. That's a pain. It's strange too. No, after searching for info on this problem, found a document that states that the moc compiler does not handle conditional macros. We'll have to use a dual file approach with the implementation files in addition to the ui files.

    To work around all such problems, the base names of all Qt4-related interface files have been created with a '_qt4' extension, such as CInputDlg_qt4.h, CInputDlg_Imp_qt4.h, CInputDlg_Imp_qt4.cpp.

    Defining the uic/moc/cpp implicit rule chain in the frameWk Makefile. I discover that gnu make automatically deletes intermediate files.
    Makefile for frameWk completed.

    There is a bug in the current VC6/WIN32 version of the build. Copying all files in the app/rbq directory to the install root results in blowing away the bas Makefile. Need to look up the cvs command to do a get on a specific rev for a repository file to get the root Makefile back. Simple, just do a 'cvs up -r 1.2 Makefile'.

    Working on rbqLua Makefile again. Running into Qt differences in header files with moc defs, which means that the lack of conditional macro support in the moc compiler may turn this port into a major PITA. Can we safely use the '// MOC_SKIP_BEGIN' '// MOC_SKIP_END' directives around the troublesome function declarations? Is moc only needed for 'signal/socket' stuff? I believe that is the case. Man, I am sure glad that I kept usage of that to an absolute minimum. I had a feeling that it would cause problems, and was I ever right.

    Tried adding the #ifdef in conjunction with the MOC_SKIP directive to CRbqGraphicsWindow() and it appears to work.
    Makefile for rbqLua completed.


    Starting on main app makefile. Working on CPdbTreeWid_Imp_qt4, it looks like major changes have been made to QListView, which is going to create some work for me. However, I notice that there is a Q3ListView, which might help. Yes, it does. CPdbTreeWid_Imp_qt4 compiles.


    Updated CRbqProgress with name changes for QProgressDialog. Updated CRbqGraphicsWindow with Q3UriDrag + misc changes. Updated CRbqKeyboard. Next, lots of old QPopupMenu refs in CRbqMenu, so the solution may be to do a #define instead of #ifdefs.

    Tried using the Q3PopupMenu, but got errors including it. The new Qt4 QMenu class uses a new class, QAction, in place of menu item data and accelerators. It looks like updating CRbqMenu will take a bit of work.

    Before going down this road, I have decided instead to try to pursue the Qt3-compatibility route and try to use again Q3PopupMenu. This requires that I solve the error that occurs when including the 'Q3PopupMenu' header file. The error is:

    gcc -I/c/swtools/qt4/include -I/c/swtools/qt4/include/QtCore -I/c/swtools/qt4/include/QtGui -I/c/swtools/qt4/include/QtOpenGL -I/c/swtools/qt4/include/Qt3Support -I../../lib/qhull -I../../lib/glut -I../../lib/lua/include -I../../lib/wklib/inc -I../../lib/wkGrMatrix/inc -I../../lib/wkGeom/inc -I../../lib/wkGraphic/inc -I../../lib/wkChem/inc -I../../lib/wkFastPdb/inc -I../../lib/wkEncon/inc -I../../lib/wkTorsion/inc -I../../lib/wkGrChem/inc -I../../lib/wkParse/inc -Iinc/rbqUtil -Iinc/frameWk -Iinc/rbqLua -Iinc -Ires  -DQT4  -c -O2  src/CRbqMenu.cpp -o../../bld/app/rbq/release/CRbqMenu.o
    In file included from c:/swtools/qt4/include/Qt3Support/q3popupmenu.h:1,
                     from c:/swtools/qt4/include/Qt3Support/Q3PopupMenu:1,
                     from src/CRbqMenu.cpp:12:
    c:/swtools/qt4/include/Qt3Support/../../src/qt3support/widgets/q3popupmenu.h: In member function `int Q3PopupMenu::exec()':
    c:/swtools/qt4/include/Qt3Support/../../src/qt3support/widgets/q3popupmenu.h:36: error: `findIdForAction' undeclared (first use this function)
    c:/swtools/qt4/include/Qt3Support/../../src/qt3support/widgets/q3popupmenu.h:36: error: (Each undeclared identifier is reported only once for each function it appears in.)
    c:/swtools/qt4/include/Qt3Support/../../src/qt3support/widgets/q3popupmenu.h: In member function `int Q3PopupMenu::exec(const QPoint&, int)':
    c:/swtools/qt4/include/Qt3Support/../../src/qt3support/widgets/q3popupmenu.h:38: error: `findIdForAction' undeclared (first use this function)
    src/CRbqMenu.cpp: In member function `bool CRbqMenu::InsertMenuItemA(QMenu*, CRbqMenu::_MenuItemDef*)':

    The identifier 'findIdForAction' is only declared in the qt4/src/gui/widgets/qmenu.h file, so I assume that this is a bug in the Qt4 distribution. However, looking at the include chain, this should be included. Ah, I see, we need the macro 'QT3_SUPPORT' to be defined. Yes, that works and will help a lot.

    CRbqMenu.cpp compiles.

    Some changes needed to eliminate of string temporaries in calls to TrimWhitespace() in wklib::wkStringUtils.

    Error compiling CRbqOption: references to non-static member functions. For some reason, VC60 accepted this. Need to fix it somehow, but before any more changes, will do a full test-build in VC60/Qt2.3NC to make sure things are still working.

    Rebuilt the release version VC60/Qt2.3NC, ran unit tests, same results: 89 pass, 11 fail.

    I'll need to do some C++ reading in order to understand how to properly code for pointers to the member functions of the CRbqOption instance. Actually, the solution is quite simple, just needed to add the '&' symbol before the function names in the function pointer assignment, as specified by Stroustrup, section 15.5. The change is compatible with VC60, it's another example of VC60 being tolerant of non-spec code.

    CRbqOption.cpp compiles. CRbqCmdProcessor.cpp compiles. Only three more files to go! CRbqMainWindow.cpp compiles. CRbqApp.cpp compiles.

    We're finally at the link stage. Next, need a mingw version of glut lib. Then, the linking fun will begin.


    Started linking rbq app, getting numerous undefined references. Created simple C++ test app and linked without any problems. Noticed that I was using 'ld' instead of 'gcc' for the linker! Didn't make much difference when specifying 'gcc'.

    Trying to output a mapfile using the mingw linker and it doesn't work. Ah, gcc doesn't pass these options to ld without the 'Wl' flag. Switched back to specifying 'ld' as the linker.

    Aha! Found it, looking at the LOAD lines in the mapfile. There are backslashes in the paths for the low-level libs. Why no error reported by the linker? Maybe that isn't the problem. No, there is a problem. Added the '--verbose' switch and now it's reporting failures in opening input files.

    Dumbkoppf! I found it. In defining my very first linux file, I specfied a '.la' extension instead of a '.a' extension. I need to go through and change every single Makefile. Sheesh.

    Fixed lib names so that they are loading now. This removed many of the undefined refs. Now, getting a bunch of undefined refs for a small number of symbols that I don't know about:

    ../../bld/app/rbq/release/CInputCmdDlg_Imp_qt4.o(.text+0x1ed):CInputCmdDlg_Imp_qt4.cpp: undefined reference to `__Unwind_SjLj_Register'
    ../../bld/app/rbq/release/CInputCmdDlg_Imp_qt4.o(.text+0x221):CInputCmdDlg_Imp_qt4.cpp: undefined reference to `__Unwind_SjLj_Unregister'
    ../../bld/app/rbq/release/CInputCmdDlg_Imp_qt4.o(.text+0x278):CInputCmdDlg_Imp_qt4.cpp: undefined reference to `_InterlockedIncrement@4'
    ../../bld/app/rbq/release/CInputCmdDlg_Imp_qt4.o(.text+0x2c7):CInputCmdDlg_Imp_qt4.cpp: undefined reference to `_InterlockedDecrement@4'
    ../../bld/app/rbq/release/CInputCmdDlg_Imp_qt4.o(.text+0x302):CInputCmdDlg_Imp_qt4.cpp: undefined reference to `_InterlockedDecrement@4'

    Did a grep on the mingw libs and the symbol '__Unwind_SjLj_Register' is reported to be in libstdc++, so I'm not sure what the problem is. Since it's also in libsupc++, tried adding that to the link line. Makes no diff.

    Found a couple of posts on the mingw users group on sourceforge confirming this is something to do with exception handling. The 'SjLj' has to do with 'set jump/long jump'. One person suggested trying the '-fno-exceptions' flag.

    Tried that, and it got rid of the 'SjLj' undefined ref, but there is still the 'InterlockedIncrement' error. There is a thread that mentions this problem, but doesn't give a solution. A grep on the mingw libs mentions this symbol in libkernel32.a in addition to libstdc++.a, so will add the kernel32 lib to the link line as well. Yes! That fixed it.

    Did full rebuild with the '-fno-exceptions' flag add to all Makefiles and this removed many undef refs, but there are still many left, which I suspect may be related to library ordering on the link line, as they are undef refs for symbols that I'm now sure should be available in one of the libs. Currently, my understanding is that the order of libs on the line should be 'greatest dependency-first', that is, I am specifying the most low-level libs first, such as -lstdc++, just as I do with include files. After reading some posts on usenet, see that this is the exact opposite, the lowest-level libs should come last.

    This greatly reduced the number of undef refs. Many now are '...SjLj..' undefs in libstdc++, so now I should perhaps go through and take out all of the '-fno-exceptions' flags from the Makefiles after getting over this major conceptual hole of link ordering that I've had all this time (about the Unix linker). Took out the flag (I can always specify it globally now after adding a 'USER_CFLAGS' macro to every Makefile).

    Verified with 'nm -u' that the '...SjLj...' symbols are undefined in libstdc++ and libsupc++. Found the /mingw/lib/gcc/mingw32/3.4.2/ subdir with more libs which have those symbols in them. Used 'nm --defined-only' to verify that those symbols are defined in libgcc.a. Made 'gcc' the linker again and used the '-Wl,(link-option)' switch instead, so that gcc will automatically add in the libgcc.a lib during link.

    Wow! Down to only 2 undefined refs!

    Link succeeded!

    Checked in the code, then tried to run it. Got a page fault in QTGUI4.DLL, which is not unexpected. Next, will do a full debug build.


    Completed full debug build, started stepping through the program in gdb. Program segfaults in CRbqMainWindow constructor during creation of CPdbTreeWid_Imp. No, that result is spurious, as it segfaults earlier when running to breakpoints instead of stepping. But when segfaulting, the 'bt' command shows the stack trace which shows that it is indeed in the CPdbTreeWid_Imp constructor, so perhaps the breakpoints are not being hit for some reason?

    Can't get gdb to stop at the breakpoints that I set. It's very frustrating. By doing 'step' and 'next' commands, I'm able to get to the point in the CPdbTreeWid_Imp constructor where it crashes, line 217, where it constructs a QFontMetrics object.

    Searching in the mingw users group and found a mention of a bug in gdb breaking into class constructors, but couldn't find additional info on that. Read some more about the problem at the gdb mailing list archive at RedHat. Apparently, this is a well-known problem, and there are patches to fix it. But perhaps I won't worry so much about that right now.

    Created mixed source/assembly output of CPdbTreeWid_Imp.cpp using:

    gcc -S -g (includes) app/rbq/src/CPdbTreeWid_Imp_qt4.cpp
    as -ahld CPdbTreeWid_Imp_qt4.s > CPdbTreeWid_Imp_qt4.mixed

    With this, was able to do stepi to see exactly where things got messed up:

    mov %eax,(%esp,1)
    mov 0x68d058,%eax
    call *%eax

    Intel format:

    mov DWORD PTR [esp], eax
    mov eax,ds:0x68d058
    call eax


    Downloaded mingw-make32.exe and building debug version of Qt4. Did build according to instructions in one post on the Qt Interest mailing list archive at Trolltech, which says that the Qt4 source can be built from a DOS box (not msys):
    configure -platform win32-g++ -fast -no-accessibility -debug -no-dsp -no-vcproj

    The configure completed, but the make failed because of ampersands in the make commands:

    cd src &&&& C:/SWTOOLS/MSYS/1.0/MINGW/BIN/MINGW3~4.EXE first
    Too many parameters - &&&&
    cd tools &&&& C:/SWTOOLS/MSYS/1.0/MINGW/BIN/MINGW3~4.EXE first
    Too many parameters - &&&&
    cd demos &&&& C:/SWTOOLS/MSYS/1.0/MINGW/BIN/MINGW3~4.EXE first
    Too many parameters - &&&&
    cd examples &&&& C:/SWTOOLS/MSYS/1.0/MINGW/BIN/MINGW3~4.EXE first
    Too many parameters - &&&&

    Looked through the source for creating the makefiles, but couldn't figure out where and how the ampersands are being defined. One option is to go through and manually edit the makefiles to move the ampersanded commands to another line.

    Learned a handy trick in vim for specifying carriage-returns in substitute commands:

    %s/&& /[Ctrl-M]\t/gc

    This hack doesn't work because after execution of 'cd (dir)', the cwd changes back to the parent, causing the next command, the subdir make, to fail. Ok, there is another option. we can try the '-C (dir)' param instead. However, one problem with this is that the subdir make call is actually using qmake.

    Tried using the '|' symbol as a replacement for the ampersands and this may acutally work.


    Reinstalled Qt4 to a new directory, this time also choosing to download and install the minimal mingw version from the Qt installer.

    After install, and running (qtdir)\bin\qtvars.bat, the makefiles were created, but still get the same problem with the ampersands.

    Started going through and changing the makefile commands to use the '-C (dir)' option instead. This appears to be working. And it's actually not as much work as I thought before, for editing the Makefile. So far, I've only had to edit a few lines in the main src/Makefile, as needed to build the debug libs for libqtmaind.a, libQtCored4.a, libQtGuid4.a, libQtOpenGLd4.a, and libQt3Supportd4.a

    There is a problem building the libQt3Supportd4.a lib, the make file fails because of dependencies on previous libs that I skipped (network and sql). Enabled building of these libs. Building of debug libs completed.

    Re-link of rbuilder.exe with new debug libs succeeded. Running the program now, get an error asking for the dll QT3SUPPORTD4.DLL. I believe that this is because the debug libs were built as shared. Added path to qt4/lib, ran again, no dll complaint, get segfault again in QtGuid4.dll, as exepected.

    Running the program again in gdb, it's running a lot more slowly now with debug symbols in the Qt code.

    Stepped to the same place as before, now I can do a 'p *pView' to inspect the variable and it returns info instead of the error before where gdb said there was no information on the variable.

    It seems like the widget point returned for the Q3ListView does not appear to be valid, as I get error 'Cannot access memory at address xxx' when trying to inspect it.

    Aha! I think I know what the problem may be. I forgot to call m_ui.setupUi() on the member designer widget for CPdbTreeWid_Imp!! Yeah!!! We have a running window! The toolbars and menus are missing, but this is great progress! The OpenGL window works, as well as the nav controls!

    Ok, got toolbars working by changing QToolbar to Q3Toolbar. Still no menus though. Successfully loaded a pdb file and did rendering commands. PDB widget is displaying, but selection of lines in it is not working.

    Got menus working (had to remove an ifdef from when I was using QMainWindow instead of Q3MainWindow).