mailRe: CST branch


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

Header


Content

Posted by Edward d'Auvergne on February 25, 2011 - 18:14:
Hi,

I've just been looking at this patch, and it seems to have a problem.
The new lines are:

            data.ri = data.ri + data[j].create_ri_prime(data[j])

But this is ri_prime.  data.ri is created later on with the call to
data.create_ri.  Should this be:

            data.ri_prime = data.ri_prime + data[j].create_ri_prime(data[j])

Regards,

Edward


On 25 February 2011 18:09, 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-02/msg00076.html
https://gna.org/support/download.php?file_id=12556

This patch includes change in  func_mf, func_local_tm, func_diff, func_all,
dfunc_mf, dfunc_local_tm, dfunc_diff, dfunc_all, d2func_mf, d2func_local_tm,
d2func_diff, d2func_all functions of class Mf in a file maths_fns/mf.py. The
functions were modified in order to handle data for more interactions.
Due to the equality of (d,d2)ri and (d,d2)ri_prime variables, the
(d,d2)ri_prime were replaced by (d,d2)ri and the equality was removed.
Moreover, (d,d2)ri was redefined as a cumulative sum of individual
interaction contributions to the total relaxation rate or corresponding
derivatives.


On 24 February 2011 12:26, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:

Hi,

Please see below:


On 24 February 2011 10:02, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx>
wrote:
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 = self.data[0]
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).

Ah, yes.  'data' here is a list rather than a container, so you can't
do this.  If you like, what I can do is create a special list-like
object for this.  The you can access list elements, but also place
variables inside it.

The other problem is that ri_prime returned by
maths_fns.ri_prime.func_ri_prime() is not a number but a numpy array.
Its dimensions are Nx1, where N is the number of relaxation data
points.  So the initialisation will have to be at the very start
rather than in the func_mf() methods, and it needs to be initialised
to the correct numpy object using something like 'zeros(num_ri[i],
float64)'.  The dri_prime, d2ri_prime, ri, dri, and d2ri prime will
have similar problems.

I would suggest that 'ri_prime' does not need to be summed, but only
'ri'.  Or am I missing something?  The difference between ri and
ri_prime is that ri contains the steady-state NOE whereas ri_prime
contains sigma_NOE.  Do we need to store and sum ri_prime at all?


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

This can be created, if I make this special Python list-like object.
There is already one special object, the Data class at the very end of
the file.  I can create a list-like object here as well, and
initialise each spin object to this.  Ok, I've just added this code in
r12618.  This should fix the problem and not cause too many problems
with your current code.


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.

I have taken your second idea, but it is inbuilt into the self.data[i]
structure itself rather than a separate object inside self.data.  I
hope this solution will be ok.

Cheers,

Edward





Related Messages


Powered by MHonArc, Updated Fri Feb 25 18:20:13 2011