Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turek & Hron FSI3 with CalculiX and OpenFOAM #304

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

JoSchrdr
Copy link

Turek & Hron FSI3 with CalculiX and OpenFOAM.

NOTE: Force instead of Stress (like it's in the tutorial with deal.ii)

@MakisH
Copy link
Member

MakisH commented Nov 12, 2022

Thank you! 😄

Is there a particular reason this is a separate PR than #300? Ideally, I would close this one and continue contributing to #300.

What is different in the fluid-openfoam case?

@JoSchrdr
Copy link
Author

In almost every file of the fluid-openfoam case something little is different. That is why I've opened another pull request.

It is a bit hard to get everything running with the openfoam files that are meant for deal.ii ...
Even the BlockMeshDict has a little change that is important for CalculiX.

@MakisH
Copy link
Member

MakisH commented Nov 13, 2022

In almost every file of the fluid-openfoam case something little is different.

Even the BlockMeshDict has a little change that is important for CalculiX.

Could you please compare and comment on these changes? We need to understand those to be able to merge it. Such documentation will help a lot the future readers.

It is a bit hard to get everything running with the openfoam files that are meant for deal.ii ...

Still, if we understand the changes and the motivation behind them, we may be able to adapt the OpenFOAM case so that it works with both deal.II and CalculiX as a structure solver. I assume the most important setting will be to use the same material model in both deal.II and CalculiX.

@JoSchrdr
Copy link
Author

I'm afraid I won't do that, because I've already given you my files, which is a great asset for you. I also have other things to do than comment on every single change (which apparently works) that I have done. Some effort on your part would be appreciated.

@MakisH
Copy link
Member

MakisH commented Nov 24, 2022

I'm afraid I won't do that, because I've already given you my files, which is a great asset for you. I also have other things to do than comment on every single change (which apparently works) that I have done. Some effort on your part would be appreciated.

I understand that it probably took you too long to make the case converge, as well that you have already completed the respective project and you may not remember everything. I also understand that it took you time to convert from the preCICE v1.x config to the v2.x (with v3.x coming soon). However, it is important for us and for many users to know why these changes are important. Some of them look very cryptic (such as the fvSchemes and fvSolution), as they probably took a lot of work and educated guess to figure out. Some other, however, are not clear.

We are trying to maintain the same structure in all tutorials and avoid duplication as much as possible. It took us already a lot of effort to merge many similar tutorials we had in the past, and we don't want to deviate unless absolutely necessary. Maybe with some work we can merge this one with the turek-hron-fsi3 case. If you cannot invest more time working on this, this is completely fine and your contribution to this open-source project is of course still very welcome. It will just be more difficult to reach the community if we do not manage to merge it to the main branch. We have had this issue already with other contributions, in which cases people try to figure out what has changed in between, but eventually someone picks them up and completes the review, in which case we merge the updated contributions.

I used meld to check the differences between the two tutorials:

  • There is no 0/ directory. run.sh copies it from 0.orig, which is not included. Due to this, I cannot run the case.
  • run.sh runs a checkMesh and a potentialFoam before running the solver. I assume that potentialFoam helps the simulation converge, but I don't understand why do that since we are copying from a 0.orig/.
  • system/blockMeshDict uses a thinner mesh on the z-direction, which is still only one cell. The order of the blocks seems changed. I don't understand the motivation here.
  • in the system/controlDict, the endTime is longer (why?), the deltaT is half (why?). writePrecision and timePrecision are lower (why?), and the forces function object is configured differently.
  • in the decomposeParDict, fewer domains are defined and a different decomposition method is defined. I assume you had to run this on a laptop, which is totally fine, but we can still use the same settings here and we can try running on a cluster.
  • system/fvSchemes changes:
    • ddtSchemes from default backward; to default Euler;
    • gradSchemes from default cellLimited Gauss linear 1; to default Gauss linear;
    • divSchemes from div(phi,U) Gauss linearUpwind grad(U); to div(phi,U) Gauss limitedLinear 1;
  • system/fvSolution changes most of the options:
    • relaxes most rollerances (I assume because stricter tollerances would take more time, which would need more cores to run on)
    • defines a DIC preconditioner for the pressure
    • reduces the number of PIMPLE iterations
  • system/preciceDict changes from Stress to Force (same as in Turek & Hron FSI3 solid-calculix #300, but I understand you wanted to change it - now I see why this is not easy, but this was not mentioned so far).
  • The precice-config.xml looks like it is mostly identical to the old FSI/cylinderFlap/OpenFOAM-deal.II tutorial, adjusted for preCICE v2.x:
    • changes from Stress to Force
    • renames the Fluid-Mesh-Centers to Fluid-Mesh-Faces (why?)
    • changes from parallel-implicit to serial-implicit
    • uses different acceleration and convergence parameters
  • adds an allrun.sh and a cleanAll.sh, probably similarly to the old Allrun and Allclean (see the tutorial structure guidelines)
  • the CalculiX run.sh hard-codes the ccx_preCICE path. I assume this was not intended.

This list is already too detailed, I was mainly looking for a summary to know where to look at, but I hope it helps understand what is different.

It looks like the CalculiX adapter does not support stress data. In this context, and considering that nobody is currently working towards that direction, I think that offering a new tutorial based on forces is fine. But we should make it as much as possible similar to the existing one.

An important decision here is if we want to offer this as a coarser option that one can run on a laptop, assuming lower accuracy. But I would trust the experience and suggestions of @davidscn on that.

As next steps, I would suggest (to you or to anyone else that wants to pick this up):

  1. Replace the fluid-openfoam directory with the one from the turek-hron-fsi3 tutorial.
  2. Text-replace Stress to Force everywhere, and convert the mapping from consistent to conservative.
  3. Apply only the changes we actually need. If we decide to keep it with 25 processes as default, we should try whether the already set parameters still work. These already took a lot of effort from @davidscn to define. If we decide to offer this as a lightweight case, then we can probably use most of the fvSchemes/fvSolution.
  4. Follow the tutorial structure guidelines for the formal details.

P.S.: Please also understand that we/I also have a lot to do and I am sorry if somehow you got the impression that we/I don't value your time. Reviewing contributions from the community takes a lot of effort from our side (already >2h to understand the situation and write this message), which I can only invest in specific times. Before I have the chance to invest a long block of time on a review, I want to have all the information I need. That's why I prefer to answer quickly to people willing to help (such as you), to help them proceed with any easy fixes when they have time to do so, so that I can carefully look at the contribution when I can devote some time to it. In this context, it also would make it easier for me if we continued in one of the two PRs. In any case, I can take over specific tasks that may be easier for me than you.

Contributing to open-source is difficult and takes a lot of effort both from the contributor and the maintainers. I understand that most of the preCICE users are not familiar with the process. I am very happy to help, but this will take time, which I completely understand if you cannot invest. And if you can invest time only in a specific period, I can try to block that period in my calendar, or get reinforcements.

@precice-bot
Copy link
Collaborator

This pull request has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/what-is-the-difference-between-fluid-transfer-to-solid-force-and-stress-when-solving-fsi/1834/4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants