Previous: Appendix C: Contouring
Next: Appendix E: Graphical interaction – the ‘stretchy box’
In this section:
It is rather difficult to imagine that anyone is setting out to convert or implement a fully-functional 3-D FEM system in FTN95/ClearWin+ today, but there are plenty of old codes around with a limited range of functionality but which are still useful in some contexts. The following section contains some suggestions for drawing 2-D images based on FEM meshes. Implementing anything more complex is down to your imagination. The advice is a mixture of algorithms and suggestions for colour.
Drawing a complete mesh is a matter of treating each element as a closed polygon, and drawing each using DRAW_POLYGON@. It doesn’t matter that many parts of the outlines will be drawn twice, as the process is very quick, and indeed, even in the pen plotter days the overhead of retracing the outlines was a tiny overhead compared to moving the pen to a new start point.
An interesting thing about two-dimensional finite element meshes is that whereas corner nodes of triangular or quadrilateral elements can ‘connect’ to variable numbers of elements, a side that is only present on one element is on the periphery of the mesh, and all other sides connect to only two elements. If those two elements have different properties, then that side is on a junction of two materials.
Therefore, if we want to draw the outline of the mesh, it is a matter of drawing all those sides that only relate to one element, and to draw the junction between material types it is a matter of drawing only the sides that have different materials in each of the two connected elements. The way I do these two actions is rather simple, because I favour elements with nodes on the sides as well as the corners, for example the 8-node isoparametric quadrilateral element or its 6-noded triangular cousin. I scan through all the elements and keep for each node a list of the materials associated with each node. I have a limit of 9 elements connecting to each (corner) node, and therefore I need a structure such as this:
DIMENSION MATERIAL_NUMBERS(No_of_NODES,10)
where the 10th element is how many connections there are. In my simple codes I don’t differentiate the numbering of corner and side nodes, and there aren’t any missing numbers. As each element is dealt with, I add its material number to each connected node. Then, I scan through the list of elements a second time, looking for sides where the side node has only one material number – which is a mesh boundary – and draw that, or where there are two material numbers that are different, and draw those sides as an internal boundary.
When using elements such as simple triangles, we do not have the convenience of having a side node, and have to treat each side in terms of the nodes at its ends. That means creating a list of sides, then scanning through the elements to see if a side is unique (for a mesh boundary) or if it occurs twice (as most sides will do) with different material types on either side (and thus is an internal boundary). If the nodes are numbered, as they are in my case, and the numbers are stored anti-clockwise round each element, then when a common side is encountered a second time the order of the nodes is reversed. I personally find the linear elements more difficult to deal with than those elements that have side nodes.
An alternative to drawing outlines is to draw the mesh as filled polygons, one for each element, and to use different colours for each material. That procedure requires little effort. The critical thing is to choose the colour values.
If the drawing is to be printed then the selection of colours should avoid saturated hues, because in the case of inkjet printers, too much ink makes the paper stretch or in the case of laser printers gives to thicker film that may not fuse properly onto the paper. Moreover, saturated colours make it difficult to print anything over-the-top such as element numbers, node numbers or indeed any other graphical element such as vector arrows, unless they are drawn in white or yellow but even then, they do not come across so well as drawing in black over pastel shades. I find it useful to have a mid-grey background rather than a white one on screen in the client area of a window and then to draw the mesh over it in pastel shades, because I find that to be more effective than simply using a white background. The colour rendition of modern monitors has improved but nevertheless it may be necessary to make the colours more saturated when drawing on screen than when printing, and in the print case not to use a grey background as that is wasteful of ink or toner and rather unnecessary. If the image is to be projected, then the more restricted colour range of projectors may need even more saturation in order for them to be more easily discriminated it is useful to have a slider control positioned in the status bar to increase the saturation of such background colours when the application is run and displayed via a projector because that gives a very easy way of making sure that things can be seen and discriminated between.
Anything overprinted as lines or text on a white or pastel background works well in black, red or blue, but less well in green or yellow, especially with thin lines. In contrast, overprinting lines or text on a saturated colour or black works best as white, yellow or perhaps green – again, the latter choice (saturated colour backgrounds and light-coloured annotations) is not good for printing on paper.
A common type of plot is to show the original mesh and overlay that with a plot of the mesh as deformed, with the displacements exaggerated. Such plots are common in plane stress, plane strain and also axisymmetric stress and deformation analyses. On-screen, the dotted and dashed lines are not particularly attractive, and it is better to use colour or even shades of grey. I have found it good in the case where there are several stages in deformation to show on a single plot to draw the original in light grey, then to follow it by over-printing in progressively darker shades, although after a few stages the picture gets too complicated, and it is not always possible to discriminate between the shades of grey. It doesn’t seem to work so well with the colour progression reversed.
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.