Re: [Users] meeting minutes for 2016-05-09
On Fri, May 13, 2016 at 11:01:02AM +0200, Ian Hinder wrote: > I could add such an exclusion, but since it seems to work now and it > is better to test the main ubuntu optionlist, I think I will just > leave it as-is. Do you agree? Yes. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
Hello all, > We are now down to zero build slaves. I will investigate. I restarted the AEI one. The workstation the hosts the VM does not auto-start the VM when it is rebooted (due to a kernel update recently) and I had forgotten about it. It is not up and running again. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
On 13 May 2016, at 11:03, Eloisa Bentivegna wrote: > On 12/05/16 21:37, Frank Loeffler wrote: >> On Thu, May 12, 2016 at 08:00:40PM +0200, Eloisa Bentivegna wrote: >>> this is really due to the fact that this specific variable >>> (ct_multilevel-err) should not be tested for relative changes, as it's >>> difficult to define a natural tolerance, and sometimes even the smallest >>> differences in execution lead to very large relative changes. I have >>> just pushed a commit that makes sure that a failure is only triggered if >>> the absolute difference is above threshold. >> >> That is great, thanks. > > No problem. But technically the next test is still pending (or at least > so it says on https://build.barrywardell.net/job/EinsteinToolkit/), so I > haven't checked that the change has fixed anything. We are now down to zero build slaves. I will investigate. -- Ian Hinder http://members.aei.mpg.de/ianhin ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
On 12/05/16 21:37, Frank Loeffler wrote: > On Thu, May 12, 2016 at 08:00:40PM +0200, Eloisa Bentivegna wrote: >> this is really due to the fact that this specific variable >> (ct_multilevel-err) should not be tested for relative changes, as it's >> difficult to define a natural tolerance, and sometimes even the smallest >> differences in execution lead to very large relative changes. I have >> just pushed a commit that makes sure that a failure is only triggered if >> the absolute difference is above threshold. > > That is great, thanks. No problem. But technically the next test is still pending (or at least so it says on https://build.barrywardell.net/job/EinsteinToolkit/), so I haven't checked that the change has fixed anything. Eloisa ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
On 12 May 2016, at 21:37, Frank Loeffler wrote: > On Thu, May 12, 2016 at 08:00:40PM +0200, Eloisa Bentivegna wrote: >> this is really due to the fact that this specific variable >> (ct_multilevel-err) should not be tested for relative changes, as it's >> difficult to define a natural tolerance, and sometimes even the smallest >> differences in execution lead to very large relative changes. I have >> just pushed a commit that makes sure that a failure is only triggered if >> the absolute difference is above threshold. > > That is great, thanks. > > On the other hand, the actual change that most likely triggered this > was a change in option lists on Jenkins, and there most likely the > -Ofast option. Before build #758 [1], the Jenkins VM used a special > jenkins option list, and starting with that build, it now uses the > generic Ubuntu option list. > > Now, the tests should obviously also pass using that option list, but I > found it interesting to know why it started to fail when it did. Was the > change in option list intentional? Hi Frank, No, this was not intentional. The change in question (https://bitbucket.org/ianhinder/cactusjenkins/commits/d7021a52bd83448db589b2346c43441682eecabb) was not supposed to change the optionlist used for the main ET job, but now that I look at it, I see that it had exactly that effect. I think when I first made the change, I was working on a separate copy of the repository that wouldn't affect the main job, but when I committed it a few days later, I forgot that I needed to add an exclusion if it was in the main job. I could add such an exclusion, but since it seems to work now and it is better to test the main ubuntu optionlist, I think I will just leave it as-is. Do you agree? This will also have the effect of making the builds slower, as the standard ubuntu optionlist does not use ccache. -- Ian Hinder http://members.aei.mpg.de/ianhin signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
On Thu, May 12, 2016 at 08:00:40PM +0200, Eloisa Bentivegna wrote: > this is really due to the fact that this specific variable > (ct_multilevel-err) should not be tested for relative changes, as it's > difficult to define a natural tolerance, and sometimes even the smallest > differences in execution lead to very large relative changes. I have > just pushed a commit that makes sure that a failure is only triggered if > the absolute difference is above threshold. That is great, thanks. On the other hand, the actual change that most likely triggered this was a change in option lists on Jenkins, and there most likely the -Ofast option. Before build #758 [1], the Jenkins VM used a special jenkins option list, and starting with that build, it now uses the generic Ubuntu option list. Now, the tests should obviously also pass using that option list, but I found it interesting to know why it started to fail when it did. Was the change in option list intentional? Frank [1] https://build.barrywardell.net/job/EinsteinToolkit/lastCompletedBuild/testReport/%28root%29/CT_MultiLevel/poisson_2procs/ signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
Hello Eloisa, > this is really due to the fact that this specific variable > (ct_multilevel-err) should not be tested for relative changes, as it's > difficult to define a natural tolerance, and sometimes even the > smallest differences in execution lead to very large relative > changes. I have just pushed a commit that makes sure that a failure > is only triggered if the absolute difference is above threshold. > > Is this problem actually reported in a ticket? I couldn't find any > reference on the ET TRAC. Nono, no ticket existed. There were a couple of errors that Jenkins reported so it was not yet clear what was to blame. If your changes fixes the issue then this is great. It means one less thing to debug on the VMs (which are slow to compile on). Thank you for the fix. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-05-09
On 09/05/16 16:51, Roland Haas wrote: > Tickets: > * poisson: not clear what causes this. Roland suspects that not all > Jenkins slaves are exactly equal and that it only fails on this one Hi all, this is really due to the fact that this specific variable (ct_multilevel-err) should not be tested for relative changes, as it's difficult to define a natural tolerance, and sometimes even the smallest differences in execution lead to very large relative changes. I have just pushed a commit that makes sure that a failure is only triggered if the absolute difference is above threshold. Is this problem actually reported in a ticket? I couldn't find any reference on the ET TRAC. Best, Eloisa ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
