Multiple Domains with different physics: multimesh?

[aminer2k]

Hello,
I am having trouble building a test case to look at solving two domains, with different physics being solved in each. The first domain is just HeatSolver (Temperature), the second domain uses a solver solving Temperature and Potential. I have been using the test case "multimesh" as a guide. multimesh has three meshes: one reference mesh, a mesh for one region, and a mesh for the second region. The multimesh example appears to be illustrating a technique for using a finer mesh in certain areas of interest, therefore is somewhat different than my needs. It is not exactly clear why the reference mesh is needed in multimesh from the documentation. In my test case, it works fine when I create a reference mesh, domain 1 mesh, and domain 2 mesh that are all solved by HeatSolver (just like multimesh test case). I get segmentation faults when trying then to switch domain 2 mesh to be solved by the customer solver, even though it includes the variable temperature, which is linked to the other meshes.

I'm doing this for two reasons: 1. as the problem scales, it could/should be more computationally efficient to only solve for the necessary variables in the domains where it is needed. and 2. the custom solver does not have all the boundary conditions that HeatSolver has, so HeatSolver is necessary to use in conjunction with the custom solver.

Is the test case multimesh a good example to use as a guide for my needs here?
If not, is there a better approach, with a test case that illustrates a better way to solve one domain with solver A, and a second domain with solver B, linking the temperatures between domains on the boundary?
Thanks!

[raback]

Hi

I think that the "multimesh" example has three meshes so that the two-mesh approach can be verified by the single-mesh approach. And the test cases are often about minimalistic variation. But basically it is ok as an example.

It might be possible to enhance also the BC conditions of this custom solver.

-Peter

[aminer2k]

Looking further at this problem, it looks like the approach used in the Elmer Tutorial "Thermal Flow in Curved Pipe" is a better way to approach my problem. In this tutorial there are two domains, the fluid and the pipe wall. the HeatSolver solves heat transfer in the pipe, and both the HeatSolver and NS solve for Temperature, V, and P in the fluid region. Temperature is defined in both domains, and V1, V2, V3, and P are only defined in the fluid domain.

I am now using this example as a starting point, and not getting very far. As a first step, I have added a third solver, ThermoElectricSolver, as a replacement for HeatSolver in the pipe domain. ThermoElectricSolver solves for Temperature and Potential, so I assume that the heat flow and temperature would be treated as continuous across the boundary of the two domains, just as in the Tutorial. The problem converges, but now the outer surface fixed temperature boundary condition is ignored, and there is no heat transfer between domain. The NS solves the flow problem OK.

An image of the domains is attached, showing that the outer BC is now ignored, and temperature is treated as 0 on the outer wall, while the 350C fluid flows in and out without exchanging heat with the wall.

Any reason why this would not work? sif attached.

[raback]

Hi

One thing is that you cannot have "Temperature" being solved by two different solvers. You should name them differently, say "TempLoc" and "TempGlob". Then if you would solve fist for TempGlob you could set as BCs

Code: Select all

TempLoc = Equals TempGlob

Now this gets you the hierarchical solution. The trickly part is how to get then a complimentary set of BCs to the other direction. Dirichlet-Dirichlet combination won't lead you anywhere, you would rather need some Dirichlet-Neumann conditions.

In the end of the day, I think that addressing the shortcomings of the ThermoElectric solver directly would be the optimal route to success.

-Peter