TMG MESH GENERATOR: USER’S GUIDE

PARTIAL VERSION

M. Paolini

Abstract. Milano, oct 21 1994. TMG v2.1-1, XSTI v1.1, TEK2PS v3.0

This is a very incomplete users guide for the TMG mesh generator, covering (by now) only the documentation of the TMG parser commands, and some features of the graphic implementation on the SUN.

Contents

??. Overview page ??

1. Level-1 interaction page 2 1.1. The TMG parser 2 1.2. Parser syntax 2 1.3. Parser commands 3 1.4. Domain definition 7 1.5. Density point definition 9 1.6. Parser expressions 10

2. Level-2 interaction page 11 2.1. The tmg init and tmg set commands page 11 2.3. Using the TMG parser from within a C program 12

3. Level-3 interaction page 14 4. gm to tmg conversion 16 5. XVIEW graphics interface 18

5.1. Calling a Tek function 18 5.2. The 41xx window 18 5.3. Hardcopy of the graphics 18 5.4. Bugs and malfunctions 19

6. Tektronix to PostScript conversion 20 7. Policy and Installation on a Unix system 21 8. Bugs and future developments 22

Typeset by AMS-TEX

1. Level-1 interaction

The easiest way to interact with the TMG mesh generator consists of using the binary interface tmg via a .tmg file. This way of interaction allows easy testing of domain definition files and provides a simple way to get acquainted with the TMG parser.

The user creates a file name.tmg normally containing the domain definition with a sequence of TMG parser commands, then invokes the mesh generator with the command

tmg name After parsing the contents of the tmg file a prompt will appear (TMG> waiting for

more TMG parser commands, exit with either exit or quit.

An example of level-1 interaction is provided in the protesi.tmg file. Capabilities of the mesh generator accessible by level-1 interaction:

- Definition of general domains, including curved boundary pieces of circular shape or parametric cubic spline, as described in [1].

- Generation of a mesh which can be uniform or locally refined around specified nodes.

- Full interaction with the graphic interface.

Capabilities of the mesh generator not accessible by level-1 interaction:

- Graded mesh definition via density function.

- Stretched mesh.

- General boundary shapes given by parametric representation.

- Generated mesh interaction by the main program: the generated mesh can however be saved to a file and then accessed by a level-3 program.

1.1. The TMG parser.

Level-1 interaction is essentially achieved via TMG parser commands as described below.

1.2. Parser syntax.

The TMG parser interacts with the user mainly through an input stream consisting basically of commands. Each line of the input stream can be one of the following:

command line: Most of the actions and operations of the TMG mesh generator can be requested by means of a command line: each parser command corresponds to a particular mesh generator action. Typical actions are, for example, the definition of the domain, the mesh generation, postprocesses, information retrieval,... The precise syntax and a list of the available command are presented in §1.3.

assignment line: Consists of a line with the following syntax: $⟨varname⟩= ⟨expression⟩ where ⟨varname⟩ is either an alphanumeric string beginning with a letter (usual

rule for variables in programming languages), in which case a local variable is beeing referred, or an integer value, in which case a global parameter is beeing referred...

⟨expression⟩ is a list of numeric values, local or global variable names, binary operators, functions, following the usual programming languages rules...

comment line: Each line beginning with a ‘%’ is considered a comment, and skipped by the parser.

blank lines: Lines consisting of solely blank characters is skipped by the parser.

Whenever a new line is expected by the parser, and the input stream is the standard input (stdin) the “TMG⟩” prompt appears on the screen.

1.3. Parser commands.

A command line consists of a string identifying the command itself, followed (if needed) by one or more values or espressions, separated by a comma A complete list of the available commands is given below. A list of parameters of specified type is associated to each command. There are three parameter types: integer, real and string. integer and real parameters can consist actually of an expression following the syntactic rules specified in §1.2, an authomatic type conversion is performed, if needed, to convert the resulting type of the evaluated expression to the appropriate type. String parameters can be specified in three different ways: a stream of nonblank ASCII characters terminated by a space, tab, carriage return or other blank characters; a stream of characters enclosed in double quotation marks (which are not part of the string); finally a single hyphen (-) character is a shorthand for the problem name contained in the problem internal variable.

a. General purpose commands:

- initialize. This command can be invoked before any other TMG command as a replacement of the tmg init routine call. However, the use of the tmg init call should be preferred, since it allows for direct initialization of personalized code, such as the density function. The parser command initialize can be entered either by typing initialize in response to the “TMG⟩” prompt, or by including the subroutine call tmg executecom(TMGC INITIALIZE) in the C code before the TMG-parser invocation.

- setgparm. ...
- getgparm. ...

- version. Prints the actual TMG version at the terminal.

- include <string>. A list of TMG commands of frequent use can be inserted in a file having .tmg extension (for example ex.tmg) and invoked with the command “include filename”. As for any string parameter the filename can be replaced by the hyphen character “-” forcing the use of the problem internal string. A tmg file can also be invoked directly by the C code as explained in section 2.3.

- problem <string>. With this command the user can set the actual problem name. The final result of this command is to set the internal string problem to the specified string value. This internal value can be referenced with the hyphen character whenever a string parameter is expected by the parser. Note that the problem internal variable is also set (if empty) to the name of the first file included with the include command or the parsefile C call (see section 2.3).

- subname <string>. In this way the user can set the internal string variable subname (the default value is the string “1”). It is used in forming the name of the geo, gen and profile files by appending a hyphen followed by subname to the name given by the user.

- title <string>. Problem title definition, written at the beginning of the geo and gen files by the GINT interface commands. If the title string contains blank characters enclose it in double quotation marks.

- quit. Signals the end of the input command stream and returns control to the upper level of include files. The same effect is obtained when the end of file is detected. A return code of 1 is returned to the TMG parser caller if quit is encountered at the top level.

- exittmg. Exits all the nested include files, returning control to the program after the first call to the TMG parser. Also a return code of 0 (zero) is returned to the caller.

- system. This is a synonym of the exittmg command.

- spawn. Spawns a copy of the operating system, thus allowing the user to enter a list of operating system commands (e.g. VMS, Unix shell, DOS). The command to return to the TMG parser depends on the operating system; for VMS is

logout.

- print <string>. The specified string is echoed to the standard output (usually the terminal). Can be used in included files to output messages to the user. A particularly useful form of this command is “print -” causing the output of the problem internal variable.

- help. A short list of available parser command is output. The list presented is not up to date.

b. Mesh interaction commands:

- domain. This command begins the definition of a new domain. See section 1.4 for the description of the domain definition syntax. Due to the complexity of the domain definition for actual problems the defining sequence is usually written in an inclusion file to be parsed at the very beginning of the main program with a “parsefile(file)” call; this will also cause the problem internal variable to be initialized to the included file name.

- enddomain. Marks the end of the domain definition.

- settags. Defines the tag field of nodes and elements of the mesh in a sequential numbering starting from 0. This allows to identify a single element or node.

- testmesh. Applies simple consistency tests to the generated mesh. By now, only two tests are applied: each node flag is tested and a warning is printed if the node is neither internal nor border nor vertex; each element is tested for its area, a negative area means that the vertices of the element are listed clockwise instead of counterclockwise. For each negative element a warning is printed and the element is outlined (if graf is not zero).

- hsize <real>. Sets the reference global size of the mesh to be generated.

- hfunc <int>. Specifies the type of mesh to be generated. A value of 0 (zero) means uniform mesh (unless some subdomain have a multiplying factor different from one, see section 1.4, or some density point has been defined with the denspoint command). Any positive value forces the use of a user defined local size function. The resulting value from the user-supplied density function can be used in 4 different ways (see the description of the user defined density function §2.2.1): a. As a multiplying factor for the hsize internal variable times the density factor

due to density points (if present). This is the default behaviour. b. As a multiplying factor for hsize, ithout taking into account density points. c. As a multiplying factor with the density points, without taking into account

hsize. d. As an absolute value.

- mesh. Causes the generation of the mesh. This is done in tree phases. First a copy of the domain boundary is obtained (which can be plotted with the drawboundary command). Then this border is meshed in accordance to the specified values of hsize, hfunc and possibly the values of these two variables specified locally for each border piece. Finally the internal mesh is generated.

- readdatb <string>. A file containing the domain definition with the old datb syntax can be loaded with this command.

- datbwithh. Means that a datb file starts with the hsize value. This is the default setting.

- datbwithouth. Means that a datb file does not contain the hsize value.

- bordmesh. Causes only the first two phases of the mesh generation to be carried out, namely the border duplication and the border gridding.

- advfront. Only the third phase of the mesh generation is performed, that is the internal mesh construction (using the advfront technique).

- flipdiag. Performs the flipdiag regularization postprocess.

- pigra. Performs the pigra regularization postprocess.

- singleflip. Executes a single flipdiag operation on a couple of adjacent elements. If graf is not zero each element is selected with graphic input by positioning the cursor on an internal point.

- movenode. Allows the user to move manually a node of the generated mesh. A border node is restricted to be moved along the border only. A vertex node cannot be moved.

- domrefine. The domain is globally refined by subdividing each element in four smaller elements.

- subrefine <int>. A single subdomain is refined by subdividing each element in four new elements. Side effects on adjacent subdomains are taken into account. A subdomain is identified by its tag.

- locrefine. The user can define (with graphic input) a refinement region. Only the elements with nonempty intersection with this region are refined.

- noderefine. A refinement of node type is performed. The user is asked to select a node and a depth level. A depth level of zero means that no refinement has to be done, a value of one means that a single refinement has to be done, a value greater than one means that a number of successive refinements of node type have to be done around the same node.

- ballrefine. Same as above, but a ball type refinement is performed around the specified node. The “radius” extra argument that the user is asked to specify is usually “1”, this means that the ball radius is equal to the local mesh size.

- addrefine. Adds a single element to the refinement list. All the elements of this list are actually refined with the refine command.

- refine. Refines the elements in the refinement list.

- clearmesh. Discards the computed mesh.

- cleardomain. Discards the defined domain border.

- savemesh <string>. Saves the current mesh in the specified file. The default extension is .mesh.

- loadmesh <string>. Loads the mesh from the specified file.

- defcond <int>. Defines the default boundary condition for the subsequently defined border, when no boundary condition is specified. This command is also recognized at the domain definition level and piece definition level.

- defdirichlet. Sets the default value for the condition bits in the flag field of the piece structure to dirichlet.

- defneumann. Sets the default value for the condition bits in the flag field of the piece structure to neumann.

- denspoint <real> <real>. This command begins the definition of a new density point. The two real parameters are the coordinates of a point where a refined mesh is needed. A number of parameters can be set to describe the characteristics of the density function near the specified point as described in section 1.5. The definition of the density point must be terminated by the enddenspoint command. More than one density point can be defined by means of the repeated use of the denspoint command. Density points defined with this command are by default cumulative with a user-defined density function (if any).

- enddenspoint. Marks the end of a density point definition.

c. Graphic presentation commands:

- graf <int>. Sets the internal variable graf to the value specified. A value of zero means that the terminal is not a Tektronix graphic terminal.

- nodemark <int> <int> <int>. Defines the marker shapes to be used respectively for internal, border and vertex nodes. The default values are 1, 2 and 3.

- setscale <real> <real> <int> <int>. The user can manually set the scaling parameters used to transform real coordinates to Tektronix integer coordinates (range 0-4095 times 0-3100). The first two values are the x and y scaling factors, the last two (integer) specify the traslation to be applied. Anyway the scale factors are automatically computed by TMG after the domain definition in order to keep the whole domain on the screen with as large scale factors as possible.

- scalecompute The user can force the automatic computation of the scale factors by TMG. This computation is anyway carried out after each domain definition.

- getpos. The user can obtain the real coordinated of a screen position using graphic input.

- drawdomain. The border of the domain and each subdomain is plotted on the screen. The boundary nodes are marked accordingly with their flag.

- drawborder. The border of the meshed boundary is plotted.

- pandomain. The total domain shape is drawn according to the value of panelflag. panelflag = 0: the domain boundary is plotted; panelflag = 1: the internal part of the domain is filled using the actual panelpattern; panelflag = 2: the domain is panelled and the border is outlined.

- pansubdomain <int>. As above, but only the specified subdomain is drawn.

- panelflag <int>. Allows the user to specify a new value for the internal variable panelflag (see command pandomain). The default value is 2.

- panelpattern <int>. A new value for the internal variable panelpattern can be specified, the default value is 9. This is the value of the fill pattern used in graphic panels. See the Tektronix reference manual for a list of possible values.

- drawmesh. Plots the generated mesh.

- drawpiece <int>. Draw a single domain boundary piece identified by its tag. The tag value must be associated to the boundary piece with the tag command during the domain definition.

- gsegment <int>. Specifies the Tektronix graphic segment to be used in the next graphic output operation. Each time a new segment is defined the value of this variable is automatically incremented by one. The commands that use

Tektronix segments are: drawdomain, drawborder, pandomain, pansubdomain,

drawmesh. The initial value is 1.

d. GINT interface commands:

- writegeo <string>. Writes the actual mesh in the geo and gen files specified, readable by GINT.

- writeprofile <string>. Creates a .profile file using the GINT profile syntax containing the actual scaling factors. This allows the merging of graphics obtained by both TMG and GINT.

e. TMG debugging commands:

- echo <int>. If echo is set to 1 each subsequent command is echoed to the terminal. This is useful to detect a syntax error in a TMG include file.

- debug <int>. Sets the debug internal variable to the specified value. This variable has various debug effects on the mesh generator. For example a value of 32 forces the graphic display of each newly generated element.

f. Information display commands:

- show. Displays at the terminal the value of the following variable or expression.

- showstatus. Displays at the terminal the value of a number of internal variables.

- shownode. Displays at the terminal the coordinates, tag and flag of the selected mesh node.

- showelem. Displays at the terminal the flag and tag of the specified element as long as the tag of the three vertices.

- statistics. Displays statistics on the newly generated mesh (number of nodes and elements, etc).

1.4. Domain definition.

The domain command starts the definition of the domain shape. The user must be aware that no domain has been defined before, otherwise he should invoke the cleardomain command before starting the domain definition. After the domain command, the parser enters the domain definition level, while at this level, the parser recognizes only the two commands listed below. To exit from the domain definition level the user must enter the enddomain command.

Domain definition level:

- subdomain <real> <real>. Starts the definition of a single subdomain. The two parameters are the coordinates of a point of the subdomain border from which the definition will start. After this command, the parser enters the subdomain definition level, the list of commands recognized at this level is listed below.

- enddomain. Marks the end of the domain definition and exits the domain definition level.

Subdomain definition level: It is assumed that the domain to be defined by the user is subdivided in one or

more subdomains. The subdivision in subdomains depends essentially on the user wishes, and it is useful when materials with different properties are present, or when different grid sizes are needed. Note that a single subdomain need not be connected nor simply connected. The subdomain is defined by listing each piece of boundary in a counterclockwise order (the inner of the domain must lie on the left during the border definition). A subdomain definition is ended either by the execution of the endsubdomain command or (more simply) when a domain definition level command is encountered (which of course is executed at the domain definition level).

- tag <int>. Allows to identify the subdomain by means of an integer value.

- hmult <real>. Defines a multiplying factor for the mesh size valid for this subdomain. The actual reference size is hsize times hmult, see command hsize.

- hfunc <int>. Specifies the non-uniform mesh to be generated, if not present, or if the value is 0 (zero), the global hfunc value is considered for a uniform mesh plus, possibly, density points defined with denspoint. See hfunc command in the Mesh interaction commands subsection.

- piece <real> <real>. Starts the definition of a piece of border, the two real parameters are the coordinates of the ending point. After this command the parser enter the piece definition level, see below.

- newcomp <real> <real>. Begins the definition of a new connected component of the border of the same subdomain. The two real parameters are the starting point of the new border component.

Piece definition level: A piece of boundary is defined by a starting point, an ending point and a number

of parameters specifying the shape and the characteristics. The pieces must be specified sequentially in such a way that the ending point of a piece coincides with the starting point of the following one (in this way the starting point of a piece is understood by the context, and must not be specified). Besides, the order in which the pieces are to be listed must be such that the inner of the domain lies on the left of each piece. The starting point of a sequence of pieces is specified with the subdomain command or with the newcomp command, and each sequence of pieces must define a closed path. It is up to the user to make sure that no self-intersections are present in the defined domain boundaries.

- tag <int>. Can be used to label this piece with the specified integer. The default is -1.

- flag <int>. The flag field of the piece data structure is loaded with the value specified (default 0). This can be typically used to specify special properties of this piece of boundary.

- condition <int>. Specifies the boundary condition associated to the piece (default 0, or specified by defcond).

- defcond <int>. Besides specifying the boundary condition associated to the piece as the condition command, it also modifyies the default value.

- dirichlet. This command can be used to set the dirichlet bit in the flag field of the piece data structure. The default value is 0, or specified by the

defdirichlet or defneumann command.

- defdirichlet. Same as the dirichlet command, it also sets the default value for the subsequent pieces.

- neumann.This command can be used to set the neumann bit in the flag field of the piece data structure. The default value is 0, or specified by the defdirichlet

or defneumann command.

- defneumann. Same as the neumann command, it also sets the default value for the subsequent pieces.

- hmult <real>. Specifies a multiplying factor for the size of the grid, used during the border gridding. The actual reference size is hsize times hmult, see command hsize. The default value is 1.

- hfunc <int>. If present and different from 0, this value overrides the global hfunc value for the gridding of this piece of boundary.

- faced. Means that this piece is faced to a previously defined piece, in the sense that the starting point of the actual piece coincides with the ending point of the faced one and that the ending point of the actual piece coincides with the starting point of the faced one. For faced pieces of boundary the mesh is generated in a compatible manner. Note that the faced piece can belong to a different subdomain, to a different component of the same subdomain, or even to the same boundary component. All the characteristics of a faced pair of pieces are shared, and thus cannot be different, they are specified within the definition of the first one of the two pieces. Note that the faced command must be present only in the definition of the second of the two faced pieces.

- segment. The shape of the piece is a straight line joining the starting and ending points of the piece. This is the default piece shape.

- arc <real>. The piece has the shape of a circular arc having the specified radius. The parameter gives the radius of the circular arc; if positive, the concavity of the piece points towards the inner of the domain, if negative, viceversa.

- splinebegin. This piece is the first of a sequence of pieces that must be connected by a parametric spline. Note that the computation of a spline sequence needs the solution of a linear system which dimension depends linearly on the number of pieces in the spline, it is thus inefficient to define splines made of a large number of pieces.

- spline. Means that this piece belongs to the inner part of a spline definition sequence.

- splineend. Means that this piece ends a spline definition sequence. If the starting point of the spline sequence and the end point are the same (i.e. if the spline sequence is the whole boundary component), than a closed parametric spline is generated (continuity of the derivatives also at the starting point).

- type <type> <parnum> <p1> ...  <pn>. A user defined shape. <type> is

an integer greater than 0 specifying the user-defined shape; it is passed to the user-defined subroutines arcx and arcy. These routines can make use of the parameters specified by the <p1> through <pn> real arguments to compute the actual shape. <parnum> gives the number of parameters <p1>, ..., <pn>. The user should not used negative or zero values of <type>, corresponding to the segment, arc and spline shapes.

- drawprecision <num>. Specifies the precision with which the piece is displayed at the terminal: a single piece is drawn as a sequence of <num> segments. This value does not affect the precision for other kind of computations, but only the graphic presentation. The default value depends on the shape of the piece: for a segment is 1, for a circular arc is 20 and for a spline piece is 10.

1.5. Density point definition.

A number of density points can be defined to obtain a refined mesh near particular locations in the domain. This allows us to obtain simple non-uniform meshes without the necessity of writing the code for the density function definition. The command denspoint followed by the coordinates starts the definition of the new density point. A number of informations are stored for each density point, these include the value hmin giving the mesh size (relative to the global reference mesh size) near the point and the far and near values, which define the transition region (in terms of distance from the density point) where the local density function varies linearly from 1 to the value hmin. This value is then multiplied by the reference value hsize. If not all of the values for these parameters are supplied by the user, the missing ones are computed according to some “rules”: If two parameters are supplied, the remaining one is computed such that the density function in the transition region (in terms of the distance) is the restriction of a linear function having value 0 on the density point. If only the value far or near is supplied, then hmin is set to 0.05, and the remaining value is computed using the above rule. If only the value hmin is supplied, far is set to 4. Finally, if none of the values are supplied, we shall have far = 4, near = 0.2 and hmin = 0.05.

- varwidth. The actual values for far and near are obtained using hsize as multiplying factor. This is the default setting.

- fixwidth. The values far and near are exactly those given by the user.

- far <real>. Sets the value for far.

- near <real>. Sets the value for near.

- hmin <real>. Sets the value for hmin.

- enddenspoint. Ends the definition of the density point.

1.6. Parser expressions.

The TMG-parser is capable to read expressions following the usual syntax of programming languages. Exponentiation is not currently implemented. Recognized operators include the usual +, −, ∗, /. Parentheses can be used as needed, function references (sin, cos, tan, exp, atan2) and predefined constants (pi,

no, yes).

Variables can be referenced prefixing the variable name with a dollar sign. A dollar followed by an integer value refers to a global parameter (see command

setgparm) above.

The resulting type of the expression depends on the operands type and the operators, following the usual programming rules, an automatic type conversion is performed whenever needed.

2. Level-2 interaction

Level-2 interaction allows the introduction of simple user-defined routines (which we assume to be coded in C language) such as, typically, the density function describing the local mesh size, mesh stretching, curved boundary shapes.

To achieve this, it is necessary to call TMG routines (contained in the TMGLIB library) via a user-written main program. Only those routines that are really needed have actually to be inserted as C functions, the binding between these functions and the TMG core is provided by means of the initialization call tmg init and by the tmg set call, as described in the next sction.

2.1. The tmg init and tmg set commands.

Initialization of the mesh generator from a C program is usually obtained through the C subroutine tmg init. Alternatively it is called when parsing the line initialize in a tmg file. The calling syntax of tmg init is the same as for the command tmg set, with the difference that the former can be called only once on top of the program. The arguments on tmg init and tmg set are in variable number and consist of a list of keywords followed by keyword values (in a number that depend on the keyword itself). The list is NULL terminated. Symbolic names are associated to the keywords through the header file tmg.h.

Here is a list of the presently recognized keywords, for each keyword we indicate in parentheses the arguments that must be supplied (with a generic name).

- TMG GRAF (graf). ...

 - TMG DENSITY FUNCTION (h).
 - TMG USER CHOOSE (uchoose).
 - TMG CHOOSE FLAG (chooseflag).
 - TMG INTERPOSE ELEM INSERTED (inselem).
 - TMG INTERPOSE ELEM REMOVED (remelem).
 - TMG INTERPOSE ELEM POSTPROCESS (postpelem).
 - TMG GET NEW ELEMENT (getnewelem).
 - TMG GET NEW BELEMENT (getnewbelem).

- TMG STRETCHING (stretching).

- TMG ARCX (arcx).

- TMG ARCY (arcy).

- TMG INSERT FRONT (insert front).

 - TMG PPSFIXELEMS (ppsfixelems).

2.2. Syntax of user-defined functions.

2.2.1. Density function. tmg init binding: TMG DENSITY FUNCTION, funcname. Prototype:

       double funcname (double x, double y, int hfunc, int *flag);

x, y are the coordinates of the position where the density function has to be evaluated. The integer hfunc (> 0) corresponds to the value set with the hfunc parser command; it can be used to distinguish among a number of different density functions (using a C switch clause). The output value *flag can be modified to achieve special effects as follows:

- USER H RELATIVE: the result is multiplied with hsize and with the density point function, if specified via the denspoint parser command. This is the default value of *flag.

- USER H RELATIVE GH: the result is only multiplied with hsize.

- USER H RELATIVE DENS POINT: the result is only multiplied with the density point function.

- USER H ABSOLUTE: the result is taken as is (no multiplication).

2.2.2. Mesh stretching. tmg init binding: TMG STRETCHING, funcname. Prototype:

     void funcname (double x, double y, int stretching,
        double *xspt, double *yspt);

2.2.3. General curved domain boundaries. tmg init binding: TMG ARCX, arcx, TMG ARCY, arcy. Prototype:

     double arcx (double t, Fdescr *fundata);
     double arcy (double t, Fdescr *fundata);

2.3. Using the TMG parser from within a C program.

A C program can invoke the parser in many different ways:

• tmg parsefile((char *) <filename>); The parser is invoked and reads the

command from the specified file. <filename> is a string constant or a character array containing the name of the file. If the extension is not specified, a default of tmg is assumed. The return value is 1 if the parser finds the end of file or the quit command, 0 if the command exittmg or system is found.

• tmg parser((FILE *) <file>); Same as tmg parsefile, but now <file> points

to a FILE structure corresponding to an opened file. It is useful to invoke an interactive parser session with the user: tmg parser (stdin). The return value is 1 or 0 as for the tmg parsefile call.

• tmg parser(0); Invocation with a null file. No action is performed unless there are some commands in the internal parser stack. These are executed in the “last in first out” order.

• par pushcom (<command>); Places a command on top of the internal parser stack. The execution of this command is delayed untill the next invocation of

tmg parsefile, tmg parser, tmg executecom. <command> is an integer identi-

fying the command to be parsed, for an easier use the tmg.h include file contains a #define directive for each command, which defines a constant of the form TMGC <command> for each parser command related to the mesh generator (or graphics), while in tmgparser.h include file is included the definition of constants of the form PARC <command> for each basic parser command. For example the constant TMGC MESH corresponds to the parser command mesh, while PARC INCLUDE corresponds to the basic parser command include. If a command needs one ore more parameters, they must be placed on the stack before the command itself (in the reverse order), in case of an integer parameter the integer value can be pushed with a par pushcom(<parameter>), in case of a real or string parameter the address of the parameter must be pushed:

par pushcom(&<parameter>).
• tmg executecom(<command>); Corresponds to the pair: tmg pushcom(<command>)

followed by tmg parser(0). It is useful to execute a single parser command. Note that any of the previous parser invocations will activate the general level

of the parser, not lower levels such as the domain definition level. So, for example, it is not possible to define a new domain with a sequence of tmg executecom calls, instead all of the commands must be pushed on the stack (in the reverse order!) and finally executed with a call to (for example) tmg executecom(TMGC DOMAIN), and this is obviously not practical.

3. Level-3 interaction

Interaction with the generated mesh can be obtained by directly accessing the TMG data structures (level 3). It is assumed that C language is used for the userwritten modules. There esists essentially a unique external variable, to be declared as

       extern Tmg *tmg;

which is a pointer to a structure containing all the relevant mesh information. Detailed information on the TMG data structures can be directly obtained from the tmg.h header file. We shall just describe here how to achieve some typical data structure scanning.

3.1. Retrieval of some useful quantitative informarions.

tmg->node num: total number of generated nodes.

tmg->elem num: total number of generated elements.

...

3.2. Loop through the mesh nodes. A typical loop through the nodes of the generated mesh can be achieved by the following segment of code.

       Node *node;
       for (node = tmg->nodes; node != 0; node = node->next) {

actions to be taken for each node

          }

It should be noted that the nodes of the mesh are not divided into subdomains, since there can actually exist common nodes.

3.3. Loop through the mesh elements. Here is a typical segment of code

       Element *elem;
       Mesh *submesh;
       for (submesh = tmg->mesh; submesh != 0;
            submesh = submesh->next) {
          for (elem = submesh->mesh; elem != 0; elem = elem->next) {

actions to be taken for each element

             }
          }

The relevant informations contained in a Mesh data structure consist of the mentioned pointer to the element list for a subdomain and to a pointer to the boundary information.

3.4. Loop along the boundary nodes. The data structure for the mesh boundary is a bit complicated by the possibility of faced pieces of boundary (typically among different subdomains). In that case the list of boundary nodes is complete for one of the two facing subdomains (relatively to a faced piece), while containing just the two end points for the other facing subdomain. In the case of no facing pieces here is a typical segment of code

       Boundary *bordl;
       Front cons *comp, *bnode;
       for (bordl = tmg->mesh boundary; bordl != 0;

bordl = bordl->next) {
for (comp = bordl->border; comp != 0; comp = comp->cdr) {
for (bnode = comp->car; bnode->flag == ISNODECELL;
  bnode = bnode->cdr) {

actions to be taken for each boundary node

e.g. nextbnode = next (bnode);
}
}
}

The next function call returns the next node along the boundary (counterclockwise).

If faced pieces are present we can either skip the facing pieces or run through them (twice, once for each facing subdomain). We have to change the inner loop of the previous example as follows

................

4. gm to tmg conversion

4.1. General conversion note. As a consecuence of the change GM into TMG, all names of functions, global variables, constant symbols, previously containing the string gm have to be now modified suitably. Some function have a somewhat different name, trying to organize things better. As an example all low level graphic calls (previously named gm????) now have changed into tmg ll????. This has better agreement with the original name ll???? of the graphic STI interface routines.

Note that some routines are now part of the parser subpackage, which is now logically distinct from the main TMG code (although still included in the final TMG library for simplicity). As a consequence the name of such routines does not include the tmg prefix. The old command pushcom (for example) now is renamed

into par pushcom.

4.2. denspoint GM/TMG command. Il calcolo con DENSPOINT e’ ora cumulabile con altre funzioni densita’, non serve ”hfunc -1”.

4.3. GM/TMG user-defined density function. La funzione densità userdefined non ha piu’ il parametro gh. Essa fornira’ il fattore relativo (che verra’ in seguito moltiplicato per gh). E’ tuttavia possibile controllare l’effetto tramite i vaori del quarto argomento come spiegato nella §2.2.1.

Naturalmente ora la funzione densita’ va definita con tmg set o tmg init.

4.4. Changed global variables. Most of the global variables used by the mesh generator are now members of the tmg structure, available with the declaration

extern Tmg *tmg;

and may possibly have a different name. Here is a list of the old names followed by the corresponding new name.

gmesh tmg->mesh
workmeshl tmg->workmesh
mesh tmg->submesh
front tmg->front
bfront tmg->bfront
gborder tmg->mesh boundary
domain border tmg->boundary
border tmg->border
domain node tmg->domain nodes
mesh node tmg->nodes
mesh num tmg->mesh num
elem num tmg->elem num
node num tmg->node num
domain nodenum tmg->domain nodenum
split num tmg->split num
delink num tmg->delink num
warning num tmg->warning num
debug tmg->debug
choose calls tmg->choose calls
nearest calls tmg->nearest calls
into calls tmg->into callse
testtria calls tmg->testtria calls

front length tmg->front length
ini front length tmg->ini front length
max front length tmg->max front length
tot front length tmg->tot front length
count front length tmg->count front length
globalflags tmg->globalflags

4.5. Changed parser simbols. Some of the TMGC * simbols corresponding to parser commands (those that are of general parser use, and do not refer to the mesh generator, nor to graphics) are now part of the parser package (file tmgbparser.c) and are defined in the header file tmgparser.h. Here is a list of the old names followed by the new replaced name.

TMGC ERROR PARC ERROR
TMGC END PARC END
TMGC EOF PARC EOF
TMGC ECHO PARC ECHO
TMGC SPAWN PARC SPAWN
TMGC PRINT PARC PRINT
FLAG CASE INSENSITIVE (no change)
FLAG SEARCH TMG FLAG DONT SEARCH PAR (reversed meaning)

5. XVIEW graphics interface

The graphics interface used by TMG (contained in the xsti library referred through the tmgxsti.c file) is in fact a rough Tek41xx emulator, capable to provide some of the basic functions of Tektronix series 41xx, such as graphic segments.

5.1. Calling a Tek function.

Each of the emulated Tektronix commands can be called using the following convention: the name of the subroutine is the same as that of the STI library but with the initial ll converted into tmg ll. For example, to open segment 10 the calling sequence (in C) will be as follows:

  tmg llopsg (10).

This is the calling convention for use in programs that link the tmg library, and should be maintained also for use with graphic systems different from XVIEW. The STI routines can however be directly accessed in the xsti library, for systems using XVIEW (openwindows), by replacing the initial ll with xsti in the STI calls.

5.2. The 41xx window.

When the tmg llinit () call is executed (usually with the graf 1 parser command), a graphics window is created, associated to an icon showing a Tektronix terminal.

This window is divided in three parts.

- A panel containing a number of buttons and data input fields, to provide control of emulated tektronix local functions (described below).

- A text subwindow (visible only if the 41xx window is enlarged) placed on the right of the button panel. Comments related to the picture can be placed there by the user.

- A canvas occupying most of the window, to contain the picture. Two scrollbars allow to navigate within the physical graphic workspace (panning). Zoom is possible through the Zoom and Dzoom buttons.

5.3. Hardcopy of the graphics.

The content of the graphic segments can be saved in a tektronix format file using the Save button, which is currently available through the Props panel. This process is accomplished through a Page, so that graphic primitives not saved within a segment will be lost as a by-product.

In order to visualize the Props panel either press the Props button in the main panel or, for SUNVIEW, select the Props entry of the push-down menu associated to the 41xx window (click the rightmost mouse button on the title bar).

In the Props panel the user is given the opportunity to specify the name of the file that will contain the picture (default: hardcopy.tek). If missing, the default extention .tek is assumed.

The inverse operation consisting to load a tektronix format file into the graphics memory (Load button) is not yet implemented.

The tek file can be converted to PostScript using the tek2ps conversion utility, described in §6.

In the Props panel the following input fields are related to the hardcopy process:

- Save Zoom info. Requires the information about the current zoom level and the shape of the window to be saved. The resulting tek file then exactly reproduces what the user sees in the window. The default is not to save zoom information, in which case the tek file will always contain an overview of the picture.

- Save Text window. This option would save the text in the text subwindow as tektronix alpha text, but is not currently implemented.

- Outline window. Puts a SET-BORDER-VISIBILITY 1 in the tek file, causing the border of the viewport to be displayed. The tek2ps conversion utility does not currently support this command.

5.4. Bugs and malfunctions.

- Espansione automatica del canvas viewport quando si espande la finestra 41xx.

6. Tektronix to PostScript conversion

The tek2ps conversion utility (by M. Paolini and S. Tentoni) is available to translate a graphic file in Tektronix format to PostScript.

The command syntax is as follows: tek2ps [options] [filename] If no arguments are given, the user will be prompted to provide all the required

information: input and output file name, title of the picture, stand-alone flag.

filename is the name of the input file. The .tek extension is assumed if not given explicitly, and the name of the output file and the title are inherited from the input file name, if they are not given explicitly.

Option must be preceded by a dash following the usual unix convention and can be given in any order. Here is a list of the available options. -s Requires the creation of a stand-alone PostScript file, that is a directly printable

file. If this option is not present, tek2ps will create an encapsulated PostScript file, intended to be included within other documents (e.g. TeX files).

-p Requires the output PostScript file to be redirected to the standard output. This is useful for example to pipe the resulting file to other tools (line printer, ...). As an example this is the definition of an alias to convert and print a tek file:

alias tekprint 'tek2ps -ps \!* | lpr -h -P2 &'

-ttitle Specifies a title for the picture. -ofile Specifies an output file. The default extension is .ps.

-d Disables the tektronix dialog area. Characters in the tek file found while in alpha mode should be written in the so called dialog area of a tektronix terminal, which is superposed to the graphic screen, but logically independent. The dialog area is not supported by tek2ps, and those characters would not appear in the final picture. Disable the dialog area means that characters found in alpha mode (alpha strings) are treated as graphic strings and printed in the graphic window at the actual beam position.

7. Policy and installation on a Unix system

We describe the installation procedure on a Sun system with Solaris 2.3 (based on Unix System V, ANSI C compiler, and XView windowing system). The code also works with the old SunView windowing system (BSD Unix, non-ANSI C compiler) and on the intermediate Solaris 2.1.

7.1. The package.

The package is divided into 3 parts: a. Main TMG code. It is composed of a number of source files tmg*.c (excluding

tmgmain.c) which will compose the object library tmglib.a; some header files tmg*.h, all of which are included by the principal one tmg.h; a main program tmgmain.c, which is used to build a sample executable capable to interpret a simple tmg file; some graphical interfaces ltmg*.c (mutually exclusive): ltmgxsti.c to interface with the XSTI library (XView), ltmgsvsti.c to interface with the SVSTI library (SunView). A sample makefile is included for installation on an XView system. Some *.tmg files are included as examples.

b. Window interface. c. Utilities. (tek2ps).

7.2. Environment variables.

Define TMGHOME, XSTIHOME, SVSTIHOME.

8. Bugs and future developments

8.1. Future Developments.

- Distinguish between commands and integers at parser level.

- Enhanced error messages from the parser: print file name and line number.

- Allow flipdiag to correctly treat boundary triangles based on the condition flag (Dirichlet or Neumann).

- Introduce flags to pilot flipdiag operation: + Silent/Verbose + UseCondition + etc.

References

1. M. Paolini and C. Verdi, An automatic triangular mesh generator for planar domains, Riv. Inform. 20 (1990), 251–267.