[ConvectionDiffusion] coupling two domains

[philbucher]

Hi,
Several ppl approached me in the past regarding the coupling of convection-diffusion problems.
Since the communication was only over mail and independent, I am trying to collect the findings here to hopefully find a solution in the future.

Problem Setup

@SADPR thx for the images

Quantities to be coupled:

• Solid (TEMPERATURE) to Fluid (TEMPERATURE)
• Fluid (REACTION_FLUX) to Solid (FACE_HEAT_FLUX)

Current Issue

@rishithellathmeethal thx for the image

As seen in the picture, the left domain "fills up with temperature", it seems like the coupling of the flux is not working.
The temperature should be linearly distributed from one side to the other (and simulating the same problem without coupling shows this correctly)

Questions to be answered

According to some conversations I had with @rubenzorrilla, the FluxCondition should be used in the solid domain to take the FACE_HEAT_FLUX coming from the fluid into account.
This seems to be correct and in accordance to this test. This test is old and does not work any more with the new structure of the ConDiff solvers. The important part is that in this test, the FluxConditions are already inside the mdpa. With the new structure of the ConDiff solvers however, the ReplaceElementsAndConditionsProcess is used which uses the ThermalCondition by default.

Now question (mostly for @rubenzorrilla): How can we achieve the desired coupling? Can we just replace all the conditions? Or do we need both conditions (i.e. FluxConditions and ThermalConditions). If we need both then I think it is not possible with the current design of the solvers.

For completeness: The REACTION_FLUX is a concentrated quantity which needs to be transformed into a distributed quantity before mapping it onto FACE_HEAT_FLUX. I did a draft for adding this in the CoSimApp in #5993 which I can finish soon. In any case I consider this as a second step for this coupling to work

@rishithellathmeethal @SADPR please add your thoughts in case I forgot sth

[loumalouomega]

You can use the MeshTying condition from the contact app, so the transference is not required, and the problem becomes "monolithic"

BTW: I need to clean up the MeshTying condition

[philbucher]

thx, but we deliberately want to set it up as a partitioned model

[ddiezrod]

We have to deal with this problem many times in altair (we do not use the ConvDiff app though). What we do for the moment is that solver has its "default condition" that replaces every condition from the mdpa. Then we have a python process which is basically a wrapper for replace_elements_and_conditions_process (we allow to also change the properties here, but its not strictly necessary) and it is called from the processes list. Not too pretty, but it worked for us so far, I'll be very happy to hear a better alternative ;)

[philbucher]

@ddiezrod so you basically replace Conditions per (Sub)ModelPart and not globally?

[ddiezrod]

@ddiezrod so you basically replace Conditions per (Sub)ModelPart and not globally?

When we call this wrapper process, yes, the model part name is an input parameter and it will be a submodel part of the main one. We still have the call to the replace process in the solver though, where every condition is replaced (This is in solver PrepareModelPart, so before the other processes are called). What I discussed not long ago with @jrubiogonzalez is that we'd like to remove this from the solver so all boundary conditions are provided only in ProjectParameters.

[jrubiogonzalez]

That's it. What we have right now it is working, not elegant but functional. We'd like to have more flexibility when imposing BC.

[rishithellathmeethal]

Questions to be answered

According to some conversations I had with @rubenzorrilla, the FluxCondition should be used in the solid domain to take the FACE_HEAT_FLUX coming from the fluid into account. This seems to be correct and in accordance to this test. This test is old and does not work any more with the new structure of the ConDiff solvers. The important part is that in this test, the FluxConditions are already inside the mdpa. With the new structure of the ConDiff solvers however, the ReplaceElementsAndConditionsProcess is used which uses the ThermalCondition by default.

@rishithellathmeethal @SADPR please add your thoughts in case I forgot sth

I tried with the following addition in the solver settings
"element_replace_settings" : { "element_name" : "EulerianConvDiff", "condition_name" : "ThermalFace" },
but, it does not have any impact on the solution. Solution is still the same as in the image.

[philbucher]

@rishithellathmeethal you tried the defaults without changing the condition, can you try with
"element_replace_settings" : { "element_name" : "EulerianConvDiff", "condition_name" : "FluxCondition" },
instead?

[rubenzorrilla]

First of all I'd like to say that there's a solver that already solves this physics. It is implemented in conjugate_heat_transfer_solver.py. In any case, I assume that you want to do this using the co-sim app, so here my thoughts about this

Questions to be answered

According to some conversations I had with @rubenzorrilla, the FluxCondition should be used in the solid domain to take the FACE_HEAT_FLUX coming from the fluid into account. This seems to be correct and in accordance to this test. This test is old and does not work any more with the new structure of the ConDiff solvers. The important part is that in this test, the FluxConditions are already inside the mdpa. With the new structure of the ConDiff solvers however, the ReplaceElementsAndConditionsProcess is used which uses the ThermalCondition by default.

The ThermalFace condition is always used as it has the capability to add a heat flux (i.e. the standard boundary term coming from integration by parts) plus two extra contributions (ambient radiation and convection). In other words, the FluxCondition can be somehow understood as a simplified version of the ThermalFace.

Note that either the ThermalFace of the FluxCondition will be substituted by all the naive conditions in your mdpa, that is to say you need to write this in the pre-processing.

Now question (mostly for @rubenzorrilla): How can we achieve the desired coupling? Can we just replace all the conditions? Or do we need both conditions (i.e. FluxConditions and ThermalConditions). If we need both then I think it is not possible with the current design of the solvers.

From my answer above, I see two options in here

1. You write the conditions when specifying the coupling interface in the pre-processing. If this is done, I'm pretty convinced that it should work with both ThermalFace or FluxCondition. I think it should work out of the box provided that you deactivate the radiation and convection contributions by setting the corresponding coefficients to zero.
2. You don't write the conditions when specifying the coupling interface in the pre-processing. Then you need to construct these from the submodelpart nodes and faces. If this is the case I'd use the FluxCondition as it does what you need with less complexity.

If possible, I'd go for option 1.

For completeness: The REACTION_FLUX is a concentrated quantity which needs to be transformed into a distributed quantity before mapping it onto FACE_HEAT_FLUX. I did a draft for adding this in the CoSimApp in #5993 which I can finish soon. In any case I consider this as a second step for this coupling to work

I confirm this. REACTION_FLUX is a concentrated magnitude (analogous to point load) than needs to be converted to the FACE_HEAT_FLUX conservative one (analogous to distributed load).

[rishithellathmeethal]

@rishithellathmeethal you tried the defaults without changing the condition, can you try with "element_replace_settings" : { "element_name" : "EulerianConvDiff", "condition_name" : "FluxCondition" }, instead?

Sorry, that was copy paste from one of the trials. But I tried both!!!

[philbucher]

thanks for the input @rubenzorrilla !
Based on this I understood that we can also use the ThermalFaceCondition aka the default settings.
Then again it seems like an issue with the boundary conditions. I had the following thought:
@rishithellathmeethal instead of performing a coupled simulation, can you only run the left domain and manually specify a FACE_HEAT_FLUX (instead of mapping it from the right domain). I would like to know how this can be done properly before moving to the coupled simulation where we would use the same principle

[rubenzorrilla]

thanks for the input @rubenzorrilla ! Based on this I understood that we can also use the ThermalFaceCondition aka the default settings. Then again it seems like an issue with the boundary conditions. I had the following thought: @rishithellathmeethal instead of performing a coupled simulation, can you only run the left domain and manually specify a FACE_HEAT_FLUX (instead of mapping it from the right domain). I would like to know how this can be done properly before moving to the coupled simulation where we would use the same principle

You understood correctly 😉

[rishithellathmeethal]

@philbucher tried it, that part works fine

[philbucher]

thx @rishithellathmeethal

so with setting this boundary condition the domain no longer "fills up" with temperature right?

Now in the coupled case, can you also print the FACE_HEAT_FLUX on the right side? I am in particular interested how the values look on the interface to the left side

[rishithellathmeethal]

thx @rishithellathmeethal

so with setting this boundary condition the domain no longer "fills up" with temperature right?

yeah, in this case domain doesn't get fills up with temperature.

This is the coupled case, cant find any FACE_HEAT_FLUX on the right side.

[philbucher]

On the right side it is called REACTION_FLUX, can you check that one?

but seeing FACE_HEAT_FLUX on the left means that (at least sth) is mapped, hence guessing the reaction flux is calculated correctly

are you using weak or strong coupling now?

[rishithellathmeethal]

I was using weak coupling, but the strong also results in "filling up" the left side.

This image is from strong coupling

[SADPR]

Sorry for the delay in my comments. These are the results that I obtained.

For the 5th time-step:

TEMPERATURE TIME-STEP 5.

FLUX TIME-STEP 5.

For the last time step (50):

TEMPERATURE TIME-STEP 50.

FLUX TIME-STEP 50.

It seems to me that the conditions are well applied in both domains, the REACTION_FLUX is the same as the FACE_HEAT_FLUX (with a change in the sign). The results that I sent at the beginning to @philbucher unfortunately were missing the FACE_HEAT_FLUX results and that may have been confusing.

I have a question @rishithellathmeethal, in my case, the initial condition is that both bodies have a temperature of 200K and the solid (left domain) has a temperature condition on its left face of 300K, meanwhile, the fluid (right domain) has a temperature condition on its right face of 250K. Did you use different conditions? Can you share them with me so I can run a simulation with these conditions?

From the last picture of the fluxes that you are showing, it seems that you have no REACTION_FLUX on the fluid's (right domain) right face, which means you may not be applying any temperature condition there.

Please find attached my test case:

Test_case_sebastian.zip

Please feel free to set up a meeting where we can discuss this.

[rishithellathmeethal]

@SADPR
In my case I am trying a domain decomposition method ie: both the left and right are having same geometrical properties.
I have a temperature of eg:500K on left, an external heatflux of 20000 at botoom and convection at top. The right boundary of second domain doesnt have any BC.
here is the problem setup.

domain_decom_thermal.zip

You can clearly see the discontinuity at the boundary.

[philbucher]

@rishithellathmeethal it seems like the discontinuity might be caused by the lack of transforming the REACTION_FLUX (which is a concentrated nodal quantity) into a distributed quantity before mapping it onto FACE_HEAT_FLUX (which is a distributed quantity)
=> I will try to finish #5993 asap so that you can test it

[philbucher]

so I finished #5993 but unfortunately it didn't make a difference in either of the examples :/

=> I still think it is a problem with the boundary conditions not properly taking into account the FACE_HEAT_FLUX => no matter what values are being mapped (i.e. no matter what magnitude) the temperature distribution doesn't change for me
I am not sure any more this problem is related to CoSimulation

MY RECOMMENDATION:
Make the ThermalCouplingTest work again, since it does exactly what we are trying to do here, but without CoSimulation.
Once this is done, then we can take a look into how things are working and proceed to apply the same schematics to CoSimulation

for reference the two parameter files where I applied #5993:
cosim_proj_params.zip
Note: For making #5993 work, I needed to add an aux historical variable (to avoid potential conflicts, I used ARRHENIUS => this is not used anywhere else)
This requires #9639 and adding the following in the solver_settings of the ConDiff proj-parameters

"auxiliary_variables_list" : ["ARRHENIUS"]

I also made a PR for adding the ConDiff CoSimWrapper to Master (requires approval): #9640

EDIT now all the PRs are merged so you can try with master

[rubenzorrilla]

Is this still active?