I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
[GiDlist] Element connectivity problem (repost)
Moderator: GiD Team
-
Enrique Escolano
[GiDlist] Element connectivity problem (repost)
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040107/ba273d90/attachment.htm
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040107/ba273d90/attachment.htm
-
Roger Young
[GiDlist] Element connectivity problem (repost)
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.bas
Type: application/octet-stream
Size: 683 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.dat
Type: application/octet-stream
Size: 689 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.cnd
Type: application/octet-stream
Size: 138 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.geo
Type: application/octet-stream
Size: 3172 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.lin
Type: application/octet-stream
Size: 212 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0004.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.msh
Type: application/octet-stream
Size: 540 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0005.obj
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.bas
Type: application/octet-stream
Size: 683 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.dat
Type: application/octet-stream
Size: 689 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.cnd
Type: application/octet-stream
Size: 138 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.geo
Type: application/octet-stream
Size: 3172 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.lin
Type: application/octet-stream
Size: 212 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0004.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.msh
Type: application/octet-stream
Size: 540 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/5d795b92/attachment-0005.obj
-
VSayako Willy
[GiDlist] tcl [.central.s info gendata OTHERFIELDS]
Hi Enrique, a GiD Team, and all
I tried to get the information from .prb file by
using
[.central.s info gendata FIELDNAME] but it said
"argument is wrong"..
What does it really mean by OTHERFIELDS and BOOKS
after gendata
if I have for example:
QUESION:Stress_Coefficient
VALUE:1
Then to get the value from FIELD: Stress_Coefficient
[.central.s info gendata Stress_Coefficient]
I wrote as above but got warning message as a "Wrong
argument"..
How would it be??
Regards.
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
I tried to get the information from .prb file by
using
[.central.s info gendata FIELDNAME] but it said
"argument is wrong"..
What does it really mean by OTHERFIELDS and BOOKS
after gendata
if I have for example:
QUESION:Stress_Coefficient
VALUE:1
Then to get the value from FIELD: Stress_Coefficient
[.central.s info gendata Stress_Coefficient]
I wrote as above but got warning message as a "Wrong
argument"..
How would it be??
Regards.
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
-
Enrique Escolano
[GiDlist] tcl [.central.s info gendata OTHERFIELDS]
.central.s info gendata
returns a list with the field names and current values, then you can get easy get from this list the desired field value, for example:
set Stress_Coefficient [lindex [.central.s info gendata] 2]
But, instead to access to field values by index, it's more easy to maintain the code (if are added or removed fields) using the fieldname
Inside the file dev_kit.tcl is defined a tcl procedure for this pourpose: proc GidUtils::GetProblemDataValue { fieldname }
For example, you must use
set Stress_Coefficient [GidUtils::GetProblemDataValue Stress_Coefficient]
The parameter OTHERFIELDS returns the value of other special fields, as HELP, DEPENDENCIES,
but in your sample only use QUESTION and VALUE, and then it not exists other fields.
The parameter BOOKS only has sense if are defined BOOKS in your problemtype
Note: With the field Book it is possible to split the data windows in other windows. For example, we can have two
windows for the materials, one for the steels and another for the concretes
Read GiD Help about Configuration files-Special fields
Enrique Escolano
----- Original Message -----
From: "VSayako Willy" vilaysako at yahoo.com
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, January 08, 2004 8:46 AM
Subject: [GiDlist] tcl [.central.s info gendata OTHERFIELDS]
Hi Enrique, a GiD Team, and all
I tried to get the information from .prb file by
using
[.central.s info gendata FIELDNAME] but it said
"argument is wrong"..
What does it really mean by OTHERFIELDS and BOOKS
after gendata
if I have for example:
QUESION:Stress_Coefficient
VALUE:1
Then to get the value from FIELD: Stress_Coefficient
[.central.s info gendata Stress_Coefficient]
I wrote as above but got warning message as a "Wrong
argument"..
How would it be??
Regards.
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/977dc182/attachment.htm
returns a list with the field names and current values, then you can get easy get from this list the desired field value, for example:
set Stress_Coefficient [lindex [.central.s info gendata] 2]
But, instead to access to field values by index, it's more easy to maintain the code (if are added or removed fields) using the fieldname
Inside the file dev_kit.tcl is defined a tcl procedure for this pourpose: proc GidUtils::GetProblemDataValue { fieldname }
For example, you must use
set Stress_Coefficient [GidUtils::GetProblemDataValue Stress_Coefficient]
The parameter OTHERFIELDS returns the value of other special fields, as HELP, DEPENDENCIES,
but in your sample only use QUESTION and VALUE, and then it not exists other fields.
The parameter BOOKS only has sense if are defined BOOKS in your problemtype
Note: With the field Book it is possible to split the data windows in other windows. For example, we can have two
windows for the materials, one for the steels and another for the concretes
Read GiD Help about Configuration files-Special fields
Enrique Escolano
----- Original Message -----
From: "VSayako Willy" vilaysako at yahoo.com
To: gidlist at gatxan.cimne.upc.es
Sent: Thursday, January 08, 2004 8:46 AM
Subject: [GiDlist] tcl [.central.s info gendata OTHERFIELDS]
Hi Enrique, a GiD Team, and all
I tried to get the information from .prb file by
using
[.central.s info gendata FIELDNAME] but it said
"argument is wrong"..
What does it really mean by OTHERFIELDS and BOOKS
after gendata
if I have for example:
QUESION:Stress_Coefficient
VALUE:1
Then to get the value from FIELD: Stress_Coefficient
[.central.s info gendata Stress_Coefficient]
I wrote as above but got warning message as a "Wrong
argument"..
How would it be??
Regards.
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040108/977dc182/attachment.htm
-
Roger Young
[GiDlist] Element connectivity problem (repost)
I made some progress with my connectivity problem...
With reference to p.200 (GlobalNodes) of the Reference Manual I think what I need to do is to
reverse the orientation on some of the faces namely
1562 -- 1265
2673 -- 2376
5876 -- 5678
In my model these faces are tagged 0,3,4 respectively. Hence in the Tag section of ucd.bas I have
something like
*# Tags over faces
*set cond FaceTag *elems *canrepeat
*loop elems *OnlyInCond
*set var n=cond(Tag,int)
*if((n==0)||(n=3)||(n=4))
*recnum *cond(Tag) quad *operation(globalnodes(1)-1) *operation(globalnodes(4)-1) *\
*operation(globalnodes(3)-1) *operation(globalnodes(2)-1)
*else
*recnum *cond(Tag) quad *operation(globalnodes(1)-1) *operation(globalnodes(2)-1) *\
*operation(globalnodes(3)-1) *operation(globalnodes(4)-1)
*endif
*set var recnum=operation(recnum+1)
*end elems
*#
Although this works for a number of examples it does seem a little ad hoc. What if I have a more
complicated model which is not a cuboid (but still using hex elements)? How can I identify which
boundary face elements need a reversed orientation for compatibility with the Deal library??
Since there is a consistent ordering in both GiD and Deal there must be a canonical transformation
between the two....
Could I ask for your opinion?
Regards,
Roger Young.
..................................................................................................
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
With reference to p.200 (GlobalNodes) of the Reference Manual I think what I need to do is to
reverse the orientation on some of the faces namely
1562 -- 1265
2673 -- 2376
5876 -- 5678
In my model these faces are tagged 0,3,4 respectively. Hence in the Tag section of ucd.bas I have
something like
*# Tags over faces
*set cond FaceTag *elems *canrepeat
*loop elems *OnlyInCond
*set var n=cond(Tag,int)
*if((n==0)||(n=3)||(n=4))
*recnum *cond(Tag) quad *operation(globalnodes(1)-1) *operation(globalnodes(4)-1) *\
*operation(globalnodes(3)-1) *operation(globalnodes(2)-1)
*else
*recnum *cond(Tag) quad *operation(globalnodes(1)-1) *operation(globalnodes(2)-1) *\
*operation(globalnodes(3)-1) *operation(globalnodes(4)-1)
*endif
*set var recnum=operation(recnum+1)
*end elems
*#
Although this works for a number of examples it does seem a little ad hoc. What if I have a more
complicated model which is not a cuboid (but still using hex elements)? How can I identify which
boundary face elements need a reversed orientation for compatibility with the Deal library??
Since there is a consistent ordering in both GiD and Deal there must be a canonical transformation
between the two....
Could I ask for your opinion?
Regards,
Roger Young.
..................................................................................................
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-
Enrique Escolano
[GiDlist] Element connectivity problem (repost)
If a GiD hexahedral has the nodes 1 2 3 4 5 6 7 8
then the vector product of the vectors 12 and 23 points inside (to the opposite face 5 6 7 8)
but in your (b) sample this vector product points outside, must swap the nodes 2-4 and 6-8
For the elements you must then write: (using numeration beginnig by 1, not 0)
*elemsconec(1) *elemsconec(4) *elemsconec(3) *elemsconec(2) *elemsconec(5) *elemsconec(8) *elemsconec(7) *elemsconec(6)
In Other hand, you can identify the face marked by a condition, the Implicit GiD Hexahedra faces are: 1234 1562 2673 3784 1485 5876
For example, the first face is 1234. Checking the second node, only this face has the node number 2 (local numeration) at this second location
*if(LocalNodes(2)==2)
This is the first Face
*endif
All GiD faces ABCD vector product ABxBC points inside the element, but in your sample (b) the faces numeration is different,
some faces points inside and some faces outside
This can be your bas file corrected (it's attached inside ucd.zip)
*#
*# Coordinates
*loop nodes
*operation(nodesnum-1) *nodescoord
*end nodes
*#
*# Hexahedral elements
*set elems(hexahedra)
*set var recnum=0
*loop elems
*recnum hex *operation(elemsconec(1)-1) *operation(elemsconec(4)-1) *operation(elemsconec(3)-1) *operation(elemsconec(2)-1) *operation(elemsconec(5)-1) *operation(elemsconec(8)-1) *operation(elemsconec(7)-1) *operation(elemsconec(7)-1)
*set var recnum=operation(recnum+1)
*end elems
*#
*# Tags over faces
*#Implicit GiD Hexahedra faces are: 1={1234} 2={1562} 3={2673} 4={3784} 5={1485} 6={5876}
*# desired ouput faces are A B C D E F
*set cond FaceTag *elems *canrepeat
*loop elems *OnlyInCond
*if(LocalNodes(2,int)==2)
*#GiD Face 1 - B
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(2,int)==5)
*#GiD Face 2 - E, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==2)
*#GiD Face 3 - F
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(1,int)==3)
*#GiD Face 4 - C
*cond(Tag) quad *operation(globalnodes(2)-1) *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1)
*elseif(LocalNodes(2,int)==4)
*#GiD Face 5 - D, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==5)
*#GiD Face 6 - A, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*endif
*end elems
Maibe it exists some order bug related to your desired output, but you can easy correct it.
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Thursday, January 08, 2004 5:20 AM
Subject: Re: [GiDlist] Element connectivity problem (repost)
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040109/86272a8e/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.zip
Type: application/x-zip-compressed
Size: 558 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040109/86272a8e/attachment.bin
then the vector product of the vectors 12 and 23 points inside (to the opposite face 5 6 7 8)
but in your (b) sample this vector product points outside, must swap the nodes 2-4 and 6-8
For the elements you must then write: (using numeration beginnig by 1, not 0)
*elemsconec(1) *elemsconec(4) *elemsconec(3) *elemsconec(2) *elemsconec(5) *elemsconec(8) *elemsconec(7) *elemsconec(6)
In Other hand, you can identify the face marked by a condition, the Implicit GiD Hexahedra faces are: 1234 1562 2673 3784 1485 5876
For example, the first face is 1234. Checking the second node, only this face has the node number 2 (local numeration) at this second location
*if(LocalNodes(2)==2)
This is the first Face
*endif
All GiD faces ABCD vector product ABxBC points inside the element, but in your sample (b) the faces numeration is different,
some faces points inside and some faces outside
This can be your bas file corrected (it's attached inside ucd.zip)
*#
*# Coordinates
*loop nodes
*operation(nodesnum-1) *nodescoord
*end nodes
*#
*# Hexahedral elements
*set elems(hexahedra)
*set var recnum=0
*loop elems
*recnum hex *operation(elemsconec(1)-1) *operation(elemsconec(4)-1) *operation(elemsconec(3)-1) *operation(elemsconec(2)-1) *operation(elemsconec(5)-1) *operation(elemsconec(8)-1) *operation(elemsconec(7)-1) *operation(elemsconec(7)-1)
*set var recnum=operation(recnum+1)
*end elems
*#
*# Tags over faces
*#Implicit GiD Hexahedra faces are: 1={1234} 2={1562} 3={2673} 4={3784} 5={1485} 6={5876}
*# desired ouput faces are A B C D E F
*set cond FaceTag *elems *canrepeat
*loop elems *OnlyInCond
*if(LocalNodes(2,int)==2)
*#GiD Face 1 - B
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(2,int)==5)
*#GiD Face 2 - E, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==2)
*#GiD Face 3 - F
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(1,int)==3)
*#GiD Face 4 - C
*cond(Tag) quad *operation(globalnodes(2)-1) *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1)
*elseif(LocalNodes(2,int)==4)
*#GiD Face 5 - D, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==5)
*#GiD Face 6 - A, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*endif
*end elems
Maibe it exists some order bug related to your desired output, but you can easy correct it.
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Thursday, January 08, 2004 5:20 AM
Subject: Re: [GiDlist] Element connectivity problem (repost)
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040109/86272a8e/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd.zip
Type: application/x-zip-compressed
Size: 558 bytes
Desc: not available
Url : http://listas.cimne.upc.edu/pipermail/gidlist/attachments/20040109/86272a8e/attachment.bin
-
Roger Young
[GiDlist] Element connectivity problem (repost)
Enrique: the key -- as you point out -- is to use the local numbering (LocalNodes)
to help identify the appropriate global orientation of the boundary faces. Thanks very much
for your assistance!!
Regards,
Roger Young
............................................................................................
On Fri, 9 Jan 2004 13:40:49 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
If a GiD hexahedral has the nodes 1 2 3 4 5 6 7 8
then the vector product of the vectors 12 and 23 points inside (to the opposite face 5 6 7 8)
but in your (b) sample this vector product points outside, must swap the nodes 2-4 and 6-8
For the elements you must then write: (using numeration beginnig by 1, not 0)
*elemsconec(1) *elemsconec(4) *elemsconec(3) *elemsconec(2) *elemsconec(5) *elemsconec(8) *elemsconec(7) *elemsconec(6)
In Other hand, you can identify the face marked by a condition, the Implicit GiD Hexahedra faces are: 1234 1562 2673 3784 1485 5876
For example, the first face is 1234. Checking the second node, only this face has the node number 2 (local numeration) at this second location
*if(LocalNodes(2)==2)
This is the first Face
*endif
All GiD faces ABCD vector product ABxBC points inside the element, but in your sample (b) the faces numeration is different,
some faces points inside and some faces outside
This can be your bas file corrected (it's attached inside ucd.zip)
*#
*# Coordinates
*loop nodes
*operation(nodesnum-1) *nodescoord
*end nodes
*#
*# Hexahedral elements
*set elems(hexahedra)
*set var recnum=0
*loop elems
*recnum hex *operation(elemsconec(1)-1) *operation(elemsconec(4)-1) *operation(elemsconec(3)-1) *operation(elemsconec(2)-1) *operation(elemsconec(5)-1) *operation(elemsconec(8)-1) *operation(elemsconec(7)-1) *operation(elemsconec(7)-1)
*set var recnum=operation(recnum+1)
*end elems
*#
*# Tags over faces
*#Implicit GiD Hexahedra faces are: 1={1234} 2={1562} 3={2673} 4={3784} 5={1485} 6={5876}
*# desired ouput faces are A B C D E F
*set cond FaceTag *elems *canrepeat
*loop elems *OnlyInCond
*if(LocalNodes(2,int)==2)
*#GiD Face 1 - B
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(2,int)==5)
*#GiD Face 2 - E, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==2)
*#GiD Face 3 - F
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(1,int)==3)
*#GiD Face 4 - C
*cond(Tag) quad *operation(globalnodes(2)-1) *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1)
*elseif(LocalNodes(2,int)==4)
*#GiD Face 5 - D, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==5)
*#GiD Face 6 - A, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*endif
*end elems
Maibe it exists some order bug related to your desired output, but you can easy correct it.
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Thursday, January 08, 2004 5:20 AM
Subject: Re: [GiDlist] Element connectivity problem (repost)
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist
to help identify the appropriate global orientation of the boundary faces. Thanks very much
for your assistance!!
Regards,
Roger Young
............................................................................................
On Fri, 9 Jan 2004 13:40:49 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
If a GiD hexahedral has the nodes 1 2 3 4 5 6 7 8
then the vector product of the vectors 12 and 23 points inside (to the opposite face 5 6 7 8)
but in your (b) sample this vector product points outside, must swap the nodes 2-4 and 6-8
For the elements you must then write: (using numeration beginnig by 1, not 0)
*elemsconec(1) *elemsconec(4) *elemsconec(3) *elemsconec(2) *elemsconec(5) *elemsconec(8) *elemsconec(7) *elemsconec(6)
In Other hand, you can identify the face marked by a condition, the Implicit GiD Hexahedra faces are: 1234 1562 2673 3784 1485 5876
For example, the first face is 1234. Checking the second node, only this face has the node number 2 (local numeration) at this second location
*if(LocalNodes(2)==2)
This is the first Face
*endif
All GiD faces ABCD vector product ABxBC points inside the element, but in your sample (b) the faces numeration is different,
some faces points inside and some faces outside
This can be your bas file corrected (it's attached inside ucd.zip)
*#
*# Coordinates
*loop nodes
*operation(nodesnum-1) *nodescoord
*end nodes
*#
*# Hexahedral elements
*set elems(hexahedra)
*set var recnum=0
*loop elems
*recnum hex *operation(elemsconec(1)-1) *operation(elemsconec(4)-1) *operation(elemsconec(3)-1) *operation(elemsconec(2)-1) *operation(elemsconec(5)-1) *operation(elemsconec(8)-1) *operation(elemsconec(7)-1) *operation(elemsconec(7)-1)
*set var recnum=operation(recnum+1)
*end elems
*#
*# Tags over faces
*#Implicit GiD Hexahedra faces are: 1={1234} 2={1562} 3={2673} 4={3784} 5={1485} 6={5876}
*# desired ouput faces are A B C D E F
*set cond FaceTag *elems *canrepeat
*loop elems *OnlyInCond
*if(LocalNodes(2,int)==2)
*#GiD Face 1 - B
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(2,int)==5)
*#GiD Face 2 - E, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==2)
*#GiD Face 3 - F
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1) *operation(globalnodes(2)-1)
*elseif(LocalNodes(1,int)==3)
*#GiD Face 4 - C
*cond(Tag) quad *operation(globalnodes(2)-1) *operation(globalnodes(3)-1) *operation(globalnodes(4)-1) *operation(globalnodes(1)-1)
*elseif(LocalNodes(2,int)==4)
*#GiD Face 5 - D, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*elseif(LocalNodes(1,int)==5)
*#GiD Face 6 - A, swap
*cond(Tag) quad *operation(globalnodes(3)-1) *operation(globalnodes(2)-1) *operation(globalnodes(1)-1) *operation(globalnodes(4)-1)
*endif
*end elems
Maibe it exists some order bug related to your desired output, but you can easy correct it.
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Thursday, January 08, 2004 5:20 AM
Subject: Re: [GiDlist] Element connectivity problem (repost)
Enrique: Thanks very much for your comments, they have been very helpful.
However I am still not able to bring the two orderings (a) and (b)
into coincidence. The tag (quad) section in (a) has the following interpretation:
0 5103 front y=0 - 5301
1 7624 back y=1
2 2014 bottom z=0
3 7415 right x=1 - 7514
4 7537 top z=1 - 7635
5 6302 left x=0
col1: tag number
col2: the 4 nodes defining the quad surface
col4: quad plane
col3: description of quad
The ordering (a) can be made equivalent to (b) by making the changes shown,
but only in tags 0,3,4. Thus a global reordering (the same for each quad)
is not what is required.
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Nevertheless the data (ucd.dat) has been produced by GiD!
Could you perhaps have a look at my procedure?
I attach the ucd database and ucd.bas.
Thanks for your help,
Roger.
On Wed, 7 Jan 2004 12:51:52 +0100
"Enrique Escolano" escolano at cimne.upc.es wrote:
In your problemtype *.bas file, you can write the 'GiD default' element connectivities with *elemsconec,
or can write your own order with *elemsconec(number), where number is a integer from 1 to the element number of nodes
In fact, in your sample (a):
0 0 hex 7 6 2 4 5 3 0 1
the connectivities are not the GiD default !!!
The vector product 7-6 X 6-2 by default points inside the element, but in your sample it points outside.
Instead the default order:
*loop elems
*elemsnum hex *elemsconec
*end elems
Can select your own output order, for example:
*loop elems
*elemsnum hex *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4) *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
quad 0 *elemsconec(1) *elemsconec(2) *elemsconec(3) *elemsconec(4)
quad 1 *elemsconec(5) *elemsconec(6) *elemsconec(7) *elemsconec(8)
...
*end elems
If your nodes number must start from 0 instead to 1, can use the *operation command:
*elemsnum hex *operation(elemsconec(1)-1) *operation(elemsconec(2)-1) , etc
Regards
Enrique Escolano
----- Original Message -----
From: "Roger Young" r.young at irl.cri.nz
To: gidlist at gatxan.cimne.upc.es
Cc: r.young at irl.cri.nz
Sent: Wednesday, January 07, 2004 12:37 AM
Subject: [GiDlist] Element connectivity problem (repost)
I posted this inquiry before Xmas but it may have got lost in the rush,
hence this repost.
Basically the problem concerns the GiD connectivity format which is
apparently incompatible with my application. Is there any way to
control/alter this format (particularly when specifying the
connectivity of surfaces)?
Roger Young.
*********************************************************************
Hello, I am trying to prepare a customized connectivity
data in a particular format ("ucd"). The data file
is created correctly following the specified template,
but it is incompatible with the orientations assumed
in the application (using the deal.II FE library).
Is it possible to specify the connectivity ordering in GiD?
For example, GiD has left-handed axes, but deal.II assumes
a right-handed system. Probably if I could work with right-handed
axes in GiD I could solve my problem? What is the recommended
procedure for working with differently ordered systems? I looked
at the "swap" feature and at defining a "local coordinate system"
but could not see how to make these work.
To make clear my problem I list below 2 ucd data files, the first (a) has been
produced by GiD, the second (b) is done by hand. The 2 formats are not
compatible because of the different implied orderings. The GiD file (a)
does not work with my application, whereas (b) is accepted.
Thanks for your help.
Seasons Greetings,
Roger Young.
Industrial Research Ltd.,
Box 31-310 Lower Hutt,
New Zealand.
r.young at irl.cri.nz
Note: the two example files below list the nodal positions
and connectivities of a unit cube. The hex line
gives the connectivity of the element, the quad lines give the
connectivities of the 6 faces. It can be seen that there
is no 1-1 mapping between (a) and (b) which preserves the orientations.
Note the numbering is 0,1,2,.... not 1,2,3....
........................................................................
(a)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 0 1 0
3 0 0 1
4 1 1 0
5 1 0 1
6 0 1 1
7 1 1 1
0 0 hex 7 6 2 4 5 3 0 1
1 0 quad 5 1 0 3
2 1 quad 7 6 2 4
3 2 quad 2 0 1 4
4 3 quad 7 4 1 5
5 4 quad 7 5 3 6
6 5 quad 6 3 0 2
...........................................................................
(b)
8 7 0 0 0
0 0 0 0
1 1 0 0
2 1 0 1
3 0 0 1
4 0 1 0
5 1 1 0
6 1 1 1
7 0 1 1
0 0 hex 0 1 2 3 4 5 6 7
1 0 quad 0 1 2 3
2 1 quad 4 5 6 7
3 2 quad 0 1 5 4
4 3 quad 1 5 6 2
5 4 quad 3 2 6 7
6 5 quad 0 4 7 3
_______________________________________________
GiDlist mailing list
GiDlist at gid.cimne.upc.es
http://gid.cimne.upc.es/mailman/listinfo/gidlist