Hi Edscott,
I'm writing you as a follow-up on your post on the DUNE mailing list.
You mention that you use DuMux with Docker. I just wanted to mention a
couple of things you might find useful:
* There is a Dockerfile
(https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-docker)
available to build a docker container with graphic support. I must warn
though that it is a bit old. I will update as soon as I get to it.
* There is a script
(https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/master/bin/moduleutil/createdockerimage.sh)
that creates a Docker container of an extracted DUNE module which is new
in the dumux-pub project (https://git.iws.uni-stuttgart.de/dumux-pub).
The Docker container built in this script also fixes the user
permissions for transferring files in and out of containers and has
graphic support on Linux machines.
* DuMux also uses Docker for automated testing with buildbot
(https://git.iws.uni-stuttgart.de/buildbot/#/builders).
* There is a DockerHub group for DuMux
(https://hub.docker.com/u/dumux/), however it's also a bit outdated.
If you are interested in contributing useful Docker images, we are
happy, please contact us.
Best wishes,
Timo
On 03.01.2018 17:26, Edscott Wilson wrote:
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"
<[email protected]
<mailto:[email protected]>> escribió:
> Am 03.01.2018 um 15:43 schrieb Christian Engwer
<[email protected]
<mailto:[email protected]>>:
>
>> 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
[email protected] <mailto:[email protected]>
http://lists.dune-project.org/mailman/listinfo/dune
<http://lists.dune-project.org/mailman/listinfo/dune>
_______________________________________________
Dune mailing list
[email protected]
http://lists.dune-project.org/mailman/listinfo/dune
--
_______________________________________________________________
Timo Koch phone: +49 711 685 64676
IWS, Universität Stuttgart fax: +49 711 685 60430
Pfaffenwaldring 61 email: [email protected]
D-70569 Stuttgart url: www.hydrosys.uni-stuttgart.de
_______________________________________________________________
_______________________________________________
Dumux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
