[Jmol-developers] new bond command

[Miguel <mi...@jm...>]

I wrote this email before ... but lost it :-( ... so this one is a bit
shorter and does no have as much explanation.

----

The Jmol scripting language needs a commmand for explicitly creating a bo=
nd.


What should the command be called?
----------------------------------

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 i=
t
links two atoms.

We may be able to consolidate 'wireframe' and 'link' under a unified
'bond' command.


Q: Thoughts on script command name? Do you like 'bond' or 'link' or
something else?




How are atoms specified?
------------------------

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=3D1; link atomno=3D2; =23 link atoms 1 and 2

  select atomno=3D1,atomno=3D2; link selected; =23 also link atoms 1 and =
2

  select =5BCYS=5D1.CA; link =5BARG=5D2.CA

  select all; link all; =23 link every atom with every other

  select carbon; link hydrogen; =23 link each carbon with every hydrogen


Q: Thoughts?


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 comman=
d
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 <=3D 1.5
Angstroms.

But, this might get in the way and become an annoyance if the distance is=

never used.

 select atomno=3D1; link 99.0 atomno=3D2;

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=3D1; link (atomno=3D2);
  select carbon; link 1.5 (hydrogen or oxygen);


Q: Thoughts?


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.


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 =7C double =7C triple =7C aromatic =7C hydrogen =7C <d=
iameter>


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; =23 choose or .OR. and
  wireframe delete;

Q: Is bond removal really desired/needed?




Please give me your feedback.

Miguel