mailRe: [bug #22055] The processor.run_queue() does not clean up in uni_processor?


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Troels Emtekær Linnet on May 20, 2014 - 14:31:
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



Related Messages


Powered by MHonArc, Updated Tue May 20 16:00:19 2014