I'm switching this discussion to Jmol Developers from Jmol Users. What 
do people think? Should I work on atom deletion?

I have made a short(?) list of the affected methods and fields. Some of 
these are easier than others, but all would need very careful 
consideration. It seems to me it might be reasonable to allow deletion 
of a whole model's worth of atoms. That way we can recover memory far 
more efficiently. I'm not keen on trying to delete specific atoms. That 
could be another discussion later if we got this one to work.

There are several questions that I can think of -- such as:

Q: Should the boundbox (which affects zoom) be recalculated?

Q: What are the implications for the state -- that is, how does one load 
and unload models and then still be able to define the state?

Q: What if selected models are deleted from a loaded file?

Q: What if load append commands are interspersed with "unload" commands?

I'm not saying these are unsurmountable problems, but I think they point 
to how major an issue this is and why I haven't gone after it before.


  /* DEVELOPER NOTE -- ATOM/MODEL DELETION --
   *
   * The challenge of atom deletion:
   *
   * Many data structures involve reference to Atom, atomIndex, Model, 
or modelIndex
   * A first-pass list includes:

org.jmol.modelset
-----------------

Atom.atomIndex
Atom.modelIndex
Bond.atom1
Bond.atom2
Chain.model
Group.firstAtomIndex
Group.lastAtomIndex
Model.modelIndex
Model.fileIndex
Model.firstAtomIndex
Model.firstMolecule
Model.chains
Model.bioPolymers
Model.auxiliaryInfo

AtomCollection.atoms
AtomCollection.atomCount
AtomCollection.atomNames
AtomCollection.atomSerials
AtomCollection.bfactor100s
AtomCollection.bspf
AtomCollection.bsHidden
AtomCollection.bsSurface
AtomCollection.nSurfaceAtoms
AtomCollection.clientAtomReferences
AtomCollection.hasBfactorRange   -- set false
AtomCollection.occupancies
AtomCollection.partialCharges
AtomCollection.specialAtomIDs
AtomCollection.surfaceDistance100s -- set null
AtomCollection.tainted
AtomCollection.vibrationVectors

BondCollection.bonds
BondCollection.bondCount

ModelCollection.averageAtomPoint
ModelCollection.bboxModels
ModelCollection.bboxAtoms
ModelCollection.boxInfo

ModelCollection.modelNumbers
ModelCollection.models
ModelCollection.modelSetAuxiliaryInfo["group3Lists", "group3Counts, 
"models"]
ModelCollection.molecules -- just set null
ModelCollection.moleculeCount
ModelCollection.stateScripts ?????
ModelCollection.thisStateModel  -- just set -1
ModelCollection.structures
ModelCollection.structureCount

ModelSet.shapes  (many of these hold references that would need adjusting)

CellInfo.modelIndex
Measurement.countPlusIndices
MeasurementPending.countPlusIndices
Polymer.leadAtomIndices -- can be set null in 
BioPolymer.recalculateLeadMidpointsAndWingVectors()

org.jmol.modelsetbio
--------------------

org.jmol.popup
--------------
 [ would need updating ]

org.jmol.shape
--------------

AtomShape.mads
AtomShape.colixes
AtomShape.paletteIDs
AtomShape.bsSizeSet
AtomShape.bsColixSet
AtomShape.atomCount
AtomShape.atoms

Dots?

Labels.strings
Labels.formats
Labels.bgcolixes
Labels.fids
Labels.offsets
Measures.measurements

Mesh.title (sometimes model-based?)
Mesh.atomIndex
Mesh.modelIndex
Mesh.modelFlags
MeshCollection.meshes
MeshCollection.modelCount
MeshCollection.title ?

Sticks.bsOrderSet
Sticks.bsSizeSet
Sticks.bsColixSet
Sticks.selectedBonds

TextShape.modelIndex

org.jmol.shapebio
-----------------

BioShape.modelIndex
BioShape.leadAtomIndices
BioShapeCollection.atoms
BioShapeRenderer -- all need to be set null

org.jmol.shapespecial
---------------------

Dipole.modelIndex
Dipole.atoms
DrawMesh.drawTypes
DrawMesh.ptCenters
DrawMesh.drawVertexCount
DrawMesh.drawVertexCounts
Draw.modelCount
MolecularOrbital.htModels
Polyhedra.Polyhedrons
Polyhedra.Polyhedron.centralAtom

org.jmol.viewer
---------------

SelectionManager.bsHidden
SelectionManager.bsSelection
SelectionManager.bsSubset
Eval.bsSubset

org.openscience.jmol.app
------------------------

AtomSetChooser ??


   *
   */


-------- Original Message --------
Subject:        Re: [Jmol-users] duplicates and rotateSelected
Date:   Tue, 11 Mar 2008 20:28:46 -0500
From:   Bob Hanson <[EMAIL PROTECTED]>
Reply-To:       [EMAIL PROTECTED]
To:     [EMAIL PROTECTED]
References:     <[EMAIL PROTECTED]>



He wants his duplicates and to eat them, too! I don't know....

Delete atoms. Why don't we do this? Well, there are a lot of data 
structures that depend critically on atom index. To do this properly we 
have to delete the atoms and somehow also clean up the arrays -- 
otherwise it's just a waste of time. I think I've been reticent to go in 
and track down all the atom references in order to delete them. I 
suppose if it were a whole model being removed it might not be so bad. I 
can see the command would be

zap 2.1

or something of that order.

But I hate to think how hard it would be to get this right. I suppose 
I'll look at it....

Say, I like that virus!

Bob


Mauricio Carrillo Tripp wrote:

> BEAUTIFUL!!
> you're the man & Jmol ROCKS
>
> BTW, I was also wondering the same as Lin Yi asked this morning,
> it's a shame it can not be done. Now that I have my duplicates, I would
> like to have a way to remove them, not just hide them...
> Just out of curiosity, can we expect this (unload/delete an specific 
> model)
> on a future release of Jmol?
>
> Thanks again!
>
>     Mauricio, you are just missing the keyword MOLECULAR on that
>     rotateSelected command. Without that, Jmol is using the window
>     coordinates, not the molecular coordinates. Sorry if that's not clear
>     from the documentation.
>
>     Bob
>
>     Mauricio Carrillo Tripp wrote:
>
>     >
>     > sorry Bob, I just tried both 11.5.14 and 11.4.RC10
>     > and still get the same odd behavior.
>     > Could it be something else in the script?
>     > thanks again for your help...
>     >
>     >
>     >     this is fixed for 11.5.14 and 11.4.RC10.
>     >
>     >     Mauricio Carrillo Tripp wrote:
>     >
>     >     > I'm having
>     >     > trouble when rotating them. I'm using the rotateSelected
>     >     > command with the AXISANGLE option, and although
>     >     > the duplicate is the only one that rotates, it does so
>     >     > around what it seems to be a different axis than the
>     >     > one that is defined. I tried setting the center to the origin
>     >     > but that didn't help. I know the rotation axis is correct
>     >     > (I'm drawing it). Most likely I'm missing something, but
>     >     > I don't know what else to try.
>     >     >
>     >     > Here's what I'm doing:
>     >     >
>     >     > select :A.Ca/2.1;
>     >     > x = data("selected","pdb");
>     >     > DATA "append @x";
>     >     > frame all;display 1.1,2.1,3.1;refresh;
>     >     > centerAt ABSOLUTE {0.0,0.0,0.0};
>     >     > select */3.1;
>     >     > draw five_fold_01 ARROW 110 DIAMETER 1 {0.0,0.0,0.0}
>     >     {0.0,70.0,113.4};
>     >     > rotateSelected AXISANGLE {0.0,70.0,113.4} 72.0;
>     >     > trace 0.5;
>     >     >
>     >     > To see it in action:
>     >     >
>     >    
>     http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1>
>     >    
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1>>
>     >     >
>     >    
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1>
>     >    
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1
>     <http://viperdb.scripps.edu/info_page_big_jmol.php?VDB=1dnv&tnumber=1>>>
>     >     >
>     >     > after the model loads, clicking on the "exp" checkbox will
>     >     > run the script above. If you zoom out and rotate with the
>     mouse,
>     >     > you'll see what I mean; the original model in blue, the
>     duplicate
>     >     > in gray and the axis in orange. The duplicate should be
>     rotating
>     >     > 72 degrees around the defined axis (right?), but instead
>     it seems
>     >     > to be doing it "in place".
>     >     >
>     >     > Thanks for your help.
>
>
> -- 
> 0 | Mauricio Carrillo Tripp, PhD
> / | Department of Molecular Biology, TPC6
> 0 | The Scripps Research Institute
> \ | 10550 North Torrey Pines Road
> 0 | La Jolla, California 92037
> / | [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> 0 | http://www.scripps.edu/~trippm <http://www.scripps.edu/%7Etrippm>
>
> ** Aut tace aut loquere meliora silentio **
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Jmol-users mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jmol-users
>  
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jmol-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-users


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to