Hi Edward,
The problem with the repeating spherical diffusion tensor initialisation has
disappeared right from the moment I updated the relax version. Also, the
problem of stopping of the calculation has not been happening anymore.
Last calculation reached the point of prolate up to 28 round, which seemed to
me strange and I stopped it.
At the moment I do not know where could be a problem. We performed
temperature calibration prior each epxeriment, as you suggest. Also we used
signle scan interleaving approach. Therefore, unless it is possible to see
from the acquired data, I do not think this is the reason, because, as I
explained, this point has been considered.
The protein I am studying is a homodimer, composed of the two head-to-head
dimerised C-terminal domains to which the N-terminal domains are attached via
flexible linkers. As this is a homodimer, I see the number of 15N-1H HSQC
peaks corresponding for only a monomer. To study this protein as a dimer (as
it is) I duplicated the data in the final DC files, in accordance with the
pdb file of the dimer.
My purpose is to run model-free analysis for the entire protein. But also I
am interested to analyse the domains separately, so I began with calculations
for the N-terminal part of it, cutting away the rest of the data. Exactly
this part I have sent you. Do you think that could cause the problem? Then I
should just run Model-free analysis for the entire protein, and see if it
will stay within 2 to 15 rounds.
As for the structure quality. What kind of parameters should be considered in
this case? Do you see the problems from the input data I have sent you?
Thanks for your effort.
Regards,
Olena
________________________________________
From: edward.dauvergne@xxxxxxxxx [edward.dauvergne@xxxxxxxxx] on behalf of
Edward d'Auvergne [edward@xxxxxxxxxxxxx]
Sent: 20 October 2014 17:02
To: Edward d'Auvergne
Cc: Olena Dobrovolska; relax-devel@xxxxxxx; Francesco Musiani
Subject: Re: [bug #22730] Model-free auto-analysis - relax stops and quits at
the polate step.
Hi Olena,
I was wondering if you had seen the repeating spherical diffusion
tensor initialisation problem again, or if this problem has
disappeared? The bug report (https://gna.org/bugs/?22730) is that the
analysis just stopped. Have you seen this stopping again in your
current calculations? You should note that in the GUI, there is a
default maximum of 30 rounds of optimisation. If you have stopped at
this limit, then that is ok. It could mean one of a few things:
- There is a problem with the data. This sometimes happens when not
using the best per-experiment temperature calibration and
per-experiment temperature control methods
(http://www.nmr-relax.com/manual/Temperature_control_calibration.html).
You should carefully note the points in that link. Often the single
90 pulse MeOH calibration used to determine the difference between the
VT unit and the spectrometer is not good enough for relaxation data.
- The affected diffusion tensor is not a good description of your
system. This happens when the molecule is not tumbling as a single
rigid body. I.e. there are freely moving domains. In this case, the
single diffusion tensor is a poor estimate of the real global motion
of the system. In such cases you should be very careful about
artificial Rex or nanosecond motions (see my 2007 Mol. Biosyst. paper
at http://dx.doi.org/10.1039/b702202f for a review about this
problem). If you don't see the motion in the noisy local tm global
model, then it is likely to not be real.
- The input structure is of low quality.
Normally you should be finished between 2 to 15 rounds of
optimisation, and anything more is an indication that something is not
quite right. I look forward to hearing what the current status of
this problem is.
Cheers,
Edward
P. S. Note that this is on the public and permanently archived
relax-devel mailing list and not the bug report. Your response will
be accepted by the mailing list moderator after a certain while.
On 15 October 2014 17:31, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:
Hi Olena,
I will reply on the relax-devel mailing list, as it is a bit
ridiculous to have a long conversation on the bug tracker. I have
received your private messages with the Input_state.bz2,
analysis.log.bz2, and analysis.log.7z files. These are not attached,
so they will remain private. Please reply to this message rather than
continuing the conversation in the bug tracker.
I have now run the analysis up to round_2 of the spherical diffusion
tensor. I stopped here, as that is where the bug reports do not
match. The problem I saw previously in your log file 'analysis_first
part.txt' (at https://gna.org/support/download.php?file_id=22627) is
that the spherical diffusion tensor initial optimisation had been
executed 42085 times (https://gna.org/bugs/index.php?22730#comment9).
But in your new analysis.log file, this is not the case. It is only
executed once:
[edward@localhost bug_22730]$ grep -c "^Function value: 200507.263"
*.txt *.log
analysis_first part.txt:42085
analysis_last10000lines.log:70
analysis.log:1
So here we now have two completely unrelated problems! The first
problem reported (https://gna.org/support/download.php?file_id=22627)
is not replicated in your current log file or in my analysis attempt.
Do you know why? This massive repetition looks like what happens when
the 'mpirun' command line program is incorrectly used or incorrectly
set up. Could that be the cause? Can you replicate this
super-massive repetition problem? Or could it be that your 7z
compression software somehow corrupted the log file? Could this be a
simple mistake? This is where I am quite confused, as it should be
impossible with relax's source code for this infinite repetition to
occur. The only case is if there are strange things happening with
your file system so that relax cannot detect the file. That is why I
asked you if your home directory was NFS, SMB, or some other network
drive.
There is one other case I can think of here, and that is if your file
system no longer had any room. Then relax will not be able to save
the results file, hence it will not be able to detect it and then it
will repeat the last optimisation round forever. Did you have such a
problem? I have not written the dauvergne_protocol auto-analysis to
handle this situation, as I assumed that a Python Error would stop the
analysis. That may not be the case when running with OpenMPI.
I would like to solve this infinite repetition first, as that has
taken up a lot of my time already. This is an impasse which prevents
the rest of the analysis from ever occurring. I.e. you cannot get to
the prolate model. Then I'll look and see if there is another issue
affecting your data.
Cheers,
Edward
On 15 October 2014 10:34, anonymous <NO-REPLY.INVALID-ADDRESS@xxxxxxx>
wrote:
Follow-up Comment #12, bug #22730 (project relax):
Hi,
I have no idea why the information containing the data and its
specification
is missing. I follow the protocol loading the DC files (after I load the H
and
N spins from the pdb file), specifying all the parameters (temperature
control
etc.). Then prior the execution, I save the input as input_state.bz2 as
recommended. Perhaps, last time I opened the input_state.bz2 file, which
perhaps did not load the data? But then why did it work?
Anyway, this time, I upgraded Relax version to 3.3.1 and load the files
once
again from the scratch. I would appreciate if you have a look at the log
file
which, being compressed to 1.8 Mb, I uploaded here
https://mega.co.nz/#fm/HI4ShI7T
The Relax calculations are currently at the 'prolate' stage. But the last
file
was generated at 4 pm yesterday.
Should it be like that? If you think there could be a problem with the
input
data, I can send it to you as well via private email.
Would appreciate if you help me to find and solve the problem.
Regards,
Olena
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?22730>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
RE: [bug #22730] Model-free auto-analysis - relax stops and quits at the polate step.