I have some questions about the postprocessing with results on the gauss points using gid version 7.1.3. b
In the attached file “prova1” I have put the gauss points coordinates in a different order respect the internal order of gid and I in the contour visualization of the scalar result I can see only the gauss points and not the whole solid . Why?
In the file “prova2” I have put the gauss points coordinates in the same order of the internal one and I in the contour visualization of the scalar result I see some problem around the nodes. (in this case the scalar result is the same for all the 8 gauss points)
In the file “prova3” I have put the gauss points coordinates in the same order of the internal one and the scalar result is not the same for all the 8 gauss points. In this case the contour visualization of the scalar result seems to be right.
I think that gid do a local smoothing of the results from the gauss points to the nodes and then do a mean of the results coming from all the elements converging in the same node . This average value has not meaning if the elements converging in the node have different material properties . In this case is better that the finite element code do the local smoothing?
In the attached file “prova1” I have put the gauss points coordinates in a different order respect the internal order of gid and I in the contour visualization of the scalar result I can see only the gauss points and not the whole solid . Why?
GiD extrapolate the gauss point results to the element nodes using the element
shape functions (this value is discontinuos between elements)
If your gauss points are not standard (in number and “internal GiD natural” location), then
it is undefined this extrapolation, and at this moment, GiD only show as coloured spheres at gauss points
(in your case, the number of gauss points is the same as the internal, but in general this number can change)
In the file “prova2” I have put the gauss points coordinates in the same order of the internal one and I in the contour visualization of the scalar result I see some problem around the nodes. (in this case the scalar result is the same for all the 8 gauss points)
This is a bug in this particular case with all values equal. We have corrected last some problems about
results in gauss points, but it seems that still it is left some defect.
I think that gid do a local smoothing of the results from the gauss points to the nodes and then do a mean of the results coming from all the elements converging in the same node . This average value has not meaning if the elements converging in the node have different material properties . In this case is better that the finite element code do the local smoothing?
GiD do a local extrapolation from the gauss points to the nodes, but it not make any mean (smooth) of the results.
The calculation code can write directly the smooted nodal values instead the gauss points values.
We are thinking about add to GiD this smoothed option of the results in gauss points.
Regards
Enrique Escolano
----- Original Message -----
From: Renato Matteazzi
To: gidlist
Sent: Thursday, November 21, 2002 12:10 PM
Subject: [GiDlist] questions about the results on gauss points of hexahedra elements
I have some questions about the postprocessing with results on the gauss points using gid version 7.1.3. b
In the attached file “prova1” I have put the gauss points coordinates in a different order respect the internal order of gid and I in the contour visualization of the scalar result I can see only the gauss points and not the whole solid . Why?
In the file “prova2” I have put the gauss points coordinates in the same order of the internal one and I in the contour visualization of the scalar result I see some problem around the nodes. (in this case the scalar result is the same for all the 8 gauss points)
In the file “prova3” I have put the gauss points coordinates in the same order of the internal one and the scalar result is not the same for all the 8 gauss points. In this case the contour visualization of the scalar result seems to be right.
I think that gid do a local smoothing of the results from the gauss points to the nodes and then do a mean of the results coming from all the elements converging in the same node . This average value has not meaning if the elements converging in the node have different material properties . In this case is better that the finite element code do the local smoothing?
for some reason GiD can not extrapolate the nodal results from
the gauss points one with the given natural coordinates.
we’ll check this.
yes, this is a bug due to some rounding/epsilon problem in the
extrapolation with the same gausspoints results. Now, this bug
is corrected for the next version.
¿?
GiD does an extrapolation from the gauss points results to the nodes
with no smoothing of any type among all the extrapolated values from
the elements which share the same node. Due to this, some discontinuities
can be appreciated when looking at a c.fill of a gauss points result,
this discontinuity is more obvious in elements which have different
material properties.
thanks, hope it helps
miguel
Renato Matteazzi wrote: I have some questions about the postprocessing with results on the gauss points using gid version 7.1.3. b 1) In the attached file “prova1” I have put the gauss points coordinates in a different order respect the internal order of gid and I in the contour visualization of the scalar result I can see only the gauss points and not the whole solid . Why? 2) In the file “prova2” I have put the gauss points coordinates in the same order of the internal one and I in the contour visualization of the scalar result I see some problem around the nodes. (in this case the scalar result is the same for all the 8 gauss points) 3) In the file “prova3” I have put the gauss points coordinates in the same order of the internal one and the scalar result is not the same for all the 8 gauss points. In this case the contour visualization of the scalar result seems to be right. 4) I think that gid do a local smoothing of the results from the gauss points to the nodes and then do a mean of the results coming from all the elements converging in the same node . This average value has not meaning if the elements converging in the node have different material properties . In this case is better that the finite element code do the local smoothing? Thanks and regards, Renato Matteazzi
Dip. di Costruzioni e Trasporti Univ. di Padova Name: prova3.flavia.res prova3.flavia.res Type: unspecified type (application/octet-stream) Encoding: quoted-printable Name: prova2.flavia.msh prova2.flavia.msh Type: unspecified type (application/octet-stream) Encoding: quoted-printable Name: prova3.flavia.msh prova3.flavia.msh Type: unspecified type (application/octet-stream) Encoding: quoted-printable Name: prova1.flavia.res prova1.flavia.res Type: unspecified type (application/octet-stream) Encoding: quoted-printable Name: prova2.flavia.res prova2.flavia.res Type: unspecified type (application/octet-stream) Encoding: quoted-printable Name: prova1.flavia.msh prova1.flavia.msh Type: unspecified type (application/octet-stream) Encoding: quoted-printable
It exists also a parameter swap *elemsconec(swap) to change the quadratic case to non hierarchic numeration.
hierarchical numeration: first vertex nodes, after midnodes
Non hierarchical: consecutive nodes
Enrique
----- Original Message -----
From: “Pablo Perez del Castillo” pablopdc at terra.es
To: gidlist at gatxan.cimne.upc.es
Sent: Tuesday, November 26, 2002 2:57 AM
Subject: [GiDlist] ElemsConec in shell elements
When i create the *.bas file, how can i chosse the sense when i write the element’s connectivities. Thanks Pablo
It is possible to obtain a mesh with tetra and hexa only in some
limited cases. In fact, to get it both volumes should have no common
surface between them and so, be independent volumes.
As you know, the hexa mesh generation must be structured.
If the volumes are independents it is possible to mesh one with hexahedra
and another with tetrahedra.
If the volumes share some surface, then it is not possible: not exists a
conformal mesh.
Dear GiD members, Can we generate meshes with sets of hexahedral and tetrahedra. For example, there is a domain containing Volume#1 and Volume#2. I would like to use hexahedra for Volume1 and tetrahedra for Volume#2. regards, kenji U. of Texas at Austin Dept. Petroleum & Geosystems Eng.
kenji
— Enrique Escolano escolano at cimne.upc.es wrote: If the volumes are independents it is possible to mesh one with hexahedra and another with tetrahedra. If the volumes share some surface, then it is not possible: not exists a conformal mesh. Enrique Escolano ----- Original Message ----- From: “kenji furui” petrocowboy at yahoo.com To: gidlist at gatxan.cimne.upc.es Sent: Tuesday, November 26, 2002 5:15 AM Subject: [GiDlist] MeshGeneration
Dear GiD members, Can we generate meshes with sets of hexahedral and tetrahedra. For example, there is a domain containing Volume#1 and Volume#2. I would like to use hexahedra for Volume1 and tetrahedra for Volume#2. regards, kenji U. of Texas at Austin Dept. Petroleum & Geosystems Eng.
An additional comment regarding Kenji’s question. This topic has already
been discussed outside the GidList context. Mixing tetra and hexa meshes
requires pyramids to make the transition (pyramids are supported by many FE
codes). This solution would be useful for problems such as acoustics, for
instance, where tets perform poorly (but geometries are too complex to mesh
with hex only).
Philippe
At 11/26/2002 08:00 AM, you wrote: Thanks, kenji — Enrique Escolano escolano at cimne.upc.es wrote: If the volumes are independents it is possible to mesh one with hexahedra and another with tetrahedra. If the volumes share some surface, then it is not possible: not exists a conformal mesh. Enrique Escolano ----- Original Message ----- From: “kenji furui” petrocowboy at yahoo.com To: gidlist at gatxan.cimne.upc.es Sent: Tuesday, November 26, 2002 5:15 AM Subject: [GiDlist] MeshGeneration
Dear GiD members, Can we generate meshes with sets of hexahedral and tetrahedra. For example, there is a domain containing Volume#1 and Volume#2. I would like to use hexahedra for Volume1 and tetrahedra for Volume#2. regards, kenji U. of Texas at Austin Dept. Petroleum & Geosystems Eng.