Rolf Huehne wrote:
>Bob Hanson wrote:
>
>
>>biomolecule oriented Jmol users:
>>
>>I suspect as people play with this more, they will want me to expand on
>>that load filter select option. What else?
>>
>>
>>
>
>It would be nice to have a "color by symop" command (e.g.: color cartoon
>symop).
>
>
Funny you should say that.... I found myself wanting that as well. I
started to put it in, then pulled it. The reason is that in general
atoms can be of multiple symmetry operations ("special positions"), and
so "color symop" is somewhat ambiguous. I know it's not ambiguous in
this context, but that's still an issue. So it's very unclear what one
would do about that.
>I know that it is difficult to define different large color sets. In the
>case of biological units our solution was to use the reverse Jmol chain
>coloring scheme for coloring the different copies of the asymmetric unit
>plus "antiquewhite" for the original part. So for most PDB entries there
>is no overlap between the colors. And even for the other cases the user
>will at least see a difference when switching between the 2 sets.
>
>
>
so the manual way of doing this is:
select symop=1; color whatever;
select symop=2; color whateverelse;
etc.
>I guess it would be possible with the new Jmol scripting possibilities
>to do this "by script". But it will be rather complicated and will at
>least result in very large scripts. (We are doing this now for "color by
>model", but still aided by information from our database. For 60 models
>the command for atom coloring by model is for example 2089 characters long.)
>
>
>
"Color model" would be easy to implement. by the way, you could perphaps
do this with some simple array definitions, a FOR command, and not so
long a script. Maybe not. 2K is not that big a script, though.
Rolf -- I did look into the memory business. I made some adjustments in
the current unreleased development version, but I don't think that will
solve your problem of 16 Mb vs 2 Mb. (Maybe it will.) I'm not seeing
anything like that with simple XYZ files. -- Loading 4064 models of
caffeine requires just a bit more (2K per model) than one model with
100,000 atoms. So either you were seeing an unreal measure of memory
usage, or the
set undo false
makes the difference (try that before loading the file and see what
happens), or something else is going on. I notice that if you have lots
of models the AtomChooser page gets pretty complex. So you might try
this as a batch job without display and see what happens. Using
jmol.jar -n
you get no display, and also no atom set chooser window. Might be
interesting to see if that changes your memory issues. Try this with the
latest code, not what has been released.
If you could send me a somewhat SMALLER example that shows the same
problem, I'd appreciate that. I only have 1Gb on this machine.
Bob
>Regards,
>Rolf
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>Don't miss this year's exciting event. There's still time to save $100.
>Use priority code J8TL2D2.
>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>_______________________________________________
>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 the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
