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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >>> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> >>>> 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 _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list [email protected] 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
