[Dune] first release candidate for 2.6 release

[Edscott Wilson]

I'll chip in my feedback from a DuMux user's viewpoint.

To create DuMux problems with dune, basic generic C++ programming is a
must,  so updating a particular compilation requirement either from source
or from binary distribution library should not pose a problem.

But what if it is a problem?

In our workgroup we use an ArchLinux based docker container prepared with
all the necessary compilation tools.

Why ArchLinux based?

Because it is a rolling release targeted at users who will be compiling
programs. This differs from Linux distributions targeted at non compiling
users (debian/redhat/opensuse and variants) where library headers are
separated into different packages. This makes updating the docker container
rather simple and always up to date. Users in the non developer Linux
distributions can run dune problems without any need for any compilation
tools (just needs docker).

But what about performance in the docker container?

We have run our DuMux problem on a Linux box using mpi with 8 processes,
both in and out of a docker container. The performance is almost the
same.This is quite different from a virtualbox Linux client on a more
robust windows host, where performance is degraded by at least 40 percent.

So docker is a perfect solution?

Not yet. The main issue is the absence of a graphical environment. This
means that file editing and result analysis must be done in the host
computer. Moving files to-and-from the host to the container is tedious and
not very efficient. A solution would be an environment where the docker
container inputs and outputs directly to the host computer disk space with
some kind of python script do process commands from the host and
communicate with the docker container. We have not done that yet, but it
sounds like fun.

In conclusion, from a simple user's viewpoint, upgrading to cmake 3.1 and
gcc 7 is just fine.


best regards,

Edscott

El 03/01/2018 8:47 a.m., "Steffen Müthing" <steffen.muething at iwr.uni-
heidelberg.de> escribió:

>
> > Am 03.01.2018 um 15:43 schrieb Christian Engwer <
> christian.engwer at uni-muenster.de>:
> >
> >> OTOH, CMake 2.8 in particular has a whole bunch of weird little bugs
> and subtle
> >> differences from CMake >= 3.1 (not accepting keyword arguments in some
> places where
> >> later releases will flag a deprecation warning if you leave them away
> for example). And configuring
> >> different modules at different compatibility levels is just an
> invitation for horrible small problems, mostly
> >> because our downstream modules all re-run the CMake code of upstream
> modules.
> >
> > Sorry, but this means the whole buildsystem is broken. The implication
> > of what you just said is, that we have to use the most recent cmake,
> > as some downstream module might use it.
> >
> > I'm happy bumping hte requirements, if there is a particular reason,
> > but not just some vague "little bugs and subtle differences". That
> > cmake is strange is a problem for a long time and it will be like this
> > also for an other long time. I there is a particular bug we fixed and
> > thus had to raise the requirements, then the discussion is settled and
> > we have to live with cmake-3.1. It is just, that nobody up to now
> > mentioned a particular reason for the new requirements and I couldn't
> > find any hint in the logs.
>
> Andreas just brought up a very valid one: We don’t have a CI config that
> can test with CMake 2.8.12
> (because our baseline is either Debian stable (3.7) or Ubuntu LTS (3.5)).
>
> Steffen
>
> >
> > Christian
> >
>
>
> _______________________________________________
> Dune mailing list
> Dune at lists.dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20180103/07d774dd/attachment.htm>