Re: [ccp4bb] mosflm and hkl2000
Hi Marius We have a little internal project where we want to compare the quality of data reduced with HKL2000 and IMOSFLM (mosflm) to 1.3 A. Unfortunately, imosflm with its standard settings crashes always even at lower resolution whereas HKL2000 is rock stable. Why is that so? Any experience with that? It could be for any number of reasons, unfortunately; however, saying imosflm crashes isn't very informative (see below the next couple of paragraphs for a little more on this). You're absolutely 100% right, though - if iMosflm loses orientation, it shouldn't crash. Those of us developing it would see this as a bug, and we'd like to fix it. Luke has now left us, so I would recommend not sending any e-mails concerning iMosflm problems to lu...@mrc-lmb.cam.ac.uk - send them to me instead. Back to your problem. Crashes covers a multitude of sins, which can be summarised thus :- (1) iMosflm itself crashing (different from Mosflm crashing, and iMosflm giving you a message that Mosflm has crashed); this is usually down to one of two different problems - (a) you are not using the version of TclTk that we recommend - could be that you are using the one that comes with the CCP4 distro, which is known to have issues on some platforms, or (b) you've found a new or unpatched bug in iMosflm, in which case, we'd really like (I mean that) to know about it so we can track it down and fix it. (2) Mosflm (the underlying processing program) has come across a situation that it can't deal with and has shut itself down (and iMosflm has lost contact with it); you should get a message about a crash log, and it will advise sending it to the Mosflm developers. If you do that, we will have a good look through it and do our best to come up with a fix, or a way round your problem. (3) Mosflm has actually crashed in an unexpected way. This is (more than likely) a bug that should be fixed. We always like to hear about things like this so that we can fix them. I have a little experience in rooting out Mosflm/iMosflm problems - if you'd like to share your error messages log files with me, I will do my best to get to the bottom of your problem. Data collected at a synchrotron, axis set to reversephi in imosflm (newest release). Suse Linux, Swap space 2 GB. Anyway, even if (i)mosflm looses orientation, it should complain and not crash. Thanks, Marius Dr.habil. Marius Schmidt Asst. Professor University of Wisconsin-Milwaukee Department of Physics Room 454 1900 E. Kenwood Blvd. Milwaukee, WI 53211 phone: +1-414-229-4338 email: m-schm...@uwm.edu http://users.physik.tu-muenchen.de/marius/ Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] mosflm and hkl2000
Hi Since this seems to have provoked a couple of responses regarding the etiquette of reporting bugs on the BB, I think I should try to clarify things. Marius sent an error report with his crash logs to Luke yesterday, but since Luke isn't reading his e-mail here any more (having left), didn't get a reply. It was only when I logged into Luke's account this morning that I found the relevant e-mail, etc., and was able to respond. I only did this after sending my initial reply to the BB. It turns out in this case that the error was a type (2) below, i.e. Mosflm found an error condition and shut down, so iMosflm lost contact with it. This shutting down may be appropriate when Mosflm is running as a batch job, but it clearly isn't when running as the processing engine behind iMosflm; so we'll address the issue and fix it. I think the cause of the problem was that iMosflm picked an incorrect indexing solution, with too high a symmetry (looking at the log files I think the right solution was oC, the one picked was tP); so the refinement started to look for reflections in the wrong places, and hence lost the orientation. iMosflm picking a solution with too high a symmetry doesn't happen very often, but it does occasionally. This is because the choice is only made on the basis of the penalty. Refining the solutions gives extra information, but at present this isn't used in highlighting/making the choice automatically. It is very useful to check the sigma(x,y) column (rms error in predicted spot positions) as well as looking at the cell parameters. If the selected solution has a significantly higher sigma(xy) than one with lower symmetry, AND the refined cell parameters of the lower symmetry deviate significantly from the constraints of the higher symmetry, then the lower symmetry solution should be seriously considered. For example, if imosflm selects a tetragonal solution with a sigma(xy) of 0.5mm (say), but there is an orthorhomic solution with a sigma of 0.25mm, where the a and b parameters differ by more than 1A, then it is likely that the true solution is orthorhombic. The actual sigma values will depend on the resolution, spot shape etc, and can be high (eg 1.0mm) even for the correct solution if the spots are split, so it is not possible to specify an expected value for all cases. On 31 Jul 2009, at 10:15, Harry Powell wrote: Hi Marius We have a little internal project where we want to compare the quality of data reduced with HKL2000 and IMOSFLM (mosflm) to 1.3 A. Unfortunately, imosflm with its standard settings crashes always even at lower resolution whereas HKL2000 is rock stable. Why is that so? Any experience with that? It could be for any number of reasons, unfortunately; however, saying imosflm crashes isn't very informative (see below the next couple of paragraphs for a little more on this). You're absolutely 100% right, though - if iMosflm loses orientation, it shouldn't crash. Those of us developing it would see this as a bug, and we'd like to fix it. Luke has now left us, so I would recommend not sending any e-mails concerning iMosflm problems to lu...@mrc-lmb.cam.ac.uk - send them to me instead. Back to your problem. Crashes covers a multitude of sins, which can be summarised thus :- (1) iMosflm itself crashing (different from Mosflm crashing, and iMosflm giving you a message that Mosflm has crashed); this is usually down to one of two different problems - (a) you are not using the version of TclTk that we recommend - could be that you are using the one that comes with the CCP4 distro, which is known to have issues on some platforms, or (b) you've found a new or unpatched bug in iMosflm, in which case, we'd really like (I mean that) to know about it so we can track it down and fix it. (2) Mosflm (the underlying processing program) has come across a situation that it can't deal with and has shut itself down (and iMosflm has lost contact with it); you should get a message about a crash log, and it will advise sending it to the Mosflm developers. If you do that, we will have a good look through it and do our best to come up with a fix, or a way round your problem. (3) Mosflm has actually crashed in an unexpected way. This is (more than likely) a bug that should be fixed. We always like to hear about things like this so that we can fix them. I have a little experience in rooting out Mosflm/iMosflm problems - if you'd like to share your error messages log files with me, I will do my best to get to the bottom of your problem. Data collected at a synchrotron, axis set to reversephi in imosflm (newest release). Suse Linux, Swap space 2 GB. Anyway, even if (i)mosflm looses orientation, it should complain and not crash. Thanks, Marius Dr.habil. Marius Schmidt Asst. Professor University of Wisconsin-Milwaukee Department of Physics Room 454 1900 E. Kenwood
Re: [ccp4bb] mosflm and hkl2000
Sorry, I was not trying to criticise. I have been trying to deal with a number of queries on and off the board recently where identifying the problem has involved an excessive number of extra exchanges to obtain information. I therefore thought it appropriate to provide some suggestions on how to facilitate this process. I attempted to employ a slightly tongue-in-cheek tone to try and avoid any impression of criticism, which would have defeated the point. I gather I did not succeed. Also, a few users commented on my signature. This was clearly another humour failure. The attempted joke being that while other people go to sychrotrons and do science and bring home results, I go to synchrotrons and never even see the hardware, let alone do an experiment. I will try and remember not to attempt humour in future. :( Kevin
[ccp4bb] mosflm and hkl2000
We have a little internal project where we want to compare the quality of data reduced with HKL2000 and IMOSFLM (mosflm) to 1.3 A. Unfortunately, imosflm with its standard settings crashes always even at lower resolution whereas HKL2000 is rock stable. Why is that so? Any experience with that? Data collected at a synchrotron, axis set to reversephi in imosflm (newest release). Suse Linux, Swap space 2 GB. Anyway, even if (i)mosflm looses orientation, it should complain and not crash. Thanks, Marius Dr.habil. Marius Schmidt Asst. Professor University of Wisconsin-Milwaukee Department of Physics Room 454 1900 E. Kenwood Blvd. Milwaukee, WI 53211 phone: +1-414-229-4338 email: m-schm...@uwm.edu http://users.physik.tu-muenchen.de/marius/
Re: [ccp4bb] mosflm and hkl2000
Dear Marius, 'crash' is a very general term. Maybe you could describe at what stage imosflm crashes? Is it reproducible or does it crash at random stages? When you start imosflm from a terminal, what are the last words printed to the terminal? Are there any log-files that might give a hint as to what went wrong? Sincerely, Tim B.T.W.: I've seen cases where hkl2000 gets stuck, too... -- Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A On Fri, 31 Jul 2009, Marius Schmidt wrote: We have a little internal project where we want to compare the quality of data reduced with HKL2000 and IMOSFLM (mosflm) to 1.3 A. Unfortunately, imosflm with its standard settings crashes always even at lower resolution whereas HKL2000 is rock stable. Why is that so? Any experience with that? Data collected at a synchrotron, axis set to reversephi in imosflm (newest release). Suse Linux, Swap space 2 GB. Anyway, even if (i)mosflm looses orientation, it should complain and not crash. Thanks, Marius Dr.habil. Marius Schmidt Asst. Professor University of Wisconsin-Milwaukee Department of Physics Room 454 1900 E. Kenwood Blvd. Milwaukee, WI 53211 phone: +1-414-229-4338 email: m-schm...@uwm.edu http://users.physik.tu-muenchen.de/marius/
Re: [ccp4bb] mosflm and hkl2000
Is it the gui or mosflm itself that crashes? The new gui is dependent upon a number of external dependencies, so you are at the mercy of the stability of those. The old gui still works fine, at least last time I checked. On Thu, July 30, 2009 4:40 pm, Marius Schmidt wrote: We have a little internal project where we want to compare the quality of data reduced with HKL2000 and IMOSFLM (mosflm) to 1.3 A. Unfortunately, imosflm with its standard settings crashes always even at lower resolution whereas HKL2000 is rock stable. Why is that so? Any experience with that? Data collected at a synchrotron, axis set to reversephi in imosflm (newest release). Suse Linux, Swap space 2 GB. Anyway, even if (i)mosflm looses orientation, it should complain and not crash. Thanks, Marius Dr.habil. Marius Schmidt Asst. Professor University of Wisconsin-Milwaukee Department of Physics Room 454 1900 E. Kenwood Blvd. Milwaukee, WI 53211 phone: +1-414-229-4338 email: m-schm...@uwm.edu http://users.physik.tu-muenchen.de/marius/ William G. Scott Contact info: http://chemistry.ucsc.edu/~wgscott/
