mailRe: Improving expressions for the CSA interaction


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Alexandar Hansen on September 25, 2006 - 18:09:
Hello,

I'll do the best I can to help clear up some of these questions.

>2.  The CS tensor.

>As the anisotropic component of the CS tensor is set using
>'value.set()', the rhombic component of the tensor could be input in
>the same way.  It's value could be specified as 'CSR' and stored in
>the residue specific variable 'csr'.  This system is also more logical
>than specifying the eigenvalues of the CS tensor (the x, y, and z
>chemical shift components of the tensor).

This actually seems very reasonable.  The code I use in my rough model free program was copied from some code where it was necessary to know the magnitudes of each component.  In relaxation, that isn't necessary.  The only components necessary are delta(zz) (the largest component in magnitude),  eta (asymmetry), and alpha/beta/gamma euler angles.

>I do have one question
>though.  Do we need to input the isotropic chemical shift for your
>equations? 

No

>Actually it
>would be useful if the equations were represented in text format to a
>post to relax-devel.  This text could be included in the comments to
>the new code.

The equations are quite complex and would be incredibly tedious to write them as text.  I'll try when I'm working in the code, but I think leaving a few references should be sufficient.

>Another important question is whether the user inputs the CS tensor
>orientation (Euler angles, quaternions, etc).  Is it necessary that
>the user inputs these values or are they dependent on the PDB
>coordinates?  If we can remove this requirement away from the user and
>handle it in the code, it would be better.  The less the user does,
>the better - this is an important philosophy behind relax.  Otherwise
>we could again use the 'value.set()' function to set parameters such
>as 'CS_alpha', 'CS_beta', and 'CS_gamma'.

The simple answer is yes, it's necessary.  The orientation and CSA parameters are equivalent to knowing the appropriate bond length for a dipolar interaction.  What the relaxation equations need are the orientations of the principle components with respect to the diffusion frame.  What I currently do is relatively simple, and I'll take a protein Ca as an example:  I find three nuclei in a plane, in this case Ca, N, and CO would work, and generate a unit tensor for the nucleus of interest.  I take what is known about the tensors orientation, converted into euler angles, and rotate the CSA tensor into it's molecular frame.  I then assume that the PDB is in the diffusion frame and calculate the euler angles from the rotated unit tensor, and these are what enter into the relaxation equations. My effort in keeping things simple for the user is to provide a table (or tables) of CSA values and orientations.  I can imagine a parameter such as 'CS_input' where one could choose DFT, SS NMR, Solution NMR, etc and the program would read the necessary values from the designated table.  These values are just now being well characterized in RNA/DNA and I know they have been studied in some depth for proteins. Long story short, there isn't a final consensus on what CSA is right, every base and ribose nucleus is different, and no study has really studied every nucleus fully (ie. in SS NMR, angles are still derived from DFT calculations).  This is the only way I can think of to keep things relatively simple, given that the CSA is rarely, if ever, simple.


>The most involved solution would be to create a new user function such
>as 'csa.init()' which mimics the 'diffusion_tensor.init()' function.

I can only imagine that some form of this will be necessary, but I can't say for sure right now.



>3. Locating homonuclei.

>This could be either very easy or quite complex.  If only the
>neighbouring bonded heteronuclei need to be taken into account then
>these could be easily extracted from the PDB. 

This could be possible, but we would need to choose what's important for every nucleus.  This wouldn't necessarily be problematic for 13C/15N/X nuclei but if someone were interested in 1H nuclei, this would be very tricky.


>Otherwise if
>atoms from other residues need to be taken into account, an algorithm
>for identifying atoms within a certain radius may need to be coded.

I have written some C code to do this.  It would likely need to be revamped (perhaps considerably) for it to work in python.


>The final question is, what is then done with these spins?

Homonuclear R1 relaxation becomes very dominant in large molecules (the spectral density term J(wi-wx) becomes a J(0) term).  These homonuclei are used to calcuate the contribution to auto-relaxation.  Pulse sequences, if written well, remove any and all cross-relaxation contributions.  The homonuclear R1 can be calculated using the heteronuclear equations if one assumes that the nucleus is excited selectively, which is easily done for many cases where the two homonuclei have significantly different isotropic CS values (is this true for proteins?).  Directly bonded nuclei of course contribute the most but if there are any other nuclei that are in fixed positions relative to the nucleus of interest and <~4 Ang away in a relatively large molecule (tau(m) > 10-15 ns) these interactions may or may not be negligible contributors to R1.  This, of course, isn't necessary if samples aren't uniformly 13C labeled (although most are) and another parameter could be introduced such as 'DD_homonuc' which could be set as 'No', 'Hetero', or 'Homo' to declare how to calculate the contributions for that particular spin.  The XX contribution to R2 is rarely very significant.


>4. The optimisation of the new equations.

>A clear statement of the problem
>including which values are fixed, which are optimised, the equations
>used, etc, would be of help in determining the scope of the changes required.

I would definitely refrain from optimizing anything more than what is already done in relax.  The number of variables is already increasing out of control. Currently I assume (a very poor assumption in all likelihood) that the CSA, XH, and XX relaxation mechanisms feel the same modelfree S2 and tau parameters. Perhaps in the future more optimization could be addressed, but if we worked on that now I would be submitting MY thesis before we have a working version of it.


>5.  Misc.

>You said that the model-free parameters are the same for the CS and
>dipolar interactions, does this mean that you assume the same spectral
>density J(w) for both relaxation mechanisms?  This would simplify
>implementation.

Yes and No.  With diffusion more complex than the spherical case, the asymmetry can not be pulled out of the spectral density equations.  What I did was write one function to calculate the spectral density for as complex a system as I needed and then input the complexity whenever I call on it.  When looking at the extended model free equations, what this means is that the c0, c1, and c2 terms include not only theta(or beta) but also eta, alpha, and gamma.  Gamma drops out when the diffusion is axially symmetric.  For dipolar relaxation, eta = 0, and so alpha and gamma both drop out as well.


>Also relax handles all types of Brownian rotational
>diffusion including diffusion as a sphere, spheroid, and ellipsoid.
>The original reference has equations for an ellipsoid and you have
>derived the equations for a spheroid.  Are there equations for the
>sphere (isotropic diffusion)?

For isotropic diffusion, no angular/asymmetry parameters are necessary.  In fact, for a spherical molecule, the current state of the equations is perfect and no changes need to be made.  Unfortunately, I don't know how often a molecule is perfectly spherical.


>The best place to dive in to would be setting the rhombic CS tensor
>component in 'value.set()'.  This will involve modifying code in the
>file 'specific_fns/model_free.py'.  If you do get lost in the large
>code base, don't hesitate to ask questions in this forum.

I'll definitely do that.


I hope this answers some questions without posing a whole list of new ones :)   If anything I've said is confusing or flat out wrong, please let me know as I would love for things to be simpler than I currently see it to be.  I appreciate all of your discussion and suggestions.  I'll post questions and progress whenever I get a chance.  Thanks!


Alex Hansen




Related Messages


Powered by MHonArc, Updated Tue Sep 26 19:00:46 2006