Un-meshing the
Finite Elements in Building Models
Finite Element (FE)
software packages are broadly classified into ‘General’ FE packages and ‘Civil Engineering’
specific FE packages – for example, ANSYS and STAAD.Pro respectively, to
mention one from each. One specific aspect that distinctly differentiates the
two is that for the former, the frame members – physical beams and columns
(both being represented by ‘beam’ elements, like BEAM188 in ANSYS) – has to be
meshed for the analysis, whereas in the latter, the analysis results, like Bending
Moment (BM), Shear Force (SF), Axial Force (AF), etc., are suitably obtained
even without meshing those – as in STAAD.Pro, a single beam element can
represent one full physical beam (from one beam-column junction spanning to the
next), and likewise, one single beam element can represent one full physical column
(from one floor to the next). This is partly due to the slightly different
approaches taken by the analysis engine itself. But this difference makes it easier
for the packages of the ‘Civil Engg’ specific category to include the
structural design utilizing the analysis results.
The
issue to deal with…
To explain this a bit more
clearly, in the design of Reinforced Concrete (RC) buildings, the BM and SF for
beams (or BM and AF in case of columns) of the full member is required for the
design, and conveniently, in packages like STAAD.Pro, the BM and SF of the
single elements represent that of the whole physical beam (or column), following
closely the requirement of the design module. To elaborate with an example, the
design of an RC beam requires the maximum hogging BM’s at both ends and the
maximum sagging BM from along the span of the whole physical beam. The reinforcement
is calculated and provided as: (1) nominal amount of reinforcement bars
provided throughout the top and bottom, and then (2) additional reinforcement
bars at the top face of the beam either ends, at either ends extending towards
the mid-span, each up to a length of one-fourth the span-length of the beam;
(3) additional reinforcement bars at the bottom face of the beam in the
mid-span portion, extending towards both ends, terminating at points short of about
one-tenth of the span-length of the beam (Fig. 1 – of course, it is slightly different for cases with seismic design). This shows how the BM of the
full beam span is required for design. A similar set of rules applies in
providing shear reinforcement for the beam.
Such an exercise with
the results from the kind of a meshed approach in a general FE package would
prove something of a nightmare: having to integrate the individual BM and SF of
each little piece elements bit by bit into a continuity; while limiting to only
those elements that form part of the physical beam. One may wonder at this
point, what then makes it so easy for simply displaying the BM and SF diagrams
– it is only when it is to be used for the structural design of the beam, it
proves cumbersome. This is primarily because the ‘parent program’ (which is soon to be discussed), which receives the analysis results, receives them as a list of nodes (along with nodal coordinates), and a list of beam elements (along with nodal connectivity). It is then up to the design module to unscramble the list and find the order of the element connections.
A
utility program to solve with…
So what I’m providing
here is a sample program that sorts these element of such a meshed structure
and gives you the list of the ID numbers of the elements that make up each
physical beam and column; and for each, the list being in order of sequence
along with the list of the inter connecting nodes. The word in the heading
‘un-meshing’ was for hype, and a bit misleading, but let it be. Now, having
been clarified the real utility of the program, continue reading…
Whom
the utility program is meant for…
So who is this program
utility aimed at? Anyone who wants to develop a design application that takes
the analysis results from a building model done in general FE package (like ANSYS,
for example, or any other), and do the structural design with it – be it RC or steel
– and this utility comes handy to them. Hereafter, the design application is
referred to as the ‘parent program’ that ‘executes’ the utility program
presented here.
What
does it do…
This utility program is
the end result of a purely hobby experiment. So (as of now), this is just a
console program that does the job, and not (yet) usefully packaged as a DLL
that another program under development can communicate directly with. The application
is provided as an executable file that…
- reads prepared text files containing (i) nodal IDs and coordinates list and (ii) elemental IDs and their nodal connectivity list and
- writes text files of the list of elements that makes the bits of each physical beam, in the order of their sequence, and another text file that lists the intermediate nodes in the aforementioned element sequence, again, in the order of the corresponding node sequence.
So in order for the
‘structural design’ program developer to use this utility, he has to program
his application to
- write all the node number IDs (with coordinates) into a text file named “Nodes.txt” – one node per line, space (or multi-space) separated,
- write all the beam element number IDs (with nodal connectivity) into another text file named “Beams.txt” – one element per line, space (or multi-space) separated,
- and also a text file that contains the number of data lines (rows) in the above two files into a text file named “Data.txt”,
- and then run this utility.
There is also a file
named “FilePath.txt” located where the utility program is located in, that
gives the path to the location of the above three written data text files
(which will be decided to be the location of the FE input file, I suppose), and
also where the processed output text files will be written. The path as written
in this file should end with a closing “\” character.
This program accepts
only details of 2-noded beam elements, and not 3-noded (2nd order) beam
elements. If the latter is the case, provide only the two end nodes of the beam
elements in “Beams.txt” file
More
about it
Now let’s go a little
deeper in to the thing, with a small sample model in a general FE package like
ANSYS, as a meshed model:
Fig.2 The model of a simple RC structure
For further reference, the above model is
shown with the slabs and associated nodes hidden – only hidden, not delegated:
Fig.3 The node ID numbers of the simple RC structure
The mesh details of the above structure
are as follows, when written on to text files for input into this utility
program (only the first few lines shown):
File: Data.txt
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(Contents for each line:
1st line: no. of nodes
listed in ‘Nodes.txt’
2nd line: no. of beam
elements listed in ‘Beams.txt’)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
On running the executing the utility, the
following files are written:
File: noOfData.txt
|
File: keyNodes.txt
|
|||||||||||||||||||||||||||||||
(Contents: no. of key nodes listed –
ie., the number of rows in files 'keyNodes.txt', 'beamLine.txt' and 'keyNodes.txt')
|
(Contents in order for each line:
Key Node ID no.,
number of elements in the sequence
along the physical beam up to the other end):
|
|||||||||||||||||||||||||||||||
15
|
|
File: beamLine.txt
|
File: nodeLine.txt
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(Contents for each line: Beam element
ID nos. in order of sequence along the physical beam up to the other end):
|
(Contents for each line: Node ID nos.
in order of sequence along the physical beam up to the other end):
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
The 1st value
(data) in each row of “keyNodes.txt” file gives the key node ID no. from which
physical beam represented by the corresponding row of “beamLine.txt” and "nodeLine.txt" starts. The 2nd value gives the number of elements and
nodes in each sequence in “beamLine.txt” and “nodeLine.txt”. For a physical
beam, the first node, being the key node is given as the 1st value
in the corresponding row in “keyNodes.txt”, while the “nodeLine.txt” file gives
node ID nos. from the second node onwards, up to the last node which is also a
key node.
Please note that the
term ‘key node’ refers to those nodes in the model that are the starting and
ending points of physical beams and columns. They are identified as nodes...
- to which more than two beam elements are connected, like ones at the beam column junctions or beam junctions),
- at the free ends of beams or columns, like one at the unconnected end of a cantilever beam or the bottom end of the column that connects to the foundation,
- where two beam elements connect, but are at an angle to each other. This is a special case, since every intermediate node in the mesh of a physical beam has two elements connected to it. But here, those that connect at an angle to each other are separated out as key nodes. In order to exclude the intermediate joints in segmented curved beams, the angle between the beam elements meeting at the node is limited to being than 120°, in order for that node to be considered as being a key node.
In the “keyNodes.txt”
file, when more than one beam starts from a key node, the starting key node ID
no. is repeated in subsequent rows, each representing that for each physical
beam. Also when a physical beam starting from a key node and ending at another
is listed, that physical beam is excluded from the list of beams listed for the
second key node.
Also note that the “keyNodes.txt”
may not list every key node in the structure. For example, the key node 58 is
not listed in the “keyNodes.txt”, since the two physical beams connected to it
have already been listed in rows 8 and 15 (element sequence listed from the
other end of the beam), leaving no beams to be listed for the key node (without
getting repeated). If one requires the list of all key nodes, for some reason, list
out all the key nodes listed in “keNodes.txt” as well as the last data value in
“nodeLine.txt” (and group then to eliminate the repetitions).
A specific example…
To illustrate the
above, as an example, consider the physical beam circled in red in the figures
below..
(a) (b)
Fig. 5 (a) Node number IDs and (b)
element number IDs of the physical beam represented by the 10th row
of the output files
For example, the 10th
row of the output file gives details of a physical beam (Fig. 5)as follows: the
1st data value in that row in “keyNodes.txt” file indicates that the
physical beam starts from the key node no. 18. The node 18 is actually
connected to two physical beams and a physical column, but the column has
already been listed in row 9 (in sequence from the other end of the column), and
the other physical beam listed in row 11. The row 10 of the three output files are as
follows..
10th row of "keyNodes.txt"
18
|
7
|
10th row of "beamLine.txt"
44
|
45
|
46
|
47
|
48
|
49
|
50
|
10th row of "nodeLine.txt"
47
|
48
|
49
|
50
|
51
|
52
|
26
|
Considering the aforementioned
physical beam from the “beamLine.txt” it indicates that it starts with element
ID 44, and connects to elements of IDs 45, 46 and so on up to 50. And the nodes
in that line start with node ID no. 18 (from “keyNodes.txt”) and continues with
47, 48 49 and so on up to 26 (from “nodeLine.txt”). Please note that here the node ID numbers are
listed in a separate file to facilitate in building the overall BM from these
elements, even to account for any case (if at all) where a couple of the
intermediate elements have connectivity (and thus its local axis) in the
direction opposite to that of the rest in the line.
As mentioned above, it
may be noted that from the 2nd value in from “keyNodes.txt” indicates
that there are 7 elements making up the physical beam in question, where the
elements are connected as listed in “beamLine.txt”, as
where the first node ID (of 18) is read
off as the first data in “keyNodes.txt”, while the rest of the node IDs (ie., 44,
45 and so on) is read from “nodeLine.txt”. So the sequence of connection from
node to element to node to element is as follows (the top row being those of
node ID’s in sequence and the bottom being element ID’s in sequence):
In the above model, the
element IDs are found to be in sequential for all the intermediate elements. In
a package like ANSYS, if each physical beam is modeled as a line (CAD object),
and mesh, most probably you would get elements in sequential ID numbers. But this utility is meant for any FE package
in general – even for ANSYS models where the modeling of line objects has not
been strictly according the extents of physical beams, or a later modification
of the model that mis-aligned the aforementioned ‘one line object per physical
beam’ approach, or in case of models where the FE model has been detached from
the CAD model: No matter which ever condition the element IDs are, and for whatever
reason, this utility will arrange them
in order in the output files.
The BM plots for each
of the above elements are as follows (Fig.6):
(a) (b) (c) (d) (e) (f) (g)
Fig. 6 (a-g). BM diagrams of elements referred to in the 10th
row of the output files – element ID’s 44 to 50
And the above can be
arranged in sequence and used for the design procedure of the parent program,
which includes extracting the BM values, determining the point to which the main
reinforcements are to be extended before curtailing, and a whole lot of similar
calculations. Graphically, on arranging it looks like the following (Fig. 7)
Considering the above
discussion on the sequentiality of node and element numbers on meshing, in
order to illustrate a case where the IDs being sequential is not be the
case, consider the same model, meshed in another FE package and imported – the IDs
in this model are not numerically in sequential order.
Here again for the same beam considered in the 1st model, the sequence of nodes and elements of
the physical beam are as circled in red in the figures below…
(a) (b)
Fig. 8 (a) Node number IDs and (b)
element number IDs of the physical beam represented by the 8th row
of the output files for the 2nd model
… are processed, and
is found to be in the 8th row of the output files.
8th row of "keyNodes.txt"
19
|
7
|
8th row of "beamLine.txt"
19
|
248
|
244
|
240
|
236
|
232
|
228
|
8th row of "nodeLine.txt"
176
|
173
|
170
|
167
|
164
|
161
|
12
|
From the “beamLine.txt” it can be seen that it starts with
element ID 19, and connects to elements of IDs 248, 244 and so on up to 228.
And the nodes in that line start with node ID no. 9 (from “keyNodes.txt”) and
continue with 176, 173 and so on up to 12 (from “nodeLine.txt”). Please note that in this model the element
IDs and node IDs are not numerically in sequential order, and the utility has
arranged the sequence of IDs as seen above.
The one problem with this
utility is concerning the criteria continuity of beams from key nodes: in the 1st
model presented, the node of ID 33 is a key node. Thus the beam comprising of
element IDs 29, 30, 31 & 32 is presented as one physical beam, while that
comprising of IDs 54, 55 & 56 is as another physical beam. But visually it
can be seen that that they both form one physical beam (only that it supports a
secondary beam comprising of elements with IDs 70 to 76). This utility does not
handle the issue, and it is up to the developer of the parent program to
provide a suitable facility to the structural designer to manually correct this
— it is rather not recommended for the program to handle the issue in an
automated fashion: a case where human decision is desirable.
How
to sense completion of processing…
On executing, all the physical
beams and physical columns are written into the above said files and closed.
Finally the file “noOfData.txt” is written. The parent program that executes
this utility program can sense if the writing of the output files are completed
by detecting whether the “noOfData.txt” file has been written. The parent
program can then start reading the written output files.
Downloading
the utility
The utility program and sample files can
be downloaded from here**. The zipped file contains
1
- The executable file “unMesh190520_V-1-0.exe”
- Sample file of “FilePath.txt” that is to be copied to the location where the “unMesh190520_V-1-0.exe” file is executed from. It should contain a single line depicting the path to the location where the rest of the input files (to be read by the utility program) are present – be it same as the location of the FE model file, or the location of the parent module, or whatever. The path as written in the “FilePath.txt” file should end with a “\” character as shown in the sample file included.
- Sample file of “Nodes.txt” containing the node listing if the sample structure shown above,
- Sample file of “Beams.txt” containing the node listing if the sample structure shown above,
- Sample file of “Data.txt” containing the number of data rows in the files listed in 3 and 4 above.
In order to utilise
this program, suitable files (similar to the sample files included), pertaining
to the model to be analysed are to be created and set ready to be read by the
program. In the included files the contents of the sample file listed in 3 is
formatted column wise, suitably padded with spaces, whereas the contents of the
sample file listed in 4 simply puts the three numerical values in each line
separated by five spaces. This reminds that as long as the numerical values are
separated by spaces, or even a single space, the formatting style is not an
issue.
The files listed in 3,
4 and 5 above should be put together in a convenient location, and the path to
that location should be included in the file listed in 2 above. The file listed
in 2 above should be located in the same location where the utility program
listed in 1 above is also located. As
of now, the presence of the required input files in the expected location are
not checked for, before attempting to open them – no code in the utility to
catch the ‘FileNotFoundException’ as of now {:-)]. The parent program should make sure the
required files are present before executing the utility. Similarly one also have to make sure the number of lines in “Nodes.txt” and “Beams.txt” are same as that denoted in “Data.txt” – other than counting up to the number found in it, there’s no check for ‘EOF‘ in place either, as of now. If the parent program is programmed correctly, it should run fine the first time, and every time. May be I’ll put all those checks sometime later {;-)].
All the best…
Rahul Leslie
rahul.leslie@gmail.com
No comments:
Post a Comment