ICON: The interactive creation of NASTRAN data. A system description

ICONthe interactive creation of NASTRAN data. A system description A. P. ARMIT and I1. U. LEMKE (Graphical Software l.imited, London)

A description is given of the ICON system for the interactive creation of data for the NASTRAN suite of structural analysis programs. The overall design and development of ICON h3.~involved a total of seven man-years of effort by Graphical Software Limited. The equivalent of about 70 k machine instructions have been written. ICON was designed and constructed to meet specific requirements of the Hull Structures Department of Lloyd's Register of Shipping, where the system is in daily use. The three-dimensional interactive system which forms a major part of ICON is the main topic of the paper. (Receivcd on 20th February 1975)

The three-dimensional intcractxve graphics system described was designed and constructed by Graphical Software l.imitcd (GSL) to mcet specific requirements of the Ilull Structures Department of Lloyd's Register of Shipping, where the system is in daily use. With thc inclusion of interactive graphics in a commercial project, the 'production' rather than the 'research' attitude has necessarily been adoptcd to ensure the relevant application of effort. 'Modularity' rather than 'total gencrality' has been a design aim, which at least gives a bounded cost and does not imply the 'total knowledge' needed to determine the truly general problem. The resulting system is flexible enough to accept allied modifications and additions: cven with a very different task many system modules would still be exactly applicable, because their function is to create an environment for the user. Certainly, the software organization is modular and we believe its extendability to have been demonstrated in our progress from a useful 'subset' system to one which includes all facilities of the specification, over a period of a year. Throughout this time working versions were released. Further proof of its extendability is the t~se with which features can be (and have been) modified, extended or added 1. The Hull Structures Department's particular need was for help in checking and modifying descriptions of finite element idcalizations (of ships' hulls etc) for input to the NASTRAN suite of structural analysis programs z. The NASTRAN programs are used within Lloyd's Register to perform many kinds of static, elastic and dynamic analyses 3. Such descriptions include both geometric and material properties of structures and may be held upon tens of thousands of inter-referencing cards, and thus manual data preparation can be tedious, time-consuming and errorprone. Although NASTRAN may detect errors such as syntax or missing refercnces before performing extensive computation, it will ncver know if a quite legal yet undesired structure is being analysed - a typical result of a data preparation error. Because, using Lloyd's Register's IBM 370/158, analyses can take several hours, the need to avoid unsuccessful runs can easily be appreciated. The ICON system was designed to alleviate these problems by giving the user a ready means to ensure the structure is as desired, as well as legal.

Volume 7

Number 3 July 1975

NASTRAN data can be thought of as part 'geometric' and part non-geometric (for cxample properties of materials, etc). In NASTRAN, only GRID cards include coordinates of points, while bar or plate clcments name GRID cards to indicate their gcomctric extrcmes. In the ICON system the geometry is separated from NAS'FRAN data and can be used to generate upon a display screen threedimensional line drawings which can be viewed from any angle; a joystick control permits instantaneous and continuous rotation about any axis. Within the environmcnt of the system, the user can modify and also gcnerate NASTRAN data by reference to geometry. Equally, the user may label and annotate the geometry according to the NASTRAN data. In this manner checking and modifying NASTRAN data has been eased. Furthermore, the ICON system allows many geometric manipulations, including 3D drawing, automatic generation of lines, points, and panels, deletions and movements of points. 'ICON was developed on a Vector Gencral 3D3 'threedimensional' display, with keyboard, light-pen and threeaxis joystick, driven by a DEC PDP-11/45 minicomputer with 64 k bytes of memory, DECwriter, cartridge discs, magnetic tape, paper tape and card readers.

NAS T R A N D A T A A N D ITS R E P R E S E N T A T I O N IN ICON

Probably the major (and most obviously necessary) feature of the system design is the treatment of the NASTRAN bulk data deck. The quantity, structure and content of the NASTRAN data necessitated alteration of the format within an interactive system to allow reasonable geometric and other manipulations. This leads to the three stages of ICON, see Figure 1. The interactive system, which forms the major part of ICON, deals solely with the internal card structure and linepoint structures and benefits greatly from the ability to allow the independent existence, creation and modification of card structure and of geometry, without being restricted to operations maintaining a combined legality. The design of the line-point structure is independent of NASTRAN and

145

A. P. Armztarm H. U. l.emhe

NASTRAN data in format

card

t

.

.

.

NASTRAN data in card format

t

i

[

] ]

[ [

/

~ g "' ' x

Card structure Of internabformat NASTRAN

.

Line point structure

Interactive system allows modificatior~ and generation

of geometry

] J

yields card format

FIGURE I. The three stages o f ICON

structure does not cause consequential geometry modifications. For example, deletion of the GRID card does not cause the referenced geometric point to be deleted. The geometry definitions of lines and points can depend upon other points and lines. Thus the geometry structure does contain internal references to other geometry, although it makes no reference to NASTRAN. The card structure must bc informed of the deletion of a line or point etc because this may modify the geometry references of the NASTRAN. The simple approach would be to immediately update geometry references in the card structure, thus causing a complcte examination of the card structure at each such geometry, change. However, a sequence of geometry changes may be recorded in a 'history' and the use o f the complete history delayed until it is necessary for the references to become up-to-date. Deletion of a geometric point will not delete the GRID referencing that point, but sets its geometry reference fields to 'blanks'.

contains all the geometric data giving co-ordinates of lines, points, etc while the card structure keeps the character data associated with each input NASTRAN data card. Wherever an original NASTRAN data card would have named a GRID card to indicate an x, y, z position, it is made to reference a point of the line-point structure. Of course, it is the linepoint structure which is processed to produce labelled linedrawings of the shapes on the screen, see Figures 2, 3 and 4. Figure 6 is more typical of the screen pictures produced during system use.

.Maintenance

of r e l a t e d

structures

This separation of the geometry from the character information of NASTRAN is responsible for most of the benefits of using ICON. However, schemes dividing information between two related structures can only work if structure maintenance problems are solved. It was found that provided the card structure could reference the geometry, the reverse was never required. The advantages of this in both space and time are great; in particular, modification of the card

FIGURE 3. Annotation o f points

,r ?

~-.~ .~,

:2 ~

"-

FIG UR E 2. Display o f view information and global and local axes with a simple geometric structure

146

FIGURE 4. Location o f panel positions within a line-point construct

COMPUTER AIDED DESIGN

ICON: the htteractive creation of NASTRAN data Syntax pseudo-machine The provision of comprehensive interactive facilities required a system that could cope fully with the many and varied idiosyncracies of NASTRAN data. This is achieved via a 'syntax pseudo-machine', which is a subroutine running interpretively from a syntax definition structure. The syntax machine runs in many different modes, each of which requires some access to the character information of NASTRAN data. Examples of running modes are, syntax checking, presentation of NASTRAN on the screen and NASTRAN generation. When an 'interesting circumstance' is located, for example, a particular card type and/or any field content, the syntax machine calls a 'success subroutine'. Such success (or fail) routines are task-dependent and access the NASTRAN data via pointers etc, setup by the syntax machine. In this manner, it is possible to 'hide' the exact nature of NASTRAN and keep the system modular.

THE USER'S VIEW OF ICON The user does not need any programming knowledge to make use of ICON. Probably the most useful qualifications are a knowledge of NASTRAN and an understanding of 3D shape. The system is operated by using a joystick to control rotations etc; a keyboard to input numbers and names; and a light-pen to pick particular geometric items or to select a 'currently legal' set from the menu displayed. The system displays advisory messages to guide the user in building commands and controlling the system from the displayed choices, see Figure 5. Despite the application of rotations, offsets and scale change, etc, to produce a screen picture, the user never communicates in screen units or axes, but always in the axcs of his structure - the global axes - or in local axes, created and modified at his instruction, possibly offset and skewed relative to the global set. As in previous systems 4 a trihedral indicating x, y and z directions for the axes is maintained on the screen. Automatically during view change commands, and at other times by user request, the system displays comprehcnsive 'view information', giving details of offsets, rotations, false origins, working plane, tracking cross resolved positions, trial positions, scale, etc. in global axes and also in local axes if these exist, see Figure 2.

Use o f I C O N f o r c h e c k i n g It is possible to use ICON both for checking existing structures and for generating new structures. When checking existing structures the user causes the 'input' programs to absorb his existing NASTRAN data and store it (in internal format) ready for the interactive stage. The interactive system can generate and check the geometric and nongeometric information o f NASTRAN data. To check existing NASTRAN data the user typically causes a particular view of the structure to be shown on the screen. The view may be rotated under joystick control and may be 'dithering', that is, given a small oscillatory rotation to provide cues to 'depth' and show otherwise hidden members. Continuous variation of brightness with depth can provide additional cues. An axonometric projection can be used to present depth as a diagonal offset, allowing a series of constructs which otherwise would overlap to be

Volume 7

Number 3 July 1975

FIGURE 5. Presentation of N A S T R A N data on screen with field numbers and legal syntax

FIG URE 6. Display showing use of ICON (by courtesy of Swan-l lunter Shipbuilders)

separately visible in true view. The picture displayed consists of straight line segments with various annotations to mark particular points and elements, see Figures 3 and 4. Geometrically obvious errors are thus discovered, and may be corrected by deletions and/or by moving existing geometry, or by creating new geometry by picking, keying or tracking as described later. The user may trace which NASTRAN data relates to a particular geometric feature in a variety of ways. For example, he may (by command) label the geometry by the identifying number associated with NASTRAN cards; or ~he may annotate those parts of the geometry which are referenced by NASTRAN elements which also reference property cards containing particular entries. In this way, bars, etc, of a given property may be made visually obvious.

147

A. P. Armitand It. U. Lemke Further, the user may point the light-pen at any part of the picture; thc x, y, z co-ordinates of the hit are then displayed in global and local co-ordinates, and the user may request the system to locate each NASTRAN card referencing the item picked. Different line and point styles (dotted, encircled, blinking, invisible, dim, normal, bright etc) may be commanded for the geometry of items picked, or the geometry of all elcments (or only the faulty elements) of a particular type. The user is able to examine the non-geometric information of the NASTRAN data quite independently of the geometry. The system (using the syntax machine) presents the information on screen in NASTRAN format, complete with field numbers and indications of legal syntax. At any presentation of a card, and after any edit, the system performs a syntax check of the single card. Fields containing errors are marked with tERROR' to attract the user's attention, see Figure 5. ICON includes full facilities to check all NASTRAN cards for correct syntax, uniqueness of identifiers and existence of references. Of course, engineering errors in the NASTRAN are not detected? The system notes erroneous cards so that thcreafter the user may examine, and corrcct if he wishes, the errors found. By editing cards individually (or in bulk when supplying 'member properties') the user may communicate with and control the non-geometric information of NASTRAN data. To modify geometry, the user deals directly with the picture in which he may identify items to be moved, deleted, etc. Such facilities form only a part of the generation schcmes now outlined.

Use o f I C O N f o r g e n e r a t i o n Generation is expected to proceed naturally. First the geometry is constructed and then the items that refer to the geometry. There are various ways to create new geometry, of which 'drawing' is the most basic. In drawing, the system constructs lines whose start and end points may be specified by keying, picking or tracking. In keying the position of a point the user simply keys in the x, y, z components in either global or local axes. With picking, the lightpen is used to identify some other line or point: picking an existing point causes its re-use for an end of the current line, while picking within alinc causes creation of a new point within the line. Thc third way of indicating end point positions is tracking in which the light-pen movement is followed by a cross displayed upon the screen. The system includes the notion of a 'working plane' (defined by a constant x, y or z component in either global or local axes) in which the end point(s) of tracked positions currently lie, see Figure 2. Thus, the system computes a 3D position as the intersection with the working plane of the screen normal through the tracking cross. If required, tracking of this position can be constrained to bc aligned with thc plane's (local or global) axes. The construction of a sequence of connected or disjoint lines by any or a mixture of keying, picking and tracking is straightforward, without restrictions upon concurrent use of rotation and other viewing facilities. While it is unlikely that all these facilities will be needed concurrently, it would have been ugly to build arbitrary restrictions into the system.

"148

Thus, ICON can, for example, accept a tracking cross position to be interpreted as a point in a working plane which is defined in local axes. The axes may have a temporary false origin and may be offset and skewed relative to the global axes which may also have a temporary false origin and may be offset and skewed (or even rotating and dithering) relative to the screen axes. A series of points may be constructed by the system to divide a line (identified by the user) into equal segments and a series of lines may automatically be created to join two such series of points. Where this, or drawing, etc, causes an intersection with other lines, the system can automatically detect and create the required intersection point~. Furthermore, and perhaps most important, ICON can automatically locate triangles and quadrilaterals, which the user may wish to become plate or membrane elements, and create a suitable 'panel' geometry within the system, see Figures 3 and 4. The generation of NASTRAN data to reference the geometry is simply controlled: when the user examines a NASTRAN card (possibly at creation) the system detects if any geometry reference fields are currently blank, see Figure 5. If so, the user is given the option of supplying the geometry reference(s) in various ways, for example, once for every appropriate existing geometric item (possibly excluding any for which the element type already exists) or perhaps only for geometry items picked, etc. In any case, the user may supply more geometry references than necessary for the current card, to have the extra used on cards generated by the system, These cards are the same in every respect as the original except for geometry reference(s) and identification number.

ORGA NIZA TION OF THE INTERA CTIVE S YS TEM The organization of the interactive system is based on a collection of individually simple notions, although the program detail of some of these is not always so simple. For example, the overall running of the system is simply a set of 'main task' subroutine calls to perform the tasks of recalculation of rotation matrix, recalculation of main display file, processing of user's input, etc. Each such subroutine is liable to execution only when an 'enable' bit becomes set (by some other process, possibly an interrupt routine). Most tasks disable themselves on completion. Of course, single-user interactive systems must present the user with the consequences of his last command as quickly as possible (and before allowing execution of the next command) by executing a definite and well-known program sequence. Thus in this environment, in contrast to that of operating systems, 'parallel' tasking etc is not important.

User's i n p u t A most important aspect of system design is coping with user's input. This problem is compounded by a variety of input devices. Within graphical interactive systems some organization is usually needed to display both choices and suitable prompting messages. Not only must the appropriate choices etc be determined, but they must be assembled in suitable display file(s) and then displayed.

COMPUTE R AIDED DESIGN

ICON: the interactive creation of IVASTRAN data

Further, the light-pen must be able to 'see' the choices, for which some identification and confirmation mechanism is needed. Thereafter the USE of a choice has still to be determined.

a set of 'data-pointers' exactly corresponding to a stack of current and previous (pseudo or otherwise) program counters 6.

Command Display and interactions pseudo-machines

The ICON system overcomes such problems b y a flexible and novel organization consisting of a 'display pseudomachine' and an 'interactions pseudo-machine' and various small data areas for device status, etc s. These pseudomachines run interpretively from (separate) data composed simply of a set of mnemonic instructions. The display machine runs during an interrupt to find and start the next display file; addresses of the display files are held in the controlling structure under 'DISPLAY' pseudo-instructions. In this manner, the display machine hides the exact nature of the display from the rest of the system. Typically, enterprises of this sort result in reduced power over the display. The reverse is true of the display machine - it hides the inadequacies of the display hardware and, for example, resolves pen hits within lines, despite the fact that the hardware only gives an interrupt at line end. The interactions machine is called as a subroutine and is one of the 'main tasks'. The structures it interprets determine which choices and messages appear on the screen at any time, see Figure 5, and also set up devices into various modes. The interactions machine runs until it reaches a 'PAUSE', by which time the possible range of user activity is fully determined. The interactions machine is released when some input is received and uses the structures it interpreted to determine the action to be taken. Appendices 1 and 2 give program examples for interaction and display machines. Those who have knowledge of large systems know well the temptations to make 'fixes' to achieve results. However, such policies tend to lead to disaster in the long term. An advantage of pseudo-machines with defined instruction sets is the provision of an environment with opportunities to 'get clever' in a formally defined manner. A particular delight of constructing pseudo-machines is that the effects of any instruction can be exactly what one wishes, and that new instructions may be added at a later date in the knowledge that existing pseudo programs are in no way spoilt. This is of great importance to large developing systems since it is not possible to foresee all requirements at the time of initial design. A useful b y p r o d u c t of using pseudo-machines is this isolation of parts of the system and localizing modifications when changing display hardware, external data formats, etc. A further important advantage of the non-haphazard approach is the circumvention of the PDP-11 memory management constraint that interrupt and other programs can communicate only through shared data and the constraint that interrupt and other routines are separately linked to form distinct load modules.

Data machines

The pseudo-machines mentioned above help in formalizing certain processes. The system also includes 'data machines' which provide standard ways of accessing data-structures via

Volume 7

Number 3 July 1975

execution

Simple interactive systems often make command execution include all necessary picture recomputation etc. This wasteful approach is not used: rather the execution of a command performs the necessary specific actions and simply enables none or more other processes, which may in turn enable others. In this way the knowledge of 'when to execute' is kept out of the routines - allowing them to be used without modification in different environments. At times, the interactions machine is used to build character commands from both picked choice(s) and keyed input, and thereafter uses a language processor 7 to enter appropriate programs. The use of pseudo-machines has formalized system control and made the interactive processes simple to construct and debug.

CONCLUSION

We have limited this presentation of ICON to give mostly the user's view in order to indicate the nature and range of activities supported by the system. In an overall sense, ICON is specific to the task it tackles, but the application of most of the system software is quite independent of NASTRAN, consisting of modules providing an interactive environment for a user together with general routines including transformations and system control. Indeed, system usage is vitally dependent upon design of the system's organization and control mechanisms. The problems in providing an unobtrusive organization and control over the user are increased by the sophisticated graphics equipment. A future paper will discuss the achievement of the usersystem interface and the accompanying design considerations.

A CKNO WLEDG E M E N T

Acknowledgement is made to those who participated in the project both from Graphical Software Limited and Lloyd's Register of Shipping.

RE1.'ER ENCES

1 Lemke, H. U. and Armit, A. P. A Note on Advanced Software Tecbniques in Computer Graphics. Conference Proceedings of G174, Berlin, October 1974, Springer Vcrlag 2 McCormick, C. W. (ed) The NASTRAN User's Manual. National Aeronautics and Space Administration 3 Viner, A. C. and Milton, D. 'Ship structural analysis and interactive graphics'. Shipping World and Shipbuilder, (August and September 1974) 4 Armit, A. P. 'Computer systems for interactive design of threedimensional shapes'. Phl) Thesis, Cambridge Univ., England, (1970) 5 Armit, A. P. Organization and Control of Interactive Design Systems. Conference Proceedings of Journres Graphiqucs 1973, organized by AFCET and IRIA at Rocqucncourt (78) France, December 1973

149

A. P. Armit and I1. (). Lemhe 6

7

Armit, A. P. and Filby, F. S. Production o f Syntactically Correct A T L A S . Conference Proceedings of A u t o m a t i c Testing 73, Session No.4, Brighton, UK, November 1973 Armit, A. P. A Language]'or Interactive Design. Proceedings of the IFIP Working Conference on Graphic Languages, Vancouver, Canada, May 1972

APPENDIX 2: example program for display machine

;Each line becomes one 16 bit word in the computer ;Display of choices, formatted by the DMC

BIBLIOGRAPHY

This includes papers on related topics. 1

Butlin, G. A. Interactive Graphics f o r Finite Elements. Finite Element Symposium, Atlas C o m p u t e r Laboratory, Chiltern, Didcot, Oxfordshire, UK. March 1974 2 Gill, J. 'Computer-aided design of shell structures using the finite element method'. PhD Thesis, Cambridge Univ., England, July 1972. 3 Grieger, I. INGA - A n Interactive Graphics S y s t e m f o r Structural Analysis. International Conference of Computers in Engineering and Building Design, CAD74. 2 5 - 2 7 September 1974 Published by IPC Science & Technology Press, Guildford (in microfiche) 4 Hubbold, R. J. An Interactive Three-Dimensional Drawing Program f o r Grapbical Display and Light-pen. Proceedings of Computer Graphics 70, Wednesday 15 April 1970, Brunel Univ. Department of Comput. Sci., Uxbridge, Middlesex, UK

;DWN CHC5 is included in the top level structure .so that CHC5 is ;executed once per frame CHCS:

DISL DF1 7"

;Note that display of DF1 just sets up the 'top left' beam position ;as required TSTP CHC14 TPEN CHC13 ;setup 'traps' for next stop and pen interrupts

CHC3:

DISL

;display list of files starting a t . .

T UP

;none at all, terminate ;exit from CHCS, all choices displayed ;leave space

.=.+40

APPENDIX 1 example program for interaction machine ;Each line becomes one 16 bit word in the computer. ;Note that in using the program to construct choice and message ;display files, set up device status, etc, the IMC ignores t h e ;instruction immediately following each 'CHC' instruction. MODE PEN 1

;allow pen to see the choices

CHC PC1 BRN L1

;cause display of 1st choice

CHC PC2 CALL R1

;cause display of 2nd choice

MES MS1

;cause display of 1st message

CHC4:

UP

C11C5:

0 0

.=.+40 ;as the IMC finds a CHC instruction it extracts t h e raw characters ;and builds a small display file and deposits a pointer to the ;display file at the current end of the list at CHC3 and a pointer to ;the IMC CHC word in the equivalent position of the list at CHC5 ;Enter by trap on pen when pen sees a choice. ;Note that the display is stopped at the character seen CHC13:

PAUSE

;display list of files starting a t . . ;address Dt:I, and that's all because ;Terminate bit set

CALL C H C l l RTIC

;enter routine C H C l l to enter confirm ;modes ;return from trap to continue display

;Enter at stop trap, i.e. after display of each choice

;The IMC waits at the PAUSE until released by some user's input. ;By t h e time the IMC pauses all device modes have been set and, ;in our example, two choices and a message are displayed on t h e :screen. The user m a y pick either choice, and the IMC will be ;released to execute the instruction immediately after the relevant ;CHC as though it were written at the position of the PAUSE. ;Thus, if the second choice is picked, routine R1 is executed and ;the IMC continues in sequence following the PAUSE.

CHC14:

DISL DF2 T

;display list of files starting a t . . ;address DF2, and terminate

;This causes the beam position to be setup for the next choice RTIN

;return from trap

;At the return the IMC continues with the next instruction, ;which in this cast will be the display of the next of the CHC3 list. ;The following display files are in the format required by the ;Vector General display and are independent of the DMC

;ltowever, if the first choice is picked, control is passed to address ;L1 L 1:

;Absolute beam positioning DF1 :

;IMC instructions obeyed if first choice picked

J+LD+XR 040000 060000*T

;set beam to top left X=2000 ;Y=3000 and terminate

;Subroutine called from IMC

;Relative beam positioning

RI:

DF2:

return ;raw character strings for display PC1:

.ASCII/ANYCHARS/24

PC2:

. ASCII/ANY CHARS/24

MSI : .ASCII/ANYCHARS/24

]50

LD+XR 04000+T J+AD+YR 174000+7'

;re-position for n e x t choice ;X=2000, i.e. reset ;decrement Y by 200 screen units ;and terminate

;Subroutines called from the DMC ;'24' is the string terminator

CHC11:

;enter confirm m o d e

return

COMPUTER AIDED DESIGN