Thanks for the information, Timo. I'll look into it as soon as possible. The docker containers we are using are available at the docker hub at the repository impmx/lswf, I will see on updating them with the methods in the DuMux containers you mention. I am more than happy to contribute whatever comes of this to the DuMux community. As soon as I have something new I will let you know.
Best regards Edscott El 03/01/2018 10:47 a.m., "Timo Koch" <[email protected]> escribió: 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] elberg.de> escribió: > > > Am 03.01.2018 um 15:43 schrieb Christian Engwer < > [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] > http://lists.dune-project.org/mailman/listinfo/dune > _______________________________________________ Dune mailing [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 60430Pfaffenwaldring 61 <https://maps.google.com/?q=Pfaffenwaldring+61&entry=gmail&source=g> 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
