Add DOLFIN-20230817 easyconfigs

[stevenvdb]

Geert Buckinx requested a new DOLFIN installation which has some bugfixes compared to 2019.1.0.post0-foss-2021a-Python-3.9.5-SuperLU_DIST, but is otherwise installed in the same way. The version he refers to is 2019.2.0.dev0, but unfortunately there is no release with that name and there are multiple commits that share that version name. So I tried to select a set of recent commits from the different fenics components that are compatible with each other, and the result is in this PR.

One thing I am not sure about yet is how to deal with the customization of the dolfin.py easyblock. I included it here, but this will become problematic in case we need multiple customized dolfin.py easyblocks.

[MaximeVdB]

Hi Steven -- looks good!

Regarding this:

One thing I am not sure about yet is how to deal with the customization of the dolfin.py easyblock. I included it here, but this will become problematic in case we need multiple customized dolfin.py easyblocks.

The only difference with the 'upstream' easyblock is the removal of the Trilinos dependency check, right? If so, maybe the best would be to e.g. add a with_trilinos easyconfig parameter to control whether the dependency check is kept (True by default, and then setting it to False in the present easyconfig).

[stevenvdb]

The only difference with the 'upstream' easyblock is the removal of the Trilinos dependency check, right? If so, maybe the best would be to e.g. add a with_trilinos easyconfig parameter to control whether the dependency check is kept (True by default, and then setting it to False in the present easyconfig).

That is indeed a good approach. The remaining question is how to make sure that the custom easyblock is used when doing the installation. I'll ask for advice in the meeting.

[smoors]

The only difference with the 'upstream' easyblock is the removal of the Trilinos dependency check, right? If so, maybe the best would be to e.g. add a with_trilinos easyconfig parameter to control whether the dependency check is kept (True by default, and then setting it to False in the present easyconfig).

That is indeed a good approach. The remaining question is how to make sure that the custom easyblock is used when doing the installation. I'll ask for advice in the meeting.

if you create a PR upstream, you can use EB option --include-easyblocks-from-pr <PR>.
alternatively, you can use a local easyblock with --include-easyblocks <path-to-easyblock>

[stevenvdb]

if you create a PR upstream, you can use EB option --include-easyblocks-from-pr <PR>. alternatively, you can use a local easyblock with --include-easyblocks <path-to-easyblock>

My question is rather the following: how can I make sure that if someone else tries to repeat the installation, they will not forget to provide the custom easyblock (for instance with --include-easyblocks)? Is this something that can be done with hooks? Or would you for instance use a custom name for the easyblock? Perhaps we can discuss this in the next meeting.

[smoors]

in that case i would suggest to:

1. get the optional parameter with_trilinos (suggested by @MaximeVdB) included in the upstream easyblock
2. set with_trilinos to false
   2a) either in a hook
   3b) or in a custom easyconfig making sure the custom easyconfig is used by prepending the directory with custom easyconfigs to the robot-paths in your EB configuration file (or with EASYBUID_ROBOT_PATHS)

we can indeed further discuss in the next meeting