On 20 September 2011 18:17, Pavel Kaderavek <
pavel.kaderavek@xxxxxxxxx> wrote:
> Hi,
> I don't know what happened. I believed I did everything as usual. Peter is
> away now, but we can try to solve it without him. Should I try to send
> something once again?
> Pavel
>
> On 19 September 2011 15:59, Edward d'Auvergne <
edward@xxxxxxxxxxxxx> wrote:
>>
>> Hi Pavel,
>>
>> Would you know what happened with this patch? Has it been applied to
>> the branch. I don't have this commit message in the logs, but the
>> file
https://gna.org/task/download.php?file_id=13916 has been
>> committed!
>>
>> Cheers,
>>
>> Edward
>>
>>
>> On 19 August 2011 11:46, Pavel Kaderavek <
pavel.kaderavek@xxxxxxxxx>
>> wrote:
>> > This change is related to the task #6397 (
https://gna.org/task/?6397)
>> >
>> > kada _at_ chemi _dot_ muni _dot_ cz
>> >
>> >
https://mail.gna.org/public/relax-devel/2011-03/msg00027.html
>> >
https://gna.org/task/download.php?file_id=13916
>> >
>> > This patch includes the changes in setup_equations function of class Mf
>> > in a
>> > file maths_fns/mf.py. The selection of the equation was modified in
>> > order to
>> > select based on both type of relaxation rate and type of interaction.
>> >
>> > On 12 April 2011 17:06, Edward d'Auvergne <
edward@xxxxxxxxxxxxx> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I think we should avoid optimising the bond length and the CSA tensor,
>> >> if the full tensor is used or if there are multiple bond lengths for
>> >> one spin, at least for now. This could be caught in the setup method
>> >> and a RelaxError thrown saying that the optimisation of these things
>> >> is not yet implemented. That will allow for the current models and
>> >> the new code to work together. Optimisation of the CSA tensor or
>> >> multiple dipole-dipole distances is too much effort for now, and there
>> >> probably isn't enough information in the current data to extract this.
>> >> What do you think?
>> >>
>> >> Cheers,
>> >>
>> >> Edward
>> >>
>> >>
>> >> On 12 April 2011 15:28, Pavel Kaderavek <
pavel.kaderavek@xxxxxxxxx>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > it seems possible, but I think that it means that there will be for
>> >> > each
>> >> > type of the interaction an unique (d,d2)ri_comps function. It will be
>> >> > defined in the setup_equation (mf.py, class Mf). Currently, the
>> >> > (d,d2)ri_comps function is selected just based on the fact whether
>> >> > the
>> >> > values of physical quantities (internuclei distance, csa) are
>> >> > optimized
>> >> > or
>> >> > not. Now it will be selected again according to the same criteria and
>> >> > moreover according the type of interaction. This ensure that inside
>> >> > the
>> >> > function (d,d2)ri_comps the function create_(d,d2)ri_comps will be
>> >> > called
>> >> > with appropriate parameters.
>> >> >
>> >> > Generally, it is probably not very convenient to optimize all
>> >> > internuclei
>> >> > distances, but only the most crucial one (to the bonded hydrogen)
>> >> > would
>> >> > be
>> >> > sufficient. However, the selection should be upon user. The
>> >> > optimalization
>> >> > of CST will be also quite difficult, because 5 parameters would be
>> >> > needed to
>> >> > optimize (3 euler angles + 2 csa values - corresponding to two pseudo
>> >> > chemical shielding tensors which stand for asymmetric chemical
>> >> > shielding
>> >> > tensor - hence I always mention csa1 and csa2 as well as the
>> >> > cross-term,
>> >> > because they are not independent). So far I would consider only the
>> >> > optimalization of the eigenvalues of the tensors, the optimalization
>> >> > of
>> >> > the
>> >> > orientation might be added later.
>> >> >
>> >> > Best regards,
>> >> > Pavel
>> >> >
>> >> > On 22 March 2011 12:23, Edward d'Auvergne <
edward@xxxxxxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> >> > At this point we would like to address a related question.
>> >> >> >> > Currently
>> >> >> >> > the
>> >> >> >> > calculation of physical constant is done in a several steps.
>> >> >> >> > First,
>> >> >> >> > the
>> >> >> >> > physical constant is calculated and the value is stored in the
>> >> >> >> > data.dip_const_func or data.csa_const_func (grad, hess). Then,
>> >> >> >> > when
>> >> >> >> > the
>> >> >> >> > relaxation rates are calculated, the physical constant is
>> >> >> >> > recalculated
>> >> >> >> > by
>> >> >> >> > the function create_dip_func or create_csa_func (grad, hess)
>> >> >> >> > (method
>> >> >> >> > setup_equations in class Mf, maths_fns/mf.py).
>> >> >> >> >
>> >> >> >> > comp_dip_const_func(data, data.bond_length)
>> >> >> >> > comp_csa_const_func(data, data.csa)
>> >> >> >> > for i in xrange(data.num_ri):
>> >> >> >> > data.dip_comps_func[i] = data.dip_const_func
>> >> >> >> > if data.create_dip_func[i]:
>> >> >> >> > data.dip_comps_func[i] =
>> >> >> >> > data.create_dip_func[i](data.dip_const_func)
>> >> >> >> > if data.create_csa_func[i]:
>> >> >> >> > data.csa_comps_func[i] =
>> >> >> >> >
>> >> >> >> > data.create_csa_func[i](data.csa_const_func[data.remap_table[i]])
>> >> >> >> >
>> >> >> >> > There is one exception, the dipolar physical constant is not
>> >> >> >> > recalculated in
>> >> >> >> > the case of calculation R1 relaxation rate, because the
>> >> >> >> > function
>> >> >> >> > create_dip_func does not exist in this case. We do not see a
>> >> >> >> > reason
>> >> >> >> > for
>> >> >> >> > such
>> >> >> >> > a recalculation.
>> >> >> >>
>> >> >> >> The reason is because of the m10 to m39 models built into relax.
>> >> >> >> I
>> >> >> >> have made it possible to optimise the bond length and CSA
>> >> >> >> information.
>> >> >> >> However these models are not stable with the current relaxation
>> >> >> >> data.
>> >> >> >> I do plan on working with these in the future though, so it
>> >> >> >> would
>> >> >> >> be
>> >> >> >> useful to keep them. Note that for models m0 to m9, the
>> >> >> >> data.create_dip_func[i] and data.create_csa_func[i] function
>> >> >> >> pointers
>> >> >> >> are set to None. Therefore for normal model-free analysis the
>> >> >> >> constant is not recalculated.
>> >> >> >>
>> >> >> >>
>> >> >> >> > It seems better to us to just change the coefficient in the
>> >> >> >> > functions comp_r1_dip_jw, comp_r2_dip_jw, comp_r1_csa_jw,
>> >> >> >> > comp_r2_csa_jw
>> >> >> >> > (maths_fns/ri_comps.py). I guess, that this design was
>> >> >> >> > dedicated
>> >> >> >> > to
>> >> >> >> > avoid
>> >> >> >> > multiple calculation of the same interaction constant for each
>> >> >> >> > measured
>> >> >> >> > relaxation rate. We would suggest to reach the same effect by
>> >> >> >> > this
>> >> >> >> > construction:
>> >> >> >> >
>> >> >> >> > for i in xrange(data.num_ri):
>> >> >> >> > if data.const_func[0]:
>> >> >> >> > data.const_func[i] = data.const_func[0]
>> >> >> >> > else
>> >> >> >> > data.create_const_func(data)
>> >> >> >>
>> >> >> >> For models m10 to m39, this construct will not work. The
>> >> >> >> constants
>> >> >> >> are already pre-calculated for models m0 to m9 so this is not
>> >> >> >> needed.
>> >> >> >>
>> >> >> >>
>> >> >> >> > Note, the comp_dip_const_func and comp_csa_const_func should be
>> >> >> >> > change
>> >> >> >> > so
>> >> >> >> > that, it is possible to call them just with the argument data
>> >> >> >> > (maths_fns/ri_comps.py). Instead of:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > def comp_dip_const_func(data, bond_length):
>> >> >> >> > """Calculate the dipolar constant.
>> >> >> >> >
>> >> >> >> > ...
>> >> >> >> >
>> >> >> >> > if bond_length == 0.0:
>> >> >> >> > data.dip_const_func = 1e99
>> >> >> >> > else:
>> >> >> >> > data.dip_const_func = 0.25 * data.dip_const_fixed *
>> >> >> >> > bond_length**-6
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > It should look like:
>> >> >> >> >
>> >> >> >> > def comp_dip_const_func(data):
>> >> >> >> > """Calculate the dipolar constant.
>> >> >> >> >
>> >> >> >> > ...
>> >> >> >> >
>> >> >> >> > if data.internuclei_distance == 0.0:
>> >> >> >> > data.const_func = 1e99
>> >> >> >> > else:
>> >> >> >> > data.const_func = 0.25 * data.dip_const_fixed *
>> >> >> >> > data.internuclei_distance**-6
>> >> >> >>
>> >> >> >> The bond_length arg was designed so that the bond length could
>> >> >> >> either
>> >> >> >> come from a fixed value supplied by the user or from the
>> >> >> >> parameter
>> >> >> >> vector when bond lengths or CSA values are optimised. This
>> >> >> >> behaviour
>> >> >> >> might have to be preserved.
>> >> >> >>
>> >> >> >>
>> >> >> >> > data.dip_const_func were renamed to more general
>> >> >> >> > data.const_func
>> >> >> >> > and
>> >> >> >> > instead
>> >> >> >> > of bond_length the function directly takes the internuclei
>> >> >> >> > distance
>> >> >> >> > for
>> >> >> >> > the
>> >> >> >> > current dipole-dipole interaction. The change of
>> >> >> >> > data.dip_const_func
>> >> >> >> > to
>> >> >> >> > data.const_func later simplify the code design in the
>> >> >> >> > maths_fns/ri_prime.py
>> >> >> >> > . It will be reduced just to a multiplication of constant and
>> >> >> >> > the
>> >> >> >> > linear
>> >> >> >> > combination of spectral density functions.
>> >> >> >>
>> >> >> >> For models m10 to m39, I'm not sure if this design would work.
>> >> >> >> Could
>> >> >> >> we redesign this in another way in which these complex models are
>> >> >> >> still functional?
>> >> >> >>
>> >> >> >
>> >> >> > Then, we would suggest to call the function comp_dip_const_func,
>> >> >> > comp_csa_const_func ... with full set of possible parameters, i.e.
>> >> >> > comp_dip_const_func(data,internuclei_distance,csa1,csa2,rex)
>> >> >> > comp_csa_const_func(data,internuclei_distance,csa1,csa2,rex)
>> >> >> > ...
>> >> >> > If we would call the function with just physically relevant
>> >> >> > arguments
>> >> >> > then
>> >> >> > we would have to use yet another condition to decide the type of
>> >> >> > the
>> >> >> > interaction in the loop where individual interaction contributions
>> >> >> > are
>> >> >> > calculated. The physical quantities irrelevent for the given
>> >> >> > interaction
>> >> >> > (for example csa1,csa2,rex for the dipole-dipole interaction) are
>> >> >> > None
>> >> >> > from
>> >> >> > the initialization and will not be used by the function anyway.
>> >> >>
>> >> >> It would be easier to have a different function for each physical
>> >> >> constant, as this is very specific code. For example
>> >> >> comp_dip_const_func is only called from functions which require the
>> >> >> dipolar constant. For the normal model-free models, this is only
>> >> >> called during setup. So there is no need to pass in the csa1 and
>> >> >> csa2
>> >> >> constants, or Rex for this specific function. For the CSA
>> >> >> constants,
>> >> >> do you calculate 2 separate constants? For example would you use:
>> >> >>
>> >> >> comp_dip_const_func(data[i],internuclei_distance)
>> >> >> comp_csa_const_func(data[j],csa1)
>> >> >> comp_csa_const_func(data[k],csa2)
>> >> >>
>> >> >> where data[x] in each case is a different interaction?
>> >> >>
>> >> >>
>> >> >> >> > Moreover, there is an unanswered question about the NOE and the
>> >> >> >> > additional
>> >> >> >> > dipolar interaction. I am not sure if the suggested design is
>> >> >> >> > physically
>> >> >> >> > correct, rather not. During the NOE experiment, the protons are
>> >> >> >> > saturated in
>> >> >> >> > order to reach the steady state. Then a complete set cross
>> >> >> >> > relaxation
>> >> >> >> > rates
>> >> >> >> > between all interacting spin pairs should be taken into the
>> >> >> >> > account,
>> >> >> >> > not
>> >> >> >> > only between the spin of interest and all other interacting
>> >> >> >> > nuclei.
>> >> >> >> > On
>> >> >> >> > the
>> >> >> >> > other hand this is probably beyond the aim of the program
>> >> >> >> > relax.
>> >> >> >> > What
>> >> >> >> > do
>> >> >> >> > you
>> >> >> >> > think about that?
>> >> >> >>
>> >> >> >> This is getting quite complex as you would need to take the
>> >> >> >> cross-correlated relaxation rates between the different
>> >> >> >> relaxation
>> >> >> >> interactions into account, as well as the motion of all spins if
>> >> >> >> they
>> >> >> >> are not directly bonded. Is this needed for the current work?
>> >> >> >> Of
>> >> >> >> course anything is accepted into relax, especially if you would
>> >> >> >> like
>> >> >> >> to probe this area (with a paper in mind), but it has to play
>> >> >> >> nicely
>> >> >> >> with the rest of relax and not be a burden on the relax
>> >> >> >> developers
>> >> >> >> to
>> >> >> >> maintain in the future (as well as not make the current number
>> >> >> >> crunching code slower than it already is). The code would
>> >> >> >> therefore
>> >> >> >> need to be designed in public. So if you would like to tackle
>> >> >> >> such
>> >> >> >> a
>> >> >> >> task, I would first recommend finishing off the cst branch, and
>> >> >> >> then
>> >> >> >> make a new branch for this work.
>> >> >> >
>> >> >> > Then, I will design the code as I suggested. So, the sigma_noe
>> >> >> > will
>> >> >> > be
>> >> >> > calculated separately for all dipole-dipole interactions with the
>> >> >> > central
>> >> >> > spin (assuming they are isolated spin pairs). The total sigma_noe
>> >> >> > will
>> >> >> > be
>> >> >> > calculated as a sum of all individual sigma_noe contributions.
>> >> >>
>> >> >> This sounds the most reasonable for a first approximation. In
>> >> >> reality
>> >> >> the cross rates will be important as well.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Edward
>> >> >
>> >> >
>> >
>> >
>
>
Re: CST branch