On 1 March 2011 10:22, Pavel Kaderavek <
pavel.kaderavek@xxxxxxxxx> wrote:
> Hi,
>
> Yes, you are right. It might be included in some of the following patches.
> First, we would like to discuss changes in the next patch, where we would
> like to replace variable name ri_prime in functions calc_(d,d2)noe in a file
> maths_fns/ri.py to follow the changes in the patch:
>
https://mail.gna.org/public/relax-devel/2011-02/msg00081.html
> It was pre-discussed in:
>
https://mail.gna.org/public/relax-devel/2011-02/msg00084.html
>
> The changes also imply renaming of variables r1_data.(d,d2)ri_prime to
> r1_data.(d,d2)ri in the initialization function init_res_r1_data (class Mf,
> maths_fns/mf.py).
>
> Best regards,
> Pavel
>
>
> On 1 March 2011 09:59, Edward d'Auvergne <
edward@xxxxxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> The patch looks good, I've now applied it. In the future, you might
>> find that the self.diff_data structure does not need to be passed into
>> self.init_spin_data().
>>
>> Cheers,
>>
>> Edward
>>
>>
>>
>> On 28 February 2011 16:51, 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/msg00088.html
>> >
https://gna.org/task/download.php?file_id=12598
>> >
>> > This patch includes change in init_res_data function of class Mf in a
>> > file
>> > maths_fns/mf.py. The function is split into init_interaction_data and
>> > init_spin_data. The initializations of data.ri_prime, data.dri_prime,
>> > and
>> > data.d2ri_prime are excluded. Calls for both newly introduced functions
>> > are
>> > incorporated in the patch.
>> >
>> > On 25 February 2011 20:38, Edward d'Auvergne <
edward@xxxxxxxxxxxxx>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I agree, these are good designs. The init_res_data name is a relic of
>> >> old code from relax 1.2 when only single residues were handled and not
>> >> individual and multiple spins per residue. It should have been
>> >> renamed to init_spin_data.
>> >>
>> >> Cheers,
>> >>
>> >> Edward
>> >>
>> >>
>> >>
>> >> On 25 February 2011 20:18, Pavel Kaderavek <
pavel.kaderavek@xxxxxxxxx>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > We would like to discuss the initialization of the spin and
>> >> > interaction
>> >> > data
>> >> > (Spin_object, Data) in class Mf (maths_fns/mf.py). Currently, there
>> >> > is a
>> >> > function init_res_data which initializes variables in container Data.
>> >> > The
>> >> > container Data is now redesigned to store only the interaction
>> >> > specific
>> >> > information and the spin specific data were moved to Spin_object.
>> >> >
>> >> > We suggest to rename init_res_data to init_interaction_data and move
>> >> > spin
>> >> > data initialization parts to a newly created function init_spin_data.
>> >> > The
>> >> > function init_interaction_dat will be called at the same place as the
>> >> > original init_res_data, while init_spin_data will be called just
>> >> > after
>> >> > the
>> >> > Spin_object is appended to self.data.
>> >> >
>> >> > Best regards,
>> >> > Pavel
>> >> >
>> >> > On 25 February 2011 19:48, Edward d'Auvergne <
edward@xxxxxxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> I should have read the text of the commit message more carefully :)
>> >> >>
>> >> >> Bye,
>> >> >>
>> >> >> Edward
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 25 February 2011 19:46, Edward d'Auvergne <
edward@xxxxxxxxxxxxx>
>> >> >> wrote:
>> >> >> > Ah, this will also work. I didn't release that one of the next
>> >> >> > changes would be the in place replacement of sigma_noe by the NOE
>> >> >> > value inside maths_fns/ri.py. Ok, I'll commit the patch.
>> >> >> >
>> >> >> > Cheers,
>> >> >> >
>> >> >> > Edward
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 25 February 2011 19:34, Pavel Kaderavek
>> >> >> > <
pavel.kaderavek@xxxxxxxxx>
>> >> >> > wrote:
>> >> >> >> Hi,
>> >> >> >> maybe we misunderstood some parts of the code, but the
>> >> >> >> data.ri_prime
>> >> >> >> seems
>> >> >> >> to be used only in maths_fns/ri.py to calculate NOE value.
>> >> >> >> Therefore,
>> >> >> >> it
>> >> >> >> should be possible to replace data.ri_prime by data.ri directly
>> >> >> >> and
>> >> >> >> later
>> >> >> >> change function defined in ri.py to use data.ri instead of
>> >> >> >> data.ri_prime.
>> >> >> >>
>> >> >> >> original code of maths_fns/ri.py:
>> >> >> >>
>> >> >> >> def calc_noe(data, i, frq_num, get_r1, params):
>> >> >> >> """Calculate the NOE value.
>> >> >> >>
>> >> >> >> Half this code needs to be shifted into the function
>> >> >> >> initialisation
>> >> >> >> code.
>> >> >> >> """
>> >> >> >>
>> >> >> >> # Get the r1 value either from data.ri_prime or by
>> >> >> >> calculation
>> >> >> >> if
>> >> >> >> the
>> >> >> >> value is not in data.ri_prime
>> >> >> >> data.r1[i] = get_r1[i](data, i, frq_num, params)
>> >> >> >>
>> >> >> >> # Calculate the NOE.
>> >> >> >> if data.r1[i] == 0.0 and data.ri_prime[i] == 0.0:
>> >> >> >> data.ri[i] = 1.0
>> >> >> >> elif data.r1[i] == 0.0:
>> >> >> >> data.ri[i] = 1e99
>> >> >> >> else:
>> >> >> >> data.ri[i] = 1.0 + data.g_ratio*(data.ri_prime[i] /
>> >> >> >> data.r1[i])
>> >> >> >>
>> >> >> >> modified version:
>> >> >> >>
>> >> >> >> def calc_noe(data, i, frq_num, get_r1, params):
>> >> >> >> """Calculate the NOE value.
>> >> >> >>
>> >> >> >> Half this code needs to be shifted into the function
>> >> >> >> initialisation
>> >> >> >> code.
>> >> >> >> """
>> >> >> >>
>> >> >> >> # Get the r1 value either from data.ri_prime or by
>> >> >> >> calculation
>> >> >> >> if
>> >> >> >> the
>> >> >> >> value is not in data.ri_prime
>> >> >> >> data.r1[i] = get_r1[i](data, i, frq_num, params)
>> >> >> >>
>> >> >> >> # Calculate the NOE.
>> >> >> >> if data.r1[i] == 0.0 and data.ri[i] == 0.0:
>> >> >> >> data.ri[i] = 1.0
>> >> >> >> elif data.r1[i] == 0.0:
>> >> >> >> data.ri[i] = 1e99
>> >> >> >> else:
>> >> >> >> data.ri[i] = 1.0 + data.g_ratio*(data.ri[i] / data.r1[i])
>> >> >> >>
>> >> >> >> the data structure data.ri is created during the initialization
>> >> >> >> and
>> >> >> >> data.ri
>> >> >> >> is calculated by function calc_noe. Therefore we
>> >> >> >> do not see a reason to keep this line in the code:
>> >> >> >>
>> >> >> >> data.ri = data.ri_prime * 1.0
>> >> >> >>
>> >> >> >> since data.ri would be calculated by cumulative summation as we
>> >> >> >> suggested.
>> >> >> >> Is our understanding correct?
>> >> >> >>
>> >> >> >> Best regards,
>> >> >> >> Pavel
>> >> >> >>
>> >> >> >>
>> >> >> >> On 25 February 2011 18:16, Edward d'Auvergne
>> >> >> >> <
edward@xxxxxxxxxxxxx>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> The line:
>> >> >> >>>
>> >> >> >>> data.ri = data.ri_prime * 1.0
>> >> >> >>>
>> >> >> >>> is also quite important. This creates a new data structure
>> >> >> >>> data.ri
>> >> >> >>> initialised to the values of data.ri_prime. These lines are
>> >> >> >>> probably
>> >> >> >>> still necessary.
>> >> >> >>>
>> >> >> >>> Cheers,
>> >> >> >>>
>> >> >> >>> Edward
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On 25 February 2011 18:14, Edward d'Auvergne
>> >> >> >>> <
edward@xxxxxxxxxxxxx>
>> >> >> >>> wrote:
>> >> >> >>> > 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 = "">
>> >> >> >>> >>> > 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