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