Good luck !
On 10-03-16 12:17 PM, Edward d'Auvergne wrote: > It looks like it! I just have to schedule an entire day somewhere to > do this :S Plus I have to work out how to package minfx with relax > (to avoid version issues). > > Regards, > > Edward > > > On 16 March 2010 17:07, Sébastien Morin<[email protected]> wrote: > >> Hi Ed, >> >> I just tried using the repository version and this error is now absent >> from my 64 bit machine... >> >> Maybe it is time for relax-1.3.5... :p >> >> Cheers, >> >> >> Séb >> >> >> On 10-03-16 11:47 AM, Edward d'Auvergne wrote: >> >>> Hi, >>> >>> Does this still fail in the 1.3 line? I should have fixed this one >>> quite a while ago. I think it's about time I released relax-1.3.5! >>> >>> Cheers, >>> >>> Edward >>> >>> >>> On 16 March 2010 15:44, Sébastien Morin<[email protected]> >>> wrote: >>> >>> >>>> Hi Edward, >>>> >>>> I just tested the Gentoo machines again using relax-1.3.4 and minf-1.0.2. >>>> >>>> Three 32 bit machines I tested completed the test-suite without any >>>> error. Two other machines I previously had in my possession are no >>>> longer available... >>>> >>>> However, one 64 bit machine failed for one test, always with the same >>>> values: >>>> >>>> ==================== >>>> FAIL: Constrained Newton opt, GMW Hessian mod, More and Thuente line >>>> search {S2=0.970, te=2048, Rex=0.149} >>>> >>>> ... >>>> >>>> relax> minimise(*args=('newton',), func_tol=1e-25, >>>> max_iterations=10000000, constraints=True, scaling=True, verbosity=1) >>>> Simulation 1 >>>> Simulation 2 >>>> Simulation 3 >>>> >>>> relax> monte_carlo.error_analysis(prune=0.0) >>>> Traceback (most recent call last): >>>> File "/home/semor/relax-1.3.4/test_suite/system_tests/model_free.py", >>>> line 610, in test_opt_constr_newton_gmw_mt_S2_0_970_te_2048_Rex_0_149 >>>> self.value_test(spin, select, s2, te, rex, chi2, iter, f_count, >>>> g_count, h_count, warning) >>>> File "/home/semor/relax-1.3.4/test_suite/system_tests/model_free.py", >>>> line 1110, in value_test >>>> self.assertEqual(spin.f_count, f_count, msg=mesg) >>>> AssertionError: Optimisation failure. >>>> >>>> System: Linux >>>> Release: 2.6.20-gentoo-r7 >>>> Version: #1 SMP Sat Apr 28 23:31:52 Local time zone must be set--see zic >>>> Win32 version: >>>> Distribution: gentoo 1.12.13 >>>> Architecture: 64bit ELF >>>> Machine: x86_64 >>>> Processor: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz >>>> Python version: 2.6.4 >>>> numpy version: 1.3.0 >>>> >>>> >>>> s2: 0.9699999999999994 >>>> te: 2048.0000000000446 >>>> rex: 0.14900000000001615 >>>> chi2: 8.3312601381368332e-28 >>>> iter: 22 >>>> f_count: 91 >>>> g_count: 91 >>>> h_count: 22 >>>> warning: None >>>> ==================== >>>> >>>> Regards, >>>> >>>> >>>> Séb :) >>>> >>>> >>>> >>>> On 10-02-21 9:00 AM, Edward d'Auvergne wrote: >>>> >>>> >>>>> Is it different for the different machines, or is it different each >>>>> time on the same machine? If you give a range of numbers for the >>>>> optimisation results, these tests could be relaxed a little. >>>>> >>>>> Cheers, >>>>> >>>>> Edward >>>>> >>>>> >>>>> On 21 February 2010 14:41, Sébastien Morin<[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> Hi Ed, >>>>>> >>>>>> I agree with you that this is not an important issue given the small >>>>>> variations observed... >>>>>> >>>>>> I was just still a bit annoyed by this happening on our Gentoo systems... >>>>>> >>>>>> But maybe this is just because of Gentoo itself, as in Gentoo almost >>>>>> everything is compiled locally, so every system is different because of >>>>>> all >>>>>> the variables that can be changed that affect compilation... >>>>>> >>>>>> Ok, let's forget all this ! >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> Séb >>>>>> >>>>>> >>>>>> On 10-02-21 8:32 AM, Edward d'Auvergne wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The code is not parallelised as most optimisation algorithms are not >>>>>>> amenable to parallelisation. There's a lot of research in that field, >>>>>>> but the code here is not along these lines. Do you still see this >>>>>>> problem? Maybe it is a bug in this specific version of the GCC >>>>>>> compiler which created the python executable? Does it occur on >>>>>>> machines with a different Gentoo versions installed? Can you >>>>>>> reproduce the error in a virtual machine? This is a fixed code path >>>>>>> and cannot in any way be different upon different runs of the test >>>>>>> suite. It doesn't change on all the Mandriva installs I have, all the >>>>>>> Macs it has been tested on, or even on the Windows virtual image I use >>>>>>> to build and test relax on Windows. I've even tested it on Solaris >>>>>>> without problems! In any case, this bug is definitely machine >>>>>>> specific and not related to relax itself. Sorry, I don't know what >>>>>>> else I can do to try to track this down. Maybe your CPUs are doing >>>>>>> some strange frequency scaling depending on load, and that is causing >>>>>>> this bizarre behaviour? In any case, this is not an issue for relax >>>>>>> execution and only affects the precision of optimisation in a small >>>>>>> way. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Edward >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 21 February 2010 05:34, Sébastien Morin<[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Ed, >>>>>>>> >>>>>>>> This has been a long time since we discussed about this... >>>>>>>> >>>>>>>> However, talking with Olivier last week, we discussed about one >>>>>>>> possibility >>>>>>>> to explain this issue. Is the code in question in some way >>>>>>>> parallelized, >>>>>>>> i.e. are there multiple processes running at the same time with their >>>>>>>> results being combined subsequently ? If yes, there could be conditions >>>>>>>> in >>>>>>>> which the problem could arise either because of variations in allocated >>>>>>>> memory or cpu that would change the timing between the different >>>>>>>> processes, >>>>>>>> hence affecting the final result... >>>>>>>> >>>>>>>> Does that make sens ? >>>>>>>> >>>>>>>> Olivier, is this what you explained me last week ? >>>>>>>> >>>>>>>> >>>>>>>> Sébastien >>>>>>>> >>>>>>>> >>>>>>>> On 09-09-14 3:30 AM, Edward d'Auvergne wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've been trying to work out what is happening, but it is a complete >>>>>>>>> mystery to me. The algorithms are fixed in stone - I coded them >>>>>>>>> myself and you can see it in the minfx code. They are standard >>>>>>>>> optimisation algorithms that obey fixed rules. On the same machine it >>>>>>>>> must, without question, give the same result every time! If it >>>>>>>>> doesn't, something is wrong with the machine, either hardward or >>>>>>>>> software. Would it be possible to install an earlier python and numpy >>>>>>>>> version (maybe 2.5 and 1.2.1 respectively) to see if that makes a >>>>>>>>> difference? Or maybe it is the Linux kernel doing some strange things >>>>>>>>> with the CPU - maybe switching between power profiles causing the CPU >>>>>>>>> floating point math precision to change? Are you 100% sure that all >>>>>>>>> computers give variable results (between each run), and not that they >>>>>>>>> just give a different fixed result each time? Maybe there is a >>>>>>>>> non-fatal kernel bug not triggered by Oliver's hardward? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Edward >>>>>>>>> >>>>>>>>> >>>>>>>>> P.S. A note to others reading this - this problem is not serious for >>>>>>>>> relax's optimisation! >>>>>>>>> >>>>>>>>> >>>>>>>>> 2009/9/4 Sébastien Morin<[email protected]>: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Ed, >>>>>>>>>> >>>>>>>>>> (I added Olivier Fisette in CC as he is quite computer knowledgeable >>>>>>>>>> and >>>>>>>>>> could help us rationalize this issue...) >>>>>>>>>> >>>>>>>>>> This strange behavior was observed for my laptop and the two other >>>>>>>>>> computers in the lab with the failures in the system tests (i.e. for >>>>>>>>>> the >>>>>>>>>> three computers of the bug report). >>>>>>>>>> >>>>>>>>>> I performed some of the different tests proposed on the following >>>>>>>>>> page: >>>>>>>>>> -> >>>>>>>>>> http://www.gentoo.org/doc/en/articles/hardware-stability-p1.xml >>>>>>>>>> (tested CPU with infinite rebuild of kernel using gcc >>>>>>>>>> for 4 >>>>>>>>>> hours) >>>>>>>>>> (tested CPU with cpuburn-1.4 for XXXX hours) >>>>>>>>>> (tested RAM with memtester-4.0.7 for> 6 hours) >>>>>>>>>> to check the CPU and RAM, but did not find anything... Of course, >>>>>>>>>> these >>>>>>>>>> tests may not have uncovered potential problems in my CPU and RAM, >>>>>>>>>> but >>>>>>>>>> most chances are they are fine. Moreover, the problem being observed >>>>>>>>>> for >>>>>>>>>> three different computers, it would be surprising that hardware >>>>>>>>>> failures >>>>>>>>>> occur in these three machines... >>>>>>>>>> >>>>>>>>>> The three systems run Gentoo Linux with kernel-2.6.30, numpy-1.3.0 >>>>>>>>>> and >>>>>>>>>> python-2.6.2. However, the fourth computer to which I have access >>>>>>>>>> (for >>>>>>>>>> Olivier: this computer is 'hibou'), and which passes the system tests >>>>>>>>>> properly, also runs Gentoo Linux with kernel 2.6.30, numpy-1.3.0 and >>>>>>>>>> python-2.6.2... >>>>>>>>>> >>>>>>>>>> A potential option could be that some kernel configuration is causing >>>>>>>>>> these problems... >>>>>>>>>> >>>>>>>>>> Another option would be that, although the algorithms are supposedly >>>>>>>>>> fixed, that they are not... >>>>>>>>>> >>>>>>>>>> I could check if the calculations diverge always at the same step >>>>>>>>>> and, >>>>>>>>>> if so, try to see what function is problematic... >>>>>>>>>> >>>>>>>>>> Other ideas ? >>>>>>>>>> >>>>>>>>>> Do you know any other minimisation library with which I could test to >>>>>>>>>> see if these computers indeed give rise to changing results or if >>>>>>>>>> this >>>>>>>>>> is limited to relax (and minfx) ? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Séb :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Edward d'Auvergne wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is very strange, very strange indeed! I've never seen anything >>>>>>>>>>> quite like this. Is it only your laptop that is giving this >>>>>>>>>>> variable >>>>>>>>>>> result? I'm pretty sure that it's not related to a random seed >>>>>>>>>>> because the optimisation at no point uses random numbers - it is >>>>>>>>>>> 100% >>>>>>>>>>> fixed, pre-determined, etc. and should never, ever vary (well on >>>>>>>>>>> different machines it will change, but never on the same machine). >>>>>>>>>>> What is the operating system on the laptop? Can you run a ram >>>>>>>>>>> checking program or anything else to diagnose hardware failures? >>>>>>>>>>> Maybe the CPU is overheating? Apart from hardware problems, since >>>>>>>>>>> you >>>>>>>>>>> never recompile Python or numpy between these tests I cannot think >>>>>>>>>>> of >>>>>>>>>>> anything else that could possibly cause this. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Edward >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2009/9/3 Sébastien Morin<[email protected]>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi Ed, >>>>>>>>>>>> >>>>>>>>>>>> I've just tried what you proposed and observed something quite >>>>>>>>>>>> strange... >>>>>>>>>>>> >>>>>>>>>>>> Here are the results: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> ./relax scripts/optimisation_testing.py> /dev/null >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> (stats from my laptop, different trials, see below) >>>>>>>>>>>> iter 161 147 151 >>>>>>>>>>>> f_count 765 620 591 >>>>>>>>>>>> g_count 168 152 158 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> ./relax -s >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> (stats from my laptop, different trials, see below) >>>>>>>>>>>> iter 146 159 160 159 >>>>>>>>>>>> f_count 708 721 649 673 >>>>>>>>>>>> g_count 152 166 167 166 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Problem 1: >>>>>>>>>>>> The results should be the same in both situations, right ? >>>>>>>>>>>> >>>>>>>>>>>> Problem 2: >>>>>>>>>>>> The results should not vary when the test is done multiple times, >>>>>>>>>>>> right >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I have tested different things to find out why the tests give rise >>>>>>>>>>>> to >>>>>>>>>>>> different results as a function of time... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> ./relax scripts/optimisation_testing.py> /dev/null >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> If you modify the file >>>>>>>>>>>> "test_suite/system_tests/__init__.py", then >>>>>>>>>>>> the result will be different. By modifying, I mean just comment a >>>>>>>>>>>> few >>>>>>>>>>>> lines in the run() function. (I usually do that when I want to >>>>>>>>>>>> speed >>>>>>>>>>>> up >>>>>>>>>>>> the process of testing a specific issue.) Maybe this behavior is >>>>>>>>>>>> related >>>>>>>>>>>> to random seed based on the code files... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> ./relax -s >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> This one varies as a function of time without any change. >>>>>>>>>>>> Just >>>>>>>>>>>> doing >>>>>>>>>>>> the test several times in a row will have it varying... Maybe this >>>>>>>>>>>> behavior is related to random seed based on the date and time... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Any idea ? >>>>>>>>>>>> >>>>>>>>>>>> If you want, Ed, I could create you an account on one of these >>>>>>>>>>>> strange-behaving computers... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Séb >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Edward d'Auvergne wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I've now written a script so that you can fix this. Try running: >>>>>>>>>>>>> >>>>>>>>>>>>> ./relax scripts/optimisation_testing.py> /dev/null >>>>>>>>>>>>> >>>>>>>>>>>>> This will give you all the info you need, formatted ready for >>>>>>>>>>>>> copying >>>>>>>>>>>>> and pasting into the correct file. This is currently only >>>>>>>>>>>>> 'test_suite/system_tests/model_free.py'. Just paste the >>>>>>>>>>>>> pre-formatted >>>>>>>>>>>>> python comment into the correct test, and add the different values >>>>>>>>>>>>> to >>>>>>>>>>>>> the list of values checked. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> Edward >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2009/9/3 Sébastien Morin<[email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Ed, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I just checked my original mail >>>>>>>>>>>>>> (https://mail.gna.org/public/relax-devel/2009-05/msg00003.html). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the failure "FAIL: Constrained BFGS opt, backtracking line >>>>>>>>>>>>>> search >>>>>>>>>>>>>> {S2=0.970, te=2048, Rex=0.149}", the counts were initially as >>>>>>>>>>>>>> follows: >>>>>>>>>>>>>> f_count 386 >>>>>>>>>>>>>> g_count 386 >>>>>>>>>>>>>> and are now: >>>>>>>>>>>>>> f_count 743 694 761 >>>>>>>>>>>>>> g_count 168 172 164 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the failure "FAIL: Constrained BFGS opt, More and Thuente >>>>>>>>>>>>>> line >>>>>>>>>>>>>> search {S2=0.970, te=2048, Rex=0.149}", the counts were initially >>>>>>>>>>>>>> as >>>>>>>>>>>>>> follows: >>>>>>>>>>>>>> f_count 722 >>>>>>>>>>>>>> g_count 164 >>>>>>>>>>>>>> and are now: >>>>>>>>>>>>>> f_count 375 322 385 >>>>>>>>>>>>>> g_count 375 322 385 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The different values given for the "just-measured" parameters >>>>>>>>>>>>>> account >>>>>>>>>>>>>> for the 3 different computers I have access to that give rise to >>>>>>>>>>>>>> these >>>>>>>>>>>>>> two annoying failures... >>>>>>>>>>>>>> >>>>>>>>>>>>>> I wounder if the names of the tests in the original mail were not >>>>>>>>>>>>>> mixed, >>>>>>>>>>>>>> as numbers just measured in the second test seem closer to those >>>>>>>>>>>>>> originally posted in the first test, and vice versa... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Anyway, the problem is that there are variations between the >>>>>>>>>>>>>> different >>>>>>>>>>>>>> machines. Variations are also present for the other parameters >>>>>>>>>>>>>> (s2, >>>>>>>>>>>>>> te, >>>>>>>>>>>>>> rex, chi2, iter). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Séb :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Edward d'Auvergne wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you check and see if the numbers are exactly the same as >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> your >>>>>>>>>>>>>>> original email >>>>>>>>>>>>>>> (https://mail.gna.org/public/relax-devel/2009-05/msg00003.html)? >>>>>>>>>>>>>>> Specifically look at f_count and g_count. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Edward >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2009/9/2 Sébastien Morin<[email protected]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Ed, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I updated my svn copies to r9432 and checked if the problem was >>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>> present. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Unfortunately, it is still present... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Séb >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Edward d'Auvergne wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ah, yes, there is a reason. I went through and fixed a series >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> these optimisation difference issues - in my local svn copy. >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> collected these all together and committed them as one after I >>>>>>>>>>>>>>>>> had >>>>>>>>>>>>>>>>> shut the bugs. This was a few minutes ago at r9426. If you >>>>>>>>>>>>>>>>> update >>>>>>>>>>>>>>>>> and test now, it should work. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Edward >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2009/9/2 Sébastien Morin<[email protected]>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Ed, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I just tested the for the presence of this bug (1.3 >>>>>>>>>>>>>>>>>> repository, >>>>>>>>>>>>>>>>>> r9425) >>>>>>>>>>>>>>>>>> and it seems it is still there... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is there a reason why it was closed ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> From the data I have, I guess this bug report should >>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>> re-opened. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Maybe I could try to give more details to help debugging... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Séb :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Edward d Auvergne wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Update of bug #14182 (project relax): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Status: Confirmed => >>>>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>>>> Assigned to: None => >>>>>>>>>>>>>>>>>>> bugman >>>>>>>>>>>>>>>>>>> Open/Closed: Open => >>>>>>>>>>>>>>>>>>> Closed >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________________ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Reply to this item at: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> <http://gna.org/bugs/?14182> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> Message sent via/by Gna! >>>>>>>>>>>>>>>>>>> http://gna.org/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Sébastien Morin >>>>>>>>>>>>>>>>>> PhD Student >>>>>>>>>>>>>>>>>> S. Gagné NMR Laboratory >>>>>>>>>>>>>>>>>> Université Laval& PROTEO >>>>>>>>>>>>>>>>>> Québec, Canada >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Sébastien Morin >>>>>>>>>>>>>>>> PhD Student >>>>>>>>>>>>>>>> S. Gagné NMR Laboratory >>>>>>>>>>>>>>>> Université Laval& PROTEO >>>>>>>>>>>>>>>> Québec, Canada >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Sébastien Morin >>>>>>>>>>>>>> PhD Student >>>>>>>>>>>>>> S. Gagné NMR Laboratory >>>>>>>>>>>>>> Université Laval& PROTEO >>>>>>>>>>>>>> Québec, Canada >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Sébastien Morin >>>>>>>> PhD Student >>>>>>>> S. Gagné NMR Laboratory >>>>>>>> Université Laval& PROTEO >>>>>>>> Québec, Canada >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> Sébastien Morin >>>>>> PhD Student >>>>>> S. Gagné NMR Laboratory >>>>>> Université Laval& PROTEO >>>>>> Québec, Canada >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>>> Sébastien Morin >>>> PhD Student >>>> S. Gagné NMR Laboratory >>>> Université Laval& PROTEO >>>> Québec, Canada >>>> >>>> >>>> _______________________________________________ >>>> relax (http://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 >>>> >>>> >>>> >> -- >> Sébastien Morin >> PhD Student >> S. Gagné NMR Laboratory >> Université Laval& PROTEO >> Québec, Canada >> >> >> _______________________________________________ >> relax (http://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 >> >> -- Sébastien Morin PhD Student S. Gagné NMR Laboratory Université Laval& PROTEO Québec, Canada _______________________________________________ relax (http://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
