Dealii: 9.0.1 release

[drwells]

I believe the current consensus is to do a bugfix release to improve compiler and external library support (e.g., #7260).

Here are the PRs we should duplicate on 9.0:

• [x] #6769 (see #7279)
• [x] #7156 (see #7269)
• [x] #6929 (see #7289)
• [x] #6658 (see #7291)
• [x] #7152
• [x] #7270 (see #7286, @tamiko)

I erroneously added #6662 to the list earlier, but I think that that fixes a bug that was added after 9.0, so we should be able to skip it (we should run the test suite with complex petsc to be sure, though).

[masterleinad]

we should run the test suite with complex petsc to be sure, though

Let me do that.

[masterleinad]

Compiling with clang-6 and running the petsc_complex works fine for me. There are only some tests that fail due to missing p4est support. That does probably not have to be fixed for 9.0.1.

[masterleinad]

As far as I understand, #7152 was just an optimization and not a bugfix.

[drwells]

Lets skip #7152 then.

[drwells]

I reran the full test suite with the intel 17 and 16 compilers on a cluster (I did not install most dependencies, though). The only failing test that I see is the new data_out_filter_02.debug which is part of #6929.

[tamiko]

@drwells Running the full testsuite now on the dealii-9.0 release branch. Results should be complete in about 8h.

[tamiko]

Tester is also happy: http://cdash.kyomu.43-1.org/index.php?project=deal.II (the 64 bit container is currently broken, disregard that variant.)

[drwells]

I don't recall having so many problems with clang before. Did we?

[tamiko]

@drwells It basically boils down to 4 gmsh tests failing - that should now be resolved on the tester - as well as two step-36 and step-40 mpi variants failing. That has been a long standing issue and I suspect something in PETSc going wrong when calling mumps (and when being compiled with clang).

[tamiko]

Also, the mumps version in Gentoo is ancient. ugh.

[drwells]

Thats right; I had forgotten that SLEPc requires an LU solver at some point.

Is there anything else we need to do before we tag the release?

[tamiko]

@drwells What about tagging a release in the next 48h? (I am happy to do that) :-)

[masterleinad]

We should probably also include #6730.

[tamiko]

@masterleinad Correct me if I am wrong, but #6720 (which was reverted by #6730) was after the release branch was forked off, wasn't it?

[masterleinad]

Yes, what I meant to say that the release branch doesn't have vectorization.cc which appears to be a problem if VectorizedArray::n_array_elements is odr-used.

[davydden]

I have a few failing tests on 9.0 branch
http://cdash.kyomu.43-1.org/viewTest.php?onlyfailed&buildid=5236 I will check details tomorrow

[tamiko]

@davydden That looks quite good. One is a timeout and the other 4 are failing gmsh tests (and are almost certainly bogus - last time those tests failed for me gmsh wasn't configured with lapack/blas support.).

[davydden]

I don’t think they bogus, looks like some incompatibility with GMSH version, I build with 4.0.0. Maybe the file format changed or alike.

[davydden]

Oh, and Gmsh 3.0.6 works perfectly fine
http://cdash.kyomu.43-1.org/buildSummary.php?buildid=5220 Definitely not bogus! :-)

[davydden]

http://gmsh.info/CHANGELOG.txt

4.0.0 (August 22, 2018): new C++, C, Python and Julia API; new MSH4 format;....

[masterleinad]

Do these tests pass on master with Gmsh 4.0.0?

[tamiko]

@davydden These two gmsh tests had been incredibly unstable in the past.

@masterleinad We haven't introduced any version 4.0.0 fixes, so most likely no.

But this is really not relevant for the 9.0.1 release.

Edit: I have created an issue #7326

[davydden]

But this is really not relevant for the 9.0.1 release.

I agree, it's minor issue and should not hold 9.0.1 release. So, shall we go on and tag it? Looks like all the crucial fixes are in...

[bangerth]

So it!

[bangerth]

Err, do it!

[davydden]

do it!

i certainly don't know how to tag, I guess we need to wait for @tamiko 😄

[tamiko]

@davydden @bangerth At your service! :smile:

[tamiko]

• [x] * Nominate a "release officer" that is in charge of (almost all) of the following steps
• [x] 1 Create new changes file
• [x] 11a Check that .gitattributes is up to date. (Do quick tests work?)
• [x] 12 Push the button
  
  
  
  • Change VERSION to 9.0.1
  
  
  • Create a signed tag of exactly this commit
  
  
  • Push changes to github
  
  
• [x] 13 Create the tar files
  
  
  
  • Download the source tarball from github, verify that its contents is what we expect
  
  
  • Cryptographically sign it (detached, armored signature)
  
  
  • Create full offline_doc tarball and sign it
  
  
• [x] 14a Create a release on github and upload files (and detached signatures)
• [x] 17b Update dealii in Spack done: https://github.com/spack/spack/pull/9511
• [ ] 17c Update dealii in Candi
• [x] 17d Update dealii in Gentoo Science overlay
• [ ] 17e Update dealii in Ubuntu/Debian
• [x] 17f Update dealii in Archlinux AUR
• [ ] 19 Announce the release via e-mail
• [x] 19b Update the deal.II wikipedia page
• [x] 20 Celebrate!

[tamiko]

@drwells @davydden @koecher A bit of updating is due :-)

[drwells]

I am heading out of town today, but I should have some time to update things on Saturday.

[koecher]

@tamiko I can not connect to my university network, thus I’m not able to test before Monday. But I put as first task. Thank you for the reminder.

[drwells]

I am still working on this.

A week ago Arch Linux switched some packages around and we now use openblas as the default BLAS. This caused the errors described in #2885 to return, even though we clearly add libgslcblas.so to the link interface.

[drwells]

The only workaround I could find was disabling -Wl,--as-needed.

[drwells]

The AUR script is now up to date, with somewhat hacky workarounds, regrettably. I am still not sure why this was not an issue two weeks ago.

[tamiko]

@drwells Where did you get the link errors? While linking the library, or while trying to link an executable? The fact that you had to disable -Wl,--as-needed indicates that some of the library dependencies of deal.II in AUR are "underlinked" [1]. This is bad.

[1] https://wiki.mageia.org/en/Underlinking_issues_in_packaging

[koecher]

@tamiko 17c is to be checked now. candi is updated and merged for deal.II v9.0.1

[tamiko]

On Tue, Oct 16, 2018, at 15:08 CDT, Uwe Köcher [e-mail] wrote:

@tamiko 17c is to be checked now. candi is updated and merged for deal.II v9.0.1

Very nice :-)