Numbering of nodes in Finite element 3

[tianle]

As I knew from some finite element books, the numbering of the nodes of element can't be arbitrary. It should be
counter-clockwise ( in 2-D case). Is it true? What will
happen if I set the numbering as clockwise or any other?
I just don't understand. Thanks!

Tianle Cheng

 

[rb1957]

very occassionally very specialised elements need a numbering sequence, in which case consult your manual.

for the rest, 99.99999% of elements, numbering sequence doesn't matter. numbers don't matter either, as most codes have an optimiser embedded in them (so the code creates internal node numbers for optimising the stiffness matrix but reports back to you using your node numbers).

 

[Denial]

The sequence of specifying the nodes that define an element is very important, but it varies between FE programs. It will be described in the manuals for the program you are using.

As an example, consider a four-noded quadrilateral element.
[tt]
C--------D
| |
| |
A--------B
[/tt]
Some programs would have you define this as ABCD, whilst others would have you define this as ABDC. If you enter ABCD to a program that expects ABDC you are in effect defining an element that is grossly distorted, but usually the program's graphics will enable you to see your error.

There is a secondary aspect to this, and I suspect it is closer to the point behind your question. If (say) your program is of the ABDC variety, you can validly define the element as ABDC or ACDB (or DBAC or …). You can go clockwise around the element, or you can go anti-clockwise. Ditto for its neighbouring elements. Your subsequent analysis will be correct. However if you have mixed clockwise and anti-clockwise element definitions in the one model, it will be more difficult to display and assess the calculated results. This is because the sign conventions used on neighbouring elements will be opposite to each other. Thus, for example, on one element a positive out-of-plane bending moment will be one that puts the upper face into tension, while on the neighbouring element a positive moment will put the lower face into tension.

The key thing is to be be consistent.

 

[jhardy1]

I think the OP was asking about the node numbering sequence for an element, rather than the numbering sequence of the nodes throughout the whole model. The bandwidth minimising algorithms will deal with the latter, but won't fix up incorrect node numbering of each element.

At the element level, node numbering sequence is VERY important - it defines the actual connectivity of the element, and its resulting shape.

In the case of a 3 or 4 node plate / shell element, numbering in the correct sequence defines the direction of the positive z axis (the "top" surface of the plate). If you mix up clockwise and anti-clockwise numbered elements, the "top" surface will flip sides on an element-by-element basis. Numerically, this won't affect the solution, but it will certainly affect your ability to interpret the results!

For 4 node quads, if you don't number in a continuous loop sequence, you can end up with "butterfly-shaped" elements (which are rarely what you intend to analyse!)

For 6 and 8 node plate elements, it is important to number the corner and mid-side nodes in the correct sequence - otherwise, your elements can take on some very weird and wonderful shapes.

The possible 3D geometries with incorrectly numbered tets, wedges and bricks don't even bear thinking about!

Yes, you needed to be very careful with your element node-numbering sequence!

 

[tianle]

Suppose I'm composing a simple FE program by myself.
Like Daniel's comments. We have a FE model with only one
quadrilateral element, which has four nodes 1,2,3,4

4--------3
| |
| |
1--------2


if we numbering the nodes by 1 2 3 4, and let its true solution
(say, temperature) to be x1 x2 x3 x4



A11 A12 A13 A14 X1 Q1

A21 A22 A23 A24 X2 Q2
* = (Eq.1)
A31 A32 A33 A34 X3 Q3

A41 A42 A43 A44 X4 Q4


if we shift the 2 and 3 node and numbering the mentioned element by
1 3 2 4, we'd shift the 2nd and 3rd rows and columns of the linear equations
as

A11 A13 A12 A14 X1 Q1

A31 A33 A32 A34 X3 Q3
* = (Eq.2)
A21 A23 A22 A24 X2 Q2

A41 A43 A42 A44 X4 Q4

By this shifting, we'd get the same result as (Eq.1), right?
Can I say that, the numbering of this element don't have to be counter-clockwise
for plane stress/strain problem?

However, as what Daniel and JulianHardy said, for plate/shell elements, the
numbering of this element will affect the direction of the z-axis, which is
important for sign decision.

 

[jhardy1]

tianle,

If you are writing your own FEA code, then you can choose absolute ANY node numbering sequence you like - 1,2,3,4 (which is the typical sequence), or 1,2,4,3 (which would not be common, but could be considered to be "reasonable"), or 4,1,3,2 or 2,4,1,3 (both of which could be made to work, but I can't see any logic to them), or whatever.

BUT ...

Once you write the code, the you MUST enter your nodes in strictly the correct sequence, if you want your results to be meaningful.

Cheers!

 

[johnhors]

"Can I say that, the numbering of this element don't have to be counter-clockwise for plane stress/strain problem?"

Using the conventional right hand axis system coordinates for 2D problems are given in X and Y, the Z axis is then out of the screen towards you, it then follows that a positive rotation about the Z axis using the right hand thumb screw rule appears as anti-clockwise. When it comes to vector mathematics no sane person is going to break away from this convention ! Most (if not all) FE solvers would see a clockwise node order on a 2D element as a negative area element and would reject it.

There are however differences in node order sequence in the major commercial systems, with most systems listing all corner nodes first followed by any mid side nodes, whilst a few others have a list sequence that slots the mid side nodes in between the corner nodes.

 

[rb1957]

can we hear from tianie ... are we anywhere close to being helpful ?

generally it doesn't matter how you specify the nodes ... Cw, CCw, which node you start at. of course you have to have the right sequence ...

1234, 2341, 4321 all define the same element

1324 doesn't.

connectivity within the model is achieved in the FEM by the adjacent elements sharing the appropriate nodes.

one thing to be aware of this that the numbering sequence defines the element axes and the element normal. These are important if you're going to look at specific stresses over a group of elements (the sigmaXX stress on one element may align with the sigmaYY stress on another) or if you're applying pressure loads (you have to get the right out-of-plane direction).

 

[cbrn]

Hi,
yes, first of all we should know from Tianle if we are being helpful or not...
Moreover, it is not clear if he speaks about a FE to be programmed by himself, or about a commercial FE.
Being the elem coord sys based upon the node sequence, of course that has a crucial importance. On the other hand, all commercial FE has built-in algorithms which allow the user to completely "forget" about that. But, basically, the "matter" is still there: if you automatically mesh a volume with Ansys, you will see no clearly understandable "logic" in the nodes' order; when you apply, for example, a surface load to an area, and issue the command to transfer it to the FEs, you will see that, obviously, the program is able to load the correct "side" of each elem; on the other hand, if you try to load each elem by yourself with the same surface load, you will see two things:
- the program will ask you for the "loadkey", i.e. for the "face" or "side" of the elem to be loaded
- two adjacent elems may or may not require the same "loadkey" in order to be loaded with the surface load in the same direction: this is the demonstration that, for the program, it is not strictly necessary that adjacent elems are not "flip": the program knows how to handle that (but it usually gives YOU lots of headaches if you want to operate "full-manually" !!!).

Regards

 

[bkal]

In the good old time when I was writing FE programs (not commercial ones), having node numbers in a wrong order could lead to a negative volume due to a way in which it was numerically integrated (Jacobian). I have not come across similar problems with modern commerical codes, though.

 

[prost]

you can use any numbering system you want as long as you are consistent and bookkeep properly. For instance, coordinate and displacement fields on this quad you have shown are approximated with a summation of "N" shape functions:
x=Sum(X(i)*N(i),i=1,N), same with y, substitute Y(i) for X(i). Say for instance, the coordinates of the 4 nodes are (0,0)=node 1 (lower left), (1,0)=node 2 (lower right) (1,1)=node 3 (upper right), (0,1)=node 4 (upper left). The mapping that describes all 'x' coordinates in this element is x=X(1)*N(1)+X(2)*N(2)+X(3)*N(3)+X(4)*N(4)=
0*N(1)+1*N(2)+1*N(3)+0*N(4)=N(2)+N(3). Similarly, y=N(3)+N(4). More on what N(i) are below.

Now the temperature field (u)
u=Sum(U(i)*N(i),i=1,N)/ U(i) are what you are solving for (you've called it temperature, and labeled them x1,x2,x3,x4).

In isoparametric elements, those N(i) are constructed so that they are 1.0 at the nodes, and 0 at all other nodes (but non zero elsewhere). Say you are using linear elements, and use the numbering system you show (1 at lower left, 2 lower right, 3 upper right, 4 upper left), then N(1)=0.25*(1-eta)*(1-xi),N(2)=0.25*(1+eta)*(1-xi),
N(3)=0.25*(1+eta)*(1+xi),N(4)=0.25*(1-eta)*(1+xi).

(eta,xi) are on the basis element system..every element in your real (x,y) space is mapped to the basis element system, hence the talk about Jacobians above.

What if you didn't like the numbering system? As you suggest, switch 2 and 3. Making sure that you remember that the shape functions need to be 1.0 at the corresponding nodes, and 0.0 at all other nodes, renumber the shape functions:
N(1)=0.25*(1-eta)*(1-xi),N(3)=0.25*(1+eta)*(1-xi),
N(2)=0.25*(1+eta)*(1+xi),N(4)=0.25*(1-eta)*(1+xi).

Remembering that you switched '2' and '3', then X(1)=0,Y(1)=0, X(2)=1,Y(2)=1, X(3)=1,Y(3)=0, X(4)=1,Y(4)=1. The mapping of the 'x' coordinate in this new element becomes:

x=Sum(X(i)*N(i),i=1,N)=X(1)*N(1)+X(2)*N(2)+X(3)*N(3)
+X(4)*N(4)=0*N(1)+1*N(2)+1*N(3)+0*N(4)=N(2)+N(3), same as before, but watch what happens to the mapping of the 'y' coordinate!
y=Y(1)*N(1)+Y(2)*N(2)+Y(3)*N(3)+Y(4)*N(4)=
0*N(1)+1*N(2)+0*N(3)+1*N(4)=N(2)+N(4) (note difference from previous numbering system, y=N(3)+N(4)).

Both numbering systems are perfectly equivalent, as long as you keep the bookkeeping straight! You don't even have to start in the lower left, you could have started the numbering in the upper right, and clockwise, node 1 is upper right, node 2 lower right, node 3 lower left, node 4 is upper left. Now you have to remember to renumber the shape functions N(i):
N(3)=0.25*(1-eta)*(1-xi),N(2)=0.25*(1+eta)*(1-xi),
N(1)=0.25*(1+eta)*(1+xi),N(4)=0.25*(1-eta)*(1+xi).

 

[Dinosaur]

After reading the first and subsequent post from Tianle, it appears he knows plenty about finite elements. I also see a few other folks that know their stuff too. Great!

Whether writing your own or using a comercial program, it is important to be consistent. All the comercial systems I have used require the user to go around the element in a sequence. In one example above, this would require either A-B-D-C or A-C-D-B. I have not used a comercial program that would properly understand A-B-C-D in that example. However, as already answered, the two correct answers I give will work for the global model, but could well confuse you in the post processing because the "top" of the element is defined by going clockwise or counterclockwise. The programs I used would set the near side as top for CCW node numbering.

I haven't said anything that wasn't already said. I just wanted to reiterate their points and say this is not trivial. You can screw up a good model with poor numbering discipline.

 

[rb1957]

"You can screw up a good model with poor numbering discipline."

in the context of a commercial package, i have to disagree with this. 'cause, with a graphical front-end and post-processor, when i'm creating a model i really don't care about the node numbers ... everything is done on the screen. In the old days (say 30 years ago) graphical interfaces weren't nearly so common so you usually controlled your node numbers to help picture where in the model you were, all the nodes on rib 1 might be 1xxxx.

 

[cbrn]

Hi,
rb1957, in addition, in the early days of FEM the connectivity problem was so evident that not only you had to declare explicitly the nodes of each element in the proper - consistent - order, but also the max difference between node numbers of any two adjacent elements hadn't to be more than a certain quantity, dependent on the element formulation... In other terms, the connectivity problem was to be resolved by the user, and the computer power was so low that one was obliged to build-up an efficient connectivity; nowadays everything is resolved by the program (only way to open the path to things like adaptive refinement, rezoning, etc).
If Tianle is programming his own FE code, then node numbering "per se" should have no importance (you can place nodes in space in whatever order you want), but the nodes declaration inside each element will have to follow the rules very well described by others in the previous posts. The conventional path can be CW or CCW, it doesn't matter, it can even be "crossed" if you modify the element's shape functions accordingly (but I sincerely don't see why you should choose a complication like that). The same applies as regards elem coordinate system. If you want to achieve maximum efficiency in the matrices manipulation, then either you have to write a "re-orderer" (as Ansys has, for example), or follow stricter rules in the nodes / elements declaration... But unefficient global matrices won't make your results uncorrect.

Regards

 

[Dinosaur]

I was addressing poor number discipline with elements, which I understood the original post to be related to. Yes, todays computers are so fast and quality comercial packages written to obtain low bandwidth and handle all that in the background. But improperly defined elements can make all that work meaningless. I also know that graphical interfaces can prevent the user from even messing that up, but sometimes you are trying to solve a problem the GUI was not meant to address and you end up face-to-face with the numeric input. That's when you separate the men from the boys. Since the original question asked about this level of detail, I thought I would discuss it along those lines. And I still believe Tianle knows enough about FE to answer his own question.

 

[johnhors]

Dinosaur, do you actually sometimes type in node and element data by hand ? Yes, I remember doing this via a line printer (no VDU !) for a complete model, but that was back in the 70's. I certainly wouldn't consider hand editing the million plus node models I generate these days ! Though I find it heartening that may be there are still some skilled analysts around who are prepared to do this.

 

[GregLocock]

I don't often type a whole model in by hand, except for little tests, but I do often generate models using Basic scripts (a bad habit from the PAL2 era!). That encourages a certain appreciation for node numbering schemes.

However, in Hypermesh the node numbers are practically invisible to the user, which is just fine by me.

Incidentally one of my first real jobs was writing a wavefront counter and optimiser.





Cheers

Greg Locock

Please see FAQ731-376 for tips on how to make the best use of Eng-Tips.

 

[Dinosaur]

johnhors,

I don't get a chance to do much anymore, and I've never generated a model with over 1000 nodes that I recall, but with auto generation commands, maybe I did.

Most recently, when I did some modeling, I created an excel spreadsheet to generate the commands that built the model. I numbered all the nodes and elements this way, and generated everything except the selfweight load combination too.

I've used programs with graphical output, but never a GUI for model building.

In grad school, I derived element stiffness matrices by hand (no computer integration or anything) and even tried to convert an old Fortran IV public domain stiffness program into Qbasic. I never did get it finished before the semester ran out, but neither did the other students.

The three reasons I think I have this kind of experience:
My age and training allows me to do this
My employers were too cheap to buy me a super program
Most of my problems require unique and unusual geometry

FE is a great tool, but so is my HP.