Added support for VTK

[pcafrica]

After a discussion with @luca-heltai and @fdrmrc, we would like to add support for the VTK library in deal.II.

VTK can be used for importing scalar or vector fields, evaluate/interpolate/project them onto a triangulation and many other geometry handling tasks. We plan to support versions higher or equal to 9.0.0. These features should complement the use of CGAL.

VTK has already been extensively tested and used within lifex and we aim to port existing functionalities from lifex to deal.II. I expect many more PR to follow once this is accepted.

TODO:

• check workflow file: is it ok to update to Ubuntu 22.04?
• add sample class
• add tests

[bangerth]

I'll let @tamiko do the review.

Out of curiosity, what features in VTK do you plan on using?

[pcafrica]

I'll let @tamiko do the review.

Out of curiosity, what features in VTK do you plan on using?

Most importantly, reading a (surface or volume) field from a VTK file and interpolating/projecting it at triangulation nodes using closest-point distance, linear interpolation or signed distance. This can be used for, e.g., imposing boundary conditions, reading a mesh displacement from file, defining different material properties or defining an immersed surface.

This will involve VTK filters like cell and point locators. An example can be found here, where, inheriting from Function<dim>, we are able to evaluate an input field at an arbitrary triangulation point.

[bangerth]

Ah, very cool -- something like FEFieldFunction, just with externally provided data! That is something that I'm sure we can also put to good use in ASPECT, for example. I'm looking forward to the patch!

[bangerth]

/rebuild

[agrayver]

Is there also a possibility here to export/import refined triangulations in a backward-compatible way? Current approach based on the boost-serialization library is not backward compatible and, in practice, breaks with each major release (say meshes created/saved with 9.3 cannot be read with 9.4 and so on...).

[pcafrica]

Is there also a possibility here to export/import refined triangulations in a backward-compatible way? Current approach based on the boost-serialization library is not backward compatible and, in practice, breaks with each major release (say meshes created/saved with 9.3 cannot be read with 9.4 and so on...).

Personally I've never used VTK for this purpose, but it's something worth investigating for sure.

[pcafrica]

A note about the Linux workflow: installing libvtk9-dev from apt results in a dependency conflict that I wasn't able to solve: https://github.com/dealii/dealii/actions/runs/5073291921/jobs/9116267080?pr=15266#step:3:86

In particular, libvtk9-dev depends on libtbb-dev, therefore it is incompatible with libtrilinos-all-dev which depends on libtbb2-dev

The current workaround is to build VTK manually, but this takes ~45 minutes and I guess it is too much (?).

[luca-heltai]

Can you try to add at the end

apt-get install ...

libvtk9-dev \
libtbb-dev-

(notice the - at the end of name of the missing package). I think we do install libtbb somewhere, since dealii depends on it. Maybe the naming is not right in libvtk9-dev.

[pcafrica]

Can you try to add at the end

apt-get install ...

libvtk9-dev \
libtbb-dev-

(notice the - at the end of name of the missing package). I think we do install libtbb somewhere, since dealii depends on it. Maybe the naming is not right in libvtk9-dev.

Thanks for the hint! Unfortunately, libvtk9-dev cannot be installed without libtbb-dev.

PS: libtbb2-dev is installed as a Trilinos dependency.

[pcafrica]

Another solution I've come up with is to define a new workflow, which only builds the VTK wrappers. Opinions?

[luca-heltai]

My preference would be to add vtk as a dependency in the docker image dealii/dependencies:jammy (or focal) and use that one to build one of the workflow.

[pcafrica]

Let's wait for #15278 to be discussed/merged before continuing with this PR.

[luca-heltai]

Thanks Pasquale!

[luca-heltai]

Would you mind rebasing and squashing into a couple of significative commits?

[pcafrica]

Would you mind rebasing and squashing into a couple of significative commits?

Done! From my side, it looks ready to merge.

[luca-heltai]

@tamiko, would you mind taking a look at the cmake stuff? I am fine with everything, but you are working on restructuring stuff....

[luca-heltai]

Also, @pcafrica, would you mind adding VTK support also in contrib/docker/Dockerfile? You did this already in the docker-files repository, but this one is used by the master workflow to create docker images of master after each merge to master.

[pcafrica]

Done!

PS: the pipeline fails with error mkdir: cannot create directory ‘build’: Permission denied. I think this is due to GitHub setting HOME=/github/home, which in the Docker image belongs to a different user.

We could try adding

    defaults:
      run:
        working-directory: /home/dealii

but I don't know if this has implications on the GitHub side.

@luca-heltai any clues?

[luca-heltai]

Ah, yes. You have to run the pipeline as user root:

In the workflow:

container:
      image: dealii/dependencies:jammy
      options: --user root

This should work.

[luca-heltai]

I think we also need to set

container:
      image: dealii/dependencies:jammy
      options: -u root -e OMPI_ALLOW_RUN_AS_ROOT=1 -e OMPI_ALLOW_RUN_AS_ROOT_CONFIRM=1

[masterleinad]

Please fix the merge conflicts.

[tamiko]

Let us merge this for now
We should support simply listing all targets now, though - but I suggest we try this out in a follow-up pull request.