There are a number of options where you want to color just a range of atoms,
not the full set. So, for example,
color temperature
produces a nice red-to-blue gradation across all the atoms. But if you have
a selected set of atoms and you want red to blue over JUST THOSE, then you
need to
set rangeSelected TRUE
yeah, well, I see THAT's not working properly right now. Alas.....
Bob
On Mon, Aug 30, 2010 at 11:59 PM, Frieda Reichsman <frieda...@mac.com>wrote:
> Interesting. I will have to puzzle over the commands to really parse this
> out. I don't really follow the set rangeSelected bit, but I can look at the
> documentation later. Thanks for looking at this, Bob!
> Frieda
>
> On Aug 30, 2010, at 5:20 PM, Robert Hanson wrote:
>
> Frieda,
>
> Whew! That took all day!
>
> The short answer is that, yes, if you are mapping data, what is selected
> prior to the isosurface command determines which atoms are mapped. it should
> give just a surface fragment.
>
> The longer answer is that in Jmol 11.8 and the currently released versions
> of Jmol 12 you can't map selected atom property data onto JVXL surfaces, at
> least not properly. This should be fixed for Jmol 12.0.11 and 12.1.9.
>
> Coloring is now tied to the setting:
>
> set rangeSelected TRUE/FALSE
>
> Note also that
>
> isosurface select {helix} sasurface map property temperature
>
> and
>
> select {helix}
> isosurface sasurface map property temperature
>
> are the same, but they aren't quite the same as
>
> isosurface sasurface map select {helix} property temperature
>
> where the select is AFTER the map keyword.
>
> In both cases you get a fragment, but in the first case, a partial surface
> is created first, then it is mapped; in the second case a full surface is
> created (or, perhaps, read from a JVXL file), and then the property is
> mapped for the specific selected atoms only (and any surface closer to other
> atoms is then removed). It's not a big difference, but it is noticeable.
> The first is faster, but the second is your only option if you have saved a
> JVXL file and are now mapping it (or RE-mapping it). What's happening is
> that when you create a surface for the whole model you are limited in the
> resolution you can get, but the making of a surface fragment will generally
> run at much higher default resolution.
>
> Bob
>
> On Sun, Aug 29, 2010 at 12:46 AM, Frieda Reichsman <frieda...@mac.com>wrote:
>
>> Hi,
>>
>> Does the display of an isosurface (the area it covers) vary depending on
>> what is selected at the time you call the jvxl file? I don't recall this,
>> but it is true in 12.0.8 and 12.0.10. I expect the surface in a jvxl file to
>> be the same surface all the time... but perhaps somehow I have been lucky
>> enough not to trip over this before.
>>
>> Or perhaps it varies when you are mapping something to the surface, e.g.,
>> isosurface surf1 "3d/finalsurface.jvxl" map property_x color translucent
>> -1 colorscheme "user";
>> but then I would expect the color might vary with the selection, but not
>> the surface itself.
>>
>> Frieda
>>
>>
>>
>> On Aug 27, 2010, at 3:47 PM, Robert Hanson wrote:
>>
>> Jmol users --
>>
>> The isosurface/JVXL problems in 12.0 and 12.1 have been fixed. (Jmol 12
>> could crash opening older nonXML JVXL files.)
>>
>> http:/chemapps.stolaf.edu/jmol/docs/examples-12/Jmol-12.zip
>>
>> 12.0.10 will have that in it, probably next week.
>>
>> -- Bob
>>
>> On Mon, Aug 23, 2010 at 8:41 AM, Pshemak Maslak <p...@chem.psu.edu> wrote:
>>
>>> Hello,
>>>
>>>
>>> 4. 12.08 has difficulty in displaying jvxl file written by 11.8. It does
>>> it very slowly (several minutes) and --after finally loading -- the
>>> model cannot be interacted with. I have encountered only one example of
>>> this difficulty, and the jvxl file re-written with 12.08 Jmol works
>>> fine. Could this have anything to do with the changes in the spartan
>>> file reader? (my jvxl files are based on smol spartan files)
>>>
>>>
>>> PM
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>>
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Jmol-users mailing list
>>> Jmol-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>>
>>
>>
>>
>> --
>> Robert M. Hanson
>> Professor of Chemistry
>> St. Olaf College
>> 1520 St. Olaf Ave.
>> Northfield, MN 55057
>> http://www.stolaf.edu/people/hansonr
>> phone: 507-786-3107
>>
>>
>> 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
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>>
>> speed time-to-market. Join now, and jumpstart your future.
>>
>> http://p.sf.net/sfu/intel-atom-d2d_______________________________________________
>>
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>>
>
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> 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 Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
>
> http://p.sf.net/sfu/intel-thread-sfd_______________________________________________
>
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
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 Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
