Hi,
I would like to give you a little update about the release.
All testsuites pass now (on Jenkins). For the most part, this was 'fixing the testsuites', rather than fixing actual code.
Some tickets still need to be addressed, and/or need more input:
#1897 [1]: external library build issues #1853 [2]: diagonal Carpet output. The troubling patch will be moved to a feature branch and be reverted from both release and master until fixed. #1850 [4]: Stampede performance problem (reviewed ok, but not resolved)
Would-be-nice tickets that potentially could make it into the release include:
#1881 [3]: improve piraha error messages (needs review, and a decision about inclusion in the release, which I'll leave to the reviewer). #1894 [5]: TwoPuncture potential segfault fix (reviewed ok, but not pushed)
I propose we'll use today (and tomorrow for people in the EU) to fix all of those. I'll create release branches after that, hopefully tomorrow morning (US time). I'll then send around a request to start testing as heavily as you can/dare.
If you do start working on one of those tickets, leave a note here: https://trac.einsteintoolkit.org/ticket/1895 to avoid duplicated work.
What is the current status of the re-worked gallery?
Frank Loeffler
[1] https://trac.einsteintoolkit.org/ticket/1897 [2] https://trac.einsteintoolkit.org/ticket/1853 [3] https://trac.einsteintoolkit.org/ticket/1881 [4] https://trac.einsteintoolkit.org/ticket/1850 [5] https://trac.einsteintoolkit.org/ticket/1894
On Thu, May 26, 2016 at 11:44 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
What is the current status of the re-worked gallery?
We have a clone of the website with the galley split into separate pages. There is still a small amount to do with the example discussed in the last call, so once that is done we can push the changes to it and the re-worked gallery.
On 26 May 2016, at 17:44, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
I would like to give you a little update about the release.
All testsuites pass now (on Jenkins). For the most part, this was 'fixing the testsuites', rather than fixing actual code.
Some tickets still need to be addressed, and/or need more input:
#1897 [1]: external library build issues #1853 [2]: diagonal Carpet output. The troubling patch will be moved to a feature branch and be reverted from both release and master until fixed. #1850 [4]: Stampede performance problem (reviewed ok, but not resolved)
Would-be-nice tickets that potentially could make it into the release include:
#1881 [3]: improve piraha error messages (needs review, and a decision about inclusion in the release, which I'll leave to the reviewer). #1894 [5]: TwoPuncture potential segfault fix (reviewed ok, but not pushed)
I propose we'll use today (and tomorrow for people in the EU) to fix all of those. I'll create release branches after that, hopefully tomorrow morning (US time). I'll then send around a request to start testing as heavily as you can/dare.
Hi Frank,
Do we usually test on the release branches first? I think we should test on the trunk, otherwise the inevitable fixes for different machines will have to be separately applied to both branches. Since we haven't done ANY testing on anything other than the Ubuntu Jenkins VM yet, I think it's better to hold off on the release branches until we have some confidence in trunk.
So I would say the next step is to start testing. Erik: you have a well-developed infrastructure for this. Would you be able to submit a batch of tests?
-- Ian Hinder http://members.aei.mpg.de/ianhin
Yes, I'll submit a batch of tests.
I tested Nvidia, Bethe, Edison on Wednesday, and they worked without a hitch. Let me know once I should start more wide-spread testing. Expect fallout, i.e. necessary changes to Simfactory machine configurations.
-erik
On Fri, May 27, 2016 at 3:00 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 26 May 2016, at 17:44, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
I would like to give you a little update about the release.
All testsuites pass now (on Jenkins). For the most part, this was 'fixing the testsuites', rather than fixing actual code.
Some tickets still need to be addressed, and/or need more input:
#1897 [1]: external library build issues #1853 [2]: diagonal Carpet output. The troubling patch will be moved to a feature branch and be reverted from both release and master until fixed. #1850 [4]: Stampede performance problem (reviewed ok, but not resolved)
Would-be-nice tickets that potentially could make it into the release include:
#1881 [3]: improve piraha error messages (needs review, and a decision about inclusion in the release, which I'll leave to the reviewer). #1894 [5]: TwoPuncture potential segfault fix (reviewed ok, but not pushed)
I propose we'll use today (and tomorrow for people in the EU) to fix all of those. I'll create release branches after that, hopefully tomorrow morning (US time). I'll then send around a request to start testing as heavily as you can/dare.
Hi Frank,
Do we usually test on the release branches first? I think we should test on the trunk, otherwise the inevitable fixes for different machines will have to be separately applied to both branches. Since we haven't done ANY testing on anything other than the Ubuntu Jenkins VM yet, I think it's better to hold off on the release branches until we have some confidence in trunk.
So I would say the next step is to start testing. Erik: you have a well-developed infrastructure for this. Would you be able to submit a batch of tests?
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 27 May 2016, at 21:02, Erik Schnetter schnetter@cct.lsu.edu wrote:
Yes, I'll submit a batch of tests.
I tested Nvidia, Bethe, Edison on Wednesday, and they worked without a hitch. Let me know once I should start more wide-spread testing. Expect fallout, i.e. necessary changes to Simfactory machine configurations.
Hi Erik,
For some reason that I have not understood, the job which analyses the results in Jenkins wasn't being triggered after your tests were run. The repository was updated, but the hook that notifies Jenkins didn't seem to work. The error message would have been printed when your script ran "git push". Do you still happen to have that output?
The results so far are now shown as usual at
https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkit...
There are a lot of old runs in there. Should I apply a filter so that only runs newer than a certain date are included?
On 27 May 2016, at 21:02, Erik Schnetter schnetter@cct.lsu.edu wrote:
Yes, I'll submit a batch of tests.
I tested Nvidia, Bethe, Edison on Wednesday, and they worked without a hitch. Let me know once I should start more wide-spread testing. Expect fallout, i.e. necessary changes to Simfactory machine configurations.
Hi Erik,
The results for Edison didn't seem to make it to the repository (http://git.barrywardell.net/?p=EinsteinToolkitTestResults-sandbox.git;a=summ...).
You said the tests went "without a hitch", but I think you just meant that they still compiled, the test system worked, and results were generated. However, Bethe had 40 failures, and nvidia had 29.
Only 191 tests ran on stampede-Crelease, where most of the other machines have ~400 tests.
I have applied a cutoff in the table (https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkit...) so that only results from tests run within the past 30 days are included.
Ian
I am observing widespread breakage when running the tests. So far, things are "working" only on my laptop and two workstations, and are broken everywhere else. And "working" here is that the tests run and finish and report results, not that they succeed.
I am hoping that there is a common cause, and that we won't have to track down a different issue for every HPC system.
-erik
On Sun, May 29, 2016 at 8:36 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 27 May 2016, at 21:02, Erik Schnetter schnetter@cct.lsu.edu wrote:
Yes, I'll submit a batch of tests.
I tested Nvidia, Bethe, Edison on Wednesday, and they worked without a hitch. Let me know once I should start more wide-spread testing. Expect fallout, i.e. necessary changes to Simfactory machine configurations.
Hi Erik,
The results for Edison didn't seem to make it to the repository ( http://git.barrywardell.net/?p=EinsteinToolkitTestResults-sandbox.git;a=summ... ).
You said the tests went "without a hitch", but I think you just meant that they still compiled, the test system worked, and results were generated. However, Bethe had 40 failures, and nvidia had 29.
Only 191 tests ran on stampede-Crelease, where most of the other machines have ~400 tests.
I have applied a cutoff in the table ( https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkit...) so that only results from tests run within the past 30 days are included.
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 29 May 2016, at 16:40, Erik Schnetter schnetter@cct.lsu.edu wrote:
Ian
I am observing widespread breakage when running the tests. So far, things are "working" only on my laptop and two workstations, and are broken everywhere else. And "working" here is that the tests run and finish and report results, not that they succeed.
I am hoping that there is a common cause, and that we won't have to track down a different issue for every HPC system.
Hi Erik,
The error with triggering the analysis in Jenkins is caused by certificates.
On the git server that triggers the Jenkins analysis in a post-update hook, I get the error
$ curl -X POST https://build.barrywardell.net/job/EinsteinToolkitMulti-sandbox/build?token=... curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none More details here: http://curl.haxx.se/docs/sslcerts.html
According to
https://www.sslshopper.com/ssl-checker.html#hostname=https://build.barryward...
the Jenkins machine has a LetsEncrypt certificate which is not trusted in all browsers.
Barry, do you know what is needed?
I have added the -k option to curl to ignore the certificate error for now, so the automated triggering of the test analysis is working again.
On Sun, May 29, 2016 at 11:03 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 29 May 2016, at 16:40, Erik Schnetter schnetter@cct.lsu.edu wrote:
Ian
I am observing widespread breakage when running the tests. So far,
things are "working" only on my laptop and two workstations, and are broken everywhere else. And "working" here is that the tests run and finish and report results, not that they succeed.
I am hoping that there is a common cause, and that we won't have to
track down a different issue for every HPC system.
Hi Erik,
The error with triggering the analysis in Jenkins is caused by certificates.
On the git server that triggers the Jenkins analysis in a post-update hook, I get the error
$ curl -X POST https://build.barrywardell.net/job/EinsteinToolkitMulti-sandbox/build?token=... curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none More details here: http://curl.haxx.se/docs/sslcerts.html
According to
https://www.sslshopper.com/ssl-checker.html#hostname=https://build.barryward...
the Jenkins machine has a LetsEncrypt certificate which is not trusted in all browsers.
Barry, do you know what is needed?
This has now been fixed on https://build.barrywardell.net. The problem was a missing intermediate cert.
users@lists.einsteintoolkit.org
-
Barry Wardell -
Erik Schnetter -
Frank Loeffler -
Ian Hinder