[Nek5000-users] about fix_geom

nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov
Tue Jan 21 08:22:59 CST 2014



Hi Lailai,

fix_geom was intended to simply repair small rips in the
mesh fabric, i.e., to ensure that there are no gaps between
curved edges or corners that are slightly separated because of
round-off errors in the .rea file, etc.  So, it's not surprising
that there would be no change for a single element.

The way fix_geom is intended to work is to simply average the
values of x,y, and z that are shared between elements, and then
to use Gordon-Hall to propagate the resultant changes into the
interior of each element.   Periodic BCs are excluded from the
averaging process via a mask.   If an element is unchanged by
the averaging process then there is no change propagated into
its interior.

Hope this helps...

Paul



On Tue, 21 Jan 2014, nek5000-users at lists.mcs.anl.gov wrote:

> Hello, guys,
>
> Have you any experience with the routine fix_geom, which has not been tested
> for 2d cases as reported. I am trying to use it for a 2d case with curved
> boundaries not necessarily describable by expressions. When the gll points on
> bc are rectified to capture the right shape, a call to fix_geom is supposed
> to reposition the internal gll points following the so-called Gordon-Hall
> algorithm?
>
> I have tested for a simple mesh with only one square element, whose corners
> are located at (-1,-1), (-1,1), (1,1) and (1,-1). I find that simply moving
> the internal gll points of one edge (like (-1,-1) to (1,-1)) followed by
> calling fix_geom does nothing to the internal gll coordinates. Probably some
> key ingredients are missing here?
>
> thanks in advance,
> lailai
>
>
> _______________________________________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>


More information about the Nek5000-users mailing list