OpenFOAM: Strictly require the preciceAdapterFunctionObject

[MakisH]

Asks OpenFOAM to abort in case an error is raised inside the adapter, or in case the adapter cannot be loaded (most common source of confusion). Previously, the simulation would continue without the adapter/coupling. Now:

Starting time loop

forces forces:
    rho: rhoInf
    Freestream density (rhoInf) set to 10
    Not including porosity effects

--> FOAM Warning : 
    From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
    in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 188
    Could not load "libpreciceAdapterFunctionObject.so"
libpreciceAdapterFunctionObject.so: cannot open shared object file: No such file or directory


--> FOAM FATAL ERROR: (openfoam-2412)
Unknown function type preciceAdapterFunctionObject

Valid function types :

15
(
...
)



    From static Foam::autoPtr<Foam::functionObject> Foam::functionObject::New(const Foam::word&, const Foam::Time&, const Foam::dictionary&)
    in file db/functionObjects/functionObject/functionObject.C at line 129.

FOAM exiting

Future reader: In case you get this error, check for issues with the OpenFOAM adapter / preCICE / dependencies installation. Search or ask in the forum.

Option available since v2012, already long enough. Related discussion in the OpenFOAM GitLab.

I have added a comment, so that users of other versions can get a hint to remove it.

Pending PR to the adapter, to update the documentation and any error-handling workarounds.

Thanks to @fsimonis for asking again for a solution to this.

@vidulejs: Do you see any reason not to merge this?

Checklist:

• I added a summary of any user-facing changes (compared to the last release) in the changelog-entries/<PRnumber>.md.
• I will remember to squash-and-merge, providing a useful summary of the changes of this PR.

[MakisH]

I now also moved the libs(...) list outside the functions{...} dictionary. This is required in some cases (for custom boundary conditions in the partitioned flow cases), but we should probably be consistent everywhere.