Re: CST branch -- February 24, 2011 - 10:03

Hi,

We realized a problem during the preparation of the following patch. Currently, it is impossible to initialize variables in the originally suggested way:

data = "">data.ri_prime = 0.0

in the function func_mf (maths_fns/mf.py) and other similar functions (func_local_tm, func_diff, func_all, and their equivalents for a first and second derivatives).

It
is not possible because of the approved changes of __init__ function in
the class Mf (file maths_fns/mf.py). The array used to store data is
created in the following way:

        self.data = "">        for i in xrange(self.num_spins):
            ...
            self.data.append([])
            ...
            # Loop over the relaxation interactions.
            for j in xrange(self.num_interactions[i]):
                self.data[i].append(Data()) # This is a list dedicated for the storage of interaction specific parameters (i.e. type of interaction, internuclei distance, ...)
                self.data[i][j].interactions=interactions[i][j]
                self.data[i][j].internuclei_distance=internuclei_distance[i][j]
                ...

Thus, the list for a storage of spin specific data does not exist and the suggested variable location does not exist:

self.data[0].ri_prime

We found some possible ways to solve the problem. However we do not think, they are ideal.

First, we can add for each spin a new list except those which store the interaction specific data. Data_spin list would be at the beginning of the array and therefore every loop over interactions in the code has to keep it in mind and start from index 1 not 0 to avoid Data_spin list.

The second possibility is based on the idea to declare for
each spin a class Spin_data. The Spin_data would contain all
spin specific variables (ri_prime, chi2, ...) and also a
class Data which would contain interaction specific data.

What do you think about these suggestions? We will be glad for any better suggestion, than ours.
Best regards,
Pavel

On 18 February 2011 11:11, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:

On 16 February 2011 19:18, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:
> Hi,
>

> sorry for the late response. I am continuing in the discussion - see Section
> 1) of the message:
> https://mail.gna.org/public/relax-devel/2010-10/msg00016.html

Hi,

Don't worry about it, I fully understand how these things are.  I hope
you can add this work to a future publication (and then you can say
that relax version 1.3.x will fully support RNA work, and that all
future versions will have this functionality).  If we have a system
test checking the operation of this code for a small RNA data test set
with CSA tensors, then this part of relax will be guaranteed to always
work.

> We would like to add the implementation of relaxation rate calculation from
> the contributions of the individual interactions in the next patch. It
> covers changes of functions func_mf, func_local_tm , func_diff, func_all,
> and their equivalents for a first and second derivatives (class Mf, file
> maths_fns/mf.py). We suggest to initialize new variables which would store
> values which are related to the spin and not to the individual interactions.
> It concerns calculated relaxation rates (ri_prime), chi squared (chi2), and
> corresponding derived variables (dri_prime, dri2_prime, dchi2, and d2chi2).

This is a good idea.

> The suggested approach is demonstrated on func_mf function. The other
> function will be treated similarly (func_local_tm, func_diff, func_all, and
> their equivalents for a first and second derivatives).
>
>     def func_mf(self, params):
>         ...
>         data = ""> >         data.ri_prime = 0  # Initialization of the variable which will store
> the contribution to the relaxation rate from the individual interactions

I would make this a floating point number for speed, otherwise python
will have perform a conversion from this integer '0' to the float
'0.0'.

>         ...
>         # Loop over the relaxation interactions.
>         for j in xrange(self.num_interactions[0]):
>              ....
>             # Calculate the R1, R2, and sigma_noe contribution of j-th
> interaction.
>             data[j].ri_prime = data[j].create_ri_prime(data[j])

Is there a need to store this if the next step is to sum all values?
Are the individual components needed for the conversion of sigma_NOE
to the steady-state NOE value?  Are the individual values used in the
gradient or Hessian methods?

>             # The individual contribution will be cumulated here.
>             data.ri_prime = data.ri_prime + data[j].ri_prime

This seems ok.

>          ...
>          # Outside the loop the chi2 will be calculated (as it is already in
> the original code):
>
>          # Calculate the chi-squared value.
>          data.chi2 = chi2(data.relax_data, data.ri, data.errors)
>
> The original version of the function data[j].create_ri_prime(data[j])
> calculates the relaxation rates from all interactions (CSA, dipole-dipole,
> Rex). It will be necessary to modify the function to calculate the
> relaxation rate contribution per individual interaction separately.
> Therefore, the equation has to be selected according to both type of
> relaxation rate (R1,R2,sigmaNOE) and type of relaxation interaction
> (dipole-dipole, CSA, Rex, ...). However, this change be covered in a
> separate patch.

It would be better to have it separate.  You may have noticed new code
in your cst branch (after an 'svn up').  I have added system tests in
the main line covering the optimisation of all model-free models (m0
to m9 and tm0 to tm9).  I have merged the code into the branch as
well.  Once these all pass, then it will indicated that your code is
working perfectly.  We also need a system test, i.e. a mini analysis
with script, truncated data and CSA tensors, for showing that the new
CS tensor and multi-dipole code is fully functional.

Cheers,

Edward