-
Notifications
You must be signed in to change notification settings - Fork 69
Description
I recently encountered some issues when computing the scalar gradients in the postprocessing that i havent been aware of so far.
I tried to compute the scalar gradients using grad_sca_x and grad_sca_y arrays from the fesom.mesh.diag.nc file together with elem =[ n2de, 3] array loaded from elem2d.out. This didnt work et all !!!
I realized that the elem array (face_nodes) loaded from fesom.mesh.diag.nc, so thats what the model sees, is different from the elem array loaded based on elem2d.out
- elem array from the meshdiag file (so supposedly what the model sees):
[[ 1763 1477 78543 ... ]
[125225 703 5048 ... ]
[ 96635 112277 78544 ... ]]
- elem array loaded from elem2d.out:
[[ 1763 1477 78543 ... ]
[ 96635 112277 78544 ... ]
[125225 703 5048 ... ]]
So the elem array in meshdiag is permuted by elem[:, [0,2,1]]. Apparently in fesom2 we need the triangle indices in the elem array being clockwise sorted. We test this in the model in the routine test_tri and re-structure the elem array in the model accordingly after it is read. So when elem arrays in meshdiag are permuted, than the sorting direction in elem2d.out was counter-clockwise
@svenharig: So ideally all our grids would follow the rule that the vertice indices are clockwise sorted when they fall out of the mesh generator, so we dont step into that problem anymore!!!
As a safety switch we could also impose in the model, that it is allowed to rewrite the elem2d.out file with the proper sorting direction. In this case it would always just need to do it once.
In tripyview i enforced now that always the elem array from the meshdiag file is used for the gradient computation. However in pyfesom2 that might be not the case. And it remains a source for future problems that user might step into and fuck things up !!!