Code Monkey home page Code Monkey logo

openfoam-adapter's Introduction

OpenFOAM-preCICE adapter

Ask questions in the forum Build with OpenFOAM v2312 Changelog License

Start here

See the adapter documentation and related tutorials.

Please report any issues here and give us feedback through one of our community channels. Please ask question in the preCICE forum, not via issues.

This project is actively maintained on precice/openfoam-adapter. Current maintainers: @MakisH and @DavidSCN.

Contributing

We welcome contributions! Have a look at open good first issues and where we need help.

Check the file CONTRIBUTING.md for a few tips and guidelines.

Citing

Whenever using or referring to this adapter in academic publications, please cite it [1]. See the option "Cite this repository" in the "About" section, as well as the preCICE literature guide and the adapter overview page for more information.

References

[1] Chourdakis, G., Schneider, D., & Uekermann, B. (2023). OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations. OpenFOAM® Journal, 3, 1–25. DOI: 10.51560/ofj.v3.88

Disclaimer

This offering is not approved or endorsed by OpenCFD Limited, producer and distributor of the OpenFOAM software via www.openfoam.com, and owner of the OPENFOAM® and OpenCFD® trade marks.

openfoam-adapter's People

Contributors

benjaminrodenberg avatar cheriimoya avatar davidscn avatar dependabot[bot] avatar derekrisseeuw avatar eder-k avatar fsimonis avatar jseuffert avatar kyledavissa avatar makish avatar maxfirmbach avatar olesenm avatar shkodm avatar thesamriel avatar tirgendetwas avatar uekerman avatar valentin-seitz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openfoam-adapter's Issues

Guard against calling the function object's read() two times

Currently, we configure the adapter inside preciceAdapterFunctionObject::read():

bool Foam::functionObjects::preciceAdapterFunctionObject::read(const dictionary& dict)
{
#if defined OPENFOAM_PLUS || (defined OPENFOAM && (OPENFOAM > 1000))
// Patch for issue #27: warning "MPI was already finalized" while
// running in serial. This only affects openfoam.com, while initNull()
// does not exist in openfoam.org.
UPstream::initNull();
#endif
adapter_.configure();
return true;
}

However, this could be called again if the configuration dictionary is overwritten during the simulation, and this could have unclear side-effects.

This is an important addition, especially when we implement #30. Thanks to @olesenm for reporting this. See also #68.

Installation Problem - OpenFOAM adapter

Hello 👋!

I've been trying to install the preCICE library and its adapter for OpenFOAM but did not succeed. I followed this guide for installing the library itself and this other for the adapter. I suspect that I'm not building correctly either Boost or yaml-cpp.

I'm using:

  • Ubuntu 16.04 LTS

  • OpenFOAMv17.12

Regarding the installation of the library I did the following:

# Installation script for preCICE on Ubuntu 16.04
 
# 1.- Install the required dependencies and make sure your environment is
# set appropriately (e.g. open a new terminal).
 
# 1.1: Install all the available dependencies through APT:
sudo apt install -y build-essential scons libeigen3-dev
sudo apt install -y libxml2-dev petsc-dev python-dev python-numpy
 
# 1.2: Install Boost. In the Ubuntu 16.04 repositories, only Boost 1.58 
# is avaiable, in which the VMD library is missing. Building Boost 1.66
# from source.
# 1.2.1: Download and extract Boost into any directory. Switch to that 
# directory.
wget --no-check-certificate https://dl.bintray.com/boostorg/release/1.66.0/source/boost_1_66_0_rc2.tar.gz
tar -xvf "boost_1_66_rc2.tar.gz" > log.Boost-tar
rm boost_1_66_rc2.tar.gz
cd boost_*
# 1.2.2: Prepare the installation, selecting only the libraries that need
# to be built (this does not affect the header-only libraries). We will 
# later move these files to the system directory /usr/local. Execute:
./bootstrap.sh --with-libraries=log,thread,system,filesystem,program_options,test --prefix=/usr/local > log.Boost-install1
# 1.2.3: Install the libraries. Since /usr/local is a system directory,
# we need root access:
sudo ./b2 -j 12 install > log.Boost-install2
# 1.2.4: Update the dynamic linker's run-time bindings:
sudo ldconfig
cd ..
 
# 1.3: Add the following in your ~/.bashrc:
echo "# Eigen"                                                                 >> ~/.bashrc
echo "export CPLUS_INCLUDE_PATH="/usr/include/eigen3:$CPLUS_INCLUDE_PATH"" >> ~/.bashrc
echo "# PETSc"                                                               >> ~/.bashrc
echo "export PETSC_DIR=/usr/lib/petscdir/3.6.2/"       >> ~/.bashrc
echo "export PETSC_ARCH=x86_64-linux-gnu-real"  >> ~/.bashrc
source ~/.bashrc
  
# 2.- Download and unpack the latest release of preCICE:
wget --no-check-certificate https://github.com/precice/precice/archive/v1.1.1.tar.gz
tar -xzvf v1.1.1.tar.gz > log.preCICE-tar
rm v1.1.1.tar.gz
cd precice-1.1.1
  
# 3.- This directory is your PRECICE_ROOT. Get the absolute path with pwd
# and add it in your environment:
path=$PWD
echo "# preCICE"                   >> ~/.bashrc
echo "export PRECICE_ROOT="$path"" >> ~/.bashrc
source ~/.bashrc

# 4.- Use SCons to build preCICE without the tests target:
scons petsc=yes python=no -j 12 solib symlink > log.preCICE-build
  
# 5.- After building succesfully
# 5.1: Did NOT run the tests
# 5.2: Add $PRECICE_ROOT/build/last to your dynamic library path
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PRECICE_ROOT/build/last/

And got no errors, everything seemed fine to me. Regarding the adapter I did the following:

# 1.- Clone the adapter from github
git clone https://github.com/precice/openfoam-adapter.git
cd openfoam-adapter
# 2.- Install the latest yaml-cpp headers and shared library from the 
# distribution's repository
sudo apt-get install -y libyaml-cpp-dev
# Install the preCICE headers and library:
./installPreCICE.sh
# 5.- Execute the build script ./Allwmake
./Allwmake

The build seemed ok and the tutorial case ran, but there was no heat exchange between the fluid and the solid. Upon close inspection of Fluid.log I found this:

Starting time loop
 
 --> FOAM Warning :
     From function void* Foam::dlOpen(const Foam::fileName&, bool)
     in file POSIX.C at line 1604
     dlopen error : libprecice.so: cannot open shared object file: No such file or directory
 --> FOAM Warning :
     From function bool Foam::dlLibraryTable::open(const Foam::fileName&, bool)
     in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 105
     **could not load "libpreciceAdapterFunctionObject.so"**
 --> FOAM Warning :
     From function bool Foam::dlLibraryTable::open(const Foam::dictionary&, const Foam::word&, const TablePtr&) [with TablePtr = Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(const Foam::word&, const Foam::Time&, const Foam::dictionary&), Foam::word, Foam:     :string::hash>*]
     in file lnInclude/dlLibraryTableTemplates.C at line 62
     Could not open library "libpreciceAdapterFunctionObject.so"
 
 --> FOAM Warning :
 Unknown function type preciceAdapterFunctionObject
 
 Valid function types :
 
 7
 (
 patchProbes
 probes
 psiReactionThermoMoleFractions
 rhoReactionThermoMoleFractions
 sets
 surfMeshes
 surfaces
 )
 
 
 
     From function 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 107.
     From function bool Foam::functionObjectList::read()
     in file db/functionObjects/functionObjectList/functionObjectList.C at line 840

Then, I rebuilt the adapter (./Allclean and ./Allwmake) and stored the output in a log file:

 Compiling enabled on 12 cores
 wmake libso (openfoam-adapter-master)
 wmakeLnInclude: linking include files to ./lnInclude
 Making dependency list for source file preciceAdapterFunctionObject.C
 Making dependency list for source file Adapter.C
 Making dependency list for source file CHT.C
 Making dependency list for source file SinkTemperature.C
 Making dependency list for source file HeatTransferCoefficient.C
 Making dependency list for source file HeatFlux.C
 Making dependency list for source file KappaEffective.C
 Making dependency list for source file Temperature.C
 Making dependency list for source file CouplingDataUser.C
 Making dependency list for source file Interface.C
 Making dependency list for source file Utilities.C
 wmkdep: could not open file 'yaml-cpp/yaml.h' for source file 'Adapter.C'wmkdep: could not open **file 'yaml-cpp/yaml.h' for source file 'CHT/CHT.C': No such file or directory: No such file or directory**
 
 wmkdep: could not open file 'yaml-cpp/yaml.h' for source file 'preciceAdapterFunctionObject.C': No such file or directory
 g++ -std=c++11 -m64 -DOPENFOAM_PLUS=1712 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/andreuber    nadserra/OpenFOAM/OpenFOAM-v1712/src/finiteVolume/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/meshTools/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/transportModels/ -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/transpo    rtModels/compressible/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/thermophysicalModels/basic/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/TurbulenceModels/turbulenceModels/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v    1712/src/TurbulenceModels/compressible/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/TurbulenceModels/incompressible/lnInclude -I/usr/include/eigen3  -I/home/andreubernadserra/precice-1.1.1/src/precice  -I../ -DADAPTER_DEBUG_MODE -IlnInclude -I. -I    /home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/OpenFOAM/lnInclude -I/home/andreubernadserra/OpenFOAM/OpenFOAM-v1712/src/OSspecific/POSIX/lnInclude   -fPIC -c Utilities.C -o Make/linux64GccDPInt32Opt/Utilities.o
...

At this point I thought that the error was caused by the yams-cpp library not being found, but I can call it in a cpp script and there is no error when compiling. Now my questions, is there anything I'm doing wrong in terms of building the library or the adapter? Perhaps, is there an incompatibility between the Boost and yalm-cpp versions? Maybe I didn't install correctly the Boost library.

By any means I'm an expert in Linux or cpp (more of a Python guy), and most likely there is something I'm doing terribly wrong rather than this being a bug. I'm sorry if this is the case.

Thank you in advance!

Andreu

Releases and versioning

We should make proper releases of the adapter, similarly to preCICE. This way, a user can directly let us know which version she is using, we can announce release changes, thank contributors etc.

Questions:

  • Which version number do we start from? I vote for 0.1.0 or similar. If we gave 1.0, it would give the false impression that the project is as mature as preCICE itself.
  • Should we just release different variants of the code for each supported OpenFOAM version? If yes, how should they be named? See also #32.
  • If we wanted provide packages for each version instead, what could they be? There is already a Spack package with OpenFOAM v1806. OpenFOAM usually looks at its own paths for libraries, we should be able to write on them, or edit these paths.

Port Foam::Time::setDeltaT to new signature

On February 5, 2018, this commit to openfoam-dev broke the compatibility with the OpenFOAM adapter, as the method Foam::Time::setDeltaT now uses only one argument instead of two, changing a bit its logic.

We need to find a way to support both the old and the new signature and to check how the logic changes affect the adapter.

Support OpenFOAM 2.2.x-2.4.x

The adapter already supports openfoam.org v.5.x and v.4.x. Support for v.3.x is discussed in #8.

All the concepts used by the adapter (such as the function objects) exist in these versions.

We have not yet analyzed the differences between these versions and v.3.x that may affect the adapter. However, from the OpenFOAM 3.x release notes it looks like there are differences in the turbulence models. This may affect the CHT module.

Versions prior to 2.2.0 provide less methods for the function objects. If you want to use the adapter with a previous version, please open a similar issue.

OpenFOAM 2.2.x repository
OpenFOAM 2.3.x repository
OpenFOAM 2.4.x repository

List of tasks:

  • Support OpenFOAM 3.x (see #8)
  • Check and adjust the turbulence models, if needed.

More tasks may be required.

Edit: Keep also this in mind.

Support nearest-projection mapping

The adapter currently does not provide preCICE with the mesh edges, but only with the locations of the vertices. This means that currently nearest-projection mapping is not supported.

preCICE provides the following method in its src/precice/SolverInterface.hpp file:

int setMeshEdge (
     int meshID,
     int firstVertexID,
     int secondVertexID );

The mesh vertices are assigned in the adapter's Interface.C file, in the method preciceAdapter::Interface::configureMesh().

Building fails with Boost 1.67 because of old yaml-cpp

Hello,

I am trying to build the OpenFOAM adapter to run the tutorial https://github.com/precice/precice/wiki/Tutorial-for-CHT-with-OpenFOAM-and-CalculiX. I am doing this from a docker container with ubuntu16.04. I successfully installed:

  1. OpenFOAM under /opt/OpenFOAM/
  2. CalculiX
  3. Precice under /opt/precice-1.1.1

And I successfully made the CalculiX adapter ccx_preCICE.

I installed yaml with apt-get install libyaml-cpp-dev and also building it manually, which worked for the CalculiX adapter.

However, when I run ./Allwmake I get the following error in the wmake.log file:

 wmake libso .
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I/opt/OpenFOAM/OpenFOAM-5.x/src/finiteVolume/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/meshTools/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/transportModels/ -I/opt/OpenFOAM/OpenFOAM-5.x/src/transportModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/thermophysicalModels/basic/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/TurbulenceModels/turbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/TurbulenceModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/TurbulenceModels/incompressible/lnInclude -I/usr/include/eigen3  -I/opt/precice-1.1.1/src/precice -I../ -DADAPTER_DEBUG_MODE -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-5.x/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-5.x/src/OSspecific/POSIX/lnInclude   -fPIC -c CHT/CHT.C -o Make/linux64GccDPInt64Opt/CHT/CHT.o
In file included from /usr/include/yaml-cpp/node/iterator.h:13:0,
                 from /usr/include/yaml-cpp/node/impl.h:11,
                 from /usr/include/yaml-cpp/yaml.h:17,
                 from CHT/CHT.H:14,
                 from CHT/CHT.C:1:
/usr/include/yaml-cpp/node/detail/iterator.h: In member function 'void YAML::detail::iterator_base<V>::increment()':
/usr/include/yaml-cpp/node/detail/iterator.h:48:47: error: 'next' is not a member of 'boost'
   void increment() { this->base_reference() = boost::next(this->base()); }
                                               ^
/usr/include/yaml-cpp/node/detail/iterator.h:48:47: note: suggested alternatives:
In file included from /usr/include/c++/5/bits/stl_algobase.h:66:0,
                 from /usr/include/c++/5/bits/char_traits.h:39,
                 from /usr/include/c++/5/string:40,
                 from lnInclude/Interface.H:4,
                 from CHT/CHT.H:4,
                 from CHT/CHT.C:1:
/usr/include/c++/5/bits/stl_iterator_base_funcs.h:184:5: note:   'std::next'
     next(_ForwardIterator __x, typename
     ^
In file included from /usr/local/include/boost/mpl/next.hpp:17:0,
                 from /usr/local/include/boost/mpl/bind.hpp:25,
                 from /usr/local/include/boost/mpl/lambda.hpp:18,
                 from /usr/local/include/boost/mpl/apply.hpp:25,
                 from /usr/local/include/boost/iterator/iterator_facade.hpp:36,
                 from /usr/include/yaml-cpp/node/detail/node_iterator.h:12,
                 from /usr/include/yaml-cpp/node/detail/iterator.h:12,
                 from /usr/include/yaml-cpp/node/iterator.h:13,
                 from /usr/include/yaml-cpp/node/impl.h:11,
                 from /usr/include/yaml-cpp/yaml.h:17,
                 from CHT/CHT.H:14,
                 from CHT/CHT.C:1:
/usr/local/include/boost/mpl/next_prior.hpp:29:8: note:   'boost::mpl::next'
 struct next
        ^
/opt/OpenFOAM/OpenFOAM-5.x/wmake/rules/General/transform:25: recipe for target 'Make/linux64GccDPInt64Opt/CHT/CHT.o' failed
make: *** [Make/linux64GccDPInt64Opt/CHT/CHT.o] Error 1in the 

The standard output when I run ./Allwmake is:

Building the OpenFOAM adapter for preCICE...
Make sure that all the required dependencies (mainly yaml-cpp and preCICE) are installed.
Using the following environment variables:
  ADAPTER_PRECICE_ROOT  = /opt/precice-1.1.1
      preCICE dependencies: not specified (ok if preCICE is built as a shared library)
  ADAPTER_PREP_FLAGS    = -DADAPTER_DEBUG_MODE
  ADAPTER_TARGET_DIR    = /opt/OpenFOAM/OpenFOAM-5.x/platforms/linux64GccDPInt64Opt/lib
  ADAPTER_WMAKE_OPTIONS = 
  ADAPTER_GLOBAL_CPLUS_INC_PATHS  = -I/usr/include/eigen3 
  ADAPTER_GLOBAL_LD_LIBRARY_PATHS = -L/opt/precice-1.1.1/build/last/ 
  ADAPTER_GLOBAL_LIBRARY_PATHS    = 
  WM_PROJECT_VERSION = 5.x

Building with WMake (see the wmake.log log file)...

Building failed. See wmake.log for more.

Could you please give me a hint as to what is going wrong?

Thank you very much!

Support multiple OpenFOAM versions with the same source

Often users are bound to specific OpenFOAM variants (e.g. openfoam.com, openfoam.org, foam-extend) and versions (not always the latest, sometimes very old). However, often small or not-so-small differences will give errors during compilation. Therefore, we need a system to be able to support different versions at compile time.

Implementing such a system would help a lot dealing with issues such as #21, #8, #9, #26. A list of currently supported versions can be found in our wiki.

Fortunately, all the three main variants set the environment variables WM_PROJECT (OpenFOAM for .com and .org, foam for foam-extend) and WM_PROJECT_VERSION (4.1, 5.0, 6 (no dot), ... and dev for .org, v1712, v1806, ... for .com, 3.2, 4.0, ... for foam-extend) (see also #29). Versioning systems and other assumptions have changed much lately.

We currently use the WMake build system, developped together with OpenFOAM. This is a quite primitive system, but it is intrinsic to OpenFOAM. On top of it, I have added the Allwmake bash script to automate the procedure even more (also a common way in OpenFOAM-derived projects).

A few ideas on how to go on:

  1. (ugly) Support different versions in different branches. The current state of the branch works with the latest version, Git tags/other branches for older versions.

    • This is how we support multiple SU2 and CalculiX versions.
    • Difficult to maintain, but easier than other options (e.g. different directories)
    • Here we have multiple "latest versions".
  2. (ugly) Use pre-processor commands to check the version and activate different parts of the code.

    • A bit ugly and maybe difficult to maintain
    • Some changes (e.g. required in #8 and #9 ) are much bigger and spread throughout the code to treat with small patches
  3. (ugly) Have source files like Adapter_of6_dev.C and Adapter_of4_5.C and let our script pick the correct ones.

    • Difficult to maintain
    • Keep the files kind of clean
  4. Use a proper configuration system (e.g. CMake)

    • Ok, but how to solve our problem with it?
    • Do we need to replace WMake completely or can it work on top of it?

I would very much value your feedback on this.

FSI: Extend Force to turbulent flows

Currently, in FSI/Force.C, we only support laminar flows (see devRhoReff()).

No warning is currently implemented.

More details to follow.

See also #42. Relevant to #7.

Allwmake: check for compatible versions

In the Allwmake script, we currently check if an OpenFOAM environment is already initialized:

# Check if an OpenFOAM environment is available
echo " WM_PROJECT_VERSION = ${WM_PROJECT_VERSION}"
if [ -z "${WM_PROJECT_VERSION}" ]; then
echo " It looks like no OpenFOAM environment is available. Have you loaded the OpenFOAM etc/bashrc file?"
echo "Building failed."
exit 1
fi

However, we should also check if this is a compatible environment. For example, trying to build with foam-extend will fail.

We can get this information from WM_PROJECT (alongside WM_PROJECT_VERSION).

Remove warnings for read-data / write-data missing in config

While checking the configuration, we also check if an interface does not provide a read-data or write-data nodes. This could actually be intentional, e.g. when using one interface for nodes-based mesh points and one for centers-based mesh points (typical in FSI):

---[preciceAdapter] [DEBUG] Checking the adapter's YAML configuration file...
--> FOAM Warning : 
    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 17
    Warning in the preCICE adapter: 
The 'read-data' node is missing for the interface #1 in ./Fluid/processor0/../precice-adapter-config.yml.
--> FOAM Warning : 
    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 17
    Warning in the preCICE adapter: 
The 'write-data' node is missing for the interface #2 in ./Fluid/processor0/../precice-adapter-config.yml.

The warning could be scary without really adding anything, so we should remove it.

FSI: simple case tutorial request

a simple case tutorial configuration file is needed to start testing, I'm trying to contribute with the code, but right now I don´t know how to test it more that if the code build successfully.

Compatibility with pimpleDyMFoam

Hello,

Is there any planned update to the FSI portion of the adapter? Specifically, are plans made to couple the pimpleDyMFoam solver with a FSI solver?

If not, would you be able to provide any information or documentation you may have on the process that one should take?

Create a module for Fluid-Fluid coupling

Additionally to conjugate heat transfer and fluid-structure interaction, we plan to extend the adapter to also support fluid-fluid coupling, e.g. for coupling two models of different fidelity. A simple example would be coupling a far-field with a cheap solver_A, and a near-field with a more expensive solver_B. As always in preCICE, the two solvers sould also come from completely unrelated software projects and the two participants should know nothing about each other.

More details will be added into this issue as we make progress. This feature could be available before the end of 2019, but no strict schedule is set at the moment.

FSI: Subcycling with implicit coupling

Additional fields should be checkpointed, for stability. Meanwhile, these fields should not be checkpointed when we don't subcycle.

See the method storeMeshPoints() in Adapter.C for more. @derekrisseeuw could you maybe provide a few more details?

Relevant to #7.

Re-read the (fixed) timestep if a user modifies it at runtime

preCICE gets the time step length from the solver and restricts it (if needed) when approaching a coupling time. If the solver uses a dynamic time step, it will re-compute it in the next iteration. If it uses a constant time step, we force the solver to try the original value again (see preciceAdapter::Adapter::adjustSolverTimeStep() in the Adapter.C).

OpenFOAM allows to set the flag runTimeModifiable in the controlDict, in order to modify the configuration while the simulation is running. However, whenever this happens, we do not currently update the stored value for the fixed time step length.

This should be implemented in a way that does not degrade the performance.

Redesign checkpointing for any type

Due to the way the project evolved, checkpointing takes a very large portion of the code, which could be replaced by templates. We should try to redesign this, even if we have probably added every possible type to be checkpointed.

Some strange floating point exception at read-write timestep

Hi,

I modified another case I am working on atm, the simulation goes fine. It writes out everything as it supposed to. But after every file writeout instance, it bombs out with following error message:

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  precice::utils::EventRegistry::printGlobalStats() at ~/Downloads/precice/src/utils/EventTimings.cpp:450 (discriminator 2)
#4  precice::utils::EventRegistry::print(std::ostream&) at ~/Downloads/precice/src/utils/EventTimings.cpp:358
#5  precice::utils::EventRegistry::print() at ~/Downloads/precice/src/utils/EventTimings.cpp:365
#6  precice::utils::EventRegistry::printAll() at ~/Downloads/precice/src/utils/EventTimings.cpp:302
#7  precice::impl::SolverInterfaceImpl::finalize() at ~/Downloads/precice/src/precice/impl/SolverInterfaceImpl.cpp:473
#8  precice::SolverInterface::finalize() at ~/Downloads/precice/src/precice/SolverInterface.cpp:45
#9  preciceAdapter::Adapter::finalize() at ??:?
#10  preciceAdapter::Adapter::execute() at ??:?
#11  Foam::functionObjects::preciceAdapterFunctionObject::execute() at ??:?
#12  Foam::functionObjectList::execute() at ??:?
#13  Foam::Time::run() const at ??:?
#14  Foam::Time::loop() at ??:?
#15  Foam::simpleControl::loop() at ??:?
#16  ? at ??:?
#17  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#18  ? at ??:?

As far as controlDict - I have total simulation time 10s and file write out at 1s. And I modified the start to 'latestTime' instead of 'startTime'.

CHT: Calculation of HeatFlux for meshes which use wall functions

Hi, I just looked at the HeatFlux.C implementation and observed that it uses gradient of the temperature to calculate the heatflux. This would be accurate only if one uses very fine mesh near the wall, say with y+ < 1. Does that mean at the moment use of wall function meshes (y+> 30) is not possible for CHT analysis? Or I am missing something. :)

Only write data to the preCICE buffer if required

preCICE provides the method

bool isWriteDataRequired ( double computedTimestepLength );

in its SolverInterface.hpp which returns false when the solver is subcycling and it is not approaching a coupling time. This can improve the performance, but is not currently used in the adapter. Note that the method requires the computed timestep length.

In the Adapter.C, the method preciceAdapter::Adapter::writeCouplingData() calls the respective preciceAdapter::Interface::writeCouplingData() on each interface, which is defined in the Interface.C

Throw meaningful error message, if building OpenFOAM fails due to known reasons

If building OpenFOAM fails due to known reasons, we should (at least) throw an appropriate warning until we find a proper fix.

A small example:
I installed OpenFOAM using apt-get following the instructions on https://openfoam.org/download/6-ubuntu/. When I tried to build the adapter, compilation failed and in wmake.log there were only some error messages that didn't help a lot. The actual fix for my problem was easy. I just had to checkout the branch OpenFOAM6 instead of master. This is also documented here. However, a more meaningful error message would have helped me a lot.

FSI: Add an option for stress mapping

At the moment, we map forces. However, it would be very nice to also be able to map stresses, which would be easy to implement, having already implemented Force.C.

A limitation here is that we cannot use stresses in CalculiX at the moment. So, a prerequisite for this would be to either:

A. Implement stresses reading also in the calculix-adapter,
B. Add connectivity information in the openfoam-adapter, so that we use a preCICE action to convert the stresses to forces (see also #2 ).
C. Use another structure solver that already supports reading stresses (is there one already?).

This is relevant to #7 .

Support OpenFOAM 3.x

While openfoam.org versions 4.x have no changes that affect the adapter in comparison to versions 5.x, there are some differences in older versions.

Versions 3.x are different from 4.x in at least the following points:

Robust data handling: new convention for const and non-const reference func-
tions of fields where the non-const function uses ...Ref(); for example, where
boundaryField() provides the const reference to the boundary field,
boundaryFieldRef() provides a non-const reference. for tmp objects, non-
const access uses a ref() function rather than the () dereferencing operator.

See also the OpenFOAM-dev commit a4e2afa and this issue.

The adapter could support different versions using different branches.

List of tasks:

  • Create a separate branch for this version.
  • Write the supported versions in the README.md and link to the repository for more.
  • Adjust (replace) the preciceAdapterFunctionObject.H and preciceAdapterFunctionObject.C files.
  • Change all the boundaryFieldRef() to boundaryField().
  • Check and adjust the types and methods used to access the effective conductivity/diffusivity. The classification into compressible and incompressible solvers may need to be refined and more cases may need to be added.
  • Check and adjust the OpenFOAM dependencies in the Make/options file, if needed.
  • Update the wiki page on compatibility with OpenFOAM versions.
  • Port the tutorial files to this version.
  • Validate.

More tasks may be needed.

For older versions, see #9.

OpenFOAM-dev: changed fileName to fileType

This commit (re)moved the enum Type from src/OpenFOAM/primitives/strings/fileName/fileName.H, which we use to determine if results have already been written for this time:

openfoam-adapter/Adapter.C

Lines 402 to 421 in 49fd975

// As soon as OpenFOAM writes the results, it will not try to write again
// if the time takes the same value again. Therefore, during an implicit
// coupling, we write again when the coupling timestep is complete.
// Check the behavior e.g. by using watch on a result file:
// watch -n 0.1 -d ls --full-time Fluid/0.01/T.gz
if (checkpointing_ && isCouplingTimestepComplete())
{
// Check if the time directory already exists
// (i.e. the solver wrote results that need to be updated)
if (runTime_.timePath().type() == fileName::DIRECTORY)
{
adapterInfo
(
"The coupling timestep completed. "
"Writing the updated results.",
"info"
);
const_cast<Time&>(runTime_).writeNow();
}
}

We should either make it compatible with OpenFOAM-dev (again a special case), or change the approach to make it more generic.

Use an OpenFOAM dictionary for configuration

We currently use yaml-cpp to parse our precice-adapter-config.yml YAML file (see more in our wiki)

Although YAML is a nice language to use for configuration files, there are some problems:

  • yaml-cpp is an additional, not so common dependency
  • the yaml-cpp version may conflict with the Boost version (see again this issue)
  • it is a format foreign to OpenFOAM (although this could also be seen as an advantage)

Therefore, it would be good to allow configuring the adapter through a dictionary. This could be done alongside or instead our current YAML-based file.

CHT: Adding radiative flux Qr in interface patch

Hi,

First of all, thanks for the adapter. It is a great tool!

I am looking at adding radiation in the CHT case you have provided. How could we add Qr in patch heat flux at interface?

Thanks!
Jaydeep

Look for libraries in the LD_LIBRARY_PATH

When building the adapter with preCICE as a static library, the paths for Boost and PETSc (and maybe also other dependencies in some cases) need to be set manually in the build script. However, some users already have these paths set in their LD_LIBRARY_PATH or LIBRARY_PATH and they should not need to specify them again. Moreover, this could lead into linking to the wrong version of a library, if multiple are installed.

We use the wmake build system, which is provided with OpenFOAM. However, this does not search directories like the LIBRARY_PATH, LD_LIBRARY_PATH or CPLUS_INCLUDE_PATH, as is described in this issue. One way to search them would be to add these directories in the LIB_LIBS and EXE_INC (for header files) of the Make/options file.

In the state of the adapter at commit e70e06c we had added these paths in the LIB_LIBS. However, for some users this triggered errors during linking:

g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I/data/scratch//OF-Adapter/OpenFOAM-5.0/src/finiteVolume/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/meshTools/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/transportModels/ -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/transportModels/compressible/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/thermophysicalModels/basic/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/TurbulenceModels/turbulenceModels/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/TurbulenceModels/compressible/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/TurbulenceModels/incompressible/lnInclude -I/data/scratch/<username>/precice/src/precice -I -I../ -DADAPTER_DEBUG_MODE -IlnInclude -I. -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/OpenFOAM/lnInclude -I/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/src/OSspecific/POSIX/lnInclude   -I/home/<username>/software/boost/include -I/usr/include/eigen3 -I  -fPIC -shared -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/Utilities.o Make/linux64GccDPInt32Opt/Interface.o Make/linux64GccDPInt32Opt/CouplingDataUser.o Make/linux64GccDPInt32Opt/CHT/Temperature.o Make/linux64GccDPInt32Opt/CHT/KappaEffective.o Make/linux64GccDPInt32Opt/CHT/HeatFlux.o Make/linux64GccDPInt32Opt/CHT/HeatTransferCoefficient.o Make/linux64GccDPInt32Opt/CHT/SinkTemperature.o Make/linux64GccDPInt32Opt/CHT/CHT.o Make/linux64GccDPInt32Opt/Adapter.o Make/linux64GccDPInt32Opt/preciceAdapterFunctionObject.o -L/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/platforms/linux64GccDPInt32Opt/lib \
    -lfiniteVolume -lmeshTools -lcompressibleTurbulenceModels -lincompressibleTurbulenceModels -L/home/<username>/software/boost/lib -L/data/scratch/<username>/software/petsc/arch-linux2-c-debug/lib -L  -L/data/scratch/<username>/OF-Adapter/ThirdParty-5.0/platforms/linux64Gcc/gperftools-svn/lib -L/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/platforms/linux64GccDPInt32Opt/lib/openmpi-system -L/data/scratch/<username>/OF-Adapter/ThirdParty-5.0/platforms/linux64GccDPInt32/lib/openmpi-system -L/usr/lib/openmpi/lib -L/home/<username>/OpenFOAM/<username>-5.0/platforms/linux64GccDPInt32Opt/lib -L/data/scratch/<username>/OF-Adapter/site/5.0/platforms/linux64GccDPInt32Opt/lib -L/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/platforms/linux64GccDPInt32Opt/lib -L/data/scratch/<username>/OF-Adapter/ThirdParty-5.0/platforms/linux64GccDPInt32/lib -L/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/platforms/linux64GccDPInt32Opt/lib/dummy -L/home/<username>/software/boost/lib -L/data/scratch/<username>/precice/build/last -L/data/scratch/<username>/software/petsc/arch-linux2-c-debug/lib  -L/data/scratch/<username>/precice/build/last -L -L -lprecice -lpetsc -lmpi_cxx -lboost_system -lboost_filesystem -lboost_log -lboost_log_setup -lboost_thread -lboost_program_options -lpthread -lpython2.7 -L -lyaml-cpp  -o /home/<username>/OpenFOAM/<username>-5.0/platforms/linux64GccDPInt32Opt/lib/libpreciceAdapterFunctionObject.so
/usr/bin/ld: Make/linux64GccDPInt32Opt/Utilities.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
Make/linux64GccDPInt32Opt/Utilities.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/data/scratch/<username>/OF-Adapter/OpenFOAM-5.0/wmake/makefiles/general:167: recipe for target '/home/<username>/OpenFOAM/<username>-5.0/platforms/linux64GccDPInt32Opt/lib/libpreciceAdapterFunctionObject.so' failed
make: *** [/home/<username>/OpenFOAM/<username>-5.0/platforms/linux64GccDPInt32Opt/lib/libpreciceAdapterFunctionObject.so] Error 1

We need to investigate this issue further. Since it was always working for me, I need some help to reproduce the error or locate the problem.

compileAndTest.py fails

Whilst following the instructions at https://github.com/precice/precice/wiki/Building, I successfully completed steps 1-4, but when I try to run the tests, I get an error (NB: I am running the tests in a virtual environment with python3.6) as shown below.

Running on deiban-buster.

I've tried uninstalling and reinstalling numpy (from within the environment), doing an aptitude upgrade and update, but I still get the same error.

Any suggestions as to what I am doing incorrectly?

(precice) samuel@prandtl:/usr/local/src/sources/precice-1.1.1$ ./tools/compileAndTest.py -t                  Removing ./tests
Creating ./tests
Running:  mpirun -n 4  ../build/last/testprecice --color_output
Running 225 test cases...
Running 225 test cases...
Running 232 test cases...
Running 225 test cases...
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xb
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xb
RuntimeErrorRuntimeError: module compiled against API version 0xc but this version of numpy is 0xb
ImportError: numpy.core.multiarray failed to import
ImportError: numpy.core.multiarray failed to import
ImportError: numpy.core.multiarray failed to import
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'sys' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'sys' is not defined
: module compiled against API version 0xc but this version of numpy is 0xbTraceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named TestAllAction
ImportError: No module named TestAllAction
NameError: name 'sys' is not defined

ImportError(3) 15:27:29 [action::PythonAction]:160 in initialize: ERROR: Could not load python module "TestAllAction" at path "/usr/local/src/sources/precice-1.1.1/src/action/tests/"!
(0) 15:27:29 [action::PythonAction]:160 in initialize: ERROR: Could not load python module "TestAllAction" at path "/usr/local/src/sources/precice-1.1.1/src/action/tests/"!
: ImportError: No module named TestAllAction
numpy.core.multiarray failed to import
(2) 15:27:29 [action::PythonAction]:160 in initialize: ERROR: Could not load python module "TestAllAction" at path "/usr/local/src/sources/precice-1.1.1/src/action/tests/"!
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'sys' is not defined
ImportError: No module named TestAllAction
(1) 15:27:29 [action::PythonAction]:160 in initialize: ERROR: Could not load python module "TestAllAction" at path "/usr/local/src/sources/precice-1.1.1/src/action/tests/"!
-------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

  Process name: [[23789,1],0]
  Exit code:    255
--------------------------------------------------------------------------

Check for (in)compressible solver type with Pressure dimensions

Currently, we check the solver type based on the registered IOobjects. This is a very indirect way to check for compressible vs incompressible vs basic solvers, but it is maybe a not-so-bad way to check for the available models (classes we can access).

openfoam-adapter/CHT/CHT.C

Lines 109 to 196 in c0f2881

std::string preciceAdapter::CHT::ConjugateHeatTransfer::determineSolverType()
{
// NOTE: When coupling a different variable, you may want to
// add more cases here. Or you may provide the solverType in the config.
std::string solverType;
// Determine the solver type: Compressible, Incompressible or Basic.
// Look for the files transportProperties, turbulenceProperties,
// and thermophysicalProperties
bool transportPropertiesExists = false;
bool turbulencePropertiesExists = false;
bool thermophysicalPropertiesExists = false;
if (mesh_.foundObject<IOdictionary>(nameTransportProperties_))
{
transportPropertiesExists = true;
DEBUG(adapterInfo("Found the transportProperties dictionary."));
}
else
{
DEBUG(adapterInfo("Did not find the transportProperties dictionary."));
}
if (mesh_.foundObject<IOdictionary>(turbulenceModel::propertiesName))
{
turbulencePropertiesExists = true;
DEBUG(adapterInfo("Found the " + turbulenceModel::propertiesName
+ " dictionary."));
}
else
{
DEBUG(adapterInfo("Did not find the " + turbulenceModel::propertiesName
+ " dictionary."));
}
if (mesh_.foundObject<IOdictionary>("thermophysicalProperties"))
{
thermophysicalPropertiesExists = true;
DEBUG(adapterInfo("Found the thermophysicalProperties dictionary."));
}
else
{
DEBUG(adapterInfo("Did not find the thermophysicalProperties dictionary."));
}
if (turbulencePropertiesExists)
{
if (thermophysicalPropertiesExists)
{
solverType = "compressible";
DEBUG(adapterInfo("This is a compressible flow solver, "
"as turbulence and thermophysical properties are provided."));
}
else if (transportPropertiesExists)
{
solverType = "incompressible";
DEBUG(adapterInfo("This is an incompressible flow solver, "
"as turbulence and transport properties are provided."));
}
else
{
adapterInfo("Could not determine the solver type, or this is not "
"a compatible solver: although turbulence properties are provided, "
"neither transport or thermophysical properties are provided.",
"error");
}
}
else
{
if (transportPropertiesExists)
{
solverType = "basic";
DEBUG(adapterInfo("This is a basic solver, as transport properties "
"are provided, while turbulence or transport properties are not "
"provided."));
}
else
{
adapterInfo("Could not determine the solver type, or this is not a "
"compatible solver: neither transport, nor turbulence properties "
"are provided.",
"error");
}
}
return solverType;
}

However, this is a complicated way and maybe it would be easier to just check for the dimensions of Pressure to distinguish between compressible and incompresible solver. After this check, we can check if it is a basic solver (e.g. laplacianFoam) or an of an unknown type.

For compresible solvers, the dimensions of Pressure are [1 -1 -2 0 0 0 0], while for incompressible [0 2 -2 0 0 0 0].

FSI: Support compressible solvers

At the moment, we compute forces in FSI/Force.C (at the FSI branch for now) assuming a constant density and viscosity. In order to support compressible solvers as well, we need to abstract these in a way similar to the KappaEffective for CHT.

An open question here is how to validate the compressible FSI, as I am not aware of any literature on this at the moment. In other words, we are looking for something similar to the Turek-Hron FSI benchmark for compressible solvers.

We already had some discussion on this with @JSeuffert. Do you maybe have anything to add here?

This is relevant to #7.

Just can't get it installed...

   Trying to install following https://github.com/precice/precice/wiki/Tutorial-for-FSI-with-OpenFOAM-and-CalculiX

   on Ubuntu 18.04 using parallels on mac.

   I get scon error saying undefined fftw_taint and fftw_ialignment_of, ffftw_join_taint 
   Also same error on openfoam-adapter.

  Please let me know what else you need. 
  Or just let me know what ubuntu version and the trial was tested.
  I have just followed the instructions on the tutorial but it didn't get me anywhere.

Create a module for fluid-structure interaction

In order to support mechanical fluid-structure interaction, we need a module similar to the one for conjugate heat transfer. The adapter also needs a few additions that can also be tested in this type of problem.

Roughly, the following sub-tasks are required:

  • Resize the data buffers for vector data (see the methods preciceAdapter::Interface::addCouplingDataWriter and preciceAdapter::Interface::addCouplingDataReader in the Interface.C.
  • Create the files FSI.H and FSI.C, similarly to the CHT.H and CHT.C. They should declare and define the methods configure(const YAML::Node adapterConfig), addWriters(std::string dataName, Interface * interface), and addReaders(std::string dataName, Interface * interface). These methods must be called in the Adapter.C in two places (see comments with NOTE). A distinction among different solver types may need to be defined (most probably different than the one for CHT). Everything should be in the FSI namespace.
  • Create dummies of the new boundary conditions or coupling data users. These classes need to inherit from the CouplingDataUser class and to define the write(double * buffer) and read(double * buffer) methods. They should be in the namespace FSI.
  • Create a second mesh (point-mesh) for reading the displacements.
  • Create an IOObject to store forces (for validation).
  • Implement the new coupling data users: Force.
  • Implement the new coupling data users: Displacement.
  • Create objects of the new coupling data users, according to the adapter's configuration file.
  • Add an option to enable the FSI module in the preciceAdapter::Adapter::configFileRead().
  • If any other types need to be checkpointed, add them in the preciceAdapter::Adapter::setupCheckpointing, preciceAdapter::Adapter::readCheckpoint, and preciceAdapter::Adapter::writeCheckpoint() methods and create the respective preciceAdapter::Adapter::addCheckpointField(...).
  • Implement reading and writing checkpoints. For the displacements, use movePoints().

Probably not needed:

  • Declare and create dummies of the virtual methods updateMesh(const mapPolyMesh& mpm) and movePoints(const polyMesh& mesh) in the preciceAdapterFunctionObject.H and preciceAdapterFunctionObject.C. What do they need to do inside the adapter? We probably need to update the interface nodes locations at the preCICE interface.
  • Implement the new Function Object methods.

After a first version is ready:

  • Update the Wiki page on configuration.
  • Update the Wiki page on compatibility with OpenFOAM solvers.
  • Create a tutorial.
  • Validate. (in the Master Thesis of Derek Risseeuw at TU Delft, to be submited)
  • Before merging, update the Adapter.H to set CHTenabled_ to false by default and update the tutorials and documentation.

See also the wiki page How to extend the adapter.

Docker container for the adapter with precice

Hi, I was wondering if the team is planning to add docker images some time soon. I found that @ludcila already created some docker container for her thesis. I created one for testing the adapter using Ubuntu 16.10-artful(since boost is pre-installed :) ). The link to the repository is:

precice-docker.

Would be happy to create a Pull request or feel free to use the docker files as the team feels fit. :)

I also observed that precice uses travis CI. It would be really practical if travis can build the Docker images and test on them so that new users can straight away use the image. Really practical with not much extra work I guess. What is your opinion?

Group the modules together to reduce code duplication

At the moment, when writing a new module, the developer has to write almost the same code in order e.g. to load the new module. If we created a list of modules and iterated onto them, we would make it easier to add a new module. At the end, we could even really allow to deliver modules as "plug-ins".

This is a good issue for anyone interested in design patterns, but it is also of low priority, since at the end we don't need many modules. I will try to tackle this issue after the FSI module is ready.

Problem running laplacianFoam

We tried to run laplacianFoam. Normally it should wait but it crashed with the following output:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  5.x                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 5.x-68e8507efb72
Exec   : laplacianFoam
Date   : Jan 08 2019
Time   : 13:14:19
Host   : "alex-desktop"
PID    : 1876
I/O    : uncollated
Case   : /home/alexander/Documents/Uni/ws18_19/Numerische_Simulation/Aufgaben/Exercise_04/resources_WS4/Solid_plate
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0


SIMPLE: no convergence criteria found. Calculations will run for 1 steps.

Reading field T

Reading transportProperties

Reading diffusivity DT

No finite volume options present


Calculating temperature distribution

---[preciceAdapter] The preciceAdapter was loaded.
Registered objects: 
14
(
points
neighbour
faces
fvSchemes
fvOptions
faceZones
fvSolution
owner
data
cellZones
boundary
T
pointZones
transportProperties
)

---[preciceAdapter] Reading the adapter's YAML configuration file /home/alexander/Documents/Uni/ws18_19/Numerische_Simulation/Aufgaben/Exercise_04/resources_WS4/Solid_plate/precice-adapter-config.yml...
---[preciceAdapter] [DEBUG] Checking the adapter's YAML configuration file...
---[preciceAdapter] [DEBUG]   participant : Solid
---[preciceAdapter] [DEBUG]   precice-config-file : precice-config.xml
---[preciceAdapter] [DEBUG]   interfaces : 
---[preciceAdapter] [DEBUG]   - mesh      : Solid-Mesh
---[preciceAdapter] [DEBUG]     locations : faceCenters
---[preciceAdapter] [DEBUG]     patches   : 
---[preciceAdapter] [DEBUG]       interface
---[preciceAdapter] [DEBUG]     write-data : 
---[preciceAdapter] [DEBUG]       Heat-Flux
---[preciceAdapter] [DEBUG]     read-data : 
---[preciceAdapter] [DEBUG]       Temperature
---[preciceAdapter] [DEBUG]     subcycling : 1
---[preciceAdapter] [DEBUG]     prevent early exit : 1
---[preciceAdapter] [DEBUG]     evaluate boundaries : 1
---[preciceAdapter] [DEBUG]     disable checkpointing : 0
---[preciceAdapter] [DEBUG]     CHT module enabled : 0
---[preciceAdapter] [DEBUG]     FSI module enabled : 0
--> FOAM Warning : 
    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 17
    Warning in the preCICE adapter: 
No module is enabled.
Time = 0.001

DICPCG:  Solving for T, Initial residual = 0.638918, Final residual = 8.36199e-07, No Iterations 15
DICPCG:  Solving for T, Initial residual = 0.528235, Final residual = 5.34424e-07, No Iterations 15
DICPCG:  Solving for T, Initial residual = 0.53699, Final residual = 5.54795e-07, No Iterations 15
ExecutionTime = 0.03 s  ClockTime = 0 s



--> FOAM FATAL ERROR: 
Error in the preCICE adapter: 
There was a problem while configuring the adapter. See the log for details.

    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 31.

FOAM exiting

The tutorial shipped with the openFoam adapter succeeds.
What could be the error?

precice-config.xml
precice-Fluid-events.log
precice-Fluid-eventTimings.log
precice-adapter-config.yml

Interface.C faceCenters triggers Wmaybe-uninitialized

Issue reported by @davidscn.

// Get the face centers of the current patch
const vectorField & faceCenters =
mesh.boundaryMesh()[patchIDs_.at(j)].faceCentres();
// Assign the (x,y,z) locations to the vertices
for (int i = 0; i < faceCenters.size(); i++)
{
vertices[verticesIndex++] = faceCenters[i].x();
vertices[verticesIndex++] = faceCenters[i].y();
vertices[verticesIndex++] = faceCenters[i].z();
}

The above part of Interface.C returns the following warning in some compilers:

g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam5/src/finiteVolume/lnInclude -I/opt/openfoam5/src/meshTools/lnInclude -I/opt/openfoam5/src/transportModels/ -I/opt/openfoam5/src/transportModels/compressible/lnInclude -I/opt/openfoam5/src/thermophysicalModels/basic/lnInclude -I/opt/openfoam5/src/TurbulenceModels/turbulenceModels/lnInclude -I/opt/openfoam5/src/TurbulenceModels/compressible/lnInclude -I/opt/openfoam5/src/TurbulenceModels/incompressible/lnInclude -I/usr/include/yaml-cpp -I/usr/include/eigen3  -I/home/imperator/precice/src/precice -I../ -DADAPTER_DEBUG_MODE -IlnInclude -I. -I/opt/openfoam5/src/OpenFOAM/lnInclude -I/opt/openfoam5/src/OSspecific/POSIX/lnInclude   -fPIC -c CHT/KappaEffective.C -o Make/linux64GccDPInt32Opt/CHT/KappaEffective.o
Interface.C: In member function ‘void preciceAdapter::Interface::configureMesh(const Foam::fvMesh&)’:
Interface.C:83:49: warning: ‘*((void*)&<anonymous> +8)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
             for (int i = 0; i < faceCenters.size(); i++)
                                 ~~~~~~~~~~~~~~~~^~
Interface.C:85:58: warning: ‘*((void*)&<anonymous> +16)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                 vertices[verticesIndex++] = faceCenters[i].x();
                                                          ^

I cannot reproduce this with g++ 5.4.0 (Ubuntu 16.04). The above is probably with g++ 7.3.0 / Ubuntu 18.04 (please, @davidscn, correct me if I am wrong).

This StackOverflow question may be helpful.

Wrong write time for functionObjectProperties in OpenFOAM.com

Issue reported by @derekrisseeuw, affecting at least OpenFOAM+ v1712 and v1806, but not affecting OpenFOAM 5.x or 6.

tl;dr: Empty entries in the results output are shown as "flickering" animation in ParaView.

The problem occurs when running a coupled implicit simulation where the openfoam write interval is larger than the coupling timestep. OpenFOAM will not only write a time at the defined 'write interval', but also at: time = write interval - coupling time

The only field that is written that time is uniform/functionObjects

Which contains the attached file, with no further information.

In terms of simulation this does not pose a problem, but for postprocessing it can be inconvenient. Also, I am not sure where this functionobject is written, but the fact that the time there is not updated might also be incorrect.

I actually first noticed this problem when running the CHT tutorial. Here the coupling time is 0.01s, and the writeInterval is 0.2s. Therefore I have timefolder 0, 0.19, 0.2, 0.39, 0.4, ... etc.

Even if this seems to be version-specific, maybe there is something wrong in the adapter, as well.

Support OpenFOAM v1812

Trying to built the adapter from the FSI branch with OpenFOAM v1812, I found at least the following error:

Making dependency list for source file Force.C
g++ -std=c++11 -m64 -DOPENFOAM=1812 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3  -DNoRepository -ftemplate-depth-100 -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/finiteVolume/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/meshTools/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/transportModels/ -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/transportModels/compressible/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/thermophysicalModels/basic/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/TurbulenceModels/turbulenceModels/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/TurbulenceModels/compressible/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/TurbulenceModels/incompressible/lnInclude -I/home/makish/inst/yaml-cpp/include  -I/home/makish/inst/precice/src/precice  -I../ -DADAPTER_DEBUG_MODE -IlnInclude -I. -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/OpenFOAM/lnInclude -I/home/makish/OpenFOAM/OpenFOAM-v1812/src/OSspecific/POSIX/lnInclude   -fPIC -c FSI/Force.C -o Make/linux64GccDPInt32Opt/FSI/Force.o
FSI/Force.C: In member function ‘virtual void preciceAdapter::FSI::Force::write(double*)’:
FSI/Force.C:65:91: error: conversion from ‘Foam::ITstream’ to non-scalar type ‘Foam::dimensionedScalar {aka Foam::dimensioned<double>}’ requested
     dimensionedScalar rho = mesh_.lookupObject<IOdictionary>("transportProperties").lookup("rho");
                                                                                           ^
/home/makish/OpenFOAM/OpenFOAM-v1812/wmake/rules/General/transform:34: recipe for target 'Make/linux64GccDPInt32Opt/FSI/Force.o' failed
make: *** [Make/linux64GccDPInt32Opt/FSI/Force.o] Error 1

I have not investigated this yet. Eventually, the OpenFOAM upgrade notes for developers could help.

Evaluating the boundaries after reading a checkpoint fails for some fields

In OpenFOAM, each cell has a value at the center, but it can also have values at its faces, for example for boundary cells.

It has been found that re-evaluating the faces of the interface cells after reading a checkpoint can help the stability of the solution. This is now done for (almost) all the checkpointed fields of type volScalarField and volVectorField, by default.

However, it looks like the way this is implemented causes problems for some fields. In particular for turbulent solvers that register the epsilon field, the field is checkpointed, but when trying to evaluate the boundaries, it cannot find it. More strangely, it requests another field:

--> FOAM FATAL ERROR: 

    request for volScalarField::Internal kEpsilon:G from objectRegistry region0 failed
    available objects of type volScalarField::Internal are

21
(
thermo:mu
thermo:psi
nut
K
K_0
h
p_rgh_0
rho
k
h_0
p_rgh
dpdt
gh
alphat
rho_0
p
T
p_0
thermo:rho
epsilon
thermo:alpha
)


    From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::DimensionedField<double, Foam::volMesh>]
    in file /home/ubuntu/OpenFOAM/OpenFOAM-5.x/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 193.

The methods involved are the preciceAdapter::Adapter::readCheckpoint() and the preciceAdapter::Adapter::setupCheckpointing(), which are implemented in the Adapter.C.

The object epsilon is a match when executing mesh_.lookupClass<volScalarField>().toc().

Currently, no object named epsilon is re-evaluated, in order to prevent unexpected errors. A warning is shown when adding fields to the list of checkpointed fields.

In order to reproduce this bug, do the following:

  1. In the Adapter.C, in preciceAdapter::Adapter::readCheckpoint(), comment the if ("epsilon" != volScalarFields_.at(i)->name()) and the two brackets.
  2. In the tutorial, edit the file Fluid/constant/turbulenceProperties and set simulationType to RAS (RASModel should be set to kEpsilon already).
  3. Run the tutorial starting the scripts runFluid and runSolid in different terminals. The fluid participant should crash when reading a checkpoint.
    Make sure to have built the adapter with -DADAPTER_DEBUG_MODE, in order to see the debug messages.

Advance is called before boundary data is written in parallel

When executing the openfoam adapter in parallel, the execute() function can call the precice advance before the boundary data has finished writing, which is done by the function writeCouplingData();

I noticed this when I put a
`std::cout << "some text";
in one of the coupling classes.

line 398

void preciceAdapter::Adapter::execute()
{
    if (errorsInConfigure)
    {
        // Handle any errors during configure().
        // See the comments in configure() for details.
        adapterInfo
        (
            "There was a problem while configuring the adapter. "
            "See the log for details.",
            "error"
       );
    }

    // The solver has already solved the equations for this timestep.
    // Now call the adapter's methods to perform the coupling.

    // Write the coupling data in the buffer
    writeCouplingData();

    // Advance preCICE
    advance();

Checkpointing the old fields and mesh

Field checkpointing
OpenFOAM uses various timeschemes which can use the old field and old old field.
<field>.oldTime() and <field>.oldTime().oldTime()
The correct value of these old fields is required for correct timestepping.

When writing the checkpoint, pointers to the old fields are actually saved, but when reading the checkpoint these are not automatically updated. Therefore, this must be performed explicitly in the adapter. In the Adapter.C I added the following lines for all fields. (here for the volScalarFields, line 1260)

        int nOldTimes(volScalarFields_.at(i)->nOldTimes());
        if (nOldTimes >= 1)
        {
            volScalarFields_.at(i)->oldTime() == volScalarFieldCopies_.at(i)->oldTime();        
        }
        if (nOldTimes == 2)
        {
            volScalarFields_.at(i)->oldTime().oldTime() == volScalarFieldCopies_.at(i)->oldTime().oldTime();
        }

In the openfoam sourcecode there is one mention of the oldTime().oldTime().oldTime(), but this is used for a structural solver. Therefore I only include two 'layers'.

Mesh checkpointing
A similar approach can be taken for the mesh update. When the function movepoint is called on line 764, the pointer to the mesh.oldPoints() is reset to the current mesh.

const_cast<fvMesh&>(mesh_).movePoints(meshPoints_);
This leads to a reversion of the points of the mesh in time, which is not physical.
therefore I added the pointer to the old mesh in a checkpointed field, which is read later in the reloadMeshPoints function:

void preciceAdapter::Adapter::storeMeshPoints()
{
    DEBUG(adapterInfo("Storing mesh points..."));
    // TODO: In foam-extend, we would need "allPoints()". Check if this gives the same data.
    meshPoints_ = mesh_.points();
    oldMeshPoints_ = mesh_.oldPoints();
    DEBUG(adapterInfo("Stored mesh points."));
}

void preciceAdapter::Adapter::reloadMeshPoints()
{
    // In Foam::polyMesh::movePoints.
    // TODO: This function overwrites the pointer to the old mesh. Therefore, if you revert the mesh, the oldpointer will be set to the points, which are the new values. 
    DEBUG(adapterInfo("Moving mesh points to their previous locations..."));
    const_cast<fvMesh&>(mesh_).movePoints(meshPoints_);
    const_cast<pointField&>(mesh_.oldPoints()) = oldMeshPoints_;
    DEBUG(adapterInfo("Moved mesh points to their previous locations."));
}

Please leave any feedback on the validity of this approach. I am curious to other users experience with this issue.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.