dune-pdelab release 2.5

The Dune core 2.5 release is out for about a month. It seems time to think about the PDELab release, esp. w.r.t. the upcoming course in Heidelberg in March! I am hereby volunteering as a release manager.

As a first step, I would like to evaluate what needs to be done. For that purpose, I would like to ask @all to look through existing issues and merge requests they contributed to see what needs to be done to finalize things. I will start going through them as well, tagging them either 2.5 or 3.0. Please feel free to contradict if you do not share that opinion.

Please use this issue for general discussion on the release.

I have dug through the current issues and looked at the current state of PDELab and its tests and I think it should be possible to get this release out in reasonable time. I will branch off the release branches later today. I ask everybody to test their codes with the branches and report any arising issues. Please mark any such issues and merge requests with the 2.5.0 milestone (and let me do the cherry-picking).

I aim for a first release candidate on february, 17th followed by weekly candidates if necessary. This should be sufficient to have the release for the course.

@christi I hope that is enough time for !114 (closed), but you decide.

There is another important topic regarding the release: Releases of satellite modules!

• dune-typetree is already released, as it moved to the staging area
• dune-pdelab-tutorials will see a release together with PDELab 2.5
• dune-pdelab-howto will not be released. Instead, it will be archived.

Of course, the last one is the controversial change, so I will elaborate on it: The Heidelberg group has a consensus on not wanting (or even: being able) to maintain it any longer. However - judging by the logs - it always has been our task to do that. We would very much like to put our efforts into dune-pdelab-tutorials and the upcoming system testing module instead. The code base will not vanish, it will be available as a read-only module and we will try to brush up the contents in form of tutorials in the future. During the release procedure, the visibility of dune-pdelab-howto will be reduced accordingly.

Please share your thoughts on this.

I tested the current master with CMake 3.7 and Clang 4 RC1. Works like a charm.

The only warning I disliked is when compiling libdunepdelab without MPI:

dune-pdelab/dune/pdelab/common/logtag.cc:148:21: warning: unused function 'writeRank' [-Wunused-function]
      std::ostream &writeRank(std::ostream &s) {
                    ^
1 warning generated.

mentioned in commit 8a81198d

mentioned in merge request !209 (merged)

@dominic #24 (closed) (Clean up electrodynamic) was dealt with in !211 (merged), which was merged to master in ba9a2b19. You may want to consider to apply that to 2.5 as well.

@dominic !215 (closed) (against 2.5) temporarily addresses #41 by documenting the issue in the doxygen docs. It as already merged (in !214 (merged)) into master.

!114 (closed) will be super seeded by !218 (merged) ... I'm working on it

Everything that I consider necessary is in, I will now start heading for a release candidate.

@dominic could you have a look at !230 (merged) ?

I have now pushed a tag for the release candidate. To check it out, do

git checkout v2.5.0-rc1

The release candidate is supposed to be fully compatible with the 2.5 release of the core and staging modules. Note, that dune-functions has turned into a hard dependency of dune-pdelab. I would like to ask @all to do this and test with your applications and report back with any problems you might encounter.

Without MPI I get these warnings:

[ 50%] Building CXX object CMakeFiles/dunepdelab.dir/dune/pdelab/common/logtag.cc.o
/temp/gruenich/dune/complete/dune-pdelab/dune/pdelab/common/logtag.cc:68:12: warning: unused function 'rank' [-Wunused-function]
      int &rank() {
           ^
/temp/gruenich/dune/complete/dune-pdelab/dune/pdelab/common/logtag.cc:76:20: warning: unused function 'rankwidth' [-Wunused-function]
      std::size_t &rankwidth() {
                   ^
2 warnings generated.

With dune-alugrid I get the following error, I assume it is due to the not enabled experimental grid extensions. If this is the case, you should check for that and avoid using ALUGrid.

/temp/gruenich/dune/complete/dune-grid/dune/grid/io/file/dgfparser/dgfgridfactory.hh:109:27: error: no member named 'boundaryId' in 'Dune::Intersection<const Dune::ALU3dGrid<2, 2,
      Dune::ALU3dGridElementType::tetra, Dune::ALUGridNoComm>, Dune::LevelIntersectionWrapper<const Dune::ALU3dGrid<2, 2, Dune::ALU3dGridElementType::tetra, Dune::ALUGridNoComm> > >'
      return intersection.boundaryId();
             ~~~~~~~~~~~~ ^

!153 (merged) was only merged into releases/2.4 and is missing in releases/2.5 and master (see !232 (closed) ) otherwise my applications run through without any regressions. However, I did not test the new features so far.

Ubuntu 16.04, Clang 3.8,

I'm looking into the logtag warnings that @gruenich reported.

mentioned in merge request !233 (merged)

@gruenich Can you confirm that !233 (merged) fixes the logtag warnings?

Note: you'll have to rebase from master onto 2.5...

Thanks @andreas.nuessing for pointing out the issue with !153 (merged), fixed now.

mentioned in commit 59f68733

@dominic !233 (merged) fixes the logtag warnings found by @gruenich in #77 (comment 25594). It has been merged to master. Please consider inclusion into 2.5.

mentioned in commit 31e732b3

@joe Done!

added ~6253 label

@dominic !252 (merged) add the necessary configuration to run CI for the release branch.

Why is this still open? While people are working already on the 2.6 release?

I'm afraid we skipped an official 2.5 release :-(. Closing this issue...

closed