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=12556This
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:
> 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).
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
Re: CST branch