From: Bob H. <ha...@st...> - 2008-04-20 13:02:31
|
Better idea -- this is in Jmol 11.5.30 unless I hear complaints. PROPOSED JMOL DEFAULT CHANGE ----------------------------------------------------- set sequenceRangePhysical (default FALSE) NOTE: The default FALSE behavior for this setting is a change from previous Jmol versions because it was argued that the default behavior is unexpected, nonintuitive, and generally not useful. The issue is with PDB/mmCIF files that contain insertion codes or residue numbers that are out of order and the effect that has on selecting ranges of residues. Setting sequenceRangePhysical TRUE forces "select 1-3" to select residues physically located in the file between and including residues 1 and 3 on any chain. In the case that a chain does not contain either residue 1 or residue 3, no atoms are returned for that chain. This is Jmol behavior through Jmol 11.5.29. Setting sequenceRangePhysical FALSE (proposed default behavior starting in Jmol 11.5.30) translates "select 1-3" to "select resno >= 1 and resno <= 3", ignoring physical location in the file, and not requiring that either residue 1 nor residue 3 exist on any chain. In the case where the residue numbers include insertion codes, the behavior when sequenceRangePhysical is set TRUE is the same as above. So "select 1^A-3^B" selects for all residues in the file between and including those two codes. Both must exist on any given chain for which atoms are returned. When sequenceRangePhysical is set FALSE, the behavior is to logically AND the resno range with the insertion code. The command "select 1^A-3" is the same as "select 1-3^A" and returns the same as "select resno >=1 and resno <=3 and *^A". The selection "select 1^A-3^B" does not make sense in this context and is simply interpreted as "select 1-3^B". In either case, the second number in the range is optional. "select 1-" or "select 1^A-" selects all residues starting with the indicated residue, subject to the rules described above. ----------------------------------------------------- Comments requested. Bob Bob Hanson wrote: >Eric, > >First, I was wrong. You cannot do that test to see if sequence numbers >are out of order. (You probably figured that out.) > >Here's the deal: > > select a-b > >is not the same as > > select resno >= a and resno <= b > >because "a" may include an insertion code. For example: > >load =1JGQ >$ select *^A >7 atoms selected >$ print {selected}.label() >[G]129^A:A.P #123 >[C]186^A:A.P #181 >[G]191^A:A.P #191 >[C]998^A:A.P #976 >[C]1028^A:A.P #1007 >[G]1032^A:A.P #1013 >[C]1362^A:A.P #1344 > >$ select 129^A-130 >2 atoms selected > >$ print {selected}.label() >[G]129^A:A.P #123 >[A]130:A.P #124 > >$ select 129-130 >15 atoms selected > >$ print {selected}.label() >[U]129:A.P #122 >[G]129^A:A.P #123 >[A]130:A.P #124 >[GLU]129:E.CA #6614 >[ARG]130:E.CA #6615 >[ALA]129:F.CA #6854 >[VAL]130:F.CA #6855 >[ASN]129:G.CA #7061 >[GLY]130:G.CA #7062 >[ILE]129:H.CA #7267 >[ASN]130:H.CA #7268 >[GLU]129:J.CA #7523 >[GLY]130:J.CA #7524 >[VAL]129:K.CA #7680 >[GLY]130:K.CA #7681 > >My point here is simply that we can't just change one into the other in >general, because there is no way to generally translate the >residue+insertion code business into the <= / >= notation. Now, if we >said "OK, but if you don't use insertion codes, then "select a-b" should >mean something different than when you do," then I have a problem with >that. > >So perhaps a compromise position is to introduce a flag: > > set sequenceRangeChime > >that dumbs down Jmol to ignore insertion codes and just use the residue >numbers in >= / <= mode. More like Chime/Rasmol. > >Bob > > > > > >When you write > > >Eric Martz wrote: > > > >>I like Rolf's proposed solution very much, for the reasons he states. >>(Thanks, Rolf, for thinking creatively!) >> >>Bob, what do you think about it? >> >>This came up because when one writes simplified user interfaces to >>Jmol (as Eran Hodis is doing in Proteopedia), one wants to give the >>best reasonable result to a command like "select 10-20" without >>complicated explanations and requiring users to look up which >>residues lack coordinates. Sure, we can write code in Proteopedia to >>change the command to ">=/<=", but it seemed to me that this issue >>deserves to be handled better in Jmol itself. Again, Rolf's idea >>seems to me to fill the bill. >> >>-Eric >> >> >> >> >> >> >>>What do you think about the following solution: >>> >>>Only if one of the border residues is not present, the ">=/<=" >>>selection mechanism is used instead. This would mean that nothing >>>would change with respect to numbering irregularities if one makes >>>sure that the border residues of a range are present. This is >>>currently already necessary in order to get a correct range selection. >>>If one of the border residues is not present, the selection is >>>currently not as desired in any case (nothing is selected). But by >>>using the other mechanism in these cases the selection would be >>>probably in >=95 percent as desired. So the overall failure rate would >>>be reduced. And the failure rate for cases with numbering >>>irregularities would not be increased. Only the type of the failure >>>would change. >>> >>>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 >>Jmo...@li... >>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 |