Hello, everyone!
I’m calculating a 3D fluid-solid coupling problem where the cube-fluid region contains a small solid-cube region entirely in the center.The case is performed by openfoam for fluids and caculix for solids.
The fluid mesh is about 8 million and the solid mesh is about 40,000.
There is only one interface between the fluid and the solid (where data is exchanged), and the geometry and mesh of the fluid and the solid are the same on that interface.There are 10,000 meshes on the interface.
The nearest-neighbor mapping is used for the data mapping method.
Here are the precice configuration file
precice-config.xml (2.6 KB)
and the openfoam log file
logfluid.log (5.8 MB)
Here’s the problem: openfoam takes up very little time in each step of the computation (roughly 3.5%), and much of the rest of the time is spent exchanging and mapping data.
Any suggestions for improving the long time data exchange and mapping issues I appreciate! If there is no solution, is this a limitation of precice that only a smaller case can be caculated?
Thank you!
Hi,
You are running a Release build with nearest-neighbour mappings. These mappings are so fast, that they should be bare measurable. See the mapping section in the reference paper for result of much larger meshes.
Your (active) interface contains 14785 vertices, which really shouldn’t be an issue.
---[precice] WARNING: 14785 of 21008 vertices of mesh Solid-Mesh have been filtered out since they have no influence on the mapping.
Communication can be difficult to analyse, as it includes more than data exchange. As you are using a parallel scheme, your solvers should ideally have the same overall runtime per time-window. Also note that acceleration is computed on the second solver (Solid), which introduces an additional latency until it can send data back to your first solver (Fluid).
I recommend reducing the runtime of the test case to a few time windows and enabling the preCICE-internal profiling. Then use a trace viewer to analyse the data. This should give you a much better understanding of the overall situation.
See the chapter Tooling > Performance analysis in the archived documentation on page 193.