>
> More testing:
> Instead of loading some residues at once and then painting all of
> them, I changed the script to select each residue individually and
> then change its colour;
>
> select C1; color [0,0,0];
> select N2; color [0,0,0];
> select C3; color [0,0,0];
> ...
> select N100; color [0,10,0];
> select C101; color [0,10,0];
> ...
>
> Then, the running time of the full script is 42 seconds (2.5 times
> slower). As the color commands are the same, I suppose that the issue
> is related do the selects.
the running time is related to parsing of the script. It's just a very
long script.
>
>
> Now for a bigger DNA (2000 bps)
> -with the script split each 100 lines: 2min 26sec
> -the full script (3000+ lines): i cancelled at 8 minutes...
>
>
> So, clearly, there is an issue with the selects. I think that the cost
> of the function isn't lineal but more like exponential, as multiplying
> the residues number by four doesn't multiply the script running time
> by four but by 12!
>
> How does jmol paint the molecule on load? Clearly it goes a different
> way, because the initial load+paint is just 5-6 seconds
Selecting is extremely fast. It must be the parsing of all those commands
that is slowing the process. You could speed this several ways, depending
upon where the data are coming from:
1) If you are creating these files yourself and you can assign group names
to the atoms in the PDB file, then you could assign colors to those group
names and be done with it.
2) If you can assign a number to the temperature column of the PDB file
corresponding to a color, you can then use a color scheme to assign a
given color to a given "temperature"
3) You don't need to select, then color. You can just
color {N30} [0,0,0]
4) If you know exactly what atoms you want to color, not just their names,
then you could use the (undocumented) color command:
color ({0 4:10 13:15 18:30}) [0,0,0]
The numbers in parentheses+braces are atom index numbers starting from 0.
This feature is used by the state scripts Jmol generates.
Bob Hanson
>
> Thanks for the help,
> Carles
>
> El 10/01/2008, a las 12:46, Angel Herraez escribió:
>
>> Hi Carles
>>
>> This sound strange indeed. I agree that it shouldn't take long.
>>
>> I think that maybe the 100 kB is too long for some unknown memory,
>> stack or cache (I'm just guessing). Try cutting the script file in
>> several pieces and see what happens when you call them one after
>> another (either manually or maybe with a master script)
>>
>> Another idea: test this in the Jmol application.
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
> --
> Carles Fenollosa Bielsa
> Barcelona Supercomputing Center / Life Sciences
> Nexus II / Jordi Girona, 29 / 08034 Barcelona
> +34 93 413 76 02
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
