After some hiatus from using Elmer, I noticed in 8.4 documentation that the keyword Heat Gap is no longer in the Models manual, although it still appears to be handled by the Heat Equation solver. I also noticed the addition of several discontinuity options in the Solvers Manual. I was wondering what the current suggestions are for using internal discontinuities. Is Heat Gap deprecated?
For simple cases such as an internal thermal resistance layer in 2D geometry, can the previous methods still be used? In the past I defined my mesh in elmergrid, specifying an internal boundary with doubled nodes in the .grd file, then specified in the .sif file a boundary condition on that boundary with "heat gap = true" and a value for Heat Transfer Coefficient. Is there now a better way to approach this? I seem to remember issues with the heat gap approach and multi-material 'corners' having problems.
status of mesh discontinuty approaches (heat gap?)
Re: status of mesh discontinuty approaches (heat gap?)
To add: I noticed the problem I'm trying now has some odd asymmetries that appear when using the heat gap as mentioned above. If I have two materials joined by a heat gap, but there's a body force (heat generation) applied over part of the gap on each side, one side gets hotter than the other. it seems that there heat gap gets applied up the side of the region with the body force. this 'insulates' a bit of the hot spot on one side but not the other, creating a slight asymmetry. I've tried to attach a few images derived from the HeatGap test case.
Mesh with bodies boundaries labeled (it's a mess but you can get the idea). A heat gap exists between the two central regions. grd file:
When the two zones are heated equally with symmetric boundary conditions, the top gets just a bit hotter than the bottom. With elmerpost showing 'free boundaries', you can see that the heat gap goes up both sides of that body.
sif file:
if we turn off heating on the top zone, we can see that the heat gap extending up the first sides of the first element in that zone have an unintended insulating effect, keeping the heat confined. Not sure exactly why that BC is applied to the sides of those elements.
Mesh with bodies boundaries labeled (it's a mess but you can get the idea). A heat gap exists between the two central regions. grd file:
Code: Select all
***** ElmerGrid input file for structured grid generation *****
Version = 210903
Coordinate System = Cartesian 2D
Subcell Divisions in 2D = 3 4
Subcell Limits 1 = -1 0 1 2
Subcell Limits 2 = -1 0 1 2 3
Material Structure in 2D
5 5 5
6 1 4
6 2 4
3 3 3
End
Materials Interval = 1 6
Boundary Definitions
! type out int
1 2 1 2 !int
2 -3 5 1 !north
3 -1 3 1 !south
4 -2 3 1 !east
4 -2 4 1 !east
4 -2 5 1 !east
5 -4 3 1 !west
5 -4 6 1 !west
5 -4 5 1 !west
End
Numbering = Horizontal
Element Degree = 1
Element Innernodes = False
Triangles = False
Surface Elements = 500
Coordinate Ratios = 1
Minimum Element Divisions = 5 5
Element Densities 2 = 1 1 1 1
Element Densities 1 = 1 1
Code: Select all
Header
CHECK KEYWORDS Warn
Mesh DB "." "Mesh3"
End
Simulation
Max Output Level = 3
Coordinate System = "Cartesian 2D"
Simulation Type = "Steady State"
Steady State Max Iterations = 1
Output Intervals = 1
Solver Input File = "TempDist.sif"
Post File = "TempDist3.ep"
End
Constants
Gravity(4) = 0 -1 0 9.82
Stefan Boltzmann = 5.67e-08
End
Body 1
Name = "Body1"
Target Bodies (1) = 1
Body Force = 1
Equation = 1
Material = 1
End
Body 2
Name = "Body2"
Target Bodies (1) = 2
Body Force = 1
Equation = 1
Material = 2
End
Body 3
Target Bodies (4) = 3 4 5 6
Name = "Body3"
Equation = 1
Material = 3
End
Equation 1
Name = "Equation1"
Heat Equation = True
End
Solver 1
Exec Solver = "Always"
Equation = "Heat Equation"
Variable = "Temperature"
Variable Dofs = 1
Linear System Solver = "Direct"
Linear System Direct Method = "umfpack"
Steady State Convergence Tolerance = 1.0e-05
Stabilize = True
Nonlinear System Convergence Tolerance = 1.0e-05
Nonlinear System Max Iterations = 1000
Nonlinear System Newton After Iterations = 3
Nonlinear System Newton After Tolerance = 1.0e-02
Nonlinear System Relaxation Factor = 1.0
optimize bandwidth=false
End
Material 1
Name = "Material1"
Density = 1
Heat Conductivity = 1000
End
Material 2
Name = "Material2"
Density = 1
Heat Conductivity = 1000
End
Material 3
Name = "Material3"
Density = 1
Heat Conductivity = 10
End
Body Force 1
Name = "BodyForce1"
Heat Source = 100
End
Boundary Condition 1
Name = "Constraint1"
Target Boundaries(1) = 1
Heat Gap = Logical True
Heat Transfer Coefficient = 1
End
Boundary Condition 2
Target Boundaries(1) = 2
Temperature = 0
End
Boundary Condition 3
Target Boundaries(1) = 3
Temperature = 0
End
Re: status of mesh discontinuty approaches (heat gap?)
Last thing, playing with this: to see if I could eliminate the issue with a 'corrective' boundary, I created another heat gap up the sides of the heated zones. (elmergrid does give a warning about the multi-material corner)
as I increase this heat gap towards infinity, the asymmetry goes away. I assume it takes precedence over the erroneous heat gap.
making the heating asymmetrical, going from h = 1 to h = 1000000 the effect at that edge is a bit more apparent.
Re: status of mesh discontinuty approaches (heat gap?)
Ok, now the last. The actual problem I have to solve has the heat gap across the whole body, but the heating only on the center body. I originally defined the heat gap as two boundaries, as years ago I used one of the Save solvers that needed a defined boundary for calculating heat flux, and I thought I might need that. Defining the heat gap across the whole body this way leaves the same problem as before.
But defining it as a single boundary condition across the model eliminates this issue.
I'm not sure if I'll run into the issue of needing that BC separately defined, but it still seems odd that just having the center portion of the heat gap assigned a different boundary number produces the erroneous addition of the first element's sides to the heat gap.
And it comes back to my initial question: As I'm jumping from elmer ~6 to 8.4, is there a better way to do 'heat gaps'?
But defining it as a single boundary condition across the model eliminates this issue.
I'm not sure if I'll run into the issue of needing that BC separately defined, but it still seems odd that just having the center portion of the heat gap assigned a different boundary number produces the erroneous addition of the first element's sides to the heat gap.
And it comes back to my initial question: As I'm jumping from elmer ~6 to 8.4, is there a better way to do 'heat gaps'?
-
- Site Admin
- Posts: 4812
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: status of mesh discontinuty approaches (heat gap?)
Hi
Well, there has been an evolution of methods. I'll try to summarize them.
1) Initially the strategy was that we would create a discontinuity in the mesh using ElmerGrid and create tailored BCs for the physical modules to deal with the jump. Now the downside of this strategy is that if the mesh comes from some other source it is not easy to create a correct type of discontinuous mesh. Ideally the physical discontinuity would be dealt on ElmerSolver alone. After all, one could play with different kinds of BCs and it is not really reasonable to have to change the mesh. Also the tailored approach was only applicable to "Heat Gap" which is the first kind of discontinuity that we faced. Due to the limitations this feature is not developed and will probably be forgotten in time.
2) There is a more generic machinery to deal with discontinuities that is even applicable to nonconforming meshes. This uses the "mortar finite element" machinery. There you can define generic jump terms that are dealt on the linear system level. The keywords are less intuitive but the nice thing is that they are applicable to a broad range of physical equations. Unfortunately the direct application of the mortar method results to a saddle-point problem that may make it harder for the problem to converge compared to the strategy in 1). Even this can be overcome by some clever elimination.
If you have an existing mesh you can create "discontinuous boundary" on-the-fly. Also this will be add new nodes to the mesh. The operation is not full-proof in parallel. Also the down-side is that if you have a multiphysical problem this will make all fields discontinuous so you need to consider the jump condition for all fields. Newertheless, this would probably be your current strategy. Look at test case
https://github.com/ElmerCSC/elmerfem/tr ... arContElim
And other related ones.
3) It is a nuisance to have to really add new nodes to a mesh just to have a physical discontinuity in one of the fields. I almost hate it. So in version 8.4 there is a strategy that allows to introduce discontinuity by creating a minimal module-specific basis that can reproduce the discontinuity. The downside for this is that you need currently still some additional code to deal with discontinuous boundary. Then it will be the best strategy as it introduces minimal changes to the linear system, and allows other possible equations to be intact. The current code base does not offer a full solution for the "Heat Gap" so I would still take the strategy 2).
-Peter
Well, there has been an evolution of methods. I'll try to summarize them.
1) Initially the strategy was that we would create a discontinuity in the mesh using ElmerGrid and create tailored BCs for the physical modules to deal with the jump. Now the downside of this strategy is that if the mesh comes from some other source it is not easy to create a correct type of discontinuous mesh. Ideally the physical discontinuity would be dealt on ElmerSolver alone. After all, one could play with different kinds of BCs and it is not really reasonable to have to change the mesh. Also the tailored approach was only applicable to "Heat Gap" which is the first kind of discontinuity that we faced. Due to the limitations this feature is not developed and will probably be forgotten in time.
2) There is a more generic machinery to deal with discontinuities that is even applicable to nonconforming meshes. This uses the "mortar finite element" machinery. There you can define generic jump terms that are dealt on the linear system level. The keywords are less intuitive but the nice thing is that they are applicable to a broad range of physical equations. Unfortunately the direct application of the mortar method results to a saddle-point problem that may make it harder for the problem to converge compared to the strategy in 1). Even this can be overcome by some clever elimination.
If you have an existing mesh you can create "discontinuous boundary" on-the-fly. Also this will be add new nodes to the mesh. The operation is not full-proof in parallel. Also the down-side is that if you have a multiphysical problem this will make all fields discontinuous so you need to consider the jump condition for all fields. Newertheless, this would probably be your current strategy. Look at test case
https://github.com/ElmerCSC/elmerfem/tr ... arContElim
And other related ones.
3) It is a nuisance to have to really add new nodes to a mesh just to have a physical discontinuity in one of the fields. I almost hate it. So in version 8.4 there is a strategy that allows to introduce discontinuity by creating a minimal module-specific basis that can reproduce the discontinuity. The downside for this is that you need currently still some additional code to deal with discontinuous boundary. Then it will be the best strategy as it introduces minimal changes to the linear system, and allows other possible equations to be intact. The current code base does not offer a full solution for the "Heat Gap" so I would still take the strategy 2).
-Peter
Re: status of mesh discontinuty approaches (heat gap?)
Thanks for the summary and Happy New Year.
Was just coming back to post that even the fix from my last post was insufficient. single material boundaries work perfectly fine with the heat gap. But for the multimaterial gap it turns out this creates a 'leaky' gap. setting gap HTC to zero still allowed heat to pass across, and the model was very insensitive to changes in that HTC. As this was the primary factor i'm looking to examine, I'll take a look at that teat case for option 2.
Was just coming back to post that even the fix from my last post was insufficient. single material boundaries work perfectly fine with the heat gap. But for the multimaterial gap it turns out this creates a 'leaky' gap. setting gap HTC to zero still allowed heat to pass across, and the model was very insensitive to changes in that HTC. As this was the primary factor i'm looking to examine, I'll take a look at that teat case for option 2.
Re: status of mesh discontinuty approaches (heat gap?)
Taking a quick look, this should do the trick. The series of discont. tests are pretty informative. It appears since I'm just working with the Heat Solver, the heat gap and HTC keywords still work as expected (not sure if they're necessary, will play some more).
Pulled the whole test suite down to sit next to my ElmerDocumentation folder. Would recommend bundling the with the Windows build.
Pulled the whole test suite down to sit next to my ElmerDocumentation folder. Would recommend bundling the with the Windows build.