#408 weird color application

closed
Applet (71)
5
2007-12-30
2007-11-09
molvisions
No

hi,

this is a difficult bug to file because I can't pin down exactly when it happens (it seems random at the moment). I am loading an external file with values, and coloring atoms according to those values. a demo can be seen here:

<http://www.molvisions.com/impas/>

or, since my server is wicked slow, downloaded from here:

<http://www.molvisions.com/impas/gly_bact_min.tar>

basically, I load the external file and then use blocks of select statements to color atoms; for example:

select backbone1 and (property_potc1 > 1 and property_potc1 < 3)
color atoms yellow
color atoms translucent 0.9

clicking a radio button in the above demo should apply a single coloring script of this form. but, even though the script and data for each button are exactly the same, often the resulting color scheme is very different. for example, sometimes I see a nice, and extremely wrong, rainbow gradient in the right-hand structure. but not always.

I hope that description made sense. can anyone see a reason why this might be happening?

thanks,

tim driscoll

Discussion

  • Bob Hanson

    Bob Hanson - 2007-11-10

    Logged In: YES
    user_id=1082841
    Originator: NO

    First, better try a newer Jmol version. No sense talking about bugs in 11.1.37.

    Comments:

    color atoms [75,75,75]
    color atoms translucent 0.9
    color trace [75,75,75]
    select backbone1 and (property_potc1 > 0 and property_potc1 < 2)

    1. You can do this and save one step:

    color atoms translucent 0.9 [75,75,75]

    2. OK, you've got me. Why not just

    select backbone1 and (property_potc1 = 1)

    3. With Jmol 11.4.43 you can instead make an array of your color list and process it like this:

    mycolors = "[xff0000],[xff2200],[xff2244],[xff44ff]".split(",");
    for (var i = 1; i <= mycolors.size; i = i + 1);

    print " " + i + " color= " + mycolors[i] + " " + mycolors[i].color;

    select backbone1 and property_potc1 = i;

    color atoms translucent 0.9 @{mycolors[i]};
    color trace @{mycolors[i]};

    end for;

     
  • Bob Hanson

    Bob Hanson - 2007-11-10

    Logged In: YES
    user_id=1082841
    Originator: NO

    OK, Tim, I think I know what's going on.

    Mostly I think the problem was that you used "propertyAtomField" instead of "propertyAtomNumberFeld", and that resulted in the data being misread. I think our new recommendation to use "SET" for Jmol parameters will pay off in this regard. I noticed it because the variable was listed in the state under "user-defined variables" instead of Jmol parameters.

    Clearly we need some more feedback in those data statements that allow you to check that data were read properly.

    Aside from that, I recommend using "var" with your variables. This confines them to the script being run, and when that finishes, then they are flushed, saving memory on those huge data lists.

    Looks like it will be a fabulous resource.

    Bob

     
  • Bob Hanson

    Bob Hanson - 2007-11-10
    • assigned_to: migueljmol --> hansonr
     
  • Bob Hanson

    Bob Hanson - 2007-11-10

    Logged In: YES
    user_id=1082841
    Originator: NO

    Now that I have Jmol 11.3.43 running with your page, Tim, I see that:

    1) The images you saw initially with the radio buttons were correct.
    2) Jmol 11.3.42 has a bug that prevents using propertyAtomNumberField anyway.
    3) Jmol 11.3.43 shows the same colors, but is doing the mapping correctly, so it is independent of the selected atom set.
    4) The key to always getting the same picture with the earlier version of Jmol, since you are NOT using propertyAtomNumberField, is to add

    select *

    just before the data statement.

    I'm guessing that without the atom number field sometimes you had a different selection, and in that case, since the selection is used, it would totally mess up the colors.

    Bob

     
  • molvisions

    molvisions - 2007-11-11

    Logged In: YES
    user_id=920824
    Originator: YES

    hi Bob,

    thanks a lot for working on this. so it sounds like I should 1) upgrade to 11.3.43; and 2) use SET with propertyAtomNumberField. also thanks for the tip about using var! I was a bit worried about memory, especially using multiple data sets for multiple structures.

    oh, the reason for using

    select backbone1 and (property_potc1 > 0 and property_potc1 < 2)

    is that the range is not always 1 unit, and these scripts are generated automatically, so it was cleaner to use a single generic statement.

    cheers,

    tim

     
  • molvisions

    molvisions - 2007-11-12

    Logged In: YES
    user_id=920824
    Originator: YES

    ok, I guess I'm still somewhat confused. using propertyAtomNumberField and Jmol 11.3.44_dev does not change anything in the output. using SET propertyAtomNumberField throws an error:

    eval ERROR: invalid argument
    ----line 6 command 2 of file src/1od0/spt/sccolor_create.spt:
    >> set << propertyatomnumberfield = 1

    (the variable name is camelcase in the script, if that matters.) upon reading the documentation for set, it seems to say that set is not necessary:

    "
    Jmol allows a wide range of settings to be changed using the SET command -- see the categories below for details. Starting with Jmol 11.1.17, the SET command is no longer necessary -- anything you could set with SET can be set simply using an assignment of a value to a variable name:
    "

    also, I noticed that propertyAtomNumberField and propertyAtomField are missing from the documented list of Jmol variables with special meaning. so it seems that I am going about this in the wrong way, or something has changed in the way Jmol implements this?

    tim

     
  • Bob Hanson

    Bob Hanson - 2007-11-13

    Logged In: YES
    user_id=1082841
    Originator: NO

    can't use "set" and "=" both.

    set propertyAtomNumberField 1

    or

    propertyAtomNumberField = 1

    but not

    set propertyAtomNumberField = 1

    I know I need to update the documentation on Jmol parameters. Now that I have a COMPLETE list, I can do that.

    rainbow colors -- right, I see the same blue-to-red coloration across the molecule on the right. Far as I can tell, that's the data you are giving it. Sure looks like it is assigning the right values to atoms to me when I use

    set hoverlabel "%{property_potc1}"

    and scan the model.

    Or I use

    print {atomno=13866}.property_potc1

    I get the value I expect from your data.

    Or I use

    selectionhalos on
    select {property_potc1>30}
    select {property_potc1= 1}

    these look exactly like the coloration.

    So that has to be something with your data, that you have a rainbow.

    Initially you were getting the data assigned correctly because you used the wrong name, and the default in that case was to ignore that column -- since you had the select correct, and the data were all in order anyway, it was still assigning the values correctly.

    So what is with the rainbow?

    Bob

     
  • molvisions

    molvisions - 2007-11-13

    Logged In: YES
    user_id=920824
    Originator: YES

    ah. set, or equals, but not both. that explains it. thanks, Bob; I'll strip out the equals sign.

    re: the rainbow color: what is with it indeed? I'm told that it can't be correct, but I've tweaked the calculations six ways til sunday and I keep getting it. I'll try to reproduce it using VMD or GRASP, and if I can confirm the Jmol view, I'll write it up for Nature. :-)

    hope you are well,

    tim

     
  • Bob Hanson

    Bob Hanson - 2007-11-13

    Logged In: YES
    user_id=1082841
    Originator: NO

    this is kind of cool. A script to visualize molecular data using the molecular atoms themselves using the z direction for the variable....

    var natoms = {*}.size
    for (var i = 1; i <= natoms; i = i + 1);
    var x = {atomno=i}; x.z = x.property_potc1;
    end for;

    also, to get a listing:

    x = {*}.label("%x %y %z %{property_potc1}")
    write var x "x.txt"

     
  • Bob Hanson

    Bob Hanson - 2007-12-30
    • status: open --> closed
     

Log in to post a comment.