Quoting Bob Hanson <[EMAIL PROTECTED]>:
> 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.
>
Good point. We also have a similar problem within the "JenaLib Jmol
Viewer". The amino acid sequence motifs (PROSITE motifs) we are mapping
there onto PDB structures do sometimes overlap. So the coloring order
decides which color wins. We at least tried to minimize the problem by
coloring the larger ones first. This way all are at least partially visible.
One possible solution would be striped atoms,cartoons...
But I guess this would be a lot of work. And it might have a strong
impact on the performance.
>> 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.
>
I admit that this was developed before loops were available. But then
at least the maximum symop/model number should be available. (Not
necessarily identical with the symop/model number. Models are not
always numbered sequentially. And the symop number can be changed by
load filter options.)
>
> 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.
>
Mysteriously I could not reproduce the problem today. The file
containing ~2,000,000 'CA' atoms needed only 3 GB today. And the full
file with ~16,000,000 atoms needed only 23 GB. But there is no obvious
difference that might explain this. And the "out of memory" problem in
spite of 120 GB memory available occured before at least 3 times and
the 'CA'-only file needed at least 2 times 83 GB before.
The "set undo off" helped a lot.
Regards,
Rolf
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------------------------------------------------------------------
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
