[GiDlist] inaccurate postprocessing with given Gauss points

Moderator: GiD Team

Post Reply
Andres Peratta

[GiDlist] inaccurate postprocessing with given Gauss points

Post by Andres Peratta »

When postprocessing scalar results with "given" gauss points
I found out that the visualization becomes quite inaccurate.
For example Contour_fill and Contour_lines options, dont' work properly.
It seems that the defined coordinates of the gauss points should not have
more than 5 decimal figures,
otherwise the given coordinates in the .res file are not read properly
by GID.

To see what is going on, you can try the following example in which
a scalar field
u(x,y) = x
is visualized in a single unitary triangular element with 6 gauss points
located at the following coordinates :
a = 1/6, b = 2/3, c = 5/12, d = 1/6
( a, a) ( b, a) ( a, b) ( c, d) ( c, c) ( d, c)

( see the attached .res file in which I used different precisions to
represent the fractional
numbers 1/6, 2/3 and 5/12 , and see what happens when contour_lines
or contour_fill options are selected )

The main problem is that if I want to increase the precision of the
given coordinates,
beyond 5 figures the result is completely unpredictable,
and if I keep 5 or less figures, the visualization does not reflect the
real scalar field.
Is there any solution ?
Has anyone faced this problem before ?
Thanks for your help.
best regards,
Andres

--
Andres B. Peratta
Wessex Institute of Technology
Email: andres at wessex.ac.uk
Tel: +44 (0)238 029 3223
Fax: +44 (0)238 029 2853
Ashurst Lodge
Ashurst
Southampton (SO40-7AA)
UK


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testgp.flavia.res
Url: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20030630/33570632/attachment.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testgp.geo
Type: application/octet-stream
Size: 763 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20030630/33570632/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testgp.msh
Type: model/mesh
Size: 240 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20030630/33570632/attachment.msh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testgp.flavia.msh
Type: model/mesh
Size: 284 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20030630/33570632/attachment-0001.msh
Miguel A. de Riera Pasenau

[GiDlist] inaccurate postprocessing with given Gauss points

Post by Miguel A. de Riera Pasenau »

Yes, there was a problem with inverting a matrix when zeros appeared
on the diagonal. With 0.16667 there was no problem, but with 0.1666666666666666667.
i think i will prepare a new beta this week with this problem solved.

miguel

Andres Peratta wrote:

When postprocessing scalar results with "given" gauss points
I found out that the visualization becomes quite inaccurate.
For example Contour_fill and Contour_lines options, dont' work properly.
It seems that the defined coordinates of the gauss points should not have
more than 5 decimal figures,
otherwise the given coordinates in the .res file are not read properly
by GID.

To see what is going on, you can try the following example in which
a scalar field
u(x,y) = x
is visualized in a single unitary triangular element with 6 gauss points
located at the following coordinates :
a = 1/6, b = 2/3, c = 5/12, d = 1/6
( a, a) ( b, a) ( a, b) ( c, d) ( c, c) ( d, c)

( see the attached .res file in which I used different precisions to
represent the fractional
numbers 1/6, 2/3 and 5/12 , and see what happens when contour_lines
or contour_fill options are selected )

The main problem is that if I want to increase the precision of the
given coordinates,
beyond 5 figures the result is completely unpredictable,
and if I keep 5 or less figures, the visualization does not reflect the
real scalar field.
Is there any solution ?
Has anyone faced this problem before ?
Thanks for your help.
best regards,
Andres

--
Andres B. Peratta
Wessex Institute of Technology
Email: andres at wessex.ac.uk
Tel: +44 (0)238 029 3223
Fax: +44 (0)238 029 2853
Ashurst Lodge
Ashurst
Southampton (SO40-7AA)
UK

------------------------------------------------------------------------------------------------------------------------------------
Gid Post Results File 1.0

GaussPoints "gauss1" Elemtype Triangle
Number Of Gauss Points: 6
Natural Coordinates: Given
0.16667 0.16667
0.66667 0.16667
0.16667 0.66667
0.41667 0.16667
0.41667 0.41667
0.16667 0.41667
End GaussPoints

GaussPoints "gauss2" Elemtype Triangle
Number Of Gauss Points: 6
Natural Coordinates: Given
0.166666666667 0.166666666667
0.666666666667 0.166666666667
0.166666666667 0.666666666667
0.416666666667 0.166666666667
0.416666666667 0.416666666667
0.166666666667 0.416666666667
End GaussPoints

GaussPoints "gauss3" Elemtype Triangle
Number Of Gauss Points: 6
Natural Coordinates: Internal
End GaussPoints

Result "uf" "Convergency" 2.0000E+00 scalar OnGaussPoints "gauss1"
Values
1 0.16667
0.16667
0.66667
0.16667
0.41667
0.41667
End Values

Result "uf" "Convergency" 2.0000E+00 scalar OnGaussPoints "gauss2"
Values
1 0.16667
0.16667
0.66667
0.16667
0.41667
0.41667
End Values

Result "uf" "Convergency" 2.0000E+00 scalar OnGaussPoints "gauss3"
Values
1 0.16667
0.16667
0.66667
0.16667
0.41667
0.41667
End Values

------------------------------------------------------------------------------------------------------------------------------------
Name: testgp.geo
testgp.geo Type: unspecified type (application/octet-stream)
Encoding: base64

Name: testgp.msh
testgp.msh Type: model/mesh
Encoding: quoted-printable

Name: testgp.flavia.msh
testgp.flavia.msh Type: model/mesh
Encoding: 7bit

--
--------------------------------------------------------------------------------
Miguel A. Pasenau de Riera miguel at cimne.upc.es http://gid.cimne.upc.es
Post Reply