[bigphil]

Comments and questions are welcomed on the article Chourdakis et al, OpenFOAM-preCICE: Coupling OpenFOAM with external solvers, OpenFOAM Journal, February 2023, https://doi.org/10.51560/ofj.v3.88.

[MakisH]

The article is now online! Thank you very much to the editors and all five reviewers for their hard work and extensive feedback. We would be very happy for further questions and feedback here.

[ancolli]

I have read your article and it is really interesting. I have two minor questions:


a) In the partitioned and conjugated heat transfer examples, you have used a Dirichlet-Newman coupling. A few years ago, for a similar problem, I found that this was a faster method than the harmonic averaging already implemented in the chtMultiregionFoam. However, with the Dirichlet-Newman coupling, I found some convergence problems depending on the relative difference of the conductivities on each side (electrical problems with a good and a bad conductor). Is there an easy way to implement harmonic averaging to be included in the adapter, or is it the Robin-Robin coupling that you are referring to in section 7.1?

b) My second question is about the future. I saw on the webpage that the supported versions of the OpenFOAM Foundation are from v4 until the latest one (10). Additionally, for the upcoming version (11), there are huge changes from solvers to modular solvers (https://cfd.direct/openfoam/free-sof...dular-solvers/) that will facilitate the coupling between solvers. b1) Will you also support the new versions of the OpenFOAM Foundation, or will the new redesign make it complicated?

b2) Additionally, and somewhat related to the previous question, with OpenFOAM 11 already allowing modular solvers, and ignoring the extremely important issue that your utility can be coupled to external solvers, can you identify any benefits of your approach being used with the new versions of the OpenFOAM Foundation?

I hope my question is not misinterpreted. I am simply trying to understand the possibilities with a knowledge that is much less than yours.

Kind regards and congratulations on your work

[MakisH]

Hi @ancolli,

thank you for the very interesting questions, and I am sorry for the delay: the past few weeks have been quite chaotic.

a) From what I understand, and looking at the respective boundary condition [1], chtMultiRegionFoam does implement a Robin-Robin coupling. OpenFOAM-preCICE supports both Dirichlet-Neumann, as well as Robin-Robin coupling, and there is an example tutorial for that [2]. In the Robin-Robin coupling approach, the two participants exchange sink temperature and heat transfer coefficient. You can read more in an earlier master's thesis that focused on CHT with OpenFOAM and preCICE [3].

b1) We try to support both the Foundation and the OpenCFD variants, and we try to support as many of their versions as possible. This is for pragmatic reasons, as people often only have an older OpenFOAM version installed in their institution's workstation/cluster. Since the different variants have different policies on backwards compatibility at the API level, we struggle a lot maintaining compatibility with multiple Foundation versions, while we usually don't need any changes to support newer OpenCFD versions. So far, we have managed to support all recent Foundation versions as well, each on a separate branch, but with a significant delay and crucial help from the community. If you depend on the Foundation version, you can definitely help us prepare a branch for OpenFOAM 11 (based on the one for OpenFOAM 10). Note that, in contrast to, e.g., swak4Foam, we support different versions in different branches, not with macros, to have more isolated changes. You can work on porting to any new version, without interfering with the main branch. We rebase the version-specific branches onto each new adapter release.

b2) Is there already some documentation regarding this feature? I assume that "modular solvers" still means "solvers written in OpenFOAM", so this would again fall into the "internal coupling" category described in section 2.1 of this paper. Coupling to external codes remains, as well as all the features that preCICE itself brings as a coupling library (IQN acceleration, RBF and further mappings, etc). Many of these features could one day be ported to OpenFOAM itself if there is a strong-enough reason to, but I would argue that they are already there via OpenFOAM-preCICE.

Thank you very much for your questions and sorry once again for the delay. I hope these questions are now answered, please keep more coming! :-)

Best regards,
Gerasimos

[1] turbulentTemperatureCoupledBaffleMixedFvPatchScala rField: https://www.openfoam.com/documentati...d.html#details
[2] Heat exchanger tutorial: https://precice.org/tutorials-heat-exchanger.html
[3] Lucia Cheung Yau. Conjugate heat transfer with the multiphysics coupling library preCICE. Master’s thesis, Department of Informatics, Technical University of Munich, 2016. Available: http://www5.in.tum.de/pub/Cheung2016_Thesis.pdf

[ancolli]

Do not worry about the delay, I am not in a hurry. I just want to understand and see future usage possibilities.

a) Yes, I think that we are talking about the same thing. The "harmonic average" is something that I took from line 177 [1], maybe I misunderstood the name. I went to the thesis, and on page 20, there is a more complicated (iterative) way to solve it, but it seems to be the same in the end. However, in the tutorial you provided, it is implemented exactly as in the CHT. Thanks for your help and time!

b) Are solvers written in OpenFOAM but in a "modular" way

https://cfd.direct/openfoam/free-sof...dular-solvers/

In the dev version, changes have already been made. For example, the CHT tutorial is implemented as modular solvers here: https://github.com/OpenFOAM/OpenFOAM...es/multiRegion

The boundary condition is now:

fluid_to_metal 
{ 
     type coupledTemperature; 
     value $internalField;
}

As far as I understand, it is possible to couple different modules (e.g., more than one coupled multiphaseEuler module), making the internal coupling of OpenFOAM(.org)-preCICE unnecesary. But, maybe i am understanding all wrong!

Kind regards and thanks for your time and great contribution!

[1] https://github.com/OpenFOAM/OpenFOAM...hScalarField.C

[MakisH]

Interesting! I still see a runTime.run(), so, as long as the function object interface remains available, I think we will manage to support OpenFOAM 11 as well. But it will definitely take some time and v2306 will probably be supported earlier.


By the way, OpenFOAM.com also has been developing some functionality for coupling OpenFOAM solvers (but I have not tried it): https://www.openfoam.com/news/main-n...20-12/parallel


OpenFOAM-preCICE did not start with the aim to couple OpenFOAM solvers, but with the aim to couple OpenFOAM with arbitrary external simulation codes. Of course, "arbitrary" includes another OpenFOAM solver, but this is only a side-effect. :-) From our perspective, the question is not "I need this multi-physics application, OpenFOAM has these solvers, how can I couple them?" but "I have a single-physics code X, and I know that OpenFOAM can give me another single-physics code Y. How can I couple them without having to change codes or reinvent the wheel?"


Main message: preCICE goes way beyond OpenFOAM and there is already quite some community around preCICE and the adapter. People actively use it and contribute to it, so it will keep supporting newer versions.Contributing is always welcome! :-D

[ancolli]

I did not know about New multi-application coupling through boundary conditions from .com, so thank you for introducing me to it.



I totally agree with you about the importance of your application. In my first post, I mentioned the extremely important issue that your utility can be coupled to external solvers. I think what you have created is great, but my human nature wants even more from it


In the future, I am sure that I will use your tool. I have code in different versions of OF, and it would take a lot of time to convert it to the new versions. Your tool will help me save time and effort by allowing me to continue using my existing code. Thank you so much for developing such a useful tool!