[Xplor-nih] Xplor-nih Digest, Vol 52, Issue 12

[Gary S. Thompson]

xplor-nih-request at nmr.cit.nih.gov wrote:

>Send Xplor-nih mailing list submissions to
>	xplor-nih at nmr.cit.nih.gov
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://dcb.cit.nih.gov/mailman/listinfo/xplor-nih
>or, via email, send a message with subject or body 'help' to
>	xplor-nih-request at nmr.cit.nih.gov
>
>You can reach the person managing the list at
>	xplor-nih-owner at nmr.cit.nih.gov
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xplor-nih digest..."
>
>
>Today's Topics:
>
>   1. Re: marvin (John Kuszewski)
>   2. Re: error message (John Kuszewski)
>   3. Re: Ligand docking with Hbuild (Charles at Schwieters.org)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 15 Jun 2007 14:40:15 -0400
>From: John Kuszewski <johnk at mail.nih.gov>
>Subject: Re: [Xplor-nih] marvin
>To: "Gary S. Thompson" <garyt at bmb.leeds.ac.uk>
>Cc: xplor-nih at nmr.cit.nih.gov
>Message-ID: <403CC3F8-E3FA-42B1-93BB-26EBFEC16B50 at mail.nih.gov>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>On Jun 15, 2007, at 5:26 AM, Gary S. Thompson wrote:
>
>
>  
>
>>John Kuszewski wrote:
>>
>>Hi John
>>
>>firstly many thanks for all the useful input! The good news was  
>>that I had most of it right already ;-) but it was really nice to  
>>have your comments to read and assure me that i had everything  
>>right especially the deleting of the reference pdb. It would be  
>>rerally nice to have some of the things in thia note in the eginput  
>>directory and possibley a skeleton calculation that was easy to  
>>pickup and use
>>
>>    
>>
>
>Hi Gary,
>
>The next release will see some significant simplification to the  
>eginput.  I've put all of the invariant stuff into a TCL procedure, so
>all that remains in the initMatch scripts is stuff that's relevant to  
>the user.  Should be easier to understand and less error-prone to
>change.
>
>  
>

that sounds like what i was aiming for. One of the toughts i had was to 
allow the old hack of just allowing the user to source a file provided 
on the command line after all the default values have been set which 
would then just contain tcl commands e.g. 'set this 1;  set that 2' it's 
a crude but very nice way to addpreferences to a scriptted program

>  
>
>>unfortunatley it turned out that analysis can't output nmrstra with  
>>shifts and peaks  (yet)
>>
>>    
>>
>
>Exactly what are you using?
>  
>

output is coming from ccpn analysis...

>BTW, very few people seem to use NMR-STAR to hold their peak lists.   
>And there's a lot of variability in the ones
>that exist in the BioMagResBank.
>
>
>  
>
>> I did have to write a short script to get the chemical shift  
>>tranges from the nmrdraw peak table as they have a different format  
>>to pipp:
>>
>>    
>>
>
>Thanks!  I'll test it out (and double-check everything with Frank  
>Delaglio) and, if you don't mind, put it into a future release.
>  
>

that fine I had some feedback from frank on the nmrpipe list and he gave 
me a complete rundown on the format (I will append the comments at the 
end) I think the code I have here is slightly in error as you define the 
sw as extending 1/2 a digital resolution either end of the spectrum 
(i.e. no picket fence error!) and the output from ccpn doesn'yt 
currently have the number of points (theses ar what the two 1's should 
be first and last points) I will therefore talk to wim vranken about 
sorting this so I can put the right corrections in.

>
>  
>
>>#note use of list command to protect string from commands such as  
>>$noe peaks
>>eval match3d \
>>   -peakList [list [$noe peaks]] \
>>
>>    
>>
>
>This isn't necessary.  [$noe peaks] returns a TCL list structure.   
>Wrapping it in another list will almost certainly break something.
>Same thing with wrapping the readSpectralRange calls--those procs  
>also return TCL lists.
>If you're getting errors, there's probably something else wrong.
>
>  
>
Ah but I am afraid I think it is ! its because I do the eval to get the 
folding flags in. This then causes a double substituion of the 
expression causing the list that comes out of  [noe peaks] to be 
flattened to a string and a resulting in a bad function call see 
http://www.equi4.com/wikis/wikit/1535 for an example This is an old 
'feature' that has caught me before as they say eval is alittle evi. The 
example code shows the general run of things....

proc test {} {

    return [list 1 2 3]

}

%test

1 2 3

proc test2 args {

    puts "$args - [lindex $args 0]"

}

%test2 [test]

{1 2 3}  - 1 2 3

%eval test2 [test]

1 2 3  - 1

%eval test2 [list [test]]

{1 2 3}  - 1 2 3


>>I think I have this correct! but as explained in the comments to my  
>>code above I don't know if I need to allow for a 'picket fence  
>>error of 1/2 a digital resolution (I hope I don't)
>>
>>    
>>
>
>You do, depending on how your spectra were processed, and depending  
>on exactly what Frank's headers are giving you.
>The values in the spectral range flags need to be the *exact* shifts  
>about which the folding/aliasing takes place.   Remember that
>in the end, we're going to try to match peak positions to folded  
>shift values to within a rather tight tolerance (0.02 ppm in 1H, 0.2  
>ppm in heavyatoms),
>so even small errors in the spectral range will screw things up.
>
>  
>
indeed this wthat I guessed! As it turns out in our current setup we 
have no folded peak lists (we unfolded the lists in analysis)

>  
>
>>I am afraid there are more! I am quite intereested in what the  
>>graphcs that are on the top of the cvn_3dc_pass1.peaks and  
>>cvn_3dc_pass1.shiftAssignments are what they tell me and what I  
>>should be looking out for
>>
>>    
>>
>
>Good for you for looking at those headers to the peaks and  
>shiftAssignments files.  I find them quite useful.
>  
>

>The graphics are mostly just histograms of various things.  Stuff  
>that I keep track of includes:
>
>1.  Fraction of unassigned peaks.  If your peak list was generated by  
>software peak pickers (nmrDraw, CAPP, etc), it's quite common to see
>large fractions (50% +) of unassignable peaks, depending upon the  
>settings that were used.  Human-picked peak lists tend to be much
>cleaner, and it's unusual to see more than 15-20% of human peaks  
>unassignable.
>
>2.  Number of peak assignments per assigned peak.  This is a  
>distillation of the degeneracy histogram that I also print in  
>the .peaks header.
>
>3.  Number of long range peaks per residue.  If you have a reference  
>structure, the number of good long range peaks per residue is more  
>informative, of course.
>If you have 2-3 per residue, you should be in good shape.
>
>4.  If you have a reference structure, then the fraction of long- 
>range information that's bad is also tremendously informative.  Using  
>the network
>filtering, I can often bring it down to 30-40%.
>
>
>
>  
>
>>so here are some questions
>>
>>    
>>
>
>All of which, I notice, are related to stuff that's in the manuscript  
>I'm working on now.  :-)
>
>
>  
>
I look forward to that then!

>>1. what exceptions and explicitinverseexceptions
>>
>>    
>>
>
>In the sa_pass2 script that's used in the CVN example, I include  
>information not only about the peaks that exist, but also about the
>absence of peaks (which I've been calling "inverse NOEs").
>
>Essentially, if  two shiftAssignments are close (< 4 A), they will be  
>pushed apart unless one of two factors applies:
>If they have an active peakAssignment linking them together (ie.,  
>there's a NOESY peak that could be arising from their interaction), or
>if the two shift assignments have an explicit inverse exception.   
>Explicit inverse exceptions are listed out in the .exceptions file  
>for each
>spectrum.
>
>Explicit inverse exceptions are created for one of two reasons:
>
>1.  The peak that would be created by a particular pair of  
>shiftAssignments is expected to be invisible, because it would appear  
>close to
>the diagonal or the solvent line.
>
>2.  The network filter suspects that those shiftAssignments are close  
>together, even if it can't find an actual peak linking them.
>
>I realize that using the absence of NOE peaks as structural  
>restraints is a bit dangerous, but I've done it in a fairly error- 
>tolerant way:
>
>1.  The repulsive forces use the same linear potential shape as the  
>attractive forces (arising from the peak assignments).  So they can't
>easily overwhelm a bunch of peakAssignments pulling things together.
>
>2.  They're only used during pass 2.  The final pass of structure  
>calculations doesn't use this information at all.
>
>3.  The exceptions generated by the network filter work quite well.
>
>
>  
>
>>2. for the shiftAssignments Number of peak assignments per  
>>shiftAssignment  i take it this is the number of peaks assigned to  
>>each shift
>>
>>    
>>
>
>Close.  Just to bring everyone up to speed with the terminology,
>
>a Peak is a data structure that represents a peak in a NOESY  
>spectrum.  It knows the peak's location, intensity, and so forth.
>
>a ShiftAssignment is a data structure that represents an entry in a  
>chemical shift table.  It has an atom selection (for the protons, and  
>optionally
>for the attached heavy atoms), and knows its chemical shift value.
>
>a PeakAssignment is a data structure that represents a (potential)  
>match between a Peak and two ShiftAssignments (one for the 'from'  
>dimension,
>and one for the 'to' dimension).  A Peak can have any number of  
>PeakAssignments.  PeakAssignments are what are actually used to  
>calculate
>energy & forces.  They are given estimates of their likelihood (as  
>explained in the JACS paper on Marvin), and can be activated/ 
>inactivated during
>annealing.
>
>So the number of peakAssignments per shiftAssignment is different  
>from (and always >=) the number of peaks assigned using each shift
>assignment, because there are generally several peakAssignments for  
>each peak at the beginning of the structure calculation.
>
>
>  
>
>>3. for the peak assignments what are 'completeness of targets'
>>4. for peak are 'Differences between target from proton shifts and  
>>shiftAssignment values' the difference between the shift found in  
>>the peaks for assignments and the shift in the shiftLists
>>
>>    
>>
>
>These are both related to the stripe correction mechanism I added to  
>Marvin.  If I recall correctly, ATNOS does something similar.
>The idea is to correct the values of the chemical shifts to reflect  
>the actual positions of the peaks in the NOESY (to account for  
>differences
>that crop up from changes in pH, etc).  Briefly, the way it works is  
>by first performing a match between peaks and shifts using a very broad
>chemical shift tolerance.  Then intraresidue peak assignments are  
>pulled out, and the locations of the peaks corresponding to those
>intraresidue peak assignments are treated as possible target values  
>for an updated chemical shift.  Since I begin with a broad-tolerance
>match, a bunch of bad target values can crop up.  I filter them out  
>in a few ways.  One of them is by calculating the fraction of that
>shiftAssignment's residue's intraresidue peaks that would still be  
>assigned if I used that particular target shift with a tight tolerance.
>
>
>  
>
>>5. what are the good peak assignments at this stage?
>>
>>    
>>
>
>PeakAssignments are flagged as good (look down in the peaks table for  
>-good flags) if they agree with a given reference structure
>to within a given tolerance (generally 0.5 A).
>
>
>  
>
>>6. what are 'Passing SA pair scores'
>>7. what is the network filter is it network anchoring ala petere  
>>guntert?
>>
>>    
>>
>
>Yes, the network filter is similar to CANDID's network anchoring.  As  
>I've hinted above, I also use it to generate inverse exceptions
>in cases where I suspect a particular pair of shiftAssignments is  
>close, even if I can't find an actual peak linking them together.
>The histograms of SA pair scores I show summarize the internal  
>network filtering scoring system.
>
>
>  
>
>>many thanks
>>gary
>>
>>    
>>
>
>You're welcome.
>
>--JK
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 15 Jun 2007 14:45:21 -0400
>From: John Kuszewski <johnk at mail.nih.gov>
>Subject: Re: [Xplor-nih] error message
>To: Marco Roeben <roeben at fmp-berlin.de>
>Cc: xplor-nih at nmr.cit.nih.gov
>Message-ID: <4B2616B9-3BC9-465E-9A34-E90B8FCB76D4 at mail.nih.gov>
>Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
>
>It means that those two atoms ended up with positions more than  
>9999.9 A away from the
>center of the xplor coordinate system.
>
>It can happen with very big systems, or with systems that aren't  
>covalently bonded.
>Did you forget to include some intermolecular NOEs?
>
>But it's most common to see it in cases where some potential term  
>wasn't set up correctly.
>If a particular term is generating very high energy & force, it can  
>end up throwing an atom
>out into space.
>
>Take a look at the energies reported by xplor during your dynamics  
>trajectory.  Is one term
>very large?  Is the IVM taking extremely short timesteps?  That might  
>put you on the right track.
>
>--JK
>
>On Jun 15, 2007, at 5:21 AM, Marco Roeben wrote:
>
>  
>
>>Hello everyone,
>>
>>could someone explain the following error message to me? I've no  
>>clue what has
>>happened. Thank you very much!
>>
>>
>>PublicIVM::syncPos: recentering atoms
>>cm: { -174.615, 6925.09, -5895.56 }
>> %ATMCHK-ERR: unknown coordinates for atom "    -6   -PHE -CD2 "
>> %ATMCHK-ERR: unknown coordinates for atom "    -6   -PHE -HD2 "
>> %ATMCHK-ERR: Unknown coordinates
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> BOMLEV=    0 reached.  Program execution will be terminated.
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> Subroutine DIE called . Terminating
>>
>>
>>with best regards
>>Marco
>>
>>-- 
>>Dipl. Chem. Marco R?ben
>>Leibniz-Institut f?r Molekulare Pharmakologie Berlin (FMP)
>>Abt.: NMR-unterst?tzte Strukturforschung
>>Robert-R?ssle-Str. 10
>>D-13125 Berlin
>>Tel: 030-94793224
>>Fax: 030-94793169
>>mail: roeben at fmp-berlin.de
>>_______________________________________________
>>Xplor-nih mailing list
>>Xplor-nih at nmr.cit.nih.gov
>>http://dcb.cit.nih.gov/mailman/listinfo/xplor-nih
>>    
>>
>
>
>
>------------------------------
>
>Message: 3
>Date: Sat, 16 Jun 2007 10:26:04 -0400
>From: Charles at Schwieters.org
>Subject: Re: [Xplor-nih] Ligand docking with Hbuild
>To: Clemens C Heikaus <heikaus at u.washington.edu>
>Cc: xplor-nih at nmr.cit.nih.gov
>Message-ID: <E1HzZE4-0000DN-SD at oaf.wireless>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>Hello Clemens--
>
>Please note that this mailing list is for Xplor-NIH, not CNS. But please
>see below for suggestions.
>
>  
>
>>I am a rookie and working on my first NMR structure determination and
>>have to deal with a protein-ligand complex. The protein side is nicely
>>defined with cyana and I have transferred everything over to CNS in
>>order to dock the completely buried ligand (as segid B). I used xplo2d
>>to create both toplogy and parameter files of the ligand (a nucleotide
>>with sugar-ring and base). If I read in a pdb.file of the ligand with
>>protons, it throws them out to create .top and .par file. I really
>>would prefer to have them back in but don't know how. Do I have to use
>>the Hbuild function (I don't know in which interface and where to
>>find/how to run it)? 
>>    
>>
>
>hbuild still requires topology information. Perhaps the prodrg server is
>better than xplo2d at generating proton information?
>
>http://davapc1.bioch.dundee.ac.uk/programs/prodrg/
>
>You will need the protons to get an accurate structure.
>
>best regards--
>Charles
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (GNU/Linux)
>Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
>
>iD8DBQFGc/L8PK2zrJwS/lYRAsxiAJ41wJKHskC6uIYQ5OphA2dTC3U1kQCggxHY
>p9iVgYmMLGrKRHGws8pOLDg=
>=Z41k
>-----END PGP SIGNATURE-----
>
>
>------------------------------
>
>_______________________________________________
>Xplor-nih mailing list
>Xplor-nih at nmr.cit.nih.gov
>http://dcb.cit.nih.gov/mailman/listinfo/xplor-nih
>
>
>End of Xplor-nih Digest, Vol 52, Issue 12
>*****************************************
>
>.
>
>  
>


-- 
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK             Tel. +44-113-3433024
email: garyt at bmb.leeds.ac.uk                   Fax  +44-113-2331407
-------------------------------------------------------------------