Improve Adapter Installation

[BenjaminRodenberg]

Tell Fluent to use PRECICE_ROOT (Solved!)

Currently, we have to manually copy libprecice.so into libudf/lnamd64. The better approach would be to provide PRECICE_ROOT/build/last to Fluent, such that Fluent can find libprecice.so on its own.

Don't use symbolic links to src files

Symbolic links that are created during compilation of the adapter cannot be used by Fluent.

Our work-around here is to just copy-paste all src files from adapter/src into fluent-case/. However, this is not optimal. Can we somehow set an include path for Fluent, or similar?

Don't copy language bindings (Solved!)

see https://github.com/precice/fluent-adapter/issues/1#issuecomment-447407791

Provide alternative to distributing ANSYS Makefiles for compiling the adapter

Currently the adapter files include multiple ANSYS makefiles which are used to compile the adapter. These makefiles are copyrighted and cannot be distributed with the open-source adapter package. An alternative strategy to compile the adapter needs to be devised.

• Currently the most feasible idea is to provide documentation to guide the user on how to convert a FLUENT makefile for use to compile the adapter

[IshaanDesai]

• The adapter on this branch: https://github.com/precice/fluent-adapter/tree/update_fluent_19_5_R3 is at a state where manually copying the libprecice.so during installation is no longer necessary.
• Manually copying the C language bindings is no longer necessary.

Points to consider:

• ~~Manually copying libprecice.so, libprecice.so.2 and libprecice.so.2.0.0 in the directory where fluent.cas and the .scm files exist is still necessary for FLUENT to find preCICE.~~ Solution: --> Adding pkgconfig paths at appropriate locations in makefiles has solved this.
• The manual copying of src/ directory from the compiled state of the adapter to the directory where the FLUENT case is saved is still necessary because the adapter compilation creates symbolic links between the compiled UDF files in the folders 2d_node/ and 2d_host/ and the src/ directory. Currently this seems to be unavoidable.

[BenjaminRodenberg]

We definitely need an update of the installation procedure. This is something that I would consider critical for a minimal working state. A third-party user should be able to install and run the adapter.