OK, I'm catching on. Hydrogen bonds are more than bonds. They have been used as a basis for assigning structure. I understand. Yes, this is an interesting problem. We have:

Frame.freeze():

    if (! structuresDefined)
      mmset.calculateStructures();

Tim, what's the story on this:

class AminoPolymer:

  /*
   * New code for assigning secondary structure based on
   * phi-psi angles instead of hydrogen bond patterns.
   *
   * old code is commented below the new.
   *
   * molvisions 2005 10 12
   *
   */

  void calculateStructures() {
    calcHydrogenBonds();
....


If hydrogen bonding is not used for the calculation anymore, why calcHydrogenBonds()?

Is the comment wrong, or is the calculation unnecessary?

The desire here, I'm sure, is to avoid this rather complex calculation unless it's really needed -- a classic programming problem. You want it organized and predictable, but just running this for any model causes a hit on performance. Very interesting.

OK, so if the calculation is unnecessary, then calculating hydrogen bonds on the fly, though not optimal, might be OK.

All this could be a mute point when visibility flags are restored. Then you can calculate the hydrogen bonds to your heart's content, but they won't display until "hbonds on" sets that flag.

I suggest leaving it until after 10.1. It's a minor bug; very rare application; will have to be addressed in terms of visibility anyway. Probably needs more depth of thought.

Bob


Miguel wrote:

The other issue is distinguishing hbonds as calculated
and as file-determined. We should be able to selectively
display/undisplay these.


I agree.

The same applies to regular bonds as well.


Something associated
with the hbond mask should do the trick here.


Good point.

Maybe we can set a bit in the order field to say whether or not that bond
was 'original'

Good topic for discussion later.



Miguel wrote:

When we set the size on an hbond, the hbond calculation
code is being run because it has never run before.

This is fine. Just don't run the calculation if setting
the size = 0. If setting the size positive, it's pretty
clear that one is asking for the calculation.


I guess my explanation wasn't clear. I think that is part of the problem.

One creates their own hbonds using 'connect hbond ...'. They then change
the size of their hbonds. I don't think that the 'hbond calc' code should
run.

This problem existed in trunk200603 and in the current trunk.

Q: Bob, do you agree that this is a problem, or am I missing something?


It seems to me no big deal. (But see below)


Once the hbond calculation code has been run, it will never
run again ... even if we do a 'connect delete hbond ...'
because the hbond code does not
currently know that hbonds can be deleted.


Obviously we need

hbonds calculate

which might have two flavors -- Rasmol and Jmol, for example.



My thoughts:

* we need to separate hbond size control from hbond autocalculation

I don't see any great need for this. The two are already
separated; we need that default action.  Something else
must be wrong here.


Try the following ... with either trunk200603 or with the current trunk

load 1CRN.pdb
connect hbond (1.O)(1.N)
hbond 0.25

I don't think that it is giving us the desired result.

Take a look and let me know what you think


Miguel



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

--
--

Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr

"Imagination is more important than knowledge." - Albert Einstein



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to