Extending OpenFOAM adapter for volumetric coupling

Official adapters and tutorials
, , ,
1

Hi

This is a continuation of my previous topic on volumetric coupling of OpenFOAM. As Makis had pointed out, there are quite a few discrepancies on the older OF adapter for volumetric coupling. I have been working on that and made some changes to update everything for precice version2.2.0. The new adapter with volumetric coupling is working reasonably well. In this regard, I had a question and a proposition:

Question - I am testing one-way volumetric coupling now and see that the internal volumetric fields are being mapped correctly between two solvers (both OF solvers). However, when I include patches, the data is not being mapped correctly. (The solver which writes the data, writes the data correctly to the buffer, but the solver which reads the data has some 0 values in some of the patch entries where there are supposed to be non-0 values). Please let me know if you have any inkling for where the problem might be.

Proposition - Would it be better to push my OF adapter with the volumetric coupling capability to github so that you can take a look? I have also put my test case which I am running to test the volumetric coupling in the tutorials folder of the same.
This might even make its way to getting integrated with the OF adapter so that volumetric coupling becomes a part of the adapter. Please let me know how we can go about extending the capability to volumetric coupling.

Thanks
Arpan

2

That’s great news, @ArpanS!

Could you maybe describe what you mean with a figure/screenshot?

Some things to consider:

  • Since you are coupling volumes, how do you handle the boundaries?
  • Does this also happen in explicit coupling, or only on implicit? If the latter, checkpointing could be an issue.
  • Do you see the same issue in the exported preCICE meshes? If not, it could be reading-specific. If yes, it is probably write-specific.

Yes, please, definitely! :grinning_face_with_smiling_eyes:

That would be great! What we would need would be that you bring it to a state where it only has the related changes in a branch of your fork, then submit:

  • the adapter-specific changes to the adapter repo as a Merge Request, explaining a bit what is going on, how to test it, etc.
  • the tutorial case in the tutorials repository.

Please also give me some hint on your availability to work on this for the near future after you submit, so that we can manage to merge it while it is rolling.

We also collected some hints for this in our contributing guidelines, I hope they help.

3

Please find attached some files from the adapter and the test case. I have also included a README.md for the tutorial case. Please go through that to understand the setup and let me know if you have any questions. Also attached are two U files from the two OF solvers which are coupled using preCICE. You can see that they have the same entries in the internalField, but different values in the boundaryField (e.g., inlet). This is the error I was talking about.

Boundaries - I have attached the Interface.C file from the adapter to show how I treat boundaries. In the test case, I mentioned all (here, 7) the boundary patches in the preciceDict. This leads to the error I mention above.
Coupling - I have only tested explicit coupling so far. I have setup a case for implicit coupling and will be testing it soon. I will keep you posted.
Issue - I did not see any issue in the exported meshes. I printed out some numbers during write and read. The write values in the preCICE buffer were correct, but the read values in the buffer were incorrect.

Next steps for me:

  1. I will go through the guidelines for contribution.
  2. I will prepare a more detailed explanation of the test case/s.
  3. I will complete some of the changes I am making in the adapter, put proper comments and push the changes to github maybe later this week.

Looking forward to working on this. Please let me know if the information I have provided is sufficient or if you need more to diagnose the problem I am facing.

4

I forgot to attach the files in the previous message.
Here they are.

Arpan_files

Let me know if you are unable to access them, I will upload the individual files here.

5

I just looked at your files, sorry for the delay. It is always much easier to review things on GitHub (pull requests), as I can see the file changes. But this was a much smaller change than I thought (thanks!).

Did you need to touch any other adapter files, or is the Interface.C enough? I guess that the readers/writers also need to be adapted.

Moreover, we now have a very simple fluid-fluid coupling module in the adapter. I guess it only makes sense to have volume coupling for CHT and FF, and only for face centers, I cannot imagine any practical use case for face nodes or FSI and volume coupling. It would be great if you could also port the same change there in yoru pull request!

I understand you are referring to the following difference:

-     inlet
-     {
-         type            fixedValue;
-         value           uniform (0.1 0 0);
-     }
---
+     inlet
+     {
+         type            fixedValue;
+         value           nonuniform List<vector> 
+ 41
+ (
+ (0 0 0)
+ (0 0 0)
+ (0 0 0)
+ (0 0 0)
+ (0.1 0 0)
+ (0.1 0 0)
+ ...

I do not completely understand the setup, but it would be interesting to find out what is special about these cells (e.g. in ParaView). Where are they located? A figure would help.

The changes in Interface.C look ok at a first glance, but I did not look into details.

It would be great if we could continue the discussion on a pull request! Feel free to either include everything in the adapter repo for now (and move the tutorial later), or directly open one PR in the adapter and one in the tutorials. Of course, if you prefer to keep it here until you get more confident about the feasibility, that’s also perfectly fine. :slightly_smiling_face:

6

@Alphaoo1 and I have a working version of the OpenFOAM adapter for volume coupling. It is based on the original branch GitHub - JaegerSt/openfoam-adapter at dev_volume_coupling_AIT but we cleaned it up, updated it for preCICE 2.2.0 and for the adapter dictionary.

I will do a bit of cleanup in our code and then push it somewhere for you, in case you want to look at it.

3 Likes
7

That would be great, @xbesseron! Feel free to start a PR to the adapter repository as well, it should not need a lot of extra work to integrate it. Or, if @ArpanS starts one, it would be great if you could help with the reviewing.

8

@Makis I have pushed the necessary changes.
I have kept a module we use called Momentum and kept a sample Volume field so that anyone can replicate and use it.

Edit: check PR #181
Edit 2: For only volume coupling, you can check the PR #182

1 Like
9

Hi everyone

Sorry for the delay from my end this time. First of all, @Makis - I resolved the issue I had shared earlier and things are working better now.

I will take a look at the fluid-fluid coupling module since that is what I am doing for my test cases as well (only OF-OF). I added two locations type: one for cell centers and one for face centers. I do not envision face nodes coming of much use as you said as well.

I see that @Alphaoo1 has already started working on the volume coupling, I will continue with that one. I am preparing better Readme files for my test cases (again OF-OF and I use OF-v1912) - currently I have two test cases for volumetric coupling - one-way and two-way respectively.

10

@ArpanS I hope the PR helps.
Please share the Readme files for the test cases as soon as possible.
As in our team we use volume coupling between XDEM and OpenFOAM, the test case we already have is limited to the team.
For the PR I have opened, @DavidSCN has requested a test case to validate the implementation.

11

Hi :slight_smile:
I’m tying to do Fluid-Fluid volume coupling between OpenFOAM and my code (MaMiCo) which I’ve recently started to couple to preCICE. I will start a new topic soon and explain in details my setup but I would like to understand the current state of the Volume coupling PR of the openFOAM adapter. I’ve been looking at the different fork from @xbesseron or @ArpanS but I can’t seem to understand. As far as I understood, one has to specify “locations volume” in the preciceDict file (without specifying patches ?). Then, the openFOAM adapter will go through all the center of each cell of the mesh (cf. l.268 to l.324 of Interface.C) and the face center of each patch, am I correct ? However, what I would to achieve is not to give all my openFOAM mesh to preCICE but only the few cells that are used for the coupling, is it possible ? On the openFOAM side, is it possible to tell openFOAM to use these cells as boundary condition (as opposed to having faces (or patches) as boundary condition) ?

Thanks in advance,
Louis

1 Like