Should Heat Transfer really depend on mesh elements?

[srose22]

Hello,

I'm new to ALGOR, and I'm trying to do something that's giving me rather unusual results. Ultimately, I want to model the transient heat distribution of a round mirror that is being struck by a laser beam. As a first step, I have started by creating a hockey-puck shaped cylinder in Rhino3D and importing into FEMPRO (which seems to work fine in that it creates one part with 4 surfaces - top, bottom, and 2 strips that each go around half of the side of the puck). I then performed the following steps:
- Set the analysis type to Transient Heat Transfer (run for 1 second in 10 steps with a load curve of 1 over that second)
- Set the Element Type to Tetrahedron
- Set material type to Fused Quartz
- Mesh the puck (more detail on this below) which creates a "hidden" surface 0
- Apply a uniform heat flux over all 4 surfaces of the puck (puts "Q"s on every node as far as I can tell)
- Run the analysis

On meshing: Since this is a 3D object with non-trivial thickness and a non-uniform beam loading the material, I need to do a solid mesh. Since our code that projects the laser beam onto the surface assumes Tetrahedal facets, I need the mesh to use Tetrahedra only. So I set the Element Type to Tetrahedron, and in Model Mesh Settings set mesh type to Solid, then select All tetrahedra in Options-->Solid. Then I mesh the model. The surface mesh looks fine (I ended up moving the meshing to a finer size at 25%).

The results, however, are obviously wrong (see top figure in attached jpg). I have tried using Bricks only (setting Element Type to Brick and then All bricks from within Model Mesh Settings - middle figure), which also gives obviously wrong answers, but in a different way. I have tried ridiculously small meshes and the general behaviour remains the same. The only thing that works is Element Type of Brick, and then Model Mesh Settings of Bricks and tetrahedra (bottom figure). I can think of no reason why the element type should matter as long as all of the elements are sufficiently small. I have noticed the following about the resutls (though I can't figure out how these lead me to a solution):
- "Correct" results have regularly spaced load lines that all point out
- "Incorrect" results have irregularly spaced load lines that do not all point out
- "Correct" results do not show features that correspond to the element mesh
- "Incorrect" results show features that correspond to the element mesh

Does anybody have any clue what is going on? I don't doubt that I'm doing something boneheaded, but I can't think of what it could be.

Thank you,

Steve

(jpg is at

http://files.engineering.com/getfil...1c083e03d23&file=SimplePuckAlgor2-Joined.jpg)

 

[GBor]

It looks like your labels are not correct on the graphic you uploaded. The one that is behaving properly appears to be the "bricks only" version, not the mixed. If that is the case, I would say your problem is with element orientation. You need to define the element orientation for the tets, otherwise, some of the "flip direction". That would give you your uneven pattern as the wrong face is being heated or cooled.

 

[srose22]

GBor,

Thank you for your reply. The labels are correct, but are probably not quite descriptive enough:
- The top figure is meshed with the "Tetrahedra only" option inside the Model Mesh Settings Options dialog, in combination with setting Element Type to Tetrahedron. This figure shows a patchy response which is incorrect
- The middle figure is with "Bricks only" and then Bricks for Element Type. This figure shows a spotted pattern which is also incorrect
- The bottom figure shows the "Bricks and tetrahedra" with Bricks for Element Type. The results for this case seem to be correct.

I will look into the Element Orientation option - I haven't heard of that before. I'll post here if that was what was causing the problem. Thanks so much for the advice!

Steve

 

[srose22]

I just looked at the figure again, and I think perhaps the confusion is regarding the shape of the surface mesh elements. The middle figure is the Bricks only one, but the elements it shows look hexagonal. In contrast, the mixed case (bottom figure) look more brick-like. I don't know why the brick-only case ends up with hexagonal-looking elements, but those are the results, and I haven't a clue as to why it's behaving that way :-(

 

[Dengr1]

Try comparing the aspect ratio of all three cases. There is a results option that will show you this also your mesh summary will also give you this data. The higher the aspect ratio the worse the results will be (generally). In the cases with single types of elements you may have some distorted elements giving bad results. Try adding mid sided nodes and see if that changes anything. Then maybe start looking at your "hidden" surface 0. Just my thoughts though.

Best of luck. Please post if you find out solution.

 

[srose22]

(Thanks to GBor and Dengr1 for trying to help me with this)

Well, ALGOR tech support succeeded in finding an answer to what was going on, but I'm not all that thrilled with it. Basically, they are saying that the all tetrahedral mesh gives a large amount of mesh (or method?) discretization error. Since the analysis is transient with a very short time (1 second), and the material has such a low thermal diffusivity (fused quartz), the mesh errors have no time to go away.

That makes sense, but the weirdness shows up for the Bricks-only case as well (but not for the mixed case), which says to me that you are basically *always* at risk for getting an incorrect analysis unless you can figure out a way to verify that the mesh it happened to generate just happens to not exhibit a large amount of mesh discretization error.

I certainly wouldn't want to just trust that ALGOR has chosen a good mesh when I move to looking at more complicated shapes with highly non-symmetric and time-varying heat loads.

Is there a way to quantify if ALGOR has created a "good" mesh?

 

[GBor]

I'm not fond of this answer either, but could you decrease your time increment so that there are more calculations performed during that one second interval? Normally, error increases with increased increment (think of it as a fork in the road...the farther you travel down one path, the further you are from the other). What increment are you using now? They didn't offer ANY ways to get around this?