Hi,
Thanks a lot for your reply and sorry for the delayed response.
Yours was a delayed response? It didn't seem so to me ;)
1. You guessed absolutely correctly that I don't have data for the second
magnetic field yet. Having said that, I do have access to the 500 MHz magnet
except that my data with the 600 Mhz machine (with cryoprobe) was not too
great. I am worried about the quality of data from the 500 MHz non cryoprobe
spec.
500 MHz non-cryoprobe might take longer to collect good data for (1.5
weeks maybe), but it should still be fine if you perform proper
per-experiment temperature calibration and control
(http://www.nmr-relax.com/manual/Temperature_control_calibration.html).
I would highly recommend collecting data at two field strengths as
that is almost considered essential today. There is so much
literature on the problems of single field strength data. A summary
and references to all this literature can be found in my 2007 paper
(http://www.nmr-relax.com/refs.html#dAuvergneGooley07). With multiple
field strength data you are then able to take advantage of the
advanced protocol I developed in the 2007 and 2008 papers through the
dauvergne_protocol.py script. This script is automatic and will makes
life much easier.
2. I am indeed running the latest version of relax (2.1.2). The stage 2 of
palmer.py keeps failing as I reported in my original email. I believe it
might have something to do with the naming of the spin ids. it is just a
hunch though. I am using only residue numbers as yet instead of actual
residue names.
This is then a clear bug. Would you be able to submit a bug report
for this? The link is https://gna.org/bugs/?func=additem&group=relax.
The more information included the better. Ideally, if you could
create a subset of the data with 2 residues which still triggers the
bug and attach this data, the relax script, and a PDB file of those 2
residues if needed to the bug report. I will then be able to very
quickly reproduce the bug, include the data and script in the relax
test suite, and should have a bug fix within 5 minutes. Cheers! You
can slightly randomise the data if you would like to keep it
confidential.
3. I got the farthest by running mf_multimodel.py followed by modsel.py. I
am confused though about the diffusion tensor optimization part. If I run
the script, how will the script know about the model selection and and
elimination process that has already taken place. Is there a way I can tell
that to the diff_min.py to not worry about selection and elimination but use
the results from modsel.py ? Can I load the results ?
The new diff_min.py script in the relax repository is a combination of
the concepts in mf_multimodel.py and modsel.py with a final diffusion
tensor optimisation added. It is a direct subset of the algorithm in
the figure of the new protocol I developed at
http://www.nmr-relax.com/manual/Model_free_analysis_in_reverse.html.
It has the optimisation of the model-free models
(http://dx.doi.org/10.1007/s10858-007-9214-2), model elimination
(http://dx.doi.org/10.1007/s10858-006-9007-z), model selection
(http://dx.doi.org/10.1023/A:1021902006114), and then diffusion tensor
optimisation (http://dx.doi.org/10.1007/s10858-007-9214-2).
4. I am certainly hoping to find a way to get an automated script or set of
scripts that perfectly handle the data at single magnetic field although
quite rightly data from two magnetic fields ought to be used whenever
possible. If I can do that, I will love to make it available as a part of
the relax sample scripts.
It would be better to have a simple interface such as in the
dauvergne_protocol.py sample script and then to implement most of it
in a single script as in the auto_analysis/dauvergne_protocol.py file.
The auto_analysis files/modules are essentially very advanced relax
scripts implementing complex protocols. It removes the ability of the
user to change the protocol which, for a complex protocol, is a good
thing as most users will end up breaking a published protocol and then
publish the broken results as if the results obtained using the
original protocol! Those who would like to design new protocols will
be able to become a relax developer and add a new protocol to the
auto_analysis package.
If you really would like to do this, you will be required to learn how
to code in Python. But you can use the example of the
auto_analysis/dauvergne_protocol.py file to help you. I would
recommend that this is performed in a special relax branch which I can
give you developer access to. I would also recommend that you fully
read the development chapter of the relax manual first
(http://www.nmr-relax.com/manual/relax_development.html or the PDF
file), learn how to use svn, and start with the simple Python tutorial
to learn a little bit about Python
(http://docs.python.org/3/tutorial/). Note that relax now runs in
both Python 2 and 3.
You will also need to chose the protocol that you would like to
implement. For example the Mandel et al., 1995 protocol (which will
require the implementation of chi-squared and F-tests within relax
(for example as the generic_fns.anova module), the protocol I
suggested at http://www.nmr-relax.com/manual/diffusion_seeded_paradigm.html
which I never implemented into a self contained auto_analysis module,
or one of the few other published protocols. You should read all of
the model-free chapter of the relax manual as well
(http://www.nmr-relax.com/manual/Model_free_analysis.html).
Note that I would recommend you start with the creation of a test
model consisting of synthetic data which can then be incorporated into
the relax test suite. Synthetic data is important because you then
know the result that the protocol should find. You will know that the
protocol succeeds and your code is complete once the test passes.
This would all go into your dedicated relax branch.
Your aim in coding should also be a publication that relax users who
use your code will then cite. You should present it in the relax
manual. And also say that this is an alternative analysis which users
of the protocol I developed (which is almost 100% of relax users)
which can be used to validate the results. Or for a preliminary
analysis prior to collecting data at a second field.
Forgive me if some of my queries sound too beginner level but any help at
this stage will be highly appreciated.
If you become a relax developer and create the code for such a
protocol, you will become an expert in NMR relaxation. But it will
take a lot of time, a lot of learning (of Python, relaxation,
model-free, and relax), and a lot of literature reading.
Regards,
Edward
Re: Stage 2 of palmer.py