Developer Log - willkn

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.

2004-07-16

• Added rlut rbq_RotateSelectionCen.
• Added rlut rbq_CalcChainRms.
• Added rlut rbq_SetPdbName.
• Added rlut rbq_IsResidueSelected.

2004-07-17

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.

2004-07-18

2004-07-19

• Created rlut rbq_GetFfSettings.
• Created rlut rbq_GetTimestepCount.
• Created rlut rbq_StepForcefield.

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?).

2004-07-20

• Created rlut rbq_GetTotalEnergyTypes.
• Created rlut rbq_GetEnergyName.

2004-07-21

• Created rlut rbq_GetTimestepInteractionCount.

2004-07-23

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.

2004-07-31

2004-08-05

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.

2004-08-06

2004-08-07

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.

2004-08-08

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.

2004-08-09

Note: steps for ssh on GNU/Linux:

• ssh-agent /bin/bash
• ssh-add .ssh/id_rsa
• export CVSROOT=:ext:willkn@cvs.sf.net:/cvsroot/rbuilder
• export CVS_RSH=ssh

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.

2004-08-31

2004-09-01

2004-09-02

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.

2004-09-03

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.

2004-09-04

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).

2004-09-05

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.

2004-09-06

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.

2004-09-07

2004-09-08

• Writing Your Dissertation in Fifteen Minutes (a Day)
• The Chicago Guide to Communicating Science
• Tommorrow Now: Envisioning the Next 50 Years

2004-09-09

Adding keywords to my existing database of references.

2004-09-10

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.

2004-09-14

2004-09-15

2004-09-20

2004-09-21

Added AnnUtil.setBillboard() and supporting billboard code.

2004-09-22

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 'AnnUtil.Sim.new()'. Can we not nest package names? Changed to 'AnnUtil_Sim.new()', 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.

2004-09-23

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.

2004-09-24

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!

2004-09-25

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.

2004-09-26

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.

2004-09-27

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.

2004-09-28

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.

2004-09-29

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.

2004-10-01

2004-10-05

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.

2004-10-07

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 'makeThesis.pl'. 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.

2004-10-13

• wkChem
• wkFastPdb
• wkEncon
• wkTorsion
• wkGrMatrix
• wkGraphic

2004-10-14

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.

2004-10-15

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.

2004-10-16

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 (http://cic.nist.gov/vrml/vbdetect.html), 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.

2004-10-17

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

2004-10-22

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.

2004-10-26

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.

2004-11-02

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.

2004-11-03

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.

2004-11-04

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.

2004-11-05

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!

2004-11-06

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.

2004-11-07

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.

2004-11-08

2004-11-09

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.

2004-11-10

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.

2004-11-11

2004-11-12

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.

2004-11-13

2004-11-15

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.

2004-11-16

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).

2004-11-17

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!

2004-11-18

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.

2004-11-19

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.

2004-11-20

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.

2004-11-21

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/renumPdb.pl'. 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.

2004-11-22

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 'renumPdb.pl' script, and pasted them back into 2fmt_D1.pdb. Finally, can successfully create full dynamic model for all 76 nucleic residues of 2fmt_D1.

2004-11-23

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.

2004-11-24

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.

2004-11-25

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.

2004-11-26

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.

2004-11-27

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.

2004-11-28

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).

2004-11-29

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.

2004-11-30

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

2004-12-01

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.

2004-12-02

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).

2004-12-03

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

2004-12-04

2004-12-05

2004-12-07

2004-12-08

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.

2004-12-10

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.

2004-12-11

2004-12-12

2004-12-13

Finished incorporation of aligned codon model into eln001.

2004-12-15

2004-12-18

2004-12-19

2005-01-01

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.

2005-01-02

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.

2005-01-03

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.

2005-01-04

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.

2005-01-07

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

2005-01-08

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\makefile.win).

2005-01-09

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.

2005-01-10

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.

2005-01-11

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

2005-01-12

2005-01-14

2005-01-15

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.

2005-01-16

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.

2005-01-20

2005-01-27

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.

2005-02-04

2005-06-29

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.

2005-06-30

2005-07-01

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.

2005-07-02

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++));

2005-07-03

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.

2005-07-04

2005-07-05

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.

2005-07-06

2005-07-07

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.

2005-07-08

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.

2005-07-09

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

2005-07-10

configure -platform win32-g++ -fast -no-accessibility -debug -no-dsp -no-vcproj
mingw-make32.exe

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

C:\swtools\qt4d>mingw32-make
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.

2005-07-11

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).