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/