High-level languages and userinterface managers for finite-element analysis systemsby Prof. D. A. LowtherMcGill University

The construction of large finite-element design packages is a time-consuming and expensive task, requiring expertise in many areas ofsoftware engineering. Suitably designed high-level languages can helpto alleviate this problem, making it possible for a design engineer totailor a CAE package to his own particular requirements.

Introduction

Over the past two decades, finite-ele-ment analysis has become one of themainstays of structural, mechanical andelectrical design on digital computers,and thus a major part of any computer-aided engineering system. It provides apowerful and flexible way of modellingthe real world, while giving designengineers increased insight into devicebehaviour and reducing overall designcosts. However, the complexity offinite-element analysis, or of anynumerical approach to device model-ling, has restricted the use of thesetechniques to relatively few experts inthe field.

Indeed, the construction of a com-plete finite-element analysis system is acomplex task involving many man-yearsof effort and many different areas ofexpertise, such as user interface design,numerical analysis, computer graphicsand database design, to name but a few.The final system may translate into hun-dreds of thousands of lines of code in aconventional high-level language suchas Fortran 77 (Ref. 1), and will usuallyamount to several megabytes of actualmachine code.

Such reasons have tended to dis-courage smaller companies — i.e. the

180

ones that could most benefit from thepotential cost gains — from becominginvolved in advanced, computer-baseddesign tools. Recently, packages havebecome commercially available whichare capable of providing theseadvanced techniques at the designer'sdesk and at a relatively low cost. How-ever, these systems are not always quitesuited to the particular purpose that theuser had in mind, and, although thechanges needed appear superficiallytrivial, the actual implications for anentire design system may be extremelycomplex. Typical examples might be:the inclusion of time dependency,which could require a re-design of theentire database; or a new form of out-put parameter calculation, whichrequires considerable new code andmaybe even a new solver; or the systemmight have a proprietary database sothat it will not fit well into a totalcomputer-aided engineering environ-ment.

To satisfy specific user requirementsit is necessary thatfinite-elementdesignsystems provide simple methods foruser-based modification and extension.

Machines and languages

The user's view of a computer architec-

ture is almost totally controlled by theway in which he communicates with themachine. This is generally known as 'theprogrammer's model' and defines theoperational capability of the device. Itmay bear very little resemblance to theunderlying hardware structure, and,except in terms of operational speed,the physical hardware is of little inter-est. If this concept is considered furtherit is possible to suggest that all anycomputer language does is to presentthe programmer with a method ofmanipulating a particular virtual (orimaginary) computer structure. Forexample, the virtual machine presentedby the Fortran 77 language has beendesigned to ease the task of buildingscientific numeric computation sys-tems. It becomes an exceedingly diffi-cult machine to use if the ultimateobjective is to construct software for aword processing system.

Virtual machines may exist at severallevels and even, under some operatingsystems, simultaneously. Thus an oper-ating system might be considered to bea virtual computer which provides anenvironment within which other virtualmachines exist. Usually, the lower-levelmachines are referred to as 'tools' exist-ing within the overall environment.Each tool is designed to be efficient atperforming a specific task, and fre-quently the operating system willprovide methods for linking toolstogether.

The lower-level utilities may be usedto construct more complex and specifictools. Thus Fortran 77 might be used toconstruct an equation-solving machine,which then becomes a higher-level

Computer-Aided Engineering Journal October 1986

tool. The concept of a software system,such as a computer-aided design (CAD)package, as a complex but well definedmachine can often be helpful, both inits initial design and in understandinghow to use it efficiently.

Therefore the CAD system may beviewed as any other virtual computer,and thus has a set of valid operationsdefined for manipulating data withspecific, well understood properties.For example, the field solution pro-duced by a solver may be in the form ofan array of numbers representing amultiple-component vector field in twodimensions. The valid operationsapplicable to the field are those of vec-tor calculus and vector and scalaralgebra. In a mesh generator, the datarepresents a geometric description of adevice, and the valid operations arethose of a geometric modeller.

In addition, computing devices arecapable of conditional operation, andthese constructs are implemented in alanguage by means of the familiarIF...THEN, DO...WHILE etc. struc-tures. In a typical CAD package thesestructures tend to be provided by usercontrol rather than within the package.Thus the fundamental properties of theCAD package are little different fromthose of any programming language! Infact, this argument leads to the naturaldevelopment of problem-oriented lan-guages (Ref. 2) and problem-specificinterfaces (Ref. 3) as the only sensiblemethod for providing access to the CADtool. Recently, considerable work hasbeen focused on the development ofsophisticated consistent languages fordesign systems, in place of the ad hocapproach used in the past.

Software development versuslanguage level

Fortran was designed for early commer-cial computers to provide users with amore sophisticated mathematicalmachine than was possible at the purehardware level. Increased sophisti-cation in the virtual machine meant thatsoftware development times could bereduced; it was no longer necessary toworry about exactly where in the lin-early addressable memory space a par-ticular variable resided, and whetherthat variable was a number or acharacter. In fact, Fortran provided amethod for linking together many basicfunctions by single calls, each functiontranslating into many lines of assemblercode and then many more machineinstructions.

Of course, the overall effect was thatFortran programs ran more slowly thantheir assembler or machine code coun-

terparts because the low-level oper-ations on the real hardware were nolonger optimised to take account of thereal hardware capabilities. Instead,code was linked together from pre-stored blocks by a set of rules whichgave the best average performance. Asthe rules grew more complex, theFortran programs became faster.

However, the main gain was in thecost and speed of sotfware develop-ment; an instruction to the Fortran'computer' took as long to design as aninstruction to the 'real computer' but itcould do so much more! In fact it mightbe equivalent to ten or20real computerinstructions. Thus programmer pro-ductivity increased by the sameamount.

The addition of a sub-routinecapability provides the language with amethod of expansion: a sub-routinemay be considered to become yetanother language construct. In effect itdoes the same as the basic languagecommands; i.e. it is replaced by a blockof pre-defined code each time it is used.Thus every language is expanded by theuse of large sub-routine packages,often giving it the capability to performnumerical analysis, graphical oper-ations, database management etc.

High-level programming and userinterfaces

All computer programs must have someform of user interface, even if this onlyrequires typing the program name.However, the capabilities provided inthe interface vary widely between CADsystems. In general the 'user interface'is considered to be that part of a pro-gram which is visible to the user and bywhich a user controls the operation ofthe program. Traditionally, such inter-faces were terse commands and stringsof numbers issued via a punched cardor an alphanumeric keyboard. Thearrival of inexpensive graphics displayshad little effect on most CAD interfacesinitially, because of the investment inexisting programs. Graphical displayswere added, rather than designed in abinitio.

Recently, however, the wide avail-ability of raster graphics systems andlocal processing power has encouragedthe development of highly interactivegraphical interfaces in which the usercommunicates via a range of devices,the most common being a keyboard foralphanumeric input and a 'mouse' forgraphical input (Ref. 4). These advancesprovide the end-user with an environ-ment which is exceptionally powerful inits capabilities. What was once just asimple piece of code to drive the analy-sis software has become a major com-

Computer-Aided Engineering Journal October 1986

ponent, the 'user interface manager'(Refs. 5-7).

From the definitions given above,these interfaces may be considered tobe programming languages in their ownright. In general they provide a simplesingle command line execution of theapplications code to which they inter-face. These commands may be issuedvia the keyboarder more commonly byselecting menu items. Rarely, however,do such interfaces provide any form ofprogrammable control structures, suchas looping or conditional execution.

Many of the properties of the userinterface, such as menu management,command interpretation, graphics echoetc., are common to a range of appli-cations, thus allowing the user interfacemanager to be defined separately fromthe applications code that it is expectedto control. Essentially, it provides theskeleton of a programming language inwhich all the control structures,together with parsing systems and arith-metic and logical operations, can bedefined. Many of these operations canbe controlled from any available inputdevice, allowing graphical, keyboard orfile-directed entry to the program withthe ability to switch between modes asthe user desires. In terms of a finite-element system module, the structurebecomes that shown in Fig. 1 (Ref. 8).

Application-code-specific operationsare driven via operators in the language(or interface) which are uniquefor eachapplication and are added to thevocabulary by the applications pro-grammer. Each one of these operators,or 'commands' or 'verbs', is parsed andtranslated into a program line which isinput device independent. Thus inputfrom a 'mouse' or a keyboard is treatedin exactly the same manner at the lowerlevel of the user interface. The inputline is passed to a lower-level decoder,which causes the appropriate appli-cation function to be executed.

As with any programming language,sequences of operations may be storedas a program and executed by recallingthe program name. Since the intermedi-ate code level is independent of theinput device, program sequences maybe written equally as easily by graphicalselection and pointing as by keyboardinput.

As an example of the power of thisstructure, a programming language fora finite-element mesh generator may becreated by providing operators in thelanguage which act on the basic parts ofa mesh, and on the mesh itself. Thus anassignment operator would make acopy of one entity (for example a node,an element or a collection of elements)into a similar one. This might well beimplemented by an operator 'COPY'.

181

user interface manager

applicationscode

databasemanager

graphicsmanager

operating system utilities

Fig. 1 The structure of a typical module

The exact form of the operators and thecommand string will depend on the par-sing system embedded in the interface,i.e. prefix, infix or postfix notation. Theonly application functions required arethe ones which allow the editing (inser-tion, deletion, copying or merging) ofeach entity that may be stored in thedatabase. The result is a programminglanguage which allows a customisedmesh generator to be built with rela-tively little programming effort (Ref. 9).

Program structure versus executionspeed

Execution speed has been, and to alarge extent still is, one of the mostimportant criteria in the selection of anydesign analysis program. For anycomputer-based design system tocompete with current 'hand'-basedmethods it must provide a performancebetter than or equalling traditionalmethods in several areas:

• It should reduce overall turn-around time for a design.• It would provide information to thedesigner which is as good as, and pre-ferably betterthan, information that canbe derived by more traditionalmethods; i.e. the design system shouldprovide answers to problems that can-not be solved by traditional means.

182

• It should allow access to the resultsin a quick and easy manner. If thecomputer takes longer to find a particu-lar result than a designer takes to look itup in design notes, then the computersystem is unacceptable.• It should help the designer, ratherthan control him.

From the viewpoint of an interactivesystem, response time should be asshort as possible; i.e. any entry at thekeyboard should create a reply'instantaneously'.

It should be noted that there is a dif-ference between the response to anaction and the response to a command.The former requires some form of feed-back, usually visual, that the action hasbeen entered; the latter is the result ofthe specified operation on the currentdata. If instantaneous response isrequired in both cases the executionspeed of the software is very important.However, short response times may beachieved even on relatively slowcomputers if the software is carefullydesigned and the capabilities arelimited. Conversely, even fastcomputers can exhibit bad responsetimes if the software is poorly designedor the capabilities provided range fromextremely simple to extremelycomplex.

Instant response to the user may not

guarantee that the first criterion listedabove is satisfied. In fact, fast responsemay actually lead to an increase in over-all design time if the designer uses theCAD system as a substitute for thought!

Although many CAD systems are soldon the basis of their interactivity, theultimate use is often in a 'batch' mode,where the computer is used to analyse awhole sequence of designs while theengineer is free to pursue other tasks.Interactivity is a useful property duringthe time in which the designer is learn-ing about the characteristics of a par-ticular device, or while a program isbeing tested and developed. If thedesign process is to explore a large partof a specific design space to create anoptimum design, then a programmable'batch'-oriented system is much morelikely to satisfy the requirements. Untilcomputers are able to solve the massivesystems of equations that can beproduced with finite elements'instantaneously', this situation is likelyto continue to exist.

Thus execution speed may not beseen as the ultimate goal of a currentCAD system; rather the major require-ment has to be one of flexibility.

Finite-element systems

Traditionally, finite-element design sys-tems have been constructed as either alarge monolithic block or as severalsmaller pieces communicating by a setof data files which do not necessarilyform a uniform data structure frommesh generation to result evaluation.For example, the data structure used inthe database for storing mesh descrip-tions may be totally different from thatused for the same description in thesolution database. In more modern sys-tems, the multiple-file approach tendsto have been used both to simplify con-struction and maintenance problems,and to provide a logical separationbetween the distinct tasks of geometricinput, problem specification, equationsolution and result evaluation — seeFig. 2 (Ref. 10).

The effect of the separation is to pre-vent a user from being able to movefreely between separate, disjointphases of the process, such as request-ing a change in the geometric specifi-cation while in the solution phase, thusemphasising that these operations aredistinct tasks which require differenttypes of virtual machine for theirimplementation.

However, this separation can thenprevent further development of a sys-tem. For instance, in an adaptive mesh-ing scheme, where the mesh is refinedb'ased on one or more solutions to theproblem, it seems obvious that the

Computer-Aided Engineering Journal October 1986

geometrydefiner

problemdefiner

defined problemsand solutions

physicalpropertydefiner

resultevaluation

solver

Fig. 2 A typical system structure for a finite-element based CAD package

solver must have access both to thecapabilities of the result evaluationmodule and the mesh generator. If itcannot access these easily then therequired functionality must be built intothe solver itself, thus returning to themonolithic system with all its potentialdrawbacks for a software engineer.

An alternative approach is to providean ability to link the various distinctmodules together when needed so thatdata from the solver may be passed tothe result evaluation system and thenfed back to the mesh generator; ineffect, the monolithic structure is cre-ated at a higher level. To accomplishthis the system design must satisfy twocriteria: the first is that all three mod-ules communicate via a commondatabase structure (Ref. 11), while thesecond requires that each module beable to operate in a batch-orientedmode, i.e. without user intervention.The chaining of the three modulesmight then be accomplished by a smallset of operating system commands.

Of course, this approach will prob-ably lead to considerably longerexecution times than those encoun-tered for a monolithic solver structurebecause of more frequent access to sec-ondary memory in the form of thedatabase and the need to keep loadingexecutable modules into primary mem-ory. The latter problem may well turnout to be an advantage since the mem-ory requirements for the system maywell be reduced, allowing execution onsmaller computers!

The gains in system flexibility

obtained from a distributed structureare usually of prime importancebecause of both the man-time saved inconstructing and testing the controlstructures needed for a variety of tasksand the fact that many, otherwise com-plex, user requirements of this naturedo not require an expert in the internalcoding of the system for their creation.Rather, the structures can be created bya user who has no understanding of thereal internals of the system; all that isneeded is a set of well definedinterfaces.

Comdec — a command decoderexample

An example of a user interface manage-ment system coupled with program-ming language constructs designed towork with finite-element modules isComdec, the interface associated withthe MagNet (Ref. 12) finite-elementpackage. This command decoder wasdesigned in the spirit of the principlesdiscussed above, although severalextensions have been added.

The extensions include capabilitieswithin the interface for creating pro-grams with local parameters. These par-ameters may then be specified atexecution time as part of the input com-mand line, allowing considerable flexi-bility in the use of stored programs.Since the program may be run merelyby typing its name, each new storedsequence of instructions can become anew command (or operator) in the lan-guage. Thus the programming language

Computer-Aided Engineering Journal October 1986

can be extended by the programmer toprovide a virtual machine which fitswith his view of the world.

An additional extension allowsincreased communication between theinterface package and the applicationfunctions. Each application routine canimport and export, via reserved key-words in the interface, variable valuessuch as, in the case of a mesh generator,the Cartesian co-ordinates of a point orthe nodes making up an element etc.This data is available via a set of appli-cation-controlled variables which maybe manipulated by arithmetic oper-ations in the interface. The variablesmay have scalar or vector properties;i.e. entire arrays may be manipulatedwithin the interface.

Thus a geometric operation, such as'ROTATE', may be performed by access-ing the co-ordinates of the entire pointset by a simple function which loads theinterface data structures from thedatabase, transforming the entire arraywith a single high-level instruction, andre-loading the database. In the lan-guage provided by Comdec this oper-ation could become just threeinstructions; and these in turn could bestored under a single name whichwould then become a new 'macro'instruction in the language.

As this concept is pursued further, itis possible that an entire mesh gener-ator could be produced to a user'srequirements in around 400 lines ofcode, as opposed to the 8000 to 10000lines of Fortran 77 or Pascal that are cur-rently required, giving a large reduction

183

in system development time as well asproviding relatively unspecialised pro-grammers with the capability of con-structing the software. The price is, asusual, one of execution time, which islikely to be somewhat longer than thatfor an equivalent system written at alower level. However, this cost shouldalso be set against the reduction inmaintenance and support timerequired.

The example used above has men-tioned mesh generation; however,similar procedures may be applied tothe solver module and the result evalu-ation phase. Solvers tend to be batch-oriented processes in any case. How-ever, the development times of a newsolver are considerable, and yet manyof the processes are common to manysolvers, for example the assembly ofindividual parts of the coefficientmatrix, the forward elimination phase,decomposition etc.

Of course the use of sub-routinelibraries makes this kind of develop-ment somewhat simpler at the Fortranlevel, since many of the fundamentaloperations required are now availablein libraries, such as the Finite ElementLibrary under construction at theRutherford and Appleton Laboratory(Ref. 13). The interfaces to these rou-tines are often complex, having largenumbers of parameters of many types,and may require considerable coding.The advantage of the high-level lan-guage is that it can remove the interfac-ing problems by ensuring that the front-end routines set up the correct par-ameters from a relatively simple userinput format.

Results

User interfaces providing high-levelprogramming capabilities within finite-element based analysis systems havebeen used in several recent result evalu-ation systems (Refs. 14 and 15). This hasbeen the first area of applicationbecause of the obvious need for adapt-ability to a user's requirements; it isvery difficult to predict in advance thetype of results that a user mightultimately require.

However, often the input data is welldefined and consequently the range ofvalid operations is known. For example,as described earlier, the data availableat the input to the system is a field sol-ution, usually in the form of a potentialdistribution, while the valid range ofoperations allowable on the solutionmay be determined from a knowledgeof the mathematical and numericalapproximations made in the overalldesign system. The output of the systemmay be almost anything definable in

184

terms of the operators, but the basicdata forms which can occur may bespecified at the system design stage.Thus a basic result evaluator can be con-structed which defines a language bywhich the operations may be applied tothe field, and a particular user's require-ment may be met by programming atthe higher level.

In the two examples to date, thisapproach has proved to be very suc-cessful. Typically, a new result may beobtained from the system with less thanhalf a man-day of programming effort.For example, a force calculation routinein an electromagnetic analysis systemmay be constructed in around ten or 20lines of application-specific code.

Although the language was designedto be interactive, many users requirethe same set of operations to be appliedto many solutions, particularly if a rangeof possible designs is being examined.In this case, once a program has beenwritten and tested the system may berun in a batch mode to provide therequired outputs for later examination.

Frequently the users of the systemwere not electrical engineers, and theflexibility provided by the languageallowed operations to be expressed interms with which they were familiar.

Conclusions

The development of high-level userinterfaces combining both graphicaland keyboard input can significantlyreduce system development times.These interfaces may be considered ashigh-level application-dependent pro-gramming languages in their own rightand provide a user with a relativelysimple environment in which toprogram.

However, to create such a completesystem standardised database struc-tures are needed, as well as standard-ised interfaces.

When the concepts described aboveare used to create a design system it ispossible for a finite-element package tobe constructed to meet a specific user'sneeds at considerably lower initial cost,and with substantially fewer mainten-ance problems.

Acknowledgments

The author would like to acknowledgethe support of the Natural Science andEngineering Research Council oiCanada and Infolytica Corporation ofMontreal, Canada, during the course ofthis work.

References

1 'The programming language Fortran'. ANSI X3.9-1978, American National StandardsInstitute, Inc. , New York, NY, USA, 1978

2 GRODZKI,Z.,andWINIARSKI,M.: 'IDIM —an interactive data input model'. Proceedingsof CAD 84 Conference on Computers in Design Engineering, Brighton, England, April1984, pp. 15-22 (Butterworth Scientific, 1984)

3 LIM, P. T. K., and MOFFAT, K. P.: 'ADL — a data language for engineers', Proceedings ofICE, Part 2, 1981, 71, pp. 131-149

4 LIBERMAN, H.: 'There's more to menu systems than meets the screen', Computer Graph-ics ,1985,19, pp. 181-189

5 GREEN, M.: 'The University of Alberta user interface management system', ibid., 1985,19,pp. 205-213

6 OLSEN, D. R., )r., DEMPSEY, E. P., and ROGGE, R.: 'Input/output linkage in a userinterface management system', ibid., 1985, 19, pp. 191-197

7 LITTLEFIELD, R. j . : 'Priority windows: a device independent, vector oriented approach',ibid., 1984, 18, pp. 187-193

8 KASIK, D. J.: 'An architecture for graphics application development'. SIGGRAPH 85Course Notes: Building Engineering and Scientific Graphics Applications, SIGGRAPH 85,San Francisco, CA, USA, July 1985

9 MARTIN, R., DOWNS, J. E., and SIMON. M.: 'Some human factors in effective CAD',Computer-Aided Engineering journal, 1985, 2, (I), pp. 21-23

10 LOWTHER, D. A., and SILVESTER, P. P.: 'Computer-aided design in magnetics' (Springer-Verlag, 1985)

11 SABOURIN, R., LOWTHER, D. A., and WEBB, ]. P.: 'GBASE — a generalised databasemanagement system for CAD', Computer-Aided Engineering Journal, 1986, 3, (5), pp. 207-212

12 'The MagNet user's manual'. Infolytica Corporation, Montreal, Canada, 198513 GREENOUGH, C , and EMSON, C. R. I.: 'A flexible finite element system suitable for

electromagnetic research', IEEE Transactions on Magnetics, 1985, MAG-21, pp. 2531-253414 LOWTHER, D. A., and FORGHANI, B.: 'Interactive post-processing techniques for elec-

tromagnetic field analysis', ibid., 1983, MAG-19, pp. 2168-217015 LOWTHER, D. A., REA, K., SILVESTER, P. P., FREEMAN, E. M., TROWBRIDGE, C. W.,

SIMKIN,)., and NEWMAN, M.: 'A stack configured vector calculator for electromagneticfield evaluation', ibid., 1982, MAG-18, pp. 627-629

Prof. D. A. Lowther is with the Computational Analysis & Design Laboratory of the Depart-ment of Electrical Engineering, McGill University, 3480 University Street, Montreal, Quebec,Canada H3A 2A7.

Computer-Aided Engineering Journal October 1986