Present: Frank, Josh, Roland, Ian, Philipp, Erik, Peter
Please register lunch preferences here http://goo.gl/forms/XAlDgYvxuK so that food can be ordered.
Tickets: * failing Dissipation tests: these are caused by changes to AHFinderDirect related to scheduling. * poisson: not clear what causes this. Roland suspects that not all Jenkins slaves are exactly equal and that it only fails on this one * testsuite comparison is script received comments, Frank will look at them * HDF5 zlib etc detection: apply all patches and test, Ian to provide his changes as well
Next ET release: * Frank will work toward it but we are waiting or some of the fixes to be tested first
Workshop: * please submit your information about lunch and receiption information here: http://goo.gl/forms/XAlDgYvxuK
Yours, Roland
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
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
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/testRe...
On 12 May 2016, at 21:37, Frank Loeffler knarf@cct.lsu.edu 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/d7021a52bd83448db589b2...) 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
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
On 13 May 2016, at 11:03, Eloisa Bentivegna eloisa.bentivegna@ct.infn.it 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.
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
users@lists.einsteintoolkit.org
-
Eloisa Bentivegna -
Frank Loeffler -
Frank Löffler
-
Ian Hinder -
Roland Haas