Hi Timo, The Dockerfile at (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-docker) is not available for the general public, 404 error (file not found or insufficient permissions).
But I’ve now build a new Dumux docker image with a dockerfile, which is much more efficient than what I was doing previously. I’m attaching the dockerfile if you want to use it for the DockerHub group for DuMux. The docker image dumux-2.12 built thus at https://hub.docker.com/r/impmx/lswf/tags/ Has the following characteristics: Built with base/archlinux (jan-11-18) Dune-2.5 and Dumux-2.12.0. compiled with gcc-7.2.1, cmake-3.10.1, Dune release/2.5 modules: dune-common, dune-geometry, dune-uggrid, dune-grid, dune-istl, dune-localfunctions, dune-spgrid, dune-alugrid (head). With openmpi-3.0.0, superLU, UMFpack, SuiteSparse and many other optional packages. Next I will see how to enable graphics support by studying the information you mention in your post. Best regards, Edscott De: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] En nombre de Timo Koch Enviado el: miércoles, 3 de enero de 2018 10:47 a. m. Para: DuMuX User Forum; Edscott Wilson Asunto: [DuMuX] DuMux and Docker 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" <steffen.mueth...@iwr.uni-heidelberg.de<mailto:steffen.mueth...@iwr.uni-heidelberg.de>> escribió: > Am 03.01.2018 um 15:43 schrieb Christian Engwer > <christian.eng...@uni-muenster.de<mailto:christian.eng...@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 d...@lists.dune-project.org<mailto:d...@lists.dune-project.org> http://lists.dune-project.org/mailman/listinfo/dune _______________________________________________ Dune mailing list d...@lists.dune-project.org<mailto:d...@lists.dune-project.org> 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: timo.k...@iws.uni-stuttgart.de<mailto:timo.k...@iws.uni-stuttgart.de> D-70569 Stuttgart url: www.hydrosys.uni-stuttgart.de<http://www.hydrosys.uni-stuttgart.de> _______________________________________________________________
Dockerfile
Description: Dockerfile
makepackage
Description: makepackage
_______________________________________________ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
