Hi,
Please see below:
As you may are aware, I am trying to reproduce parameters from the
article of Kjaergaard et al. http://dx.doi.org/10.1021/bi4001062
In this article, the R1 rate was fitted in the model of DPL94.
At the moment, I am reading in the R1 fitted values from this article, to
be used at relax R1 values.
I had forgotten that this was your plan of attack. If it doesn't work
with direct R1 input, then optimising R1 would be pointless.
I have a little trouble to reach the same fitted parameters, and my first
idea is to produce graphs, which will convince me that my input values
are correct.
This is a good check. These graphs would also be of general benefit
to all relax users (well, those performing a dispersion analysis).
Now that the hard part is out of the way - the infrastructure - you
should have the R2eff dispersion plots functional very soon.
Whether or not this implementation is good, I have a little trouble
figuring out.
From the commits so far it looks good. You now have all of the base
data at hand that you need for the plots.
I have now spent around 2 weeks, just to produce graphs, and implementing
the TSMFK01 model took me around 3 weeks?
So spending my time is really an issue here.
The time depends on the task. As you have implemented some very
important infrastructure, this always takes a bit longer. And the
amount of learning of the code base and the entire relax
infrastructure must have been a large part of that time. Especially
starting with the TSMFK01 model. I'm actually pleasantly surprised by
the speed of things as it often takes developers longer to familiarise
themselves with the project - especially considering how many areas in
relax you have touched. You will probably find that implementing the
R1 optimisation will be much quicker, especially if we plan it all out
in advance. Planning might take a few days - this will be the longest
step. But then I think you are now capable enough to have the code
and new system tests (via copying) implemented within 1-2 days.
Anyway, reproducing the results with fixed R1 values is more important
for now.
The smallest implementation, would be implementing a DPL94 model where
R1 is also fitted.
By adding R1fit as a parameter in relax and write a new target function.
I have no goal to implement this for other models.
With planning, I think I can see how the code changes would
automatically apply to all models ;) The code separation of the
specific_analyses, target_functions and relax library packages will be
a huge advantage for this and should make the task rather trivial.
Whether or not this model should be available as a standard model in
the GUI is up for discussion.
This is where planning is useful. Maybe a relax_disp user function
could be added to activate R1 optimisation (this would be model
independent). It could have a flag which could be set to True or
False to allow this to be turned on or off. Then the R1 button in the
GUI could have a new wizard added, where the first page presents a
choice - load R1 or optimise R1, with text telling the user that it is
far more favourable to collect the data so as to simplify optimisation
and minimise parameter errors. If 'load R1' is chosen, then the
current relax_data.read user function is presented. If 'optimise R1'
is chosen, then a flag is stored in the current data pipe and the
wizard exits.
I think I would have to return to this issue after producing graphs,
running a global fit for the
15 residues, inspect results, double check input values and units
before considering this issue again.
True. I'm sure you are close though!
I do think that relax should raise an Error rather than Warning, when
no R1 data is loaded in.
The warning message is lost in the long logfile, and setting the R1
value to 0, is dangerous.
I think this is a good idea. Is it really only giving a warning?
That is really not good! If the user wants R1 values of 0, they can
create a file full of zeros and read that in. This must be a result
of implementing the R1rho dispersion models - I must have set this for
debugging purposes and forgotten about it. Feel free to fix!
Also, have a look at the missing list in the assemble_data() method in
the gui.analyses.auto_relax_disp module. Here the R1 data should be
added to the missing list, if missing (with the same checks as for the
RelaxWarning which should be a RelaxError). Then this will
automatically present a window to the user when they click on
"Execute" saying that the R1 data is missing. That is a better way to
communicate to the user in the GUI and is how I have implemented this
for all GUI analysis types. For simplicity, the R1 check for the
RelaxError could be shifted into specific_analyses.relax_disp.checks
and then reused for the GUI to add text to the missing list.
One could consider the two possibilities for the missing of reading R1
values.
Either relax should change to the model, where R1 is fitted of the
user should actively
chose the model where R1 is fitted.
I prefer the last option.
User input into the subject is best. We can never know what a user
really wants, so forcing them to say what they want is best. And if
it is a mistake, a RelaxError should be raised explaining to the user
the exact problem. I think that having a new relax_disp user function
allowing the user to say that R1 should be optimised is the simplest
implementation and easiest to understand. Then we change the
specific_analyses annd target_functions code to handle this (the lib
package will require no changes :).
Regards,
Edward
Re: Optimisation of the R1 relaxation rate for the off-resonance R1rho relaxation dispersion models.