Hi Timo,
I can now access dumux-repositories/dumux-docker without any problems,
thanks!. What I find is that graphics support is mostly defined in the
dumux start script. But graphics does not start on an archlinux box unless
XAUTHORITY permission is granted for the docker container. This can be done
by applying the following patch to the startup script.
--- dumux.sh 2018-01-17 15:43:42.818240499 -0600
+++ dumux-new.sh 2018-01-17 15:43:58.718209994 -0600
@@ -29,11 +29,14 @@
open()
{
IMAGE="$1"
-
+ XAUTH=/tmp/.docker.xauth
+ `xauth nlist $DISPLAY | sed 's/^..../ffff/' | xauth -f $XAUTH nmerge -`
COMMAND="docker create -i -t \
-e HOST_UID=$(id -u $USER) \
-e HOST_GID=$(id -g $USER) \
-e DISPLAY=$DISPLAY \
+ -v $XAUTH:$XAUTH \
+ -e XAUTHORITY=$XAUTH \
--device /dev/dri \
-v $SHARED_DIR_HOST:$SHARED_DIR_CONTAINER \
-v /tmp/.X11-unix:/tmp/.X11-unix:rw \
With that, paraview with initially opens, but then crashes with the
following:
ERROR: In
/build/paraview-arsa8T/paraview-5.0.1+dfsg1/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
line 394
vtkXOpenGLRenderWindow (0x20978a0): Could not find a decent visual
ERROR: In
/build/paraview-arsa8T/paraview-5.0.1+dfsg1/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
line 613
vtkXOpenGLRenderWindow (0x20978a0): GLX not found. Aborting.
Aborted (core dumped)
I guess that's because the host is an Archlinux box which is quite a deal
more updated than the debian container, maybe?
Nonetheless, since vtk files are shared and viewed after simulation
completes, we have no problem with using paraview on the docker host.
What we really want is to view gnuplot graphics as the simulation proceeds,
and that is now possible.
Using the shared X11 socket and XAUTHORIZATION stuff, we can now open
xterms from our container and view simulation graphs with gnuplot as the
computation proceeds. Still, installing gnuplot from package brings in too
much stuff to the container and fonts are missing. As soon as I fix those
details I will upload the docker image to the docker hub.
What follows is to create a dumux-3.0r1 image because we are very
interested in seeing how the assembler has been improved (the assembler
takes the lion's share of cpu time in our problem).
best regards,
Edscott
2018-01-17 3:49 GMT-06:00 Timo <koch_t...@hotmail.com>:
>
>
> Am 16.01.2018 um 20:58 schrieb Edscott Wilson <
> edscott.wilson.gar...@gmail.com>:
>
> 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:
>
>
> Hi Edscott,
>
> Dune 2.6 was not released yet when Dumux 2.12 was released so it is not
> supported. The Dumux 3.0-alpha release however is compatible.
>
>
> #!/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.
>
>
> This is one approach especially when you are only working with release
> versions. Another approach that is by far the more popular in the Dune
> community is creating your own dune-module. This way the user files are
> always separated from the main program. Then it doesn't matter if you
> decide to compile Dune from source (the you can keep up with the newest
> changes) or even install Dune with the Debian packages.
>
> 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.
>
>
> Please check the Dockerfile I uploaded for Dumux 2.12 in
> dumux-repositories/dumux-docker and the corresponding image on DockerHub
> dumux/release-2.12:latest. Let me know if graphics support, in particular
> paraview, works inside the container for you (Linux only).
>
> I checked access rights again and it is available to all logged-in users.
> Did you try cloning the repo? Anyway I just got news that the repo is now
> fully publicly accessible without login.
>
> Best regards
> Timo
>
>
> 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/cre
>> atedockerimage.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-heid
>> elberg.de> escribió:
>>
>>
>> > Am 03.01.2018 um 15:43 schrieb Christian Engwer <
>> 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
>> 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
>
>
--
------------------------------------------------------------------------------------
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
