Hi all,
I've removed the docker container I mentioned in the previous post, as
there was a mistake in the build. In that build the dune version was 2.6,
which means it does compile with dumux-2.12, but when you try to link a
problem, errors occur due to changes in the vtkwriter and other places.
I've now uploaded a new docker with dumux-2.12 and dune-2.5 and tested it
correctly. The "standard" way to enter this docker container is with the
following script:
#!/bin/sh
version='dumux-2.12c'
default=`pwd`
echo "Welcome to $version (docker)"
#read -p " Please specify src directory [$default]: " SRC
if test x$SRC = x; then
SRC=$default
fi
echo "Shared directory /home/dumux set to $SRC"
echo "Creating docker container"
docker rm $version-container
docker create -ti -e USER=$USER -e HOST_GID=$(id -g $USER) -e HOST_UID=$(id
-u $USER) -e SRC=$SRC -v $SRC:/home/dumux --name=$version-container
--hostname=docker impmx/lswf:$version
#mkdir "$SRC/output"
exec docker start -a -i $version-container
This opens the docker container with the same user as the invoker with
read/write privileges in the current and shared directory. If you open the
container without the enironment defined in the script, the user will be
root and no shared directories. Dune and dumux are installed in /opt and
the path and compile flags are ser accordingly. This is to keep user
problems separate from dune/dumux core, as is customary for distributed
software. User does not have write permissions in opt, but since the
include path can be defined by the user, local user versions of model.hh or
components or fluidsystems can be redefined on a problem by problem basis.
One of the goals of having this docker container is to have more dumux
users in our workgroup where these users do not have to fret with the issue
of downloading, compiling and installing, which does require a certain
level of sophistication which has nothing to do with solving a PDE system.
Thus if you run this docker image.and provide any comments or feedback, it
will be greatly appreciated. Otherwise, if you find it useful, that makes
us happy too.
This container still does not have graphic support enabled yet, but that is
coming soon.
In case you missed it, the image is at the docker hub, repository
impmx/lswf with tag dumux-2.12c. The docker file is very much similar to
the previous post, but if you want to see the differences, just let me know.
Best regards,
Edscott
2018-01-11 17:05 GMT-06:00 Ed Scott Wilson Garcia <edsc...@imp.mx>:
> 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> escribió:
>
>
> > Am 03.01.2018 um 15:43 schrieb Christian Engwer <christian.engwer@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
> http://lists.dune-project.org/mailman/listinfo/dune
>
>
>
>
> _______________________________________________
>
> Dune mailing list
>
> 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
> <https://maps.google.com/?q=Pfaffenwaldring+61&entry=gmail&source=g>
> email: timo.k...@iws.uni-stuttgart.de
>
> D-70569 Stuttgart url: www.hydrosys.uni-stuttgart.de
>
> _______________________________________________________________
>
>
--
------------------------------------------------------------------------------------
Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute
_______________________________________________
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
