<div dir="ltr"><div><div><div dir="auto">I'll chip in my feedback from a DuMux user's viewpoint.<br><br></div><div>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.<br><br>But what if it is a problem?<br><br>In our workgroup we use an ArchLinux based docker container prepared with all the necessary compilation tools. <br><br>Why ArchLinux based?<br><br></div><div>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).<br><br></div><div>But what about performance in the docker container? <br><br></div><div>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.  <br></div><div><br></div><div>So docker is a perfect solution?<br><br></div><div>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.<br></div><div> <br></div>In conclusion, from a simple user's viewpoint, upgrading to cmake 3.1 and gcc 7 is just fine.<br><br><br></div>best regards,<br><br></div>Edscott<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">El 03/01/2018 8:47 a.m., "Steffen Müthing" <<a href="mailto:steffen.muething@iwr.uni-heidelberg.de" target="_blank">steffen.muething@iwr.uni-<wbr>heidelberg.de</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Am 03.01.2018 um 15:43 schrieb Christian Engwer <<a href="mailto:christian.engwer@uni-muenster.de" target="_blank">christian.engwer@uni-muenster<wbr>.de</a>>:<br>
><br>
>> OTOH, CMake 2.8 in particular has a whole bunch of weird little bugs and subtle<br>
>> differences from CMake >= 3.1 (not accepting keyword arguments in some places where<br>
>> later releases will flag a deprecation warning if you leave them away for example). And configuring<br>
>> different modules at different compatibility levels is just an invitation for horrible small problems, mostly<br>
>> because our downstream modules all re-run the CMake code of upstream modules.<br>
><br>
> Sorry, but this means the whole buildsystem is broken. The implication<br>
> of what you just said is, that we have to use the most recent cmake,<br>
> as some downstream module might use it.<br>
><br>
> I'm happy bumping hte requirements, if there is a particular reason,<br>
> but not just some vague "little bugs and subtle differences". That<br>
> cmake is strange is a problem for a long time and it will be like this<br>
> also for an other long time. I there is a particular bug we fixed and<br>
> thus had to raise the requirements, then the discussion is settled and<br>
> we have to live with cmake-3.1. It is just, that nobody up to now<br>
> mentioned a particular reason for the new requirements and I couldn't<br>
> find any hint in the logs.<br>
<br>
Andreas just brought up a very valid one: We don’t have a CI config that can test with CMake 2.8.12<br>
(because our baseline is either Debian stable (3.7) or Ubuntu LTS (3.5)).<br>
<br>
Steffen<br>
<br>
><br>
> Christian<br>
><br>
<br>
<br>______________________________<wbr>_________________<br>
Dune mailing list<br>
<a href="mailto:Dune@lists.dune-project.org" target="_blank">Dune@lists.dune-project.org</a><br>
<a href="http://lists.dune-project.org/mailman/listinfo/dune" rel="noreferrer" target="_blank">http://lists.dune-project.org/<wbr>mailman/listinfo/dune</a><br></blockquote></div></div>
</div></div></div></div>