Miguel wrote:
The Jmol scripting language needs a commmand for explicitly creating a bond.
As noted earlier, I agree.
If this is a script command to create bonds then it seems that it should
be called 'bond' ... the verb bond.
Then again, the other script commands are called 'spacefill' and
'wireframe', not 'atom' and 'bond'. This has the advantage in that there
is not confusion between the command name and the abstract concept/object.
For the purposes of this memo, I am going to call it 'link' ... because it
links two atoms.
We may be able to consolidate 'wireframe' and 'link' under a unified
'bond' command.
The link command seems unambiguous
The 'monitor' command in rasmol takes atom numbers as arguments. I don't
like this.
We already have a very flexible and powerful mechanism for specifying
atoms. Atom expressions allow us to select atom sets based upon a number
of characteristics.
The 'link' command should use atom sets to specify the atoms.
It is hard for me to specify more than one atom set. Therefore, the
mechanism would need to be:
select <source-atom-set>;
link <target-atom-set>;
Atoms in the source set would be bonded to atoms in the target atom set.
Nothing would be bonded with itself. If the bond already existed then a
second bond would not be created.
The following would all work;
select atomno=1; link atomno=2; # link atoms 1 and 2
select atomno=1,atomno=2; link selected; # also link atoms 1 and 2
select [CYS]1.CA; link [ARG]2.CA
select all; link all; # link every atom with every other
select carbon; link hydrogen; # link each carbon with every hydrogen
OK
Should distance be part of the criteria?
----------------------------------------
The last two examples above demonstrate a problem; it will be easy to
build a pile of spaghetti with *way* too many bonds. But this is a command
for adults, so we should be able to deal with it.
The 'polyhedra' command has a similar option that perhaps we should
consider. It might be useful to have a 'distance' criteria in the target
set specification. That is:
select carbon; link 1.5 hydrogen;
This would link carbons with each hydrogens if the distance was <= 1.5
Angstroms.
But, this might get in the way and become an annoyance if the distance is
never used.
select atomno=1; link 99.0 atomno=2;
The problem is, I don't know how easy it will be to make the distance
optional, unless we say that the atom expression is in parentheses ... as
in:
select atomno=1; link (atomno=2);
select carbon; link 1.5 (hydrogen or oxygen);
As long as distance is not a required parameter, this option
might be useful
What about multiple models/frames?
----------------------------------
Atoms can only be connected with other atoms that are in the same model.
That is hard-fast and fixed.
Atom expressions give full control over the sets of atoms that are to be
bonded, including specification of models.
Therefore, I do not think that there will be any problems with supporting
multiple models ... I think it will just work as desired.
Great!
Bond order
----------
Specifying bond order is modifying the properties of an existing bond.
Therefore, specifying bond order should operate like the existing
mechanism for specifying diameter.
We should extend the 'wireframe' command to allow the following:
wireframe single | double | triple | aromatic | hydrogen | <diameter>
This would be a nice touch.
Bond removal
------------
I think that we could remove bonds without causing problems. I think that
this could work on an existing selected set of bonds ... as another
extension to the 'wireframe' command.
select <some-set-of-atoms>;
set bondmode or; # choose or .OR. and
wireframe delete;
Q: Is bond removal really desired/needed?
This might be a useful feature.
Bill
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
