edge_local_num returns the wrong answer for quads.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fluidity |
Fix Committed
|
High
|
David Ham |
Bug Description
Mark Goffin noticed the following:
I found the error in the calculation (NaN's) came from the normal vector calculation for some of the element faces. I kept digging and found that the normals were coming out as NaN's because the face_lnos for the face element (linear line element) were the same i.e. it was using the same coordinates for the two points of the line and getting a determinant of zero. I investigated where the face_lno's were set and have arrived at the function boundary_local_num which calls edge_local_num for 2D elements (both functions in Element_
Related branches
- Stephan Kramer: Approve
-
Diff: 438 lines (+372/-5)7 files modifiedfemtools/Element_Numbering.F90 (+10/-4)
femtools/tests/test_ele_local_num.F90 (+16/-1)
tests/tracer_inflow_2d_dg_cg_quad/Makefile (+6/-0)
tests/tracer_inflow_2d_dg_cg_quad/src/channel.geo (+16/-0)
tests/tracer_inflow_2d_dg_cg_quad/src/channel.msh (+113/-0)
tests/tracer_inflow_2d_dg_cg_quad/tracer.flml (+169/-0)
tests/tracer_inflow_2d_dg_cg_quad/tracer_inflow_2d_dg_cg_quad.xml (+42/-0)
Changed in fluidity: | |
status: | Confirmed → Fix Committed |