Hi,
I have addressed the second part of your message below:
I have had a look at your thoughts about the joint fit of multiple data in
one of your previous detailed e-mails. I agree that this would be a nice
feature, but that some parts of it might take quite some effort. Mathilde is
going to leave soon to another lab, so we have to see whether we have
capacities to push these developments further.
When there is interesting science to be uncovered, one can always find
a way ;) I hope to help you benefit from from the project relax.
Just as there are benefits for myself, namely citations for my
published papers.
For us, the first step is to
get relax running and get familiar with it.
I can see that you have been having a few problems. I would highly
recommend using the stock Python distribution files from
http://python.org rather than the Enthough Python Distribution,
special Mac OS X frameworks, etc. Compiling the C modules really
shouldn't be difficult once you have a C compiler installed on the
system, but using non-standard Python really complicates the game.
Especially if you then have multiple Python versions on the system -
for example the default Python in the PATH environment may not be that
used by the installed scons version (which is exactly Mathilde's
current problem). For code development, being able to compile the
modules is crucial.
In the course of our projects,
developing such tools, e.g. joint SQ and MQ fitting, might turn out to be
crucial, so we will probably end up doing that at some point.
I already pretty much know how this should be cleanly implemented in
relax so, when someone is ready and interested in developing this, I
can point them in the correct direction.
We have a routine now that jointly fits R1rho and CPMG data, so it would be
pretty straightforward for us to send that to you. It just calculates a
target function that consists of either the CPMG expression or the R1rho
expression. We now do it in a very clumsy way, so we explicitly fix it such
that, e.g. the first set of parameters in a list of fitting parameters (for
fmin or leastsq) is for R1rho, then then next parameters are for CPMG at
B0=600, then for CPMG at B0=700 etc. This is really unelegant, as one has to
respect exactly and precisely this order or data.
This code is not necessary. The design of relax is highly modular so,
if the dispersion models are already supported, implementation is
easy:
- Add a new joint model name, description and definition (i.e. the
parameters of the model).
- Add a test for the presence of R1rho and CPMG data if this model is chosen.
- Add a description to the relax manual.
- Duplicate one of the func_*() target function in
target_functions.relax_disp and modify it to pass the CPMG data into
one model in lib.dispersion and the R1rho data into the other.
- Create a system test.
This is steps 1, 2, 4, 5, 6, and 7 of the tutorial at
http://thread.gmane.org/gmane.science.nmr.relax.devel/3907. These
steps usually take me between 6 hours and one day to complete, but for
someone starting to learn how to code in relax, it would obviously be
longer. It is the system test that takes the longest, but is the most
important step. Step 3 is the relax library code for the
lib.dispersion modules which calculate R2eff/R1rho' values.
In addition, the function
currently optimizes three residues at the same time, so if fact the list of
fit parameters is a very long and unhandy combination of data types and
residues numbers. This works for this particular data we have at hand, but
is far from being universal. Making this a more universal thing would be
much more complicated, and you would probably be in a better situation
getting it to run, as my programming knowledge is not quite at your level, I
believe.
Such a solution would never be able to sneak its way into relax ;)
Together with Sebastien Morin's code, we have built a flexible
framework for dispersion which will hopefully be highly beneficial for
implementing a much cleaner solution. And in relax, there are many
tools (functions, modules, data models, protocols, libraries, etc.)
which will allow elegant solutions to be found. The modularity and
clean code separation in relax really enforces good code. The
practical details of each solution can be discussed on this mailing
list in depth first. But there will be no limitations for the
implemented solution. And relax works with spin systems rather than
residues, so it does not matter if the data is from a methyl group,
the backbone, or anywhere else. The modularity and flexibility of
relax means that the user can input their data in any way, order,
direction, etc. they wish. It is part of relax's design that data can
be input at any time and in any way the user wishes (in the scripting
UI anyway, the GUI requires certain constraints on this). It is
considered a bug if relax does not behave the way a user expects.
Nowadays, with the comprehensive test suite, users find it quite
difficult to break relax.
Note that the level of programming knowledge does not matter. I will
always help someone to become a relax developer, even if they do not
know how to code, as long as they have interest in advancing the
project for their own benefits. A few of the relax developers learnt
to code by contributing to relax. And I will always help with design,
point to what should be done next, etc., whenever help is asked for.
And I check every line of code that is contributed to relax to be sure
that there are no bugs and that the solution is the most elegant and
flexible possible.
Regards,
Edward
Re: