Applications of Computational Mechanics in

PROCEEDINGS OF THE I ST INTERNATIONAL WORKSHOP ON APPLICATIONS OF COMPUTATIONAL MECHANICS IN GEOTECHNICAL ENGINEERING RlO DEJANEIRO/BRAZIL /29-3 1JULY1991

Applications of Computational Mechanics in Geotechnical Engineering Edited by

1

E.A.VARGAS &R.F.AZEVEDO

I

Department of Civil Engineering, Catholic University ofRio de Janeiro, Brazil

i

L. M. RIBEIRO E SOUSA l.Aborat6rio Nacional de Engenharia Civil, Lisbon, Portugal

M.MATOS FERNANDES Faculty ofEngineering, University of Porto, Portugal

OFFPRINT

1 A.A. BALKEMA I ROTTERDAM I BROOKFIELD I 1994

Applications of Computational Mechanics in Geotechnical Engineering, Vatyas et al. {eds) © 1994 Balkema, Rotterdam, ISBN 90 541O348 5

New techniques to aid interactive graphical finite element analysis Marcelo Gattass & Carlos Henrique Levy Computer Science Deparrment, Catholic University of Rio de Janeiro, Brazil

ABSTRACT This work discusses new disciplines that are important to the development of interactive graphical finite element analysis programs. After a brief presentation of the disciplines related to the development of this type of program, the paper focuses on user interface issues. These issues are discussed from both the application programmer's and the user's point of view.

1. INTRODUCTION When a finite element code is developed to be used by people other than its authors, the type and quality of its user interface is of paramount importance. A good graphical interface can ease the data preparation process, guide the choice of analysis parameters and allow an easy interpretation of its results. In dynamic and/or non-linear problems, even the process of analysis should be monitored during the execution of the program by an experienced analyst using non-obstructive graphical interfaces. Several disciplines must be applied in the development of interactive graphical finite element codes: Computer Graphics, User Interface, Geometric Modeling and Computational Geometry. Computer Graphics allows the programmer to create images of two and three-dimensional objects on 2D viewing surfaces (screen or paper). The programmer describes the image of the objects with graphical primitives such as: lines, texts and areas filled with a certain color or pattern. Threedimensional objects are described by their bounding surfaces. With the proper definition of projection and illumination parameters, the graphical system is capable of rendering the correct image of the object on the 2D viewing surface. Graphical systems also provide tools to aid the programmer to detect which graphical primitive (line, text or filled area) is being pointed by the user. The binding between this graphical primitive and the object selected is made in the interactive graphical finite element program. The User Interface system provides the programmer with a variety of styles and mechanisms to communicate with the user. This communication is usually defined through interface objects such as: menus, icons, radio buttons and dialog windows. A good user interface must also consider psychological, ergonomic, cognitive and linguistic factors of the final user [FOLE90]. In Geometric Modeling, a programmer will find classes of representation such as: Constructive Solid Geometry, Boundary Representation and Spatial Decomposition developed to model solids. In the study of this discipline, the programmer will also find special data structures that implement these representations. Special emphasis should be given to quadtrees, octrees and topological data structures. The first two data structures support the implementation of spatial

453

User

Computer Figure 1 - Components of an interactive graphical FE program

decompositions of two- and three-dimensional objects, respectively. The third one is very adequate to represent boundary models. The decomposition of an interactive graphical program into the modules shown in Figure 1 illustrates the application of the disciplines just described. Computer Graphics studies programming techniques that allows the FE programmer to use a Graphical System, such as OKS or PRIGS. The User Interface discipline does the same with respect to UI Systems such as Motif or MS Windows. Geometric Modeling and Computational Geometry provide techniques and data structures that are used in the FE program in conjunction with the Data Base Manager. In a modem interactive graphical program, the interaction among these modules can happen at many different moments in time. For instance, the user hits a interaction object (such as a menu), and this object calls back some function of the finite element program; this program then queries the data base manager and draws something in the screen trough the graphical system. In another instance, the user can hit an object in the screen (through some graphical function) and the program queries the data base and returns information about the object via user interface functions. Note that, in order to allow information to travel through the modules of Figure 1, there are eight different interfaces, represented by pairs of arrows. Each one of these interfaces is object of discussion and standardization in ISO (International Organization for Standardization), ANSI (American National Standards Institute), ABNT (Associa9iio Brasileira de Normas Tecnicas) and many other national standardization organisms. The standards that emerge from these organizations plus some successful industry standards have created a very confusing alphabet soup: OKS, PHIGS, COM, PostScript, Xlib, Motif, Open Look, MS Windows, and many others. Therefore, choosing standards is a non-trivial problem, which requires addressing many questions. At PUC-Rio, two related groups, TeCGraf (Group of Technology for Computer Graphics) and !CAD (Intelligent Computer Aided Design), have been addressing these questions since 1985. Scheer and Gattass [SCHE85] and Paulino and Gattass [PAUL89] discuss the question of using graphical systems in interactive finite element programs. Paulino and Gattass [PAUL88], Fonseca and Gattass [FONS89] and Celes Filho and Gattass [CELE90] present computational geometry techniques to deal with finite element meshes. The paper by Gattass, Paulino and Gortaire [GATT92] presents algorithms to enforce geometric consistency in three-dimensional frame models. The paper by Souza and Gattass [SOUZ92] introduces the use of graph theory data structures to support the generation of arbitrary shell meshes. Carvalho, Gattass and Martha [CARV90], Campos, Martha and Gattass [CAMP91] and Celes Filho, Martha and Gattass [CELE91] discuss the use of topological data structures to aid the processes of generating meshes and visualizing analysis results. This paper discusses new issues that are important to the development of interactive graphical finite element analysis programs. These issues are discussed from both the application

454

..

programmer's and the user's point of view. The next section presents a review of user interfaces used in engineering programs, and the section after that discusses strategies to program these interfaces. A final section presents some general comments and some conclusions.

2. USER INTERFACES IN ENGINEERING PROGRAMS In the sixties, when the Finite Element Method was introduced into engineering practice, the engineer was responsible for describing the Finite Element mesh directly to the program. In broad terms, this description is performed in four stages. In the first stage, nodal coordinates are defined. Usually, node identification is implicitly defined by the order in which node coordinates are given. In the second stage, the engineer defines tables of materials, sections and other attributes of the mesh that are present in the model. Elements are defined in the third stage. This definition usually includes the nodal incidence (connectivity) of the element, a pointer to the material table and other pointers to attribute tables that are specific for that class of element Loads are defined in the fourth stage. These loads, acting on regions of the mesh, must usually be converted to nodal or element attributes. These stages are not always clearly separated and may not appear in exactly the same order presented above, but they are essentially in all Finite Element programs. Another interesting characteristic of the model description process of early Finite Element programs is that the domain of the differential equations (geometry of the body) was only implicitly defined as the union of all elements. All information was passed to the analysis programs by text files. One of the first general purpose engineering systems was the ICES (Integrated Civil Engineering System), developed at the MIT with a clear concern with the user interface. Figure 2 shows a simple structure and its definition for an ICES sub-system called STRUDL. As Figure 2 illustrates, the description of a model for the ICES/STRUDL sub-system was performed with the aid of a command language. In this type of interaction, the user types in some valid command, and the program parses this command and performs the proper action. The system then stays idle while waiting for another user input. The need for the user to memorize all valid commands and to type them correctly are a major problem in this type of interface. Nevertheless, this

y 7 lcN

ffi

"-61cN

-

0 Node

0

-;z

~

8m

)/

SPACIAL TOWER TYPE SPACE TRUSS NUMBEROFJOINTS4 NUMBER OF SUPPORTS 3 NUMBER OF MEMBERS 3 METHOD STIFFNESS JOINT COORDINATES I XO. YB. ZO. 2 X 0. Y0. Z 0. SUPPORT 3 X 6. Y 0. ZB. SUPPORT 4 X 8. Y 0. Z -3. SUPPORT MEMBER INCIDENCES

Bar

x

oof

1 21 ZJJ 34 1

MEMBER PROPERTIES I AXO./S 2AXO./S 3AXO./S

JOINT WADS I FORCE Y -7. Z6.

z

STRUDLfile

Frame

Figure 2 -A frame and its STRUDL description

455

user interface style was very adequate for the low interactivity of mainframe computers. These computers dominated the market up to the late seventies, when mini-computers appeared. Until the advent of mini-computers, the development of engineering systems was primarily concerned with the numerical techniques employed. User interface issues were regarded as not so important. The focus then was the computer itself. Users would line up and wait for their time slice. Machines costs were higher than labor costs. Not surprisingly, the model descriptions for the programs of that generation were encoded in formatted text files very adequate for the FORTRAN READ command, but with the worst possible human interface. The data was created in text files full of numbers. The meaning of each number would depend on its position in the file. Sometimes, when the program expected a formatted input, even column position of the number would be relevant. This type of program would typically process in batch mode without any interaction with the user. Figure 3 shows fragments of the file description of the frame shown in Figure 2 for the program SAP (Structural Analysis Program), developed in Berkeley under the supervision of Edward L. Wilson. During many years, the source codes of several versions of this program were distributed at cost price to any University and Research Center around the world. This distribution dramatically changed the development of the Finite Element Method in that period: many programs of that period inherited not only the numerical routines of SAP but also its poor user interface. 60 50 10 20 30 40 1 23 45678901234567890123 4567890123 4567890123 45678901234567890123456

SPACIAL TOWER 4 1 1 1 0 0 2 1 1 1 3 1 4 1 1 1 3 1 1210000000.

1 2 3 1

0 0 1 1 1

2

1

1

3 4

1

1

1

1 0.

1

0 1 1 1 1

0 1 1 1 1

- 10.

0 1 1 1 1

0.

o.

8. 8.

8. 0. 0. 0.

0. 0. 6. -3.

5.

Figure 3 - Data entry for the SAP program

By the end of the seventies, with the advent of mini and micro computers, engineering programs began to use Computer Graphics to display the model for visual verification. These machines were a lot more interactive and the low cost graphical displays, such as the TEK40xx series, were also largely available. An important example of this generation of engineering programs were the first versions of the ANSYS program. In these versions, the user would still use a command language to input data into the computer, but the response could be images of the model and its results. With the decreasing cost of computer equipment, another class of engineering programs start to appear: small programs with little input data. They would typically perform some formula computation or some small numerical simulation or optimization. To avoid boring manuals, the data was obtained in a sort of dialog guided by the computer. In this user interface style, the user reacts to machine prompts. 456

Enter section height (mm) ? 1500 Enter section width (mm) ?800 Enter web thickness (mm)

Analysis type: 1-Llneor 2 · Piostlc 3 ·Elosto-plostic

? 30 Enter with flange thickness (mm)

?50

?Type: 2

Is data above correct (Y/N)?

?Y (o)

(b)

Figure 4 - Screens of a simple sequential dialog

Section Doto Section height (mm):

rra 1

Section w idth (mm):

Lm.:J

Web thickn ess (mm): Flange thickness (mm):

t

up

.I,

PgUp previous PgDn next

d own

Figure 5 - Screen with data entry fields

The first and simplest class of dialog guided by the computer was the so called "questionnaire" programs with sequential questions and answers dialogs. Each datum in this type of program is captured by a prompt followed by some read statement as illustrated by Figure 4(a). If the set of possible answers is small, then the datum can be selected by some kind of menu, as illustrated by Figure 4(b). A common difficulty in this kind of program is the user navigation between screens and prompts. The user, almost certainly, makes mistakes and the correction, in some systems, roughly means re-entering all the data. This, of course, severely limits the size of the input data that can be handled with this class of user interface. The next class of computer guided dialog is the one based on screens, formatted as data forms. In this tape of dialog, the user enters data in the field were the cursor is. The user does not have to follow the sequence to enter data. The navigation between screens and fields is possible, but usually follows a pre-defined sequence. Even when more than one path exists in this sequence, the dialog is still considered sequential [HART89]. Applications written on top of well-known data base products, such as DBase, usually use this strategy. Figure 5 shows an example of a screen with this type of dialog. This user interface style is far superior than the "questionnaire", but it still suffers from some important limitations for engineering programs. Engineering works with visual representations of objects and it is not always possible to map drawings into words with the same meaning for all users. A simple way to overcame this difficulty is to put data entry fields directly over the drawing as illustrated by Figure 6. This style of user interaction can be classified as direct

457

manipulation [SHNE83] if the user can arbitrarily point with a cursor the field he wants to edit. If he has to follow some pre-defined paths, then the dialog becomes sequential and can no longer be classified as direct manipulation. The style of interaction illustrated in Figure 6 is only adequate to problems that are defined by a very small set of parameters. In these class one can find beam computations, slope stability, and many others. Problems that require an arbitrary Finite Element mesh, however, rarely fit in this category because the geometry of these problems cannot be described by a small set of parameters. In this class of problems, input data is prepared by the so called preprocessors.

Section Data

. :::··

«-~

L ft.L•

a .

Figure 6 - Input data based on drawings

Modem Finite Element preprocessors usually begin with the geometric definition of the domain to be divided into finite elements. This definition, the division into elements, and the attribute definitions are complex tasks requires a sophisticated user-computer dialog. The implementation of this dialog is almost always done with menus. The user interface of the first preprocessors based on menus used a fixed division of the screen into areas. One main area was dedicated to the drawing of the Finite Element mesh; the others would take care of titles, messages, menus and data entry. Figure 7 illustrates one typical layout for these screens.

Tilk..ill Meim10P,s Are.a

DRAWING AREA

Data Entry Area

Menu Option 1 O_mion 2 O_mion3 O_mion4 O_mion5 O_mion6 O...filion7 O~ion8

Return

Figure 7 - Screen with simple fixed layout

The organization of user-computer dialogs into screens with the layout illustrated in Figure 7 restricts the interactive program to few menu options. Moreover, the implementation of many phrases of the dialog requires some kind of hierarchy. This is hierarchy is implemented with a menu tree of the type illustrated in Figure 8.

458

1or101

l°fJo1. .

lot~o1

~ 101~01

... r~.'~01

~~

. . [!fj

Figure 8 - Menu hierarchy

One of the main difficulty of the simple fixed layout illustrated in Figure 7 is the navigation between options of a hierarchical menu. If the user is selecting the sub-options of Option 1, for example, and she decides to move to the sub-options of option 2, she must first go back to the root menu to only then select option 2. This becomes even more inconvenient when the menu tree has more than three levels. Some Finite Element programs solved this problem creating more areas for menus as illustrated by Figure 9.

0 lion 1 Opiion I.I

0 tion 2 0 tion 3 0 tion 4 Op1ion 1.2

Option 1.3

Oplion 1.4

DRAWING AREA

i---------------t Message and Data Entry Area

Option 1.1.7 Option 1.1.8

End

Figure 9 - Screen with fixed layout and hierarchical menus

The interface shown in Figure 9 uses a large portion of the screen to represent the menu hierarchy, thus reducing the size of the drawing area; this reduction is highly undesirable. Moreover, the resulting layout of the screen is visually confusing with several levels of menus displayed at the same time. To solve this type of problem, programs based on raster display devices began to use temporary menus. This could be achieved by simply saving the pixel color information in the area where the menu was going to show up and to restore this area when the menu was no longer needed. Two types of temporary menus are very successful nowadays: pull-down menus and pop-up menus. Moreover, modem user interfaces have menu bars with pull-down menus, dialogs with direct manipulation through icons, pop-up dialog boxes, and hot keys and menus accelerators through the keyboard. Figure 10 illustrates the screen of a modern application. Note in this figures the difference between menu accelerators and hot keys to perform the function save file. In the former style the user presses F S; in the later, he presses F12 simultaneously.

459

Interactive FEA - Dam Mesh bnalysis Result

Dialo Box &it alF4

..

Label: ~ 0 xxx • Y'fY

Label: ~ 0

7.ZZ

DRAWING AREA Messa e Area

..

Figure 10 - Screen of modem applications

It is interesting to note that the dialog through the dialog box can also be classified as dialog by direct manipulation [FOLE90]. This is so because, in modem dialog boxes, the user can directly select the field he wants to type text in or the option the wants to choose; he does not have to follow any predefined path.

3. TOOLS FOR PROGRAMMING DEVELOPMENT The development of batch Finite Element programs, without any graphical interface, can be performed with simply a good compiler. Despite the advances of ALGOL, PL/l, PASCAL and now C, FORTRAN is still the most popular tool for this class of programmers. To develop programs with user interfaces illustrated in Figures 7 and 8, the programmer must use a graphical library with support for drawing graphical primitives (such as lines and filled area) and with at least a function to capture a screen position selected by the user. GKS (Graphical Kernel System) and PRIGS (Programmer's Hierarchical Interactive Graphics System) are among the most common used libraries for this purpose. If the programmer chooses to develop these functions directly, he will have to face lots of programming details of the devices he will be using. Libraries such as GKS and PHIGS are device independent and have drivers to support virtually all important devices. GKS and PHIGS are very similar in many ways. One can go even further and say that, in a certain sense, GKS is a 20 subset of PHIGS. This because all GKS primitive functions (polyline, fill area, etc.) are present in PHIGS with a similar name. The same can be said about the functions that control the style of these primitives (line width, color, etc.) and the functions that capture user input These similarities come from the fact that both systems are ISO standards and that this organization enforces compatibility among its standards. The basic differences between GKS and PHIGS are the dimensions, the storage mode and the image generation mode. GKS is a two-dimensional package, while PHIGS is three-dimensional. This says not only that the coordinates in GKS are (x,y) and in PRIGS are (x,y,z) but also that, with PHIGS, the application programmer can also define projection and illumination parameters. GKS stores figure components in disjoint group of primitives called segments. These segments are entities which exist during program execution. These entities can be geometrically transformed as a group and can be selected by the user through the pick input function. Primitives

460

and attributes in PRIGS are stored in a tree where the nodes are groups of primitives or transformations. Parts of this model can also be selected by the user through the pick function. The third important difference is the image generation mode. In the GKS, the primitives are sent to the workstation (abstract devices) where they are shown or stored. In the PHIGS system, the application programmer edits the tree that describes the figure. A concurrent process, internal to PRIGS, transverses the tree and exhibits an image, which is a function of the projection and illumination parameters. The concurrent process used in PHIGS is its biggest strength and weakness when compared to OKS. The concurrent processes somewhat separate the modeling of the objects in the scene from the rendering process, allowing several interesting effects such as walk-through the model. This concurrence, however, is difficult to implement in the DOS operating system, and DOS is still responsible for a large portion of currently available computers. OKS and PHIGS were developed with emphasis in the generation of images from abstract data. They have very limited tools to support user interface activities. Dialogs of the type illustrated by Figure 10 are almost impossible to be developed using only OKS or PRIGS. The support for this type of user interface is currently available only in modem windows environments. One of the first windowing system was Star system by Xerox Park. Currently, two competing window systems dominate the market: X-Windows and MS-Windows. X-Windows is the industry standard for the workstation market [SCHE86]. This system, developed by MIT, supports graphical interfaces with hierarchical windows and the client-server model. Although X was designed to be independent of hardware and operating systems, it can be found mainly running on top of Unix and in a network of multi-vendor workstations. The development of applications with user interfaces of the type illustrated in Figure 10 directly on top of the X-Windows is a very hard task. The tools available for application programmers in X-Windows alone is very limited. To discuss this point further, let us examine the progranuning environment of the X-Window system. In X, applications cannot access video memory as they can in DOS: to draw anything onto the screen, an application program (client) must communicate with the X-Server. This communication is always done through a network protocol; thus, client and server do not need to be in the same machine. To free application programmers from having to deal with network protocols, X implementations always supply a raster graphical library called Xlib. This graphical library provides C functions to draw graphical primitives (lines, filled areas, etc.) and to somewhat control the layout of the windows. Xlib, however, is very simple and does not provide direct support for programming graphical user interfaces. This support can only be found when a graphical system, such as PHIGS, OKS or XGL, is introduced to handle the computer graphics aspects and a toolkit of user interface objects (widgets) associated with an object oriented library called Xt Intrinsics is also used [ASEN90]. Figure 11 illustrates the structure of programs written on top of X-Windows.

Aplication

1

Widget

l

Xt Intrinsics

OKS

Xlib Operating System Hardware Platform Figure 11 - Typical Structure of a X-Windows Application 461

The user interface objects (widgets) are still not standardized and several competing sets are available in the market today. The Athena widgets distributed with X-Windows by the X Consortium, the Open Look widgets [SUN90] and the Motif widgets [DOUG90] are among the most widely accepted. The second window system, which is very important in the IBM-PC compatible market, is the MS Windows. In this environment, the tools for constructing graphical interfaces are based on the SDK (Microsoft Software Development Kit) [Wll.,K91,PET'Z90] for Microsoft Windows. This toolkit has tools for both computer graphics and user interface tasks. Compared with the XWindows architecture, the SDK includes the widgets, the Xt Intrinsics and the Xlib. Recent C compilers in this environment are already totally integrated with tools to construct user interfaces via direct manipulation. This variety of systems and toolkits, specializ.ed for different classes of hardware platforms, makes the education in the graphical interface area more difficult and delays the development of Interactive Graphical Finite Element programs. On top of this confusion, even the programming language is changing. The best user interface toolkits are object oriented and prepared to be programmed by C++ (Object Oriented C).

4. CONCLUSION When choosing a formulation or an algorithm to implement a Finite Elements numeric simulation, we are used to the idea that there isn't a single best simulation or best algorithm for all the problems; we thus prepare ourselves to face a wide range of solutions. When Finite Elements specialists deal with graphics systems and user interface systems matters, with which they are not familiar, they expect that specialists from these areas will show them the better option. The discussion presented here demonstrates that there is no such thing as the best graphical user interface tool, but only the most appropriate to the circumstance. This leads Finite Elements specialists to invest more in their formation on graphics and interface areas, so that they will be able to develop Interactive Graphical Finite Elements programs.

5. ACKNOWLEDGMENT The authors thank SCT and CAPES for the financial support and to Clarisse Sieckenius de Souza, Luiz Henrique de Figueiredo and Enio Emanuel Ramos Russo for the revisions and suggestions. :::

REFERENCES [ASEN90] [CAMP91]

[CARV90]

Asente, Paul J. and Swick Ralph R., X Window System toolkit: the complete Programmer's Guide and Specification, Digital Press X-motif series, 2nd ed., 1990. Campos, J.A., Martha, L.F.R. and Gattass, M., Estruturas de Dados Topol6gicas para Gera