{cae}[foss/2019b] OpenFOAM 7 #9390

furstj · 2019-11-27T14:30:50Z

(created using eb --new-pr)

…cleanup.patch

boegel · 2019-11-27T19:24:21Z

Test report by @boegel
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in this PR)
node3153.skitty.os - Linux centos linux 7.7.1908, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, Python 3.6.8
See https://gist.github.com/35b0bf38c96af2a155d57726e438ab56 for a full test report.

lexming · 2019-11-28T14:19:47Z

Test report by @lexming
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in this PR)
login2.cerberus.os - Linux centos linux 7.6.1810, Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz, Python 2.7.5
See https://gist.github.com/13f5a8e12d1e4e2988449f5cd38a5067 for a full test report.

lexming · 2019-11-28T14:58:38Z

My failed test seems to be related to https://bugs.openfoam.org/view.php?id=3303 and the changes in OpenFOAM/OpenFOAM-7@9980357

furstj · 2019-11-28T17:53:09Z

@lexming it seems that OF7 already includes changes related to OF bug no. 3301. Nevertheless, I inclded also a patch related to OF bug 3303 (bashrc, wclean, wrmdep).

boegel · 2019-11-28T18:53:37Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node2470.golett.os - Linux centos linux 7.7.1908, Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz, Python 2.7.5
See https://gist.github.com/8478fa351f2368ee228f72f446f30756 for a full test report.

boegel · 2019-11-28T22:54:28Z

@lexming Can you also re-test this PR?

boegel · 2019-11-28T22:56:47Z

Test report by @boegel
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in this PR)
generoso-2 - Linux centos linux 7.6.1810, Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz, Python 3.6.8
See https://gist.github.com/04f6cd66fb6e5506ef7eb2a26d94c568 for a full test report.

boegel · 2019-11-29T08:40:49Z

@furstj Any idea on this? Looks related to Mesa, which provides GL/gl.h, not sure why it expects it to be in the libdrm install dir?

CMake Error at /work/maintainers/CO7/broadwell/software/Qt5/5.13.1-GCCcore-8.3.0/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:9 (message):
  Failed to find "GL/gl.h" in
  "/work/maintainers/CO7/broadwell/software/libdrm/2.4.99-GCCcore-8.3.0/include/libdrm".
Call Stack (most recent call first):
  /work/maintainers/CO7/broadwell/software/Qt5/5.13.1-GCCcore-8.3.0/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:187 (include)
  /work/maintainers/CO7/broadwell/software/Qt5/5.13.1-GCCcore-8.3.0/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:100 (find_package)
  /work/maintainers/CO7/broadwell/software/Qt5/5.13.1-GCCcore-8.3.0/lib/cmake/Qt5/Qt5Config.cmake:28 (find_package)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/ParaViewQt.cmake:71 (find_package)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/Modules/pqApplicationComponents.cmake:12 (pv_find_package_qt)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/vtkModuleAPI.cmake:45 (include)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/vtkModuleAPI.cmake:15 (vtk_module_load)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/vtkModuleAPI.cmake:152 (_vtk_module_config_recurse)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/VTKConfig.cmake:143 (vtk_module_config)
  /work/maintainers/CO7/broadwell/software/ParaView/5.6.2-foss-2019b-Python-3.7.4-mpi/lib/cmake/paraview-5.6/ParaViewConfig.cmake:75 (include)
  CMakeLists.txt:4 (FIND_PACKAGE)

boegel · 2019-11-29T09:13:43Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node3169.skitty.os - Linux centos linux 7.7.1908, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, Python 3.6.8
See https://gist.github.com/be47f02ecd17a33ceb9870604bd4d7d9 for a full test report.

furstj · 2019-11-29T10:43:49Z

@boegel I have no idea why it failed due to GL/gl.h. It compiles on my system without problems and you were able to compile it to in your last test. Interesting is that Qt or ParaView compile well (and both use OpenGL too). Do you have any idea wht is the difference between your systems or build environments at node3169.skitty.os and generoso-2?

My latest version uses several patches for OpenFOAM build system (wmake) which are connected to problems with compiling in directories with symlinks. Do you mean that there is any difference between generoso-2 and node3169 related to symlinks?

lexming · 2019-11-29T11:21:00Z

@furstj yep, I also saw that some patches for OF bug 3303 are already merged in version 7 and it seems that the expansion of $WM_PROJECT_DIR is the intended behavior moving forward. So I took a different approach to solve this issue and updated the easyblock for OpenFOAM to expand $FOAM_INST_DIR (and $WM_PROJECT_DIR) from version 7 onward.

My changes are in lexming/easybuild-easyblocks@a6292b3

I would say that maintaining the code in the easyblock might be easier than having an additional patch, but honestly, I'm not familiar with the development of OpenFOAM, so I'm not sure which solution is best moving forward. Let me know what you think. I'll only open a PR in easybuild-easyblocks, if you and @boegel prefer that.

lexming · 2019-11-29T12:09:05Z

Test report by @lexming
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
login2.cerberus.os - Linux centos linux 7.6.1810, Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz, Python 2.7.5
See https://gist.github.com/777b53a22981e6f75d95d9cd4ac7296e for a full test report.

lexming · 2019-11-29T12:57:01Z

The previous test report is done with this PR for OpenFOAM-7 and the easyblock for OpenFOAM in current develop branch.

boegel · 2019-11-29T15:18:20Z

@furstj On all systems I tested except generoso we have mesa-libGL-devel installed in the OS, which provides /usr/include/GL/gl.h.
mesa-libGL-devel is not there on generoso (only mesa-libGL), so GL/gl.h can't be found in the OS on that system.

boegel · 2019-11-29T15:19:35Z

@furstj Can you open an issue on that problem?

I don't think it should block this PR (since it's not specific to this particular OpenFOAM version, I think), but it would be nice to get it fixed (and not having an open issue for it means we'll forget about it).

akesandgren · 2019-11-29T16:06:49Z

Why is OpenFOAM pulling in MESA in the first place? Did they add a GUI?

boegel · 2019-11-29T17:02:58Z

@akesandgren As a dep for ParaView, which is a dep for OpenFOAM (for paraFoam, I think)

furstj · 2019-11-29T17:38:33Z

@boegel I will try to compile this EB on a machine without mesa-devel package and we will see.

@akesandgren OF compiles also some plugins to ParaView (e.g. specific openfoam readers). I guess that it needs whole ParaView stack in order to compile these plugins (i.e. ParaView, Qt, Mesa, ...)

@lexming I agree with you that corrected easyblock is much better solution than a mega-patch. However I think that the problem is in OpenFOAM build scripts (I mean in wmake) and it will hurt also all non-easybuild OpenFoamers. Moreover, patches for OpenFOAM 3303 bug are already included in OpenFOAM-dev version, so the current EB patch for 3303 is only temporary solution. I hope that the OpenFOAM-8 (when it will be released) will solve the problem.
Therefore my preference is to use ugly patch for OF7 and to leave easyblock untouched.

lexming · 2019-12-02T09:23:23Z

@furstj if this patchset is already part of OpenFOAM-dev, then having it included in OF7 is indeed the best solution.

furstj · 2019-12-02T13:16:37Z

@boegel I tried a compilation on a system without mesa-devel and it failed with missing GL/gl.h too. After some analysis I found that the problem is quite complicated and it probably goes through Qt5 down to pkg-config. The "pkg-config --cflags gl" returns wrong include path! It then goes to Qt5 (it can be found in Qt5GuiConfigExtras.cmake) and finally breaks the OpenFOAM compilation.

It is very interesting that the pkg-config from OpenSUSE Leap distribution reports also wrong path with libdrm and the Qt5GuiConfigExtras.cmake from standard distribution contains the wrong path too.

There are several possibilities for dealing with this issue:

one can replace the wrong path in Qt5GuiConfigExtras.cmake using a postinstallcmd in Qt5 easyconfig (I have done this on my computer and it seems to work - I was able to compile ParaView and OpenFOAM)
one can patch OpenFOAM's compilation scripts in order to look for GL/gl.h in correct places (I didn't try it yet but I hope that it should be possible)
one can correct the pkg-config (or at least Mesa pkg-config) in order to give right answer to "--cflags gl"
put "mesa-devel" in osdependencies for OpenFOAM

Under my opinion the least distracting is the option 1. It is sufficient to recompile Qt5 and that's all.
The second option isolates the changes to OpenFOAM package, so it does not solve the problem for other packages using Qt5.
The option 3 is very dangerous. There are plenty of packages depending on pkg-config. So any change in pkg-config could break a tons of software packages.
The option 4 is safe but we then use gl.h from different mesa version. What is your opinion?

akesandgren · 2019-12-02T13:40:33Z

Note that pkg-config --cflags gl returns the wrong include path in Ubuntu too, so this is not a EasyBuild specific problem.

akesandgren · 2019-12-02T14:23:02Z

This looks more like a bug in how pkg-config works to me.

akesandgren · 2019-12-02T14:24:45Z

The gl.pc pkgconfig file (from both Ubuntu and EasyBuild) is technically correct. But pkg-config is not returning what you'd expect.

Try

pkg-config --debug --cflags gl 2>&1 | less

And look at what it really does...

akesandgren · 2019-12-02T14:58:37Z

Actually, this is a bug in pkg-config 0.29.2...
0.29.1 returns the correct answers

I'll try to chase it down

akesandgren · 2019-12-03T13:19:29Z

I'll have to do this in our cleanroom setup to double check.

akesandgren · 2019-12-03T17:41:52Z

Hmmm, my cleanroom install do fail on GL/gl.h

furstj · 2019-12-03T19:39:50Z

@akesandgren Yes, exactly what happens to me and boegel. It fails when there is no /usr/include/GL/gl.h.

I did try also OpenFOAM-v1906 and it compiles fine. Therefore it should be possible to patch OpenFOAM-7 too. The question is then if I should modify OpenFOAM-7 easyconfig letting Qt intact, or if (me someone else?) will modify Qt in order to replace librm path by path to mesa. Both options are feasible. What is your opinion?

boegel · 2019-12-03T19:44:56Z

It's still not clear to me where the bug/breakage is actually taking place...

Is the Qt5GuiConfigExtras.cmake in the Qt5 installation buggy, or is OpenFOAM 7 making incorrect assumptions somewhere?
A clear answer to that question could indicate the right place to fix the issue, I think...

Also note that OpenFOAM-6-foss-2018b.eb built fine on the exact same system (without GL/gl.h available in the OS), not sure if that helps at all to pinpoint the problem...

akesandgren · 2019-12-03T20:52:30Z

Something in either Qt5 or OpenFOAM has to be setting some variable that forces find_path to NOT look in CMAKE_INCLUDE_DIRS, or unsetting CMAKE_INCLUDE_DIRS.

akesandgren · 2019-12-03T21:17:46Z

I'll be chasing this down (I hope) so hang in there...

furstj · 2019-12-03T21:22:47Z

I'm able to patch OF7 compilation now. If we replace

cmake ../..

by

cmake -D_qt5gui_OPENGL_INCLUDE_DIR=$EBROOTMESA/include ../..

in applications/utilities/postProcessing/graphics/PVReaders/Allwmake, the OF compiles.

akesandgren · 2019-12-04T05:42:02Z

Yeah, the reason it doesn't work as we expected it to, is that OpenFOAM is not using the cmakemake easyblock. That's where we are setting CMAKE_INCLUDE_PATH=paths(CPPFLAGS)+CPATH.

So there is one fairly simple way out and that is to set CMAKE_INCLUDE_PATH the same way we do in cmakemake.py in the OpenFOAM easyblock. Or we could let openfoam.py inherit cmakemake.
We should probably make sure CMAKE_C_COMPILER etc are also correctly set in openfoam.py...

akesandgren · 2019-12-04T08:30:15Z

I have a potential fix involving cmakemake.py and openfoam.py that fixes this in a slightly more generic way.

boegel · 2019-12-04T19:21:21Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
generoso-2 - Linux centos linux 7.6.1810, Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz, Python 3.6.8
See https://gist.github.com/9d018e73f209b3e13f764bd8396fc5b3 for a full test report.

boegel · 2019-12-04T19:30:03Z

Test report on generoso was on top of easybuilders/easybuild-easyblocks#1869... 👍

akesandgren · 2019-12-04T19:40:54Z

with or without the patch to work around the GL/gl.h problem? I.e. with or without 0efd968

boegel · 2019-12-04T20:33:48Z

with or without the patch to work around the GL/gl.h problem? I.e. with or without 0efd968

Test report was with the last commit included (so not really testing easybuilders/easybuild-easyblocks#1869 I guess).

But we get another opportunity for that in #9440...

boegel · 2019-12-04T22:00:28Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node3109.skitty.os - Linux centos linux 7.7.1908, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, Python 3.6.8
See https://gist.github.com/d1482fc927ce2465fe187d94c7afff1b for a full test report.

boegel · 2019-12-04T22:19:19Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node2704.swalot.os - Linux centos linux 7.7.1908, Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, Python 2.7.5
See https://gist.github.com/ba07928db1cf0e2ff1c40e2788e9d6d0 for a full test report.

akesandgren · 2019-12-05T06:39:37Z

@furstj with the updated easyblock for cmakemake and openfoam in easybuilders/easybuild-easyblocks#1869 you can remove the patch that sets
-D_qt5gui_OPENGL_INCLUDE_DIR=$EBROOTMESA/include

Although they did not make it into EB 4.1.0

furstj · 2019-12-05T07:48:45Z

@akesandgren I have just tested easybuilders/easybuild-easyblocks#1869 without -D_qt5.... and it works. Next commit removes the -D_qt5gui... Thanx a lot for more systematic solution.

boegel

lgtm

lexming · 2019-12-05T10:26:22Z

Test report by @lexming
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
login2.cerberus.os - Linux centos linux 7.6.1810, Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz, Python 2.7.5
See https://gist.github.com/7f37148f74e7d4b53b33e092d565c286 for a full test report.

lexming · 2019-12-05T10:27:10Z

Tested on top of easybuilders/easybuild-easyblocks#1869

boegel · 2019-12-05T10:42:11Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
generoso-1 - Linux centos linux 7.6.1810, Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz, Python 3.6.8
See https://gist.github.com/086f5b2515fa992d61390e8e560db30c for a full test report.

boegel · 2019-12-05T10:44:30Z

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node3112.skitty.os - Linux centos linux 7.7.1908, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, Python 3.6.8
See https://gist.github.com/4afdaccb9453ae7b8f7e4526c9e224f0 for a full test report.

boegel · 2019-12-05T11:11:13Z

Going in, thanks @furstj!

furstj added 2 commits November 27, 2019 15:30

adding easyconfigs: OpenFOAM-7-foss-2019b.eb and patches: OpenFOAM-7-…

7bb0c91

…cleanup.patch

Updates checksums

4465181

furstj changed the title ~~{cae}[foss/2019b] OpenFOAM v7~~ {cae}[foss/2019b] OpenFOAM 7 Nov 27, 2019

boegel added the update label Nov 27, 2019

boegel added this to the 4.x milestone Nov 27, 2019

Patch for OpenFOAM bug 3303

4a5133c

Updated patch for compilation without system-wide GL/gl.h

0efd968

akesandgren mentioned this pull request Dec 4, 2019

Make setup of cmake env usable from outside easybuilders/easybuild-easyblocks#1869

Merged

boegel mentioned this pull request Dec 4, 2019

{cae}[foss/2019b] OpenFOAM v6 #9440

Merged

Removed -D_qt5gui_.. patch

9d4dd1e

boegel approved these changes Dec 5, 2019

View reviewed changes

boegel merged commit 6429def into easybuilders:develop Dec 5, 2019

boegel modified the milestones: 4.x, release after 4.1.0 (4.1.1?) Dec 6, 2019

{cae}[foss/2019b] OpenFOAM 7 #9390

{cae}[foss/2019b] OpenFOAM 7 #9390

Uh oh!

Conversation

furstj commented Nov 27, 2019

Uh oh!

boegel commented Nov 27, 2019

Uh oh!

lexming commented Nov 28, 2019

Uh oh!

lexming commented Nov 28, 2019

Uh oh!

furstj commented Nov 28, 2019

Uh oh!

boegel commented Nov 28, 2019

Uh oh!

boegel commented Nov 28, 2019

Uh oh!

boegel commented Nov 28, 2019

Uh oh!

boegel commented Nov 29, 2019

Uh oh!

boegel commented Nov 29, 2019

Uh oh!

furstj commented Nov 29, 2019

Uh oh!

lexming commented Nov 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lexming commented Nov 29, 2019

Uh oh!

lexming commented Nov 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

boegel commented Nov 29, 2019

Uh oh!

boegel commented Nov 29, 2019

Uh oh!

akesandgren commented Nov 29, 2019

Uh oh!

boegel commented Nov 29, 2019

Uh oh!

furstj commented Nov 29, 2019

Uh oh!

lexming commented Dec 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

furstj commented Dec 2, 2019

Uh oh!

akesandgren commented Dec 2, 2019

Uh oh!

akesandgren commented Dec 2, 2019

Uh oh!

akesandgren commented Dec 2, 2019

Uh oh!

akesandgren commented Dec 2, 2019

Uh oh!

akesandgren commented Dec 3, 2019

Uh oh!

akesandgren commented Dec 3, 2019

Uh oh!

furstj commented Dec 3, 2019

Uh oh!

boegel commented Dec 3, 2019

Uh oh!

akesandgren commented Dec 3, 2019

Uh oh!

akesandgren commented Dec 3, 2019

Uh oh!

furstj commented Dec 3, 2019

Uh oh!

akesandgren commented Dec 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

akesandgren commented Dec 4, 2019

Uh oh!

boegel commented Dec 4, 2019

Uh oh!

boegel commented Dec 4, 2019

Uh oh!

lexming commented Nov 29, 2019 •

edited

Loading

lexming commented Nov 29, 2019 •

edited

Loading

lexming commented Dec 2, 2019 •

edited

Loading

akesandgren commented Dec 4, 2019 •

edited

Loading

furstj commented Dec 5, 2019 •

edited by boegel

Loading