Hi Ed. Thanks for fixing the bug! But I think the worst most pity thing, is that I have waster 1/4-1/2 year of my PhD to fix this bug: bug #22032: Minimisation explodes when using Grid_INC=None https://gna.org/bugs/index.php?22032 My last three weeks analysis have shown that the error catching at boundary values had a huge impact on the minimisation search. It simply went to scrap. This was also the case when running grid search. Touching the math domain errors, caught simplex to stop. https://gna.org/bugs/download.php?file_id=20704 https://gna.org/bugs/download.php?file_id=20698 I have tried so hard to understand why the behaviour of relax is different from other programs. I have tested, and inspected code, and tried other programs. relax was just stubborn. Realising this issue has been a relieve! I am happy that the processor.run_queue() bug only is related to the test-suite. It hopefully did not affect production??? I can have night-mares about these bugs, as that can mean that scientists are wasting their time. Including mine. Best Troels 2014-05-20 13:44 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:
Hi, I have now fixed this issue: http://svn.gna.org/viewcvs/relax/trunk/multi/uni_processor.py?r1=23254&r2=23253&pathrev=23254 As you can see, the change is incredibly simple, and it is exactly what Gary documented in his FIXME comment. It's almost a pity Troels that, after finding the source of this 8 year old bug, you didn't take the final honours and kill it. You deserve the credit though as this has been annoying multiple relax developers via the test suite for all of those 8 years! You should be able to find mentions of it throughout the relax-devel mailing list archives. No one thought to look at the command queuing as the source of this. Cheers, Edward On 20 May 2014 11:52, Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx> wrote:Hi Ed. I tried hard for several hours yesterday. But this multi-processing goes beyond my skills... If you know a little more about, and can fix it, I would be very happy. I can try the thing you suggested, but beyond that, I would be lost. Best Trpels 2014-05-20 9:43 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:Hi Troels, You might have actually have found the source of the problem! This has been an issue for a long time, but I never solved it. It affects many analysis types and I have always wondered why one failing test would cause many subsequent tests of the same analysis type to fail. This has been around longer than the dispersion analysis which was started in 2009. I always tried to solve it in the special self.tearDown() test suite method for cleaning up after tests, but this somehow never completely solved the issue. So it could have something to do with the FIXME comment in the run_queue() method of the multi.uni_processor module: def run_queue(self): #FIXME: need a finally here to cleanup exceptions states for windows etc last_command = len(self.command_queue)-1 for i, command in enumerate(self.command_queue): completed = (i == last_command) command.run(self, completed) #self.run_command_queue() #TODO: add cheques for empty queues and maps if now warn del self.command_queue[:] self.memo_map.clear() There are a few minor FIXMEs and TODOs in Gary Thompson's multi-processor framework. But this one might be quite important for the test suite. You could try as the FIXME says, add a 'try-finally' statements so the last two lines are always run. This may cause other issues, so be careful. Note, this must not be committed to your 'disp_speed' branch. If you have a fix, make sure it is applied to the trunk. Cheers, Edward On 20 May 2014 02:04, Troels E. Linnet <NO-REPLY.INVALID-ADDRESS@xxxxxxx> wrote:Additional Item Attachment, bug #22055 (project relax): File name: log.txt Size:792 KB _______________________________________________________ Reply to this item at: <http://gna.org/bugs/?22055> _______________________________________________ Message sent via/by Gna! http://gna.org/ _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list relax-devel@xxxxxxx To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel