[dune-pdelab] PDELab release

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Fri May 15 17:53:33 CEST 2015

Hi everybody,

just to reiterate on my earlier email:

All PDELab development has been moved to


There are new repositories at that location that get automatically mirrored to the "canonical" place
on git.dune-project.org. We also switched to the bugtracker and the merge request features of the
GitLab instance at the new location. If you want to take part in PDELab development and need an
account, please let me know.

As a normal user, you don’t have to change anything, but if you want to contribute code and report
bugs, you should move over to the new repositories.

For now, this is all very much in a testing phase, but if everything works as well as we hope, we’ll
introduce a more permanent setup and update the PDELab web site etc.


> Am 13.05.2015 um 13:37 schrieb Steffen Müthing <steffen.muething at iwr.uni-heidelberg.de>:
>> Am 06.05.2015 um 17:38 schrieb Steffen Müthing <steffen.muething at iwr.uni-heidelberg.de>:
>> Hi Christian,
>>> Am 05.05.2015 um 17:13 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:
>>> Hi Steffen,
>>>> 1) What will be our minimum compiler requirements? I am *very much* opposed to anything
>>>>  below 4.6, as that gives us range-based for, clear semantics for move operations (I’ve had some
>>>>  nasty problems with autogenerated move member functions in 4.5) as well as constexpr.
>>>>  That said, my suggestion would be GCC 4.7, as that also gives us template aliases and delegated
>>>>  constructors. Moreover, I am unable to run decent testing for GCC < 4.7 on my machine because
>>>>  DUNE itself doesn’t support older GCC on OS X, so until we have some automatic testing infrastructure
>>>>  and a development model that makes it easy to use such an infrastructure (e.g. pull requests), I’ll probably
>>>>  break GCC 4.6 from time to time.
>>> 4.7 is OK for me.
>> judging from the general feedback, that seems settled, then.
>>>> 2) What’s our position regarding ALUGrid? My suggestion is to simply require the new dune-alugrid
>>>>   module and be done with it.
>>> #1
>> Ditto.
>>>> 3) Somehow related to this: Christian already did some work on cleaning up the heaps of deprecation
>>>>  warnings due to the changed grid interface, but IMHO we should do a coordinated sweep of the
>>>>  complete code base PDELab and the Howto and also take the chance to improve coding style in
>>>>  general: range-based for loops (e.g. for quadrature loops), store inside and outside entities and
>>>>  geometries in variables for better performance etc.
>>> I don't want to argue against a cleanup, but for pdelab itself, I
>>> think it doesn't matter too much, there are more pressing problems...
>>> * we should cleanup the local operators:
>>> - consistent parameters classes
>>> - unify nearly identical operators
>>> - fix or remove broken operators (e.g. MFD)
>> I fully agree, but that is probably too much work before 2.4. OTOH, we should at least
>> make sure we don’t spew heaps of warnings at our users (and I also think that it is important
>> to have reasonably clean code in the local operators - they serve as templates for most user
>> code, and we should try and present a somewhat clear coding style in there…).
>>> * we should update the finiteelementmaps to recent changes in
>>> localfunctions
>> Oh, I think I missed something there. What changed in localfunctions?
>>> * cleanup memory management (shared_ptr vs. copy vs. reference) in the
>>> pdelab guts
>>> ... ideally I should not have to keep pointers to heap-allocated
>>> objects in order to keep other objects valid, e.g. keep the GFS to
>>> have a valid discrete function.
>> Again, that’s something else that requires a little more work. We’ll have to discuss here in Heidelberg
>> whether there is time to do a mini PDELab sprint and tackle some of those before 2.4.
>>> then we have a few other things that become nicer with the recent changes
>>> besides this the coding style in the howto is much more critical, as
>>> it is the stuff, users will copy into their code and bad styles there
>>> will give us hard times in the support. On the other hand updating the
>>> howto is really a lot of work.
>>> The last thing I would like to add is that time is limited and I would
>>> rather not delay the pdelab release too much ;-) We should make a list
>>> of topics and sort them according to priority.
>>> An other thing... if we develop fixes in branches, we can easily merge
>>> them to the master and the release-branche. Steffen and I discussed
>>> already to try a no-push-to-master policy in pdelab to check the
>>> implications on the workflow, before discussing such a thing for the
>>> core modules. Perhaps this is the right time to start with such a policy.
>> In keeping with the last two paragraphs, I cloned PDELab and the Howto into our local GitLab instance
>> in Heidelberg at http://conan2.iwr.uni-heidelberg.de/git/groups/pdelab
>> If you want to help with the process and do not yet have an account, please send me an email and I’ll invite you.
>> So my idea of the whole process is as follows: If you have a bug or a feature that you want in for 2.4, open a bug, and
>> we will use that as a thread to discuss the issue. As soon as we have figured out whether / how we want to tackle it,
>> someone starts to code. All coding happens in a feature branch (even if it’s only a small bugfix!). Once you’re done,
>> you push the feature branch to GitLab and open a merge request. Optimally, you mention the bug in the merge request
>> (e.g.: The bug is #42, so you write in your merge request: „This fixes #42“ or something similar). That way, GitLab connects
>> the bug and the merge request. Then we can use the merge request to discuss any problems with that implementation,
>> and the person working on it can keep pushing to the same branch (GitLab will automatically update the merge request).
>> Finally, the branch gets merged using „git merge —no-ff“, which automatically closes the merge request (and, if you have
>> written „fixes #42“, also closes the bug).
>> All code branches should start from master and should *never* be rebased, otherwise GitLab runs into problems.
>> Sound good?
>> Steffen
>> PS: I haven’t yet setup GitLab to automatically push updates to git.dune-project.org, I’ll do that tomorrow.
> (Almost) all pushes to the repository will now have to go through GitLab - I locked down write access to everything
> but private branches for the PDELab repos on git.dune-project.org. A cron job will automatically mirror the master and release
> branches on GitLab to the corresponding repository at git.dune-project.org every 5 minutes.
> Please make sure to always install the whitespace hook in your local repositories (by running "dunecontrol all“ or
> "dunecontrol vcsetup", as GitLab currently doesn’t enforce that hook yet. That means that you can push your changes with
> illegal whitespace to GitLab, but then the commit wouldn’t get mirrored to the official repo because your changes
> trigger the whitespace hook on the official server).
> Steffen
>>> Ciao
>>> Christian
>> _______________________________________________
>> dune-pdelab mailing list
>> dune-pdelab at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-pdelab
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150515/9f2ddd5c/attachment.pgp>

More information about the dune-pdelab mailing list