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 December 06, 2010 - 18:59:
Ah, sorry I missed that.  I downloaded the file attached to the last
comment, and that was patch00003.  I didn't see that there was another
file in the listing at the bottom.

Cheers,

Edward



On 6 December 2010 18:21, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:
Hi,
excuse me, but it seems to me that you looked at the patch00003, while we
uploaded patch00004. Changes introduced in patch00003 are already included
in the code when I apply "svn up" (I believe I did "svn up" before I created
patch00004).
Regards,
Pavel

On 3 December 2010 10:54, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:

Hi,

The Gna! infrastructure is finally back.  It looks like nothing was
cracked.  So I can now apply your patch.  However there is a problem:

[edau@localhost cst]$ patch -p0 < patch00003.bin
patching file maths_fns/mf.py
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #1 succeeded at 40 (offset 1 line).
Hunk #2 FAILED at 56.
Hunk #3 FAILED at 253.
2 out of 3 hunks FAILED -- saving rejects to file maths_fns/mf.py.rej
[edau@localhost cst]$ svn st
?       patch00003.bin
?       svnmerge-commit-message.txt
?       .sconsign.dblite
?       maths_fns/mf.py.orig
?       maths_fns/relax_fit.so
?       maths_fns/mf.py.rej
M       maths_fns/mf.py
[edau@localhost cst]$ svn info
Path: .
URL: svn+ssh://bugman@xxxxxxxxxxx/svn/relax/branches/cst
Repository Root: svn+ssh://bugman@xxxxxxxxxxx/svn/relax
Repository UUID: b7916896-f9f9-0310-9fe5-b3996d8957d5
Revision: 11699
Node Kind: directory
Schedule: normal
Last Changed Author: bugman
Last Changed Rev: 11695
Last Changed Date: 2010-11-23 11:30:42 +0100 (Tue, 23 Nov 2010)

[edau@localhost cst]$

This looks like the patch is for an earlier revision of the branch.
Would you be able to 'svn up' and attach a new patch to the task
(https://gna.org/task/?6397).

Cheers,

Edward




On 30 November 2010 18:21, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:
Hi,

I'll have to look at this patch later.  The Gna! website
(http://gna.org) looks like it has been hacked, so I can't reach the
task to download the patch :S  Hopefully I can have it applied
tomorrow, but the next 2 days will be almost impossible for me due to
a day long meeting.

Cheers,

Edward



On 29 November 2010 23:28, 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/2010-11/msg00001.html
https://gna.org/task/download.php?file_id=11449

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.
Functions were modified in order to handle data for more interactions.

On 27 November 2010 09:25, Edward d'Auvergne <edward@xxxxxxxxxxxxx>
wrote:

Hi,

First make a backup copy just in case, then simply perform an 'svn up'
and then 'svn diff'.  This should work without clashes.  If there is a
clash, this is a normal part of software development.  This really
shouldn't be necessary.  But if you need to resolve a clash, you need
to edit the file and find the '<<<<<', '=====', and '>>>>>' marks.
This separates code from the old file and the new file for you to
manually edit and merge.  If it's too confusing, just ask again.

Cheers,

Edward


On 25 November 2010 19:25, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx>
wrote:
Hi,

We prepared another set of changes according to discussion in:
https://mail.gna.org/public/relax-devel/2010-11/msg00001.html
and previous.

Normally, we use command "svn diff" to create a patch by comparing
new
code
and code of our branch in the repository. As the current changes are
applied
on the already patched version of the code (not present in the
current
repository revision of our branch obtained by "svn up"), we would
like
to
ask you how the patch should be created.

Regards,
Pavel


On 15 November 2010 19:21, Edward d'Auvergne <edward@xxxxxxxxxxxxx>
wrote:

Hi,

I'm now back from a few weeks holidays.  This is correct, a double
looping will be required.  I think this will still be efficient as
the
"for k in xrange(self.num_interactions[0])" loops are not very
expensive.  The alternative is to bring the "for j in
xrange(data.total_num_params):" loop, but this would duplicate
calculations and hence be even more expensive.  This will also be
required in the d2func_* methods as well.

On a different note, as the code is becoming more complex, I would
recommend for a future patch that "data = self.data[0]" so that we
always use "self.data[0][k].dri_prime[j]" for each element rather
than
"data..dri_prime[j]".  This will help with debugging in the future
as
we could end up mixing the self.data elements.

Also for the Rex interaction, there are plans for the future to
allow
for it to be non-quadratic for situations closer to slow exchange
or
intermediate.  For slow exchange the interaction is then linear
with
field strength, and the value ranges from linear (alpha=1) to
quadratic (alpha=2).  So the alpha value between 1 and 2 might
become
an optimisable parameter and hence this interaction type will
become
more complex and require its own code paths.  So if this branch
separates out the Rex interaction, this would be of benefit to the
rest of relax.  Though the separation might be essential for the
powerful code restructuring currently anyway.

Cheers,

Edward




On 27 October 2010 20:45, Pavel Kaderavek
<pavel.kaderavek@xxxxxxxxx>
wrote:
Hi,
sorry for a late response. Your suggestions seem reasonable. I
would
add
just a two comments.
1) We should keep as before not only ri_prime but probably also
chi2,
dchi2
and d2chi2 as well.
.
2)The consideration of Rex as an additional interaction is a one
of
the
suitable approaches and it fits the general idea. We have to
consider
that
it requires to add new interaction into the list of the
interactions
(
__init__ function in class Mf, file maths_fns/mf.py).
It might be done just within the __init__ function (class Mf,
file
maths_fns/mf.py). It will be based on the presence of Rex term
within
the
loaded variable param_types. The other possibility is to do it
before
calling this __init__ function (number of interactions is one of
its
arguments).

Then I address to discussion one additional problem related to
the
patch
in
the preparation. Within the  functions related to the
derivations:
dfunc_mf,
dfunc_local_tm, dfunc_all, dfunc_diff (class Mf, maths_fns/mf.py)
there
is a
small complication. It will be illustrated using  "dfunc_mf"
function
as
an
example. The original code is following:

        data = self.data[0]

        # Calculate the spectral density gradient components.
        if data.calc_djw_comps:
            data.calc_djw_comps(data, params)

        # Diffusion tensor correlation times.
        self.diff_data.calc_dti(data, self.diff_data)

        # Loop over the gradient.
        for j in xrange(data.total_num_params):
            # Calculate the spectral density gradients.
            if data.calc_djw[j]:
                data.djw = data.calc_djw[j](data, params, j)
            else:
                data.djw = data.djw * 0.0

            # Calculate the relaxation gradient components.
            data.create_dri_comps(data, params)

            # Calculate the R1, R2, and sigma_noe gradients.
            data.dri_prime[j] = data.create_dri_prime[j](data)

            # Loop over the relaxation values and modify the NOE
gradients.
            data.dri[j] = data.dri_prime[j]
            for m in xrange(data.num_ri):
                if data.create_dri[m]:
                    data.create_dri[m](data, m,
data.remap_table[m],
data.get_dr1, params, j)

            # Calculate the chi-squared gradient.
            data.dchi2[j] = dchi2_element(data.relax_data,
data.ri,
data.dri[j], data.errors)

If  the loop over interactions is incorporated, it is necessary
to do
it
before "data.calc_djw_comps" is calculated. However then we get
into
the
conflict with calculation of "modification of NOE gradients" and
also
calculation of "dchi2". These quantities can be calculated only
when
contributions from all interactions has been already evaluated
(it is
similar to already discussed ri_prime). In this case it is
complicated
by
the presence of loop over fitted parameters. The possible
solution
would
be
to make the loop over the interactions the inner one. However
this
seems
to
require repeating the loop over interactions twice within the
code:

        data = self.data[0]

        # Loop over the interactions
        for k in xrange(self.num_interactions[0]):
            # Calculate the spectral density gradient components.
            if data[k].calc_djw_comps:
                data[k].calc_djw_comps(data[k], params)

            # Diffusion tensor correlation times.
            self.diff_data.calc_dti(data[k], self.diff_data)

        # Loop over the gradient.
        for j in xrange(data.total_num_params):
            # Loop over the interactions
            for k in xrange(self.num_interactions[0])
                # Calculate the spectral density gradients.
                if data[k].calc_djw[j]:
                    data[k].djw = data[k].calc_djw[j](data[k],
params,
j)
                else:
                    data[k].djw = data[k].djw * 0.0

                    # Calculate the relaxation gradient
components.
                    data[k].create_dri_comps(data[k], params)

                # Calculate the R1, R2, and sigma_noe gradients.
                data[k].dri_prime[j] =
data[k].create_dri_prime[j](data[k])
#
later
data[k].dri_prime[j] will be replaced by data.dri_prime[j]

                                                   # but you
suggest
not
to
include both changes into the following patch together


            # Loop over the relaxation values and modify the NOE
gradients.
            data.dri[j] = data.dri_prime[j]
            for m in xrange(data.num_ri):
                if data.create_dri[m]:
                    data.create_dri[m](data, m,
data.remap_table[m],
data.get_dr1, params, j)

                # Calculate the chi-squared gradient.
                data.dchi2[j] = dchi2_element(data.relax_data,
data.ri,
data.dri[j], data.errors)

Additionally I would notify that variable "total_num_params"
needs to
be
kept at the position self.data[0] (similar to your suggestion in
your
last
mail, concerning ri_prime)
What do you think about this?
Regards
Pavel

On 22 October 2010 19:46, Edward d'Auvergne
<edward@xxxxxxxxxxxxx>
wrote:

Hi,

This is a good idea.  First I would suggest putting this into 2
patches, as this is easier to check and apply.  Don't worry
about
breaking the code at this point - it is in your own special
branch
so
as long as it works in the end, you can smash it into a million
pieces
and put it back together again if you like.  Commits to the
repository
are better when they are many small ones, as they can be more
easily
managed.  For example if something is found to be designed not
ideally, or there is a fatal bug, that patch/commit can be
reverted
and then new code can be worked on.  And small patches make it
much
easier for the other relax developers to read and catch
potential
hidden bugs or design issues.

This is an intriguing problem, as the data flow hits a fork
here.
ri_prime is the correct target for the merging of the data from
all
the interactions, as this needs to occur before the calculation
of
the
NOE using sigma_noe and the R1.  The relaxation rates R1, R2,
and
sigma_noe add.  However the NOE does not.  I just thought I'd
explain
the logic for others to follow ;)

I would suggest we store ri_prime somewhere else.  What I can do
is
to
apply a patch for the first change to accommodate for the
multiple
relaxation interactions.  Then I could make a change myself,
creating
a special Python object for 'data[i]'.  We can store the
ri_prime
data
this special object.  Essentially, it will be like the current
code
base.  We could have specific interaction data in say:

self.data[10][0].jw  (or self.data[0].jw if data = self.data[i])

This is new.  But as before we could have:

self.data[10].ri_prime (or data.ri_prime if data = self.data[i])

So the forking can all be managed within the self.data[i] data
structures.  What do you think?  Also, we will have to work out
how
to
modify or replace func_ri_prime and func_ri_prime_rex in the
maths_fns.ri_prime module.  This is where the merging of data
streams
currently occurs.  Maybe Rex needs to be considered as its own
interaction, as this is added to produce ri_prime?

Regards,

Edward


P. S.  I just talked to Kathleen Hall and she seemed very
interested
in what you are doing here!



On 22 October 2010 18:26, Pavel Kaderavek
<pavel.kaderavek@xxxxxxxxx>
wrote:
Hi,
I am continuing in the discussion started in my post
https://mail.gna.org/public/relax-devel/2010-09/msg00020.html
It covers changes of functions func_mf.py, func_local_tm ,
func_diff,
func_all and their equivalents for a first and second
derivatives
(class
Mf,
file maths_fns/mf.py).

I would like to include into next patch also treatment of the
fact,
that
it
is necessary to sum together contributions of all
interactions. It
seems
to
me that the most suitable way is to do that by the
modification
just
revised
functions (func_mf.py, func_local_tm ...)
I would suggest to initialize ri_prime before loop over
interactions
and
then step by step add the contributions into the ri_prime:

        data = self.data[i]                                  #
the
cases
when `i` is replaced by `0` were discussed in your last mail
        ri_prime=0


        for j in xrange(self.num_interactions[i]):

              ...
              ...

              # Calculate the R1, R2, and sigma_noe values.
              ri_prime = ri_prime +
data[j].create_ri_prime(data[j])

         data[0].ri_prime = ri_prime


When the loop over interactions is finished the accumulated
relaxation
rate
is copied into the data storage of the first interaction. Then
it
is
possible to call functions, where total ri_prime is needed:

        # Calculate the NOE values.
        data[0].ri = data[0].ri_prime * 1.0
        for m in xrange(data[0].num_ri):
            if data[0].create_ri[m]:
                data[0].create_ri[m](data[0], m,
data[0].remap_table[m],
data[0].get_r1, params)

        # Calculate the chi-squared value.
        data[0].chi2 = chi2(data[0].relax_data, data[0].ri,
data[0].errors)

Regards,
Pavel

On 19 October 2010 13:49, Edward d'Auvergne
<edward@xxxxxxxxxxxxx>
wrote:

Hi,

Sorry for the delay, I just came back from a 2 week holiday.
 This
is
correct, the func_mf, func_local_tm, etc. methods are working
on
a
single spin.  This is stored in self.data[0].  The other
functions
work on multiple spin data located in self.data[0],
self.data[1],
etc.

Regards,

Edward



On 14 October 2010 19:38, Pavel Kaderavek
<pavel.kaderavek@xxxxxxxxx>
wrote:
Hi,

I would like to announce a small clarification of my
previous
mail
about
changes in functions func_mf, func_local_tm, func_diff,
func_all,
and
their
derivatives (class Mf, file maths_fns/mf.py). Loop
suggested in
my
last
post:


https://mail.gna.org/public/relax-devel/2010-09/msg00020.html

is valid just for the functions func_diff, func_all, and
their
equivalents
for a first and second derivatives.
While for the functions  func_mf, func_local_tm, and
corresponding
derivatives the index of self.num_interactions should be
set to
`0`
instead
of index `i`

        for j in xrange(self.num_interactions[0]):

(The rest of the loop remains the same)
That comes from the fact that these functions (func_mf,
func_local_tm,
...
) are called for each spin separately. As it is indicated
by
the
preceding
statement:

        data = self.data[0]

Regards,
Pavel

On 29 September 2010 10:53, Edward d'Auvergne
<edward@xxxxxxxxxxxxx>
wrote:

Hi,

This is the perfect approach.  It will abstract the
calculations
so
that we will not need to touch many of maths_fns modules.
 With
this
code in place, I would aim at then making the test suite
pass
again
by
having the correct data structures pass into maths_fns.mf.
 The
last
step would be to input CSA tensors and the multi-dipole
interactions
via user functions.  If you make a patch for all of the
func_*(),
dfunc_*(), and d2func_*() methods, I can check and apply
it
quickly.

Regards,

Edward


On 28 September 2010 12:07, Pavel Kaderavek
<pavel.kaderavek@xxxxxxxxx>
wrote:
Hi,
we were thinking about next necessary changes in the CST
branch.

Now we need to break through the problem, which implies
the
fact
we
split
the relaxation rate calculation into contributions of
individual
interactions. Each of them has its own data class to
store
its
parameters
(so far called data[i][j], where the [i] was a spin
index
and
[j]
was
the
interaction index).

It seems to us, that it the best way to deal with it is
to
edit
functions:
func_mf, func_local_tm , func_diff, func_all and their
equivalents
for a
first and second derivatives (defined in mf.py file).

Within these functions the calculations of direction
cosines,
diffusion
tensor weight calculations, components of the spectral
densities
and
so
on
are performed. All these must be calculated for each
interaction
separately,
because each interaction has its own data storage (which
replaced
previously
used one data class container for the whole IS spin
system).

Instead of:


        # Direction cosine calculations.
        if self.diff_data.calc_di:
            self.diff_data.calc_di(data, self.diff_data)

        # Diffusion tensor weight calculations.
        self.diff_data.calc_ci(data, self.diff_data)

        # Diffusion tensor correlation times.
        self.diff_data.calc_ti(data, self.diff_data)

        # Calculate the components of the spectral
densities.
        if data.calc_jw_comps:
            data.calc_jw_comps(data, params)

        # Calculate the R1, R2, and sigma_noe values.
        data.ri_prime = data.create_ri_prime(data)


we would suggest to introduce a loop over interacations
        for j in xrange(self.num_interactions[i]):
            # Direction cosine calculations.
            if self.diff_data.calc_di:
                self.diff_data.calc_di(data[j],
self.diff_data)

            # Diffusion tensor weight calculations.
            self.diff_data.calc_ci(data[j],
self.diff_data)

            # Diffusion tensor correlation times.
            self.diff_data.calc_ti(data[j],
self.diff_data)

            # Calculate the components of the spectral
densities.
            if data.calc_jw_comps:
                data.calc_jw_comps(data[j], params)

            # Calculate the R1, R2, and sigma_noe
components.
            data.ri_prime =
data.create_ri_prime(data[j])


It must be accompanied in the next step by a change the
ri_prime
function so
that it just calculate only a product of specific
interaction
constant
and
corresponding linear combination of spectral densities.
While
the
final
sumation over all interactions should be done in a
separate
step.

Moreover it will be also necessary to distinguish within
the
function
setup_equation the type of equation used for
contribution of
individual
interactions according to their type.

Best
Pavel


On 10 September 2010 15:43, Edward d'Auvergne
<edward@xxxxxxxxxxxxx>
wrote:

Hi Pavel,

I missed it in the patches, but there were tab
characters
'\t'
causing
problems.  These are now fixed.  relax requires that a
tab
is
replaced
by 4 spaces.  I have also added you to the copyright
notices

(http://svn.gna.org/viewcvs/relax?view=rev&revision=11543)
of
the
files you have modified.

Regards,

Edward

On 10 September 2010 15:36, Edward d'Auvergne
<edward@xxxxxxxxxxxxx>
wrote:
Hi,

I've carefully checked the patches and committed them
with
the
messages you wrote.  Sorry again for the delays.  It
should
be
faster
now that I am no longer in the tropical wilderness of
far
north
Australia.

Regards,

Edward


On 6 September 2010 13:23, Edward d'Auvergne
<edward@xxxxxxxxxxxxx>
wrote:
Hi Pavel,

Sorry for the delayed response.  I was at the ICMRBS
conference
in
Australia and then travelled through the tropical
north
end
of
Australia afterwards.  I came back yesterday out of
the
remote
wilderness and can soon start looking at this
patches.

Regards,

Edward


On 31 August 2010 18:00, Pavel Kaderavek
<pavel.kaderavek@xxxxxxxxx>
wrote:
Hi,

some time ago, we submitted two patches regarding
CST
branch.
We
are
not
sure if we should wait for some additional comment
from
your
side,
or
we can
continue with introducing further changes in the
code.
Next step would be a splitting of the relaxation
equation
so
that
contribution to the relaxation due to the
individual
types
of
interaction
(dipole-dipole, CSA) can be calculated separately.


Regars,

Pavel, Petr





















Related Messages


Powered by MHonArc, Updated Mon Dec 06 19:20:14 2010