Installtion issues around VTK and BLAS libraries

[sassy-crick]

Dear all,

I am trying to install the fluidity-4.1.20 release as a user requested that to be installed on our cluster. The overall aim is to get it into our automatic build system and for this we are using EasyBuild. That aside, there are some major problems with the current installation, unless I am getting things completely wrong.

For starters: we got VTK-9.2.2, PETSc-3.17.4, and HDF5-1.12.2 already installed on our cluster using GCC-11.3.0. So that is the framework we have and I want to build on top of that.

The configure.in file in the root directory, and in libadaptivity one has a few issues. For starters, it is configured to use version 5 or 6 of VTK when newer versions are clearly available. Next, the use of

    VTK_FLAGS=`cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=COMPILE`
    VTK_LIBS=`cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=LINK`

is not working and will never work. See here for the reason why. That trick might have worked with the older versions of VTK but is no longer working.

The cmake problem turns up at least at three different occasions

Also, it would be nice to add FlexiBLAS to configure when it is searching for BLAS, given the project has taken off quite a bit.

I managed with the help of some colleagues to get most things somehow working, but there is also a problem in the code:

Mesh_Quality_C.cpp: In function ‘void mesh_quality_c(int*, int*, int*, int*, int*, double*, int*, double*)’:
Mesh_Quality_C.cpp:82:19: error: ‘VTK_QUALITY_AREA’ was not declared in this scope
   82 |   if (*measure == VTK_QUALITY_AREA) {
      |                   ^~~~~~~~~~~~~~~~
Mesh_Quality_C.cpp:83:34: error: ‘VTK_QUALITY_VOLUME’ was not declared in this scope
   83 |     filter->SetTetQualityMeasure(VTK_QUALITY_VOLUME);
      |                                  ^~~~~~~~~~~~~~~~~~
gmake[1]: *** [Makefile:130: Mesh_Quality_C.o] Error 1
make: *** [Makefile:244: lib/libfluidity.a] Error 2

Finally:

  --enable-vtk            Only use to disable vtk

This is counter-intuitive and also not best practice. It would be better to do:

  --disable-vtk            To disable vtk

I would highly appreciate if these issues are being looked at as they currently stop me to install the code on the cluster. As suggested before, the use of cmake might be better suited for a modern Linux environment.

Thanks for your help.

[Flamefire]

As additional context why cmake --find-package does not work (for VTK): 1) VTK depends on Threads (i.e. pthreads) and FindThreads doesn't work with --find-package_

CMake Error at /software/CMake/3.24.3-GCCcore-11.3.0/share/cmake-3.24/Modules/FindThreads.cmake:66 (message):
  FindThreads only works if either C or CXX language is enabled
Call Stack (most recent call first):
  /software/VTK/9.2.2-foss-2022a/lib64/cmake/vtk-9.2/VTK-vtk-module-find-packages.cmake:115 (find_package)

2) VTK also depends on X11 which would then fail similarly:

CMake Error at /software/CMake/3.24.3-GCCcore-11.3.0/share/cmake-3.24/Modules/CheckLibraryExists.cmake:69 (message):
  CHECK_FUNCTION_EXISTS needs either C or CXX language enabled
Call Stack (most recent call first):
  /software/CMake/3.24.3-GCCcore-11.3.0/share/cmake-3.24/Modules/FindX11.cmake:498 (check_library_exists)

Manually specifying the VTK libraries to link is also infeasible: Patching CMake to allow to return the list of libs (i.e. VTK_LIBS) returns around 150 libraries of VTK alone and some others which could not be resolved to actual files such as X11, Python, MPI

Moving to CMake allows to cleanly integrate those libraries in a future proof way.

[Patol75]

Hi @sassy-crick and @Flamefire,

Apologies for the late reply.

Maintainers are aware of the issue you mentioned with VTK. It should be possible to build Fluidity with the latest VTK using this patch.

For BLAS, I do not believe it is needed to build Fluidity. I think it is accessed through PETSc.

I am not quite sure what the issue you are hitting in Mesh_Quality_C.cpp is; I have not seen it before.

Regarding a CMake build, please have a look at gh-358 for a proof of concept. Unfortunately, there has not been sufficient interest in that endeavour for merging to happen, but you should be able to build Fluidity using that branch.

[stephankramer]

Thanks @Patol75 - if you still want to pursue that cmake PR, I'd be happy to discuss further what's left to be done.

Just to come back to some of the underlying issues here: we simply can't support every version of vtk. Ubuntu 20.04, which a lot of our users will be on is still on vtk6. We should probably have aimed for vtk9 support with 22.04 - it's just we've had little dedicated developer time the last 2 years - so we've just stuck with vtk7 for 22.04. Our historic hesitation to switching over from autoconf to cmake is based on the fact that although it's great for a lot of newer (in particular c++) projects that were specifically written with it, it just brings in other issues for other dependencies - and the switch over itself which I think on balance would be beneficial will take up a lot of developer time dealing with teething issues of different users. I'm sure it's a great portable way to configure vtk, but that's not very surprising given it comes from the same stall. cmake's insistence on you always installing the latest version isn't very helpful either. Again I'm all for the switch, it's just someone needs to do it and deal with the pain that comes when it lands.

I just like to point out that this is a common issue for several similar projects with many projects choosing a much stricter dependency policy. So then your options are either a "user rebuilds all dependencies themselves exactly at the versions we specify" strategy maybe with something like spack to manage that or some convoluted, ever broken buildscript - or, going for containerized solutions.

If there's specific quick things you'd like to see fixed, feel free to mention them specifically, maybe best file separate issues. For instance I believe libadaptivity's vtk dependency is entirely spurious, so if it helps to remove that we can have a quick look. Supporting cmake+vtk9 is probably going to take a bit longer, probably when there's enough pressure to support the next Ubuntu LTS

[Patol75]

So I ran into the mesh quality issue mentioned here; it is a recent change in VTK, as documented here.

I have very limited C++ knowledge, but I think that replacing these lines with

  using QualityMeasureTypes = vtkMeshQuality::QualityMeasureTypes;
  filter->SetTriangleQualityMeasure(*measure);
  if (filter->GetTriangleQualityMeasure() == QualityMeasureTypes::AREA) {
    filter->SetTetQualityMeasure(QualityMeasureTypes::VOLUME);
  } else {
    filter->SetTetQualityMeasure(*measure);
  }

should solve the issue.