# Collapsible Tube (OpenFOAM+CalculiX) **URL:** \ **Category:** Official adapters and tutorials\ **Tags:** openfoam, calculix, fsi\ **Created:** [March 20, 2023, 3:50pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334 "2023-03-20T15:50:59Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [March 30, 2023, 10:03am UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/21 "2023-03-30T10:03:38Z")
> [@mishal49](#): > > I did however, try taking the elastic pipe and imposing the same boundary conditions. Good strategy! You could even use ASTE to mock the other participant: [Artificial Solver Testing Environment (ASTE) | preCICE - The Coupling Library](https://precice.org/tooling-aste.html#replay-mode) (even though it currently only works with explicit schemes). > [@mishal49](#): > > The case ran fine so this brings me to question whether the mesh types of the fluid and solid matter. Do they have to be the same type? No. The participants know nothing about each other’s internals (including their mesh) and you don’t need conforming meshes on the interface: that’s what data mapping is for. > [@mishal49](#): > > Do they have to be coarse because a finer mesh might be more likely to get twisted? Generally, the mesh resolution is defined by the needs of the solvers themselves. Most commonly, we use much finer fluid meshes than solid meshes, just because usually flows are much more complex than solid dynamics. > [@mishal49](#): > > Do I change the solver in dynamicmeshdict based on my mesh types maybe? This is indeed a much more important point. By default, we use displacementLaplacian in our OpenFOAM tutorials, which is a rather simple mesh motion solver, that does not perform so well. But it just works most of the time. If your mesh gets too skewed, then you could try, e.g., RBFMeshMotionSolver: [Mesh Solver OpenFOAM Error - #10 by Makis](https://precice.discourse.group/t/mesh-solver-openfoam-error/1130/10) ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [March 30, 2023, 4:14pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/22 "2023-03-30T16:14:33Z")
Thank you @Makis. I corrected this and the one-way FSI still diverges. [calculix.out](https://precice.discourse.group/uploads/short-url/3hDzUtERimDUOqBTbE1koaVIgop.out) (9.2 KB) [foam.out](https://precice.discourse.group/uploads/short-url/vw6jlPilDBjwvFojrKEWDxrqmMv.out) (7.1 KB) [preciceDict.txt](https://precice.discourse.group/uploads/short-url/qERWwmdjm41qH7ROr4IaVLhxHSG.txt) (459 Bytes) [precice-config\_t.xml](https://precice.discourse.group/uploads/short-url/u830t4sDejor5T4n79w8H2cw76l.xml) (2.5 KB) [config.yml](https://precice.discourse.group/uploads/short-url/lGdGGc15jbDrtj5iCdsux1vFwTx.yml) (242 Bytes) ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [March 30, 2023, 7:41pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/23 "2023-03-30T19:41:38Z")
Why are you not exchanging and reading displacements in the fluid side? Note that you need `DisplacementDelta` (displacements relative to the last coupling time window), in contrast to `Displacement` (relative to the original reference point). Which brings me to the question: does the fluid simulation itself (without coupling, since anyway OpenFOAM does not read anything) converge? ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 14, 2023, 4:37pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/24 "2023-04-14T16:37:38Z")
Hi @Makis Sorry for the delayed response. The simulation runs well with the fluid side alone. I did manage to get the coupling to work by regenerating the meshes with fewer software packages. Maybe the import from one software to another led to more mesh discrepancies than expected. However, the weird thing is that the case diverges at a certain point in time and the displacements in the x direction look like they are only happening on 3/4ths of the tube (Shown below). One side: ![image](https://global.discourse-cdn.com/free1/uploads/precice/original/2X/4/40b38857c33a4885a7484178b9cc8244a1c6a99a.png) Other side: ![image](https://global.discourse-cdn.com/free1/uploads/precice/original/2X/2/28d2855f6e945a04b8beef6522682b83214a8263.png) I tried to check if maybe my nodesets in CalculiX were only defining 3/4th of the pipe, but this is not the case. Would appreciate any help. ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [April 26, 2023, 11:11am UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/25 "2023-04-26T11:11:41Z")
> [@mishal49](#): > > However, the weird thing is that the case diverges at a certain point in time and the displacements in the x direction look like they are only happening on 3/4ths of the tube (Shown below). I am not sure I understand what you expected to see in the figure and what you see at the moment. If this is indeed an issue, then it probably has something to do with the definition of the coupling interface. Maybe try exporting the coupling mesh from preCICE and visualize it: > **[Export configuration | preCICE - The Coupling Library](https://precice.org/configuration-export.html)** > > You can export your coupling meshes to various formats. This is a great feature for debugging as you can monitor how preCICE maps and exchanges data. On this page, we explain how to configure such exporters. The observation that the case eventually diverges is not surprising: even if everything in the setup is fine (check the above point), there are often aspects you can tune in the configuration. Have you modified the configuration to also read displacements, as I wrote in [Collapsible Tube (OpenFOAM+CalculiX) - #23 by Makis](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/23)? If yes, could you upload the config and any further logs, such as the preCICE `iterations.log`, `convergence.log`, and the logs of the solvers? ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 27, 2023, 2:45pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/26 "2023-04-27T14:45:38Z")
Hi @Makis I adding the export lines to my precice-config however it says: > —[preciceAdapter] Loaded the OpenFOAM-preCICE adapter - v1.1.0 + unreleased changes. > MPI startup(): PMI server not found. Please set I\_MPI\_PMI\_LIBRARY variable if it is not a singleton case. > —[preciceAdapter] Reading preciceDict… > —[precice] ERROR: The configuration contains an unknown tag export:vtu. [precice-config.xml](https://precice.discourse.group/uploads/short-url/fFdYyyeW3IYD4vtR76U88N0Fk9P.xml) (2.7 KB) ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 27, 2023, 2:46pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/27 "2023-04-27T14:46:07Z")
> [@Makis](#): > > Have you modified the configuration to also read displacements, as I wrote in [Collapsible Tube (OpenFOAM+CalculiX) - #23 by Makis](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/23)? You mean this for one-way FSI correct? ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 27, 2023, 3:13pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/28 "2023-04-27T15:13:50Z")
it works for export:vtk/ but not vtu ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 27, 2023, 4:11pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/29 "2023-04-27T16:11:19Z")
I used the visualization and if I am not mistaken it is just like visualizing the mesh at any timestep. The case does not even get through the first iteration and then diverges. ![image](https://global.discourse-cdn.com/free1/uploads/precice/original/2X/f/f8d03c11d47b98c15c3f4f8b89686d9ae6efa744.jpeg) This is what the forces look like for the fluid-mesh-face-fluid after 1st iteration. What configurations do you suggest I tune to get the case to converge? Is it more of a trial and error? ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [April 28, 2023, 6:57am UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/30 "2023-04-28T06:57:05Z")
> [@mishal49](#): > > I adding the export lines to my precice-config however it says: This looks more like an system-specific execution issue, which I assume you solved already. Can you reproduce it? > [@mishal49](#): > > You mean this for one-way FSI correct? While one-way coupling is a natural first step when setting up a simulation, I would not expect a one-way FSI to converge. But this diverges too early, which hints an issue with the configuration. Looking at your `precice-config.xml`: ```xml ``` The `preciceDict` you posted above: ```plaintext interfaces { Interface2 { mesh Fluid-Mesh-Faces; patches (interface); locations faceCenters; readData ( ); writeData ( Force ); }; }; ``` The `config.yml` you posted above: ```yaml participants: Solid: interfaces: - nodes-mesh: Solid-Mesh patch: interface read-data: [Force] write-data: [DisplacementDelta] ``` Some observations: - You are (correctly) exchanging both force and relative displacement, but (based on the `preciceDict` I saw before) you are not reading those displacements. - You are writing displacements from CalculiX, but not reading them in OpenFOAM, which looks unmotivated. - You are (correctly) using an implicit coupling scheme, but this requires a bi-directional coupling to work, as it is based on iterations and corrections. If one participant always gives the same values, preCICE will complain. When you say “it diverges”, what exactly do you mean? Who is “it” and what errors / logs are you getting? > [@mishal49](#): > > I used the visualization and if I am not mistaken it is just like visualizing the mesh at any timestep. Correct. But this is, in this case, important to check that the definition of the mesh is correct. You previously observed that CalculiX was “only defining 3/4th of the pipe”. Do the Solid exports confirm this observation? Are the nodes there and always with the same results, or simply not there? I don’t know how the results are expected to look like, but if you are applying a pulse at the inlet (as we do in [Elastic tube 3D | preCICE - The Coupling Library](https://precice.org/tutorials-elastic-tube-3d.html)), it is normal that the values near the outlet will stay constant for a few time steps. > [@mishal49](#): > > What configurations do you suggest I tune to get the case to converge? Is it more of a trial and error? Make it first bi-directional, we are not yet at the point that it needs fine-tuning. The coupling scheme and acceleration method you have selected are appropriate, but the convergence measures may be a bit too relaxed. There are a few more parameters in the acceleration, which would need looking closer into the case. The mapping also looks reasonable. ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 28, 2023, 4:20pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/31 "2023-04-28T16:20:40Z")
Thank you for your response. > [@Makis](#): > > This looks more like an system-specific execution issue, which I assume you solved already. Can you reproduce it? Yes, the command works when I use the tag export:vtk however, it gives the error when I change to export:vtu. Maybe the cluster system does not have anything for vtu files I am guessing. > [@Makis](#): > > When you say “it diverges”, what exactly do you mean? Who is “it” and what errors / logs are you getting? The case diverges on the fluid side first and looks like a timestep continuity error. Please find attached the log files for the fluid and solid side. [foam.out](https://precice.discourse.group/uploads/short-url/LBEAkHWgB9LHfKgghcG8sIebyN.out) (72.1 KB) [calculix.out](https://precice.discourse.group/uploads/short-url/r5YsmxEDEXuhQT7eDMIabJeMgBm.out) (56.7 KB) I have the output files for the interface if you would like those as well > [@Makis](#): > > CalculiX was “only defining 3/4th of the pipe”. Do the Solid exports confirm this observation? Are the nodes there and always with the same results, or simply not there? This one was a wrong case setup. I had the scales off for the two sides which is why it gave me that error regardless, of the boundary conditions used. I corrected this and the case is back to diverging after the first timestep. Sorry for forgetting to clarify this. > [@Makis](#): > > I don’t know how the results are expected to look like, So, all the precice files are exactly like the tutorial elastic 3d case, however, the meshes and tube sizes are obviously different. Also, my boundary conditions are not the same as the tutorial. I have a fixed value velocity inlet and a fixed value pressure outlet. The case is supposed to align with experimental data and the pipe should stay almost intact with no displacement, i.e. the cross section should still be circular. Once I have this confirmed I can move on to higher displacement cases. The fluid side works perfectly fine alone. I would be happy to attach the updated case if it is needed. * * * > [@Makis](#): > > ome observations: > > - You are (correctly) exchanging both force and relative displacement, but (based on the `preciceDict` I saw before) you are not reading those displacements. > - You are writing displacements from CalculiX, but not reading them in OpenFOAM, which looks unmotivated. > - You are (correctly) using an implicit coupling scheme, but this requires a bi-directional coupling to work, as it is based on iterations and corrections. If one participant always gives the same values, preCICE will complain. Oh I understand now. Let me change this and get back to you. ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [April 28, 2023, 6:34pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/32 "2023-04-28T18:34:50Z")
> [@Makis](#): > > - You are (correctly) exchanging both force and relative displacement, but (based on the `preciceDict` I saw before) you are not reading those displacements. > - You are writing displacements from CalculiX, but not reading them in OpenFOAM, which looks unmotivated. > - You are (correctly) using an implicit coupling scheme, but this requires a bi-directional coupling to work, as it is based on iterations and corrections. If one participant always gives the same values, preCICE will complain. I changed this. Please find attached the preciceDict, precice-config.xml and config.yml files: [preciceDict.txt](https://precice.discourse.group/uploads/short-url/4U3eRBUFdke59eYOlxRp272a09I.txt) (700 Bytes) [precice-config.xml](https://precice.discourse.group/uploads/short-url/m002KeMJDucC1fCXiacSXivIWNL.xml) (2.9 KB) [config.yml](https://precice.discourse.group/uploads/short-url/5L4Hktm9wh1dt5DrkJU3MY37lbp.yml) (249 Bytes) The case still diverged after the first timestep. Please find attached output files: [foam.out](https://precice.discourse.group/uploads/short-url/RSCBQkVX2FBNeCPLKlrAxZR1Ea.out) (70.4 KB) [calculix.out](https://precice.discourse.group/uploads/short-url/bD3Y8us0wvq1HGbjgqXjHe9ERSd.out) (56.7 KB) ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [May 9, 2023, 1:36pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/33 "2023-05-09T13:36:37Z")
I noticed something in my solid mesh; I generate.nam, .sur and . msh files using cgx. I make my mesh in prePoMax and then run commands like ‘send all abq’ etc to generate precice required files. The original file ([solidtube.inp](https://precice.discourse.group/uploads/short-url/iUvNSDXRYLiaLSxat8BdtY5uXJY.inp) (730.8 KB)) results in a complete interface as shown however, when I split the file up into .nam files and a manually made .sur file, the mesh looks like the second image. ![image](https://global.discourse-cdn.com/free1/uploads/precice/original/2X/f/f43420da21ecab806a7523ea4fdd3185ac97cb35.png) I noticed that the .sur file generated by cgx is not the same as the .sur file in the elastic tutorial case which is why I copy and paste sets manually to make the .sur file identical to the tutorial format. I guess that could be the issue. Do you maybe know how to generate those files without ruining with the original mesh? ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [May 9, 2023, 2:35pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/34 "2023-05-09T14:35:21Z")
Unfortunately, my CalculiX knowledge has reached its limits here… 😕 But this could be a nice question for [https://calculix.discourse.group/](https://calculix.discourse.group/) ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [May 14, 2023, 6:17pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/35 "2023-05-14T18:17:53Z")
I have tried asking this on the ccx platform, but this is more of a preCICE file configuration issue which is why I was not really able to get an answer. ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [May 15, 2023, 4:26am UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/36 "2023-05-15T04:26:32Z")
> [@mishal49](#): > > I noticed that the .sur file generated by cgx is not the same as the .sur file in the elastic tutorial case which is why I copy and paste sets manually to make the .sur file identical to the tutorial format. I am referring to this part, not the complete preCICE-related topic. Did you focus your question on this in the CalculiX forum? It is understandable that CalculiX users may overlook the topic if it seems to be preCICE-specific. ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [May 18, 2023, 5:10pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/37 "2023-05-18T17:10:24Z")
Hello @Makis Yes, I had a conversation with a calculix user about this specific .sur file format issue. The .sur file generated by CCX looks like this: [Sinterface.sur](https://precice.discourse.group/uploads/short-url/q2Fe2ibvnz6W5813acnq668HHn1.sur) (23.7 KB) However, the one used in the 3D elastic pipe tutorial is: [interface.sur](https://precice.discourse.group/uploads/short-url/70njpX8iKOISHiw3UOdhgomd9fo.sur) (7.8 KB) Hence, the question arises, why does preCICE have that specific format and how can it be generated without resulting in mesh distortion? Even though I can switch to a different mapping technique, some cases need the application of a distributed load in Calculix, which also needs a surface file. As we try to figure this out, I switched my mapping technique to rbf-compact-tps-c2, which does not use any surface files, and the case has now coupled. I am still looking into the validity of results but so far it is coupling well and diverges after a bit, when a pressure wave hits, I think? Not sure and would love to get some clarity on this. ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [May 19, 2023, 7:47am UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/38 "2023-05-19T07:47:52Z")
> [@mishal49](#): > > Yes, I had a conversation with a calculix user about this specific .sur file format issue. Linking to that conversation could be useful for the future reader. > [@mishal49](#): > > The .sur file generated by CCX looks like this: [Sinterface.sur](https://precice.discourse.group/uploads/short-url/q2Fe2ibvnz6W5813acnq668HHn1.sur) (23.7 KB) > However, the one used in the 3D elastic pipe tutorial is: [interface.sur](https://precice.discourse.group/uploads/short-url/70njpX8iKOISHiw3UOdhgomd9fo.sur) (7.8 KB) > Hence, the question arises, why does preCICE have that specific format and how can it be generated without resulting in mesh distortion? Even though I can switch to a different mapping technique, some cases need the application of a distributed load in Calculix, which also needs a surface file. I honestly have no idea about preparing CalculiX cases and the choices here… 🤷‍♂️ I think that @KyleDavisSA created this case (with Salome, if I am not mistaken). It could also be related to the nearest-projection mapping that the case uses and demonstrates. > [@mishal49](#): > > As we try to figure this out, I switched my mapping technique to rbf-compact-tps-c2, which does not use any surface files, and the case has now coupled. I am still looking into the validity of results but so far it is coupling well and diverges after a bit, when a pressure wave hits, I think? Not sure and would love to get some clarity on this. Great! The RBF mapping is definitely a good choice. Regarding the divergence when the pressure hits, it is probably time to tune the acceleration. Could you please upload your current `precice-config.xml`? ---
**Author:** ![mishal49](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mishal49](https://precice.discourse.group/u/mishal49)\ **Post date:** [May 19, 2023, 3:03pm UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/39 "2023-05-19T15:03:30Z")
Unfortunately, I had this conversation in person and therefore, do not have a written version. I have started a topic on the CalculiX platform and will see if I can get something more helpful for other users. Please find attached the file:[precice-config.xml](https://precice.discourse.group/uploads/short-url/iPXzTK7kJqIHjV6CCSF5G7qVxqf.xml) (2.7 KB) Should I change the relaxation factor perhaps? ---
**Author:** ![uekerman](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/uekerman/32/2199_2.png) [@uekerman](https://precice.discourse.group/u/uekerman)\ **Post date:** [May 22, 2023, 9:53am UTC](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334/40 "2023-05-22T09:53:42Z")
You could add a `filter` to your acceleration: ```xml ``` Complete coupling scheme: ```xml ``` Otherwise, the configuration looks good enough for a first try. Could you please upload your iterations and convergence files (or did I overlook these?)? > **[Output files | preCICE - The Coupling Library](https://precice.org/running-output-files.html)** > > During runtime, preCICE writes different output files. On this page, we give an overview of these files and their content. [Previous page](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334.md?page=1) [Next page](https://precice.discourse.group/t/collapsible-tube-openfoam-calculix/1334.md?page=3)