Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001026/bf5109b2/attachment.htm
[ GiDlist ] preprocessor bug
Moderator: GiD Team
-
Enrique Escolano
[ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/9bc3b245/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/9bc3b245/attachment.bin
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/9bc3b245/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/9bc3b245/attachment.bin
-
M. A. Meguid
[ GiDlist ] preprocessor bug
Thank you sir for your response
I understand that the normal to the face does not have to point in the +Y direction. But, the point is the "consistency". why some elements are being generated counting the nodes clockwise and some are counterclockwise. And why it worked for the single volume and did not work for the multi-volume mesh.
Also If there is consistency, the connectivity writing will be much easier to control in the .bas file. Some solvers require that the 20 noded element must be written in a certain direction in order to define the correct shape function at the proper node. This does not apply to the 8 noded brick element (for example) because the 8 shape functions are the same.
This is the case with my solver. It requires that the element connectivity being numbered in a consistent manner in the counterclockwise direction and apparently the preprocessor can not do that for a complex geometries.
I would appreciate your help if you could elaborate on the *operation command and how is it going to work in order to make the .bas file writes the connectivity for all the elements in a consistent manner counting in one face (x-z for example) and going perpendicular.
Thanks
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 7:39 AM
Subject: Re: [ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/6c994ed2/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/6c994ed2/attachment.bin
I understand that the normal to the face does not have to point in the +Y direction. But, the point is the "consistency". why some elements are being generated counting the nodes clockwise and some are counterclockwise. And why it worked for the single volume and did not work for the multi-volume mesh.
Also If there is consistency, the connectivity writing will be much easier to control in the .bas file. Some solvers require that the 20 noded element must be written in a certain direction in order to define the correct shape function at the proper node. This does not apply to the 8 noded brick element (for example) because the 8 shape functions are the same.
This is the case with my solver. It requires that the element connectivity being numbered in a consistent manner in the counterclockwise direction and apparently the preprocessor can not do that for a complex geometries.
I would appreciate your help if you could elaborate on the *operation command and how is it going to work in order to make the .bas file writes the connectivity for all the elements in a consistent manner counting in one face (x-z for example) and going perpendicular.
Thanks
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 7:39 AM
Subject: Re: [ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/6c994ed2/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/6c994ed2/attachment.bin
-
Enrique Escolano
[ GiDlist ] preprocessor bug
In 3D elements it does not have sense to speak of clockwise orientation.
The first face of the elements is located randomly (depending on the way that has been created the geometry, etc). GiD cannot guarantee where this face points, only guarantees that this first face (nodes 1-2-3-4) points inside of the element.
In your simple example, the direction is correct by chance (if the piece is rotated 180º, the orientation swaps).
If your solver requires the face pointing +y considered as the first, you can reorganize, in the file *, bas, the way in which these connectivities are written, as it is mentioned in the previous message.
For example, it is checked which of the faces points to +Y vector
If the following 6 faces are considered (pointing inside the element):
face 1: 1-2-3-4
face 2: 8-7-6-5
face 3: 1-5-6-2
face 4: 3-7-8-4
face 5: 2-6-7-3
face 6: 1-4-8-5
1) Look for the unit normal of each face with a vectorial product of its 3 first ABC nodes:
Normal=AB^BC / |ab^bc|
2) Verify if the scalar product with the +Y vector (0,1,0) is approximately 1 ( 0,99 actually)
Once is known if one of the 6 faces points the wished direction, write the connectivities, rearranging the numbers as if is considered this the first face of the element
The file * bas would become of the following way:
(Is Attached final-1.bas with the mentioned changes)
*loop elems
*set var CARAY(int)=0
*if(CARAY==0)
*#cara1: 1-2-3-4
*set var ABX(real)=Operation(NodesCoord(2,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(2,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(2,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(3,1,real)-NodesCoord(2,1,real))
*set var BCY(real)=Operation(NodesCoord(3,2,real)-NodesCoord(2,2,real))
*set var BCZ(real)=Operation(NodesCoord(3,3,real)-NodesCoord(2,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=1
*endif
*endif
*if(CARAY==0)
*#cara2: 8-7-6-5
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(8,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(8,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(8,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=2
*endif
*endif
*if(CARAY==0)
*#cara3: 1-5-6-2
*set var ABX(real)=Operation(NodesCoord(5,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(5,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(5,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(5,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(5,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(5,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=3
*endif
*endif
*if(CARAY==0)
*#cara4: 3-7-8-4
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(3,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(3,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(3,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=4
*endif
*endif
*if(CARAY==0)
*#cara5: 2-6-7-3
*set var ABX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(2,1,real))
*set var ABY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(2,2,real))
*set var ABZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(2,3,real))
*set var BCX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(6,1,real))
*set var BCY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(6,2,real))
*set var BCZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(6,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==0)
*#cara6: 1-4-8-5
*set var ABX(real)=Operation(NodesCoord(4,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(4,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(4,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(4,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(4,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(4,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==1)
*elemsConec(1) *elemsConec(9) *elemsConec(2) *elemsConec(10) *elemsConec(3) *\
*elemsConec(11) *elemsConec(4) *elemsConec(12) *elemsConec(13) *elemsConec(14)*\
*elemsConec(15) *elemsConec(16) *elemsConec(5) *elemsConec(17) *elemsConec(6)*\
*elemsConec(18) *elemsConec(7) *elemsConec(19) *elemsConec(8) *elemsConec(20)
*elseif(CARAY==2)
*elemsConec(20) *elemsConec(8) *elemsConec(19) *elemsConec(7) *elemsConec(18) *\
*elemsConec(6) *elemsConec(17) *elemsConec(5) *elemsConec(16) *elemsConec(15)*\
*elemsConec(14) *elemsConec(13) *elemsConec(12) *elemsConec(4) *elemsConec(11)*\
*elemsConec(3) *elemsConec(10) *elemsConec(2) *elemsConec(9) *elemsConec(1)
*elseif(CARAY==3)
... face=*CARAY
*elseif(CARAY==4)
... face=*CARAY
*elseif(CARAY==5)
... face=*CARAY
*elseif(CARAY==6)
... face=*CARAY
*else
Not exist face pointing to +y axis
*endif
*set var CARAY(int)=0
*end elems
*endif
*if(ndime==2)
*#----- 8-node quadrilateral Y +ve upward ----------
*if(gendata(2,int)==8)
*loop elems
*elemsConec(4)*elemsConec(7)*elemsConec(3)*elemsConec(6)*elemsConec(2)*\
*elemsConec(5)*elemsConec(1)*elemsConec(8)
*end elems
NOTE: the connectivities are written according to your numeration, different from the one of GiD:
As you can check, this solution works but it is slow and annoying. The best option is integrate this algorithm inside your calculations code.
----- Original Message -----
From: M. A. Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 3:05 PM
Subject: Re: [ GiDlist ] preprocessor bug
Thank you sir for your response
I understand that the normal to the face does not have to point in the +Y direction. But, the point is the "consistency". why some elements are being generated counting the nodes clockwise and some are counterclockwise. And why it worked for the single volume and did not work for the multi-volume mesh.
Also If there is consistency, the connectivity writing will be much easier to control in the .bas file. Some solvers require that the 20 noded element must be written in a certain direction in order to define the correct shape function at the proper node. This does not apply to the 8 noded brick element (for example) because the 8 shape functions are the same.
This is the case with my solver. It requires that the element connectivity being numbered in a consistent manner in the counterclockwise direction and apparently the preprocessor can not do that for a complex geometries.
I would appreciate your help if you could elaborate on the *operation command and how is it going to work in order to make the .bas file writes the connectivity for all the elements in a consistent manner counting in one face (x-z for example) and going perpendicular.
Thanks
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 7:39 AM
Subject: Re: [ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2616 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2533 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: final-1.bas
Type: application/octet-stream
Size: 8420 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.obj
The first face of the elements is located randomly (depending on the way that has been created the geometry, etc). GiD cannot guarantee where this face points, only guarantees that this first face (nodes 1-2-3-4) points inside of the element.
In your simple example, the direction is correct by chance (if the piece is rotated 180º, the orientation swaps).
If your solver requires the face pointing +y considered as the first, you can reorganize, in the file *, bas, the way in which these connectivities are written, as it is mentioned in the previous message.
For example, it is checked which of the faces points to +Y vector
If the following 6 faces are considered (pointing inside the element):
face 1: 1-2-3-4
face 2: 8-7-6-5
face 3: 1-5-6-2
face 4: 3-7-8-4
face 5: 2-6-7-3
face 6: 1-4-8-5
1) Look for the unit normal of each face with a vectorial product of its 3 first ABC nodes:
Normal=AB^BC / |ab^bc|
2) Verify if the scalar product with the +Y vector (0,1,0) is approximately 1 ( 0,99 actually)
Once is known if one of the 6 faces points the wished direction, write the connectivities, rearranging the numbers as if is considered this the first face of the element
The file * bas would become of the following way:
(Is Attached final-1.bas with the mentioned changes)
*loop elems
*set var CARAY(int)=0
*if(CARAY==0)
*#cara1: 1-2-3-4
*set var ABX(real)=Operation(NodesCoord(2,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(2,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(2,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(3,1,real)-NodesCoord(2,1,real))
*set var BCY(real)=Operation(NodesCoord(3,2,real)-NodesCoord(2,2,real))
*set var BCZ(real)=Operation(NodesCoord(3,3,real)-NodesCoord(2,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=1
*endif
*endif
*if(CARAY==0)
*#cara2: 8-7-6-5
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(8,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(8,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(8,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=2
*endif
*endif
*if(CARAY==0)
*#cara3: 1-5-6-2
*set var ABX(real)=Operation(NodesCoord(5,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(5,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(5,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(5,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(5,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(5,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=3
*endif
*endif
*if(CARAY==0)
*#cara4: 3-7-8-4
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(3,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(3,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(3,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=4
*endif
*endif
*if(CARAY==0)
*#cara5: 2-6-7-3
*set var ABX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(2,1,real))
*set var ABY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(2,2,real))
*set var ABZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(2,3,real))
*set var BCX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(6,1,real))
*set var BCY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(6,2,real))
*set var BCZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(6,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==0)
*#cara6: 1-4-8-5
*set var ABX(real)=Operation(NodesCoord(4,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(4,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(4,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(4,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(4,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(4,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==1)
*elemsConec(1) *elemsConec(9) *elemsConec(2) *elemsConec(10) *elemsConec(3) *\
*elemsConec(11) *elemsConec(4) *elemsConec(12) *elemsConec(13) *elemsConec(14)*\
*elemsConec(15) *elemsConec(16) *elemsConec(5) *elemsConec(17) *elemsConec(6)*\
*elemsConec(18) *elemsConec(7) *elemsConec(19) *elemsConec(8) *elemsConec(20)
*elseif(CARAY==2)
*elemsConec(20) *elemsConec(8) *elemsConec(19) *elemsConec(7) *elemsConec(18) *\
*elemsConec(6) *elemsConec(17) *elemsConec(5) *elemsConec(16) *elemsConec(15)*\
*elemsConec(14) *elemsConec(13) *elemsConec(12) *elemsConec(4) *elemsConec(11)*\
*elemsConec(3) *elemsConec(10) *elemsConec(2) *elemsConec(9) *elemsConec(1)
*elseif(CARAY==3)
... face=*CARAY
*elseif(CARAY==4)
... face=*CARAY
*elseif(CARAY==5)
... face=*CARAY
*elseif(CARAY==6)
... face=*CARAY
*else
Not exist face pointing to +y axis
*endif
*set var CARAY(int)=0
*end elems
*endif
*if(ndime==2)
*#----- 8-node quadrilateral Y +ve upward ----------
*if(gendata(2,int)==8)
*loop elems
*elemsConec(4)*elemsConec(7)*elemsConec(3)*elemsConec(6)*elemsConec(2)*\
*elemsConec(5)*elemsConec(1)*elemsConec(8)
*end elems
NOTE: the connectivities are written according to your numeration, different from the one of GiD:
As you can check, this solution works but it is slow and annoying. The best option is integrate this algorithm inside your calculations code.
----- Original Message -----
From: M. A. Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 3:05 PM
Subject: Re: [ GiDlist ] preprocessor bug
Thank you sir for your response
I understand that the normal to the face does not have to point in the +Y direction. But, the point is the "consistency". why some elements are being generated counting the nodes clockwise and some are counterclockwise. And why it worked for the single volume and did not work for the multi-volume mesh.
Also If there is consistency, the connectivity writing will be much easier to control in the .bas file. Some solvers require that the 20 noded element must be written in a certain direction in order to define the correct shape function at the proper node. This does not apply to the 8 noded brick element (for example) because the 8 shape functions are the same.
This is the case with my solver. It requires that the element connectivity being numbered in a consistent manner in the counterclockwise direction and apparently the preprocessor can not do that for a complex geometries.
I would appreciate your help if you could elaborate on the *operation command and how is it going to work in order to make the .bas file writes the connectivity for all the elements in a consistent manner counting in one face (x-z for example) and going perpendicular.
Thanks
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 7:39 AM
Subject: Re: [ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2616 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2533 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: final-1.bas
Type: application/octet-stream
Size: 8420 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001027/7598a977/attachment.obj
-
M. A. Meguid
[ GiDlist ] preprocessor bug
Dear Mr. Escolano
First of all, I would like to thank you for your help and assistance. It is really appreciated
Second, I tried this way of defining the face that is point to the +Y axis as you advised and it worked after little modification. But, I would like to further minimize the probability of the starting point in that face which could be one of the four corner points.
Is there any additional condition that could be added to define the starting point to be at the left lower corner of the face (for example, point 1 if face 1-5-6-2 pointing in +Y "GID numeration").
This condition is important for the solver to work properly.
Thank you again for your cooperation
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 2:03 PM
Subject: Re: [ GiDlist ] preprocessor bug
In 3D elements it does not have sense to speak of clockwise orientation.
The first face of the elements is located randomly (depending on the way that has been created the geometry, etc). GiD cannot guarantee where this face points, only guarantees that this first face (nodes 1-2-3-4) points inside of the element.
In your simple example, the direction is correct by chance (if the piece is rotated 180º, the orientation swaps).
If your solver requires the face pointing +y considered as the first, you can reorganize, in the file *, bas, the way in which these connectivities are written, as it is mentioned in the previous message.
For example, it is checked which of the faces points to +Y vector
If the following 6 faces are considered (pointing inside the element):
face 1: 1-2-3-4
face 2: 8-7-6-5
face 3: 1-5-6-2
face 4: 3-7-8-4
face 5: 2-6-7-3
face 6: 1-4-8-5
1) Look for the unit normal of each face with a vectorial product of its 3 first ABC nodes:
Normal=AB^BC / |ab^bc|
2) Verify if the scalar product with the +Y vector (0,1,0) is approximately 1 ( 0,99 actually)
Once is known if one of the 6 faces points the wished direction, write the connectivities, rearranging the numbers as if is considered this the first face of the element
The file * bas would become of the following way:
(Is Attached final-1.bas with the mentioned changes)
*loop elems
*set var CARAY(int)=0
*if(CARAY==0)
*#cara1: 1-2-3-4
*set var ABX(real)=Operation(NodesCoord(2,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(2,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(2,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(3,1,real)-NodesCoord(2,1,real))
*set var BCY(real)=Operation(NodesCoord(3,2,real)-NodesCoord(2,2,real))
*set var BCZ(real)=Operation(NodesCoord(3,3,real)-NodesCoord(2,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=1
*endif
*endif
*if(CARAY==0)
*#cara2: 8-7-6-5
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(8,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(8,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(8,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=2
*endif
*endif
*if(CARAY==0)
*#cara3: 1-5-6-2
*set var ABX(real)=Operation(NodesCoord(5,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(5,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(5,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(5,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(5,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(5,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=3
*endif
*endif
*if(CARAY==0)
*#cara4: 3-7-8-4
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(3,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(3,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(3,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=4
*endif
*endif
*if(CARAY==0)
*#cara5: 2-6-7-3
*set var ABX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(2,1,real))
*set var ABY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(2,2,real))
*set var ABZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(2,3,real))
*set var BCX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(6,1,real))
*set var BCY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(6,2,real))
*set var BCZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(6,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==0)
*#cara6: 1-4-8-5
*set var ABX(real)=Operation(NodesCoord(4,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(4,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(4,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(4,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(4,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(4,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==1)
*elemsConec(1) *elemsConec(9) *elemsConec(2) *elemsConec(10) *elemsConec(3) *\
*elemsConec(11) *elemsConec(4) *elemsConec(12) *elemsConec(13) *elemsConec(14)*\
*elemsConec(15) *elemsConec(16) *elemsConec(5) *elemsConec(17) *elemsConec(6)*\
*elemsConec(18) *elemsConec(7) *elemsConec(19) *elemsConec(8) *elemsConec(20)
*elseif(CARAY==2)
*elemsConec(20) *elemsConec(8) *elemsConec(19) *elemsConec(7) *elemsConec(18) *\
*elemsConec(6) *elemsConec(17) *elemsConec(5) *elemsConec(16) *elemsConec(15)*\
*elemsConec(14) *elemsConec(13) *elemsConec(12) *elemsConec(4) *elemsConec(11)*\
*elemsConec(3) *elemsConec(10) *elemsConec(2) *elemsConec(9) *elemsConec(1)
*elseif(CARAY==3)
... face=*CARAY
*elseif(CARAY==4)
... face=*CARAY
*elseif(CARAY==5)
... face=*CARAY
*elseif(CARAY==6)
... face=*CARAY
*else
Not exist face pointing to +y axis
*endif
*set var CARAY(int)=0
*end elems
*endif
*if(ndime==2)
*#----- 8-node quadrilateral Y +ve upward ----------
*if(gendata(2,int)==8)
*loop elems
*elemsConec(4)*elemsConec(7)*elemsConec(3)*elemsConec(6)*elemsConec(2)*\
*elemsConec(5)*elemsConec(1)*elemsConec(8)
*end elems
NOTE: the connectivities are written according to your numeration, different from the one of GiD:
As you can check, this solution works but it is slow and annoying. The best option is integrate this algorithm inside your calculations code.
----- Original Message -----
From: M. A. Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 3:05 PM
Subject: Re: [ GiDlist ] preprocessor bug
Thank you sir for your response
I understand that the normal to the face does not have to point in the +Y direction. But, the point is the "consistency". why some elements are being generated counting the nodes clockwise and some are counterclockwise. And why it worked for the single volume and did not work for the multi-volume mesh.
Also If there is consistency, the connectivity writing will be much easier to control in the .bas file. Some solvers require that the 20 noded element must be written in a certain direction in order to define the correct shape function at the proper node. This does not apply to the 8 noded brick element (for example) because the 8 shape functions are the same.
This is the case with my solver. It requires that the element connectivity being numbered in a consistent manner in the counterclockwise direction and apparently the preprocessor can not do that for a complex geometries.
I would appreciate your help if you could elaborate on the *operation command and how is it going to work in order to make the .bas file writes the connectivity for all the elements in a consistent manner counting in one face (x-z for example) and going perpendicular.
Thanks
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 7:39 AM
Subject: Re: [ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2616 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2533 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment.bin
First of all, I would like to thank you for your help and assistance. It is really appreciated
Second, I tried this way of defining the face that is point to the +Y axis as you advised and it worked after little modification. But, I would like to further minimize the probability of the starting point in that face which could be one of the four corner points.
Is there any additional condition that could be added to define the starting point to be at the left lower corner of the face (for example, point 1 if face 1-5-6-2 pointing in +Y "GID numeration").
This condition is important for the solver to work properly.
Thank you again for your cooperation
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 2:03 PM
Subject: Re: [ GiDlist ] preprocessor bug
In 3D elements it does not have sense to speak of clockwise orientation.
The first face of the elements is located randomly (depending on the way that has been created the geometry, etc). GiD cannot guarantee where this face points, only guarantees that this first face (nodes 1-2-3-4) points inside of the element.
In your simple example, the direction is correct by chance (if the piece is rotated 180º, the orientation swaps).
If your solver requires the face pointing +y considered as the first, you can reorganize, in the file *, bas, the way in which these connectivities are written, as it is mentioned in the previous message.
For example, it is checked which of the faces points to +Y vector
If the following 6 faces are considered (pointing inside the element):
face 1: 1-2-3-4
face 2: 8-7-6-5
face 3: 1-5-6-2
face 4: 3-7-8-4
face 5: 2-6-7-3
face 6: 1-4-8-5
1) Look for the unit normal of each face with a vectorial product of its 3 first ABC nodes:
Normal=AB^BC / |ab^bc|
2) Verify if the scalar product with the +Y vector (0,1,0) is approximately 1 ( 0,99 actually)
Once is known if one of the 6 faces points the wished direction, write the connectivities, rearranging the numbers as if is considered this the first face of the element
The file * bas would become of the following way:
(Is Attached final-1.bas with the mentioned changes)
*loop elems
*set var CARAY(int)=0
*if(CARAY==0)
*#cara1: 1-2-3-4
*set var ABX(real)=Operation(NodesCoord(2,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(2,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(2,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(3,1,real)-NodesCoord(2,1,real))
*set var BCY(real)=Operation(NodesCoord(3,2,real)-NodesCoord(2,2,real))
*set var BCZ(real)=Operation(NodesCoord(3,3,real)-NodesCoord(2,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=1
*endif
*endif
*if(CARAY==0)
*#cara2: 8-7-6-5
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(8,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(8,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(8,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=2
*endif
*endif
*if(CARAY==0)
*#cara3: 1-5-6-2
*set var ABX(real)=Operation(NodesCoord(5,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(5,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(5,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(5,1,real))
*set var BCY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(5,2,real))
*set var BCZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(5,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=3
*endif
*endif
*if(CARAY==0)
*#cara4: 3-7-8-4
*set var ABX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(3,1,real))
*set var ABY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(3,2,real))
*set var ABZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(3,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(7,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(7,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(7,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=4
*endif
*endif
*if(CARAY==0)
*#cara5: 2-6-7-3
*set var ABX(real)=Operation(NodesCoord(6,1,real)-NodesCoord(2,1,real))
*set var ABY(real)=Operation(NodesCoord(6,2,real)-NodesCoord(2,2,real))
*set var ABZ(real)=Operation(NodesCoord(6,3,real)-NodesCoord(2,3,real))
*set var BCX(real)=Operation(NodesCoord(7,1,real)-NodesCoord(6,1,real))
*set var BCY(real)=Operation(NodesCoord(7,2,real)-NodesCoord(6,2,real))
*set var BCZ(real)=Operation(NodesCoord(7,3,real)-NodesCoord(6,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==0)
*#cara6: 1-4-8-5
*set var ABX(real)=Operation(NodesCoord(4,1,real)-NodesCoord(1,1,real))
*set var ABY(real)=Operation(NodesCoord(4,2,real)-NodesCoord(1,2,real))
*set var ABZ(real)=Operation(NodesCoord(4,3,real)-NodesCoord(1,3,real))
*set var BCX(real)=Operation(NodesCoord(8,1,real)-NodesCoord(4,1,real))
*set var BCY(real)=Operation(NodesCoord(8,2,real)-NodesCoord(4,2,real))
*set var BCZ(real)=Operation(NodesCoord(8,3,real)-NodesCoord(4,3,real))
*set var PVX(real)=Operation(ABY*BCZ-ABZ*BCY)
*set var PVY(real)=Operation(ABZ*BCX-ABX*BCZ)
*set var PVZ(real)=Operation(ABX*BCY-ABY*BCX)
*set var MODULO(real)=Operation(sqrt(PVX*PVX+PVY*PVY+PVZ*PVZ))
*set var CANGLEY=Operation(PVX/MODULO)
*if(CANGLEY(real)0.99)
*set var CARAY=5
*endif
*endif
*if(CARAY==1)
*elemsConec(1) *elemsConec(9) *elemsConec(2) *elemsConec(10) *elemsConec(3) *\
*elemsConec(11) *elemsConec(4) *elemsConec(12) *elemsConec(13) *elemsConec(14)*\
*elemsConec(15) *elemsConec(16) *elemsConec(5) *elemsConec(17) *elemsConec(6)*\
*elemsConec(18) *elemsConec(7) *elemsConec(19) *elemsConec(8) *elemsConec(20)
*elseif(CARAY==2)
*elemsConec(20) *elemsConec(8) *elemsConec(19) *elemsConec(7) *elemsConec(18) *\
*elemsConec(6) *elemsConec(17) *elemsConec(5) *elemsConec(16) *elemsConec(15)*\
*elemsConec(14) *elemsConec(13) *elemsConec(12) *elemsConec(4) *elemsConec(11)*\
*elemsConec(3) *elemsConec(10) *elemsConec(2) *elemsConec(9) *elemsConec(1)
*elseif(CARAY==3)
... face=*CARAY
*elseif(CARAY==4)
... face=*CARAY
*elseif(CARAY==5)
... face=*CARAY
*elseif(CARAY==6)
... face=*CARAY
*else
Not exist face pointing to +y axis
*endif
*set var CARAY(int)=0
*end elems
*endif
*if(ndime==2)
*#----- 8-node quadrilateral Y +ve upward ----------
*if(gendata(2,int)==8)
*loop elems
*elemsConec(4)*elemsConec(7)*elemsConec(3)*elemsConec(6)*elemsConec(2)*\
*elemsConec(5)*elemsConec(1)*elemsConec(8)
*end elems
NOTE: the connectivities are written according to your numeration, different from the one of GiD:
As you can check, this solution works but it is slow and annoying. The best option is integrate this algorithm inside your calculations code.
----- Original Message -----
From: M. A. Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 3:05 PM
Subject: Re: [ GiDlist ] preprocessor bug
Thank you sir for your response
I understand that the normal to the face does not have to point in the +Y direction. But, the point is the "consistency". why some elements are being generated counting the nodes clockwise and some are counterclockwise. And why it worked for the single volume and did not work for the multi-volume mesh.
Also If there is consistency, the connectivity writing will be much easier to control in the .bas file. Some solvers require that the 20 noded element must be written in a certain direction in order to define the correct shape function at the proper node. This does not apply to the 8 noded brick element (for example) because the 8 shape functions are the same.
This is the case with my solver. It requires that the element connectivity being numbered in a consistent manner in the counterclockwise direction and apparently the preprocessor can not do that for a complex geometries.
I would appreciate your help if you could elaborate on the *operation command and how is it going to work in order to make the .bas file writes the connectivity for all the elements in a consistent manner counting in one face (x-z for example) and going perpendicular.
Thanks
----- Original Message -----
From: Enrique Escolano
To: gidlist at gatxan.cimne.upc.es
Sent: Friday, October 27, 2000 7:39 AM
Subject: Re: [ GiDlist ] preprocessor bug
The 3D elements, in general, can be located in any
position and direction of the space. The program can only guarantee
the local numeration. In the case of 20 nodes hexaedron the local
numeration is the following one:
That is to say, the face (1-2-3-4), following its numeration defines a
normal pointing at the face (5-6-7-8), but this normal does
not have to point at the axis +Y or any other axis. In fact,
in general the sides of the element do not have to be parallel
to the X,Y or Z axis.
In your case, if the analysis requires that the face (1-2-3-4) point to the axis +Y,
you can check in the file *.bas wich of the 6 faces points approximately at this direction, writing the numeration consequently.
(simple calculus can be make in the file *.bas with the *operation command , which will be necessary to carry out the vectorial and scalar products required)
Note: In the 2D case, to help the user, GiD orients the elements with the normal pointing towards the axis +Z.
I hope that your doubts have been solved. Kindly.
Enrique Escolano
----- Original Message -----
From: M. A.Meguid
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, October 26, 2000 4:50 PM
Subject: [ GiDlist ] preprocessor bug
Dear GID users and developers
During my little experience working with GID and using it in solving several 2D and 3D problems, I noticed that there are problems with the preprocessor writing the element connectivity for a complex geometry in a consistent manner.
As far as I understand, The element connectivity order can be controlled by using the following statement in the .bas file
*elemsConec(1)*elemsConec(2)*elemsConec(3)*elemsConec(4)... etc
The following have been observed:
using the same .bas file for two different 3D meshes, the first one is a simple geometry consists of one single volume and the second is a complex geometry
consists of several volumes. It was observed that the same .bas file works well for the simple geometry and writes the exact element order as in the .bas file.
However, it produces inconsistent order of element connectivity for the more complex geometry, where, part of the mesh is being written in a correct manner and the rest of the elements are not.
This problem has been repeated several times for different problem configurations and I had to write the elements connectivity by hand !
Hope this is not a bug in the program.
If you have explanation or suggestion for this problem please email me.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2616 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2533 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 25542 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20001029/c9dfd527/attachment.bin