Pointwise Glyph Reference Manual

PointwiseGlyph ReferenceManual

Copyright © 2012 Pointwise, Inc.

All rights reserved.

Pointwise, Inc. reserves the right to make changes in specifications and other information contained in this document without prior notice.

ALTHOUGH DUE CARE HAS BEEN TAKEN TO PRESENT ACCURATE INFORMATION, POINTWISE, INC. DISCLAIMS ALL WARRANTIES WITH RESPECT TO THE CONTENTS OF THIS DOCUMENT (INLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE), EITHER EXPRESSED OR IMPLIED. POINTWISE, INC. SHALL NOT BE LIABLE FOR DAMAGES RESULTING FROM ANY ERROR CONTAINED HEREIN, INCLUDING, BUT NOT LIMITED TO, FOR ANY SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF, OR IN CONNECTION WITH, THE USE OF THIS DOCUMENT.

Pointwise, Inc.213 S. Jennings Ave.Fort Worth, Texas 76104-1107, USA

Phone: (817) 377-2807Toll free: (800) 4PTWISEFax: (817) 377-2799

Email: [email protected]: http://www.pointwise.com

Notice: The terms of the agreement under which you are acquiring the right to use the software include the “Right to Use License” attached hereto or accompanying the software. Your purchase, license, receipt or use of the software constitutes your acceptance of all the “Right to Use License.”

Pointwise, Gridgen, and Get the Point are registered trademarks and GridgenGlyph and PointwiseGlyph are trademarks of Pointwise, Inc.

Pointwise® uses the Qt® toolkit from Qt Software, a subsidiary of Nokia Corporation. Nokia, the Nokia logo, Qt®, and the Qt logo are trademarks of Nokia Corporation and/or its subsidiaries in Finland and other countries. FLEXnet is a registered trademark of Acresso Software in the United States and/or other countries. Pointwise® uses HDF5 from the HDF Group. Pointwise® uses Thread Building Blocks (TBB) from Intel Corp., licensed under the Gnu Public License V2 with the runtime exception. Intel® is a registered trademark of Intel Corporation in the United States, other countries, or both. Pointwise® uses the TetMesh-GHS3D tetrahedral mesher, Copyright © DISTENE S.A.S./INRIA.

FIELDVIEW and FVX are trademarks of Intelligent Light. FIELDVIEW Unstructured format Copyright © 1996-2009 Intelligent Light. Used by Permission. FIELDVIEW Unstructured format is intended for the exclusive use of the licensers of FIELDVIEW from Intelligent Light. PATRAN is a registered trademark of The MSC.Software Corporation. NASTRAN is a registered trademark of NASA. ANSYS FLUENT is a trademark of ANSYS. Star-CD is a trademark of CD-adapco. ANSYS CFX is a registered trademark of ANSYS. OPENFOAM® is a registered trademark of OpenCFD Limited.

OpenGL® and the oval logo are trademarks or registered trademarks of Silicon Graphics, Inc. in the United States and/or other countries worldwide. LINUX is a trademark of Linux Torvalds. REDHAT is a registered trademark of Red Hat,Inc. Microsoft and Windows are registered trademarks of Microsoft Corp. UNIX and XWindow System are regis-tered trademarks in the U.S. and other countries, licensed exclusively through the X/Open Company Limited. Mac and Mac OS are registered trademarks of Apple Computer, Inc. All other registered and unregistered trademarks are properties of their respective owner.

1. DEFINITIONS.

(a) “Licensed Software” means any computer

program(s) supplied by Pointwise, Inc. (PWI) to

Licensee under a valid Purchase Order or Con-

tract, whether in object code, reconfigurable

binary, or any other form; video media and

training aids; and any backup or other copies,

updates, derivative works, modifications,

enhancements, and extensions thereof.

(b) “Documentation” means user manuals,

documentation binders, release notes, installa-

tion notes, written utility programs and other

written or graphic materials related to the

Licensed Software and all copies thereof.

(c) “Licensed Product(s)” means the Licensed

Software and Documentation.

(d) “Maintenance Period” means the first cal-

endar year of a perpetual license or 12 months

for an annual license.

2. LICENSE.

PWI grants to Licensee a non-exclusive, non-

transferable license to use the Licensed Prod-

ucts in accordance with the terms and condi-

tions set forth herein. As long as this License is

in effect, Licensee may transfer its use of the

Licensed Products to a replacement computer

system on a temporary or permanent basis,

provided that Licensee gives PWI written

notice of such transfer.

3. TERM and FEES.

The Term of the Right to Use License is annual

or perpetual, as set forth in the Purchase

Order or Contract, provided that the License

has not been terminated as set forth in Sec-

tion 10.

All applicable fees are payable to PWI within

thirty (30) days from Invoice Date. Failure to

pay such fees in a timely manner is a material

breach of this License. Licensee agrees to pay

any legal or collection fees incurred by PWI in

collecting any amounts that may be delin-

quent.

4. COPIES and MODIFICATIONS.

Licensee may copy the Licensed Products in

whole or in part, in written or machine read-

able form for use in understanding the

Licensed Software and for archive or backup

purposes. Licensee shall reproduce and

include PWI’s trade secret or copyright notices

on and in any copies, in any form. Licensee

shall not reverse assemble, reverse compile or

otherwise reverse engineer the Licensed Soft-

ware in whole or in part.

The License includes the right to reproduce

the Licensed Software’s documentation exclu-

sively for the use of Licensee and its employ-

ees only. All other reproduction and

distribution is strictly prohibited.

5. OWNERSHIP.

All Licensed Products and the information they

contain, any updates and all copies of them

are PWI’s or PWI’s licensors’ property, and title

to them remains in PWI or such licensors. All

applicable rights in patents, copyrights or

trade secrets in the Licensed Products are and

will remain in PWI and PWI’s licensors. No title

to or ownership of the Licensed Software or

the information they contain is transferred to

Licensee. Licensee agrees that any terms and

conditions imposed by PWI’s licensor and

communicated by PWI to Licensee by PWI,

shall apply to the Licensed Products.

6. CONFIDENTIALITY.

(a) Licensee will take all reasonable precau-

tions to maintain the confidentiality of the

Licensed Products, and agrees to take all rea-

sonable and necessary steps to protect the

patents, trademarks, copyrights, trade secrets

and any other forms of intellectual or indus-

trial property of PWI in the Licensed Products.

(b) Licensee will not provide the Licensed

Products to any person, other than employees

of Licensee, without PWI’s prior written con-

sent, except during the period any such per-

son is on Licensee’s premises with Licensee’s

permission for purposes specifically related to

Licensee’s use of the Licensed Products.

7. COPYRIGHT AND PATENT INDEMNITY.

PWI assures Licensee that, to the best of PWI’s

knowledge, the Licensed Products do not

infringe any patent, copyright, trademark or

trade secret. In the event any legal proceed-

ings are brought against Licensee claiming an

infringement of a patent, copyright, trade-

mark or trade secret based on Licensee’s use

of the Licensed Products, PWI agrees to

defend at PWI’s own expense any such legal

proceeding relating to such claim or claims

and to hold Licensee harmless from any dam-

age incurred or awarded as the result of set-

tlement or judgment against Licensee,

provided Licensee gives PWI prompt written

notice within fifteen (15) days of any such

claim or the institution of any such claims

against Licensee, and further, Licensee coop-

erates completely with PWI in providing all

necessary authority, information, and reason-

able assistance to enable PWI, at PWI’s option,

to settle or defend such claims.

8. U.S. EXPORT COMPLIANCE AND INDEM-

NITY

Licensee agrees to comply fully with all U.S.

export laws and regulations concerning the

purchase and sale of Licensed Software. In

particular, Licensee agrees that any Licensed

Software purchased from PWI shall not be

exported, re-exported, transferred, used, sold,

resold, delivered, diverted, or retransferred,

directly or indirectly, contrary to United States

government export control laws, regulations,

policies, and executive orders.

Without limiting the foregoing, any PWI

Licensed Software is prohibited for export, re-

export, or transfer to embargoed countries of

Cuba, Iran, North Korea, Sudan, and Syria,

as well as to persons, organizations, entities,

or end-users listed on U.S. government denial

lists published by the U.S. Departments of

Commerce, Treasury, or State. Additionally,

absent an authorization from the U.S. govern-

ment or as permitted under the Export

Administration Regulations, the Licensed Soft-

ware is prohibited for export, re-export, or

transfer to any person or entity which will use

it for end-uses proscribed by U.S. export con-

trol regulations, including certain chemical

and biological weapons, missiles, rocket sys-

tems and unmanned aerial vehicles, nuclear

activities, maritime nuclear propulsion, and

terrorism-related activities.

Licensee also agrees to indemnify PWI for any

costs, including but not limited to penalties,

damages, claims, demands, losses, or attor-

ney’s fees and costs, that PWI may incur as a

RIGHT TO USE LICENSE

result of any potential or actual violation of

this provision by Licensee.

9. LIMITATION OF WARRANTY AND LIABILITY.

PWI warrants that the Licensed Products will

perform substantially in accordance with all

written specifications furnished to Licensee by

PWI if properly used. TO THE MAXIMUM

EXTENT PERMITTED BY APPLICABLE LAW, PWI

DISCLAIMS ALL OTHER WARRANTIES, EITHER

EXPRESS OR IMPLIED, INCLUDING, BUT NOT

LIMITED TO, IMPLIED WARRANTIES OF MER-

CHANTABILITY AND FITNESS FOR A PARTICU-

LAR PURPOSE, WITH REGARD TO THE

LICENSED PRODUCTS. TO THE MAXIMUM

EXTENT PERMITTED BY APPLICABLE LAW, IN

NO EVENT SHALL PWI BE LIABLE TO LICENSEE

OR ANY PARTY FOR ANY SPECIAL, INCIDEN-

TAL, INDIRECT, OR CONSEQUENTIAL DAM-

AGES WHATSOEVER (INCLUDING, WITHOUT

LIMITATION, DAMAGES FOR LOSS OF BUSI-

NESS INFORMATION, OR ANY OTHER PECUNI-

ARY LOSS) ARISING OUT OF THE USE OF OR

INABILITY TO USE THE LICENSED PRODUCTS

EVEN IF PWI HAS BEEN ADVISED OF THE POS-

SIBILITY OF SUCH DAMAGES AND REGARD-

LESS OF THE FAULT OR NEGLIGENCE OF PWI.

PWI’s liability to Licensee for damages shall

not exceed the amount of the license fee paid

by Licensee to PWI. PWI will hold Distene

harmless for and against any claims arising out

of or resulting from the use of the Licensed

Software with TetMesh-GHS3D as an included

option.

10. MAINTENANCE AND SUPPORT.

(a) PWI will be responsible for providing cor-

rections for programming errors and periodic

software updates only during the Mainte-

nance Period and during any period when the

Licensee is covered by a Maintenance Agree-

ment from PWI or an authorized representa-

tive of PWI. The specific policy for software

updates and enhancement varies on a per

product basis. PWI warrants that during the

term of this License it will use reasonable

efforts to remedy defects in the unaltered

Licensed Software made known to it by Lic-

ensee. PWI does not warrant that the Licensed

Products will meet all requirements of Lic-

ensee, or that the operation of the Licensed

Software will be uninterrupted or error free,

or that all software defects will be corrected.

(b) During the Maintenance Period, PWI

agrees to telephone hot-line support available

to Licensee. These services may be provided by

PWI or a designated third party.

11. TERMINATION.

Licensee may terminate this License upon

thirty (30) days written notice to PWI. PWI may

terminate this License for any material breach

by Licensee of the terms and conditions con-

tained herein upon thirty (30) days written

notice to Licensee. Licensee will have thirty

(30) days from the date of such notice to cure

the breach, and if the breach is cured to the

satisfaction of PWI, this License will remain in

full force and effect.

Upon termination, Licensee shall promptly: (i)

discontinue use of the Licensed Products; (ii)

remove the Licensed Products from any soft-

ware in Licensee’s possession or control that

incorporates or uses the Licensed Products in

whole or in part; (iii) erase or destroy any of

the Licensed Products contained in the com-

puter memory or data storage apparatus

under the control of Licensee. Licensee’s obli-

gations under Section 6 shall survive any

termination of this License.

12. GENERAL TERMS.

The entire agreement between the parties is

contained herein and in a valid Purchase Order

or Contract, which supersede all proposals,

oral or written, and all other communications

between the parties relating to this Agree-

ment and it may be executed in any number

of counterparts, each of which shall constitute

an original, and all of which taken together

shall constitute one and the same Agreement.

This Agreement is not assignable by Licensee

without prior written permission from PWI.

The section headings and subheadings herein

are for convenience only and shall not affect

the interpretation or construction of this

Agreement. PWI shall not be liable for any fail-

ure or delay in performance due in whole or in

part to any cause beyond PWI’s control.

This Agreement and all transactions under it

shall be governed by the laws of the State of

Texas. All claims arising under or related to

this Right to Use License, Purchase Order or

Contract shall be settled finally and exclusively

by arbitration in accordance with the Com-

mercial Arbitration Rules of the American

Arbitration Association (AAA).

Arbitration shall take place in Dallas, Texas and be administered by the AAA’s Dallas, Texas office.

i

Table of Contents Glyph Reference Manual

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.21.2 Learning Glyph2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.21.3 Glyph2 Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.31.4 Windows Informational Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.3

2. Scripting Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.22.2 Tcl Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2

Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2 Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2 Command Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2 Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.3 Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.3 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.6 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.6 Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.7 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.7 Filenames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.8

2.3 Tk Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.9 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.9 Initialize Tk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.9 Create a Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.9 Geometry Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.11

ii

Tk Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.112.4 Scripting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15

Glyph2 Is Object-Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15 Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.17 Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.17 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.18

3. Journal Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2

Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Undo Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Undo and Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Create and Modify Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3

4. Glyph1 to Glyph2 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.24.2 Programming Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.24.3 Direct Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2

Initializing a script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Setting a CAE Solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Entity Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Running a Solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Grid Extrusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7

5. Glyph2 Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.15.1 Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.25.2 Navigating the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3

I. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .I.I

II. Glyph2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II.III.I BC Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II.IIII.II Deleting a List Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II.IIII.III Setting the Script Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II.IIII.IV Timing a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II.IIII.V Transforming Database and Grid Simultaneously . . . . . . . . . . . . . . . . . . . . . . . . II.III

iii

II.VI Identifying Connectors for Domain Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . .II.IIIII.VII Converting Grid Entities into Database Entities . . . . . . . . . . . . . . . . . . . . . . . . .II.IIIII.VIII Reversing an Edge’s Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II.IVII.IX Calculating the Number of Segment Control Points . . . . . . . . . . . . . . . . . . . . . II.IVII.X Interactively Selecting Structured Domains from Display . . . . . . . . . . . . . . . . II.IVII.XI Export CAE Data With User Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . II.V

III. Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III.1

iv

1.1

Chapter 1

Introduction

1.2 Pointwise Glyph Reference Manual

Tip

1 .1 Overv iew

Pointwise’s scripting language, Glyph2, provides a text-based, procedural, object-oriented interface to Pointwise’s features. Glyph2 is based on the widely used, open source scripting language Tcl.

Some reasons you might wish use a Glyph2 script include:

1. Start Pointwise and automatically import the Project file for the grid on which you are currently working.

2. Encapsulate repetitive tasks.

3. Run Pointwise in batch mode.

4. Develop specialized meshing applications.

There are three means by which you can have Pointwise execute a Glyph2 script.

1. Put the name of your Glyph2 script on the Pointwise command line. Pointwise will execute this script at startup.

2. Run Pointwise in batch mode by:

• typing $pointwise_home_path/win32 (or win64)/bin/tclsh MyScript.glf at the command line in a DOS prompt on Windows platforms.

• typing $pointwise_home_path/pointwise -b MyScript.glf at the command line of a terminal window on Linux platforms.

• typing $pointwise_home_path/macosx/Pointwise.app/Contents/MacOS/tclsh MyScript.glf at the command line of a terminal window on MacOSX platforms.

where pointwise_home_path refers to the Pointwise installation directory

3. Use the Execute command from the Script menu.

Pointwise reads a Glyph2 script and executes its commands one at a time until either the end of the file is reached, an error is encountered, or until it encounters the pw::Application exit, abort, or exit commands.

Due to the differences between Glyph1 and Glyph2, Pointwise currently only executes Glyph2 scripts.

1.2 Lear n ing Glyph2

To get started with writing Glyph2 scripts, you first need to understand the Glyph scripting language. Within this manual, you will find discussions on the topics below.

• Glyph2 and Tcl syntax and scripting conventions

Try using journal files to create scripts for small repetitive tasks or as an aid when learning the Glyph2 commands associated with an operation. Scripts to generate large or complicated meshes should always be constructed by hand to ensure that the script is being written efficiently and with the necessary control structures.

1.3

Tip

• Journal files and their characteristics

• Transitioning from programming in Glyph2 to Glyph2

• Navigating and using the Glyph2 manual pages to construct scripts

Prior to creating your first Glyph2 script or journal file, it is recommended that you read through the chapters in this manual so that you learn the most effective methods to program for Pointwise.

Additionally, many example scripts are available for use online at the Pointwise Glyph Script Exchange (http://www.pointwise.com/glyph/). We encourage you to use these scripts for your own work and as learning tools. Feel free to modify and experiment with these scripts as you wish.

1.3 Glyph2 Command Reference

Glyph2 manual pages which describe each command, its usage, options, and restrictions, are available in HTML form at:

http://www.pointwise.com/glyph2/

Navigation of these documents and their conventions is described in detail in Section 5.2.

1.4 Windows Informat ional Regist ry Keys

A set of informational registry keys are defined during installation on Windows platforms. These registry keys can be useful when attempting to execute Pointwise, tclsh, or wish from an external script or program:

• HKLM/Software/Pointwise/CurrentVersion = {version-string}

• HKLM/Software/Pointwise/{version}/GUI = {full-path-to-pointwise.exe}

• HKLM/Software/Pointwise/{version}/tclsh = {full-path-to-tclsh.exe}

• HKLM/Software/Pointwise/{version}/wish = {full-path-to-wish.exe}

When constructing a Glyph2 script, make use of the indices provided in the Glyph2 HTML manual pages. They can be found in the About section and make finding commands easy and quick.


2.1

Chapter 2

Scripting Basics


Tip

2 .1 Overv iew

The Pointwise scripting language, Glyph2, is based on Tcl 8.5 (Ref. 4) with Pointwise-specific commands added to it. Tcl is a general purpose scripting language. It is an interpreted language and is therefore text based.

This primer will provide a brief explanation of the fundamentals of Glyph2/Tcl programming. There are a number of excellent resources for learning Tcl programming in depth. A few of these are listed in Appendix I. Finally, conventions used in Pointwise scripting are covered.

2.2 Tc l Syntax

2.2 .1 Commands

A Glyph2 script is comprised of a series of commands. These commands may be functions built in to Tcl, Pointwise-specific functions, or functions defined by the user elsewhere in the script. Each line in Tcl begins with a command which is followed by zero or more arguments separated by spaces. Commands are terminated by the end-of-line. To have a command span several lines, you must use \ (the backslash character) as a continuation indicator.

set dbs \

[pw::Application getAll]

A line may also be terminated with the ; (semicolon). This lets you put multiple commands on a single line.

set var_a foo; set var_b bar

2.2 .2 Var iables

Values can be assigned to variables for substitution in subsequent commands. It is not necessary to declare Tcl variables before using them. Variable names are case sensitive. A variable is assigned a value with the set command. The first argument is the name of the variable, and the second argument is its value. The value of a variable is obtained by prepending $ to the name.

set foo 10

set bar $foo

This stores the value 10 in both the foo and bar variables.

2.2 .3 Command Subst i tut ion

The value of an expression can be substituted into a command with the use of square brackets, []. The following example calls the expr command to calculate the square root of a value:

set b 81

set root [expr {sqrt($b)}]

Using the puts command, you can print the intermediate values of a variable while debugging. For example:

puts "Value of variable \ var_1: $var_1"

2.3

Tip

This assigns the value of 9 to the variable root. It is important to note the use of the expr function. Tcl does not support math functions directly. All math operations are handled by functions such as expr. The use of braces, {}, is explained in the next section.

Expressions can be nested. In such a case, the most deeply nested commands are run first. Commands at the same nesting level are evaluated from left to right.

2.2 .4 Grouping

As mentioned above, spaces are used to separate arguments to a command. Multiple words are grouped into a single argument with double quotes or braces. Double quotes allow variable and command substitution; braces do not. Braces are typically used when no substitutions are desired or to delay substitution such as in conditional statements and loops.

Braces can also be used to delimit odd variable names. If a variable name contains characters other than letters, digits, or the underscore, braces must be used to delimit the name.

set {my var} 5

set {a#b} ${my var}

Braces and double quotes include everything between them, including semicolons and newlines. Braces inside of double quotes do not prevent substitution - they are treated as regular characters. A backslash \ can be used before a double quote or brace to use it as a regular character.

set a "Use \" to quote"

set b {The \} is a right brace}

2.2 .5 Comments

A comment is indicated by specifying the # (pound) character at the start of a line. The comment is continued until the end of the line and can be carried to the next line with the use of the \ (backslash) character. Semicolons do not terminate comments. To start a comment in the middle of a line, terminate the previous command with a semicolon.

set ds 0.5 ; # Set the grid spacing

2.2 .6 Control Structures

2.2 .6 .1 I f then e l se

The syntax is

if expression1 ?then? body1 elseif expression2 ?then? body2 elseif .... ?else? ?bodyN?

The then and else words are optional. If none of the expressions evaluates to true then bodyN is executed. There may be any number of elseif clauses, including zero. BodyN may also be omitted as long as else is omitted too.

Variables can be defined as strings that can be easily manipulated by the stringcommand.

More details can be found in

Example II.I in our Glyph2 Examples Appendix.


Tip

Typically, braces are used around the command bodies and conditionals.

if {$sp == 0} {

set spacing 0.5

} elseif {$sp < 0} {

set spacing 1.0

} else {

set spacing $sp

}

Multiple conditionals can be chained together with the elseif keyword as illustrated above.

2.2 .6 .2 Swi tch

The syntax is

switch flags value pattern1 body1 pattern2 body2 …

When value matches a pattern, the corresponding command body is executed. Different values for flags control how the value is matched:

-exact Matches the value exactly (default).

-glob Uses glob-style pattern matching (* and ?).

-regexp

Uses regular expression pattern matching.--

No flags or end of flags. Needed when value can start with -.

Any number of pattern-body pairs can be supplied. If multiple patterns match, the first matching pattern is used. If the last pattern is default, then the associated command body is executed if none of the preceding patterns match. If a command body is composed of just a dash (-), then execution falls through to the next command body.

switch -glob -- $filename {

*.igs -

*.iges { set format IGES }

*.stl { set format STL }

default { set format Gridgen }

}

This associates any filename that ends in '.igs' or '.iges' with the IGES format, any filename ending in '.stl' with the STL format, and any other filename with the Gridgen format.

The switch command raises an error if any flag other than -- is used for a value that could begin with the dash (-) character. In practice, it is always a good idea to use the -- flag in addition to any other switch flag you use.

2.5

Tip

2.2 .6 .3 Whi l e

The syntax is

while expr body

The command repeatedly tests the Boolean expression and executes the command body if the expression evaluates to TRUE. Since the expr is repeatedly evaluated, it is important to place it in braces to defer substitution until the proper time. Otherwise, the expr will be evaluated only initially, resulting in a possible endless loop.

set ds $spacing

while {$ds > 0.5} {

set ds [expr {0.5 * $ds}]

}

2.2 .6 .4 Foreach

The syntax is

foreach var values body

This command loops over body once for each value in the list of values, with var taking on successive values in the list. It is recommended that the list command be used to define the list of values (double quotes can be used, but variables with spaces in the value will cause unexpected results).

foreach db [list $db_wing $db_fuselage $db_tail] {

$db setEnabled true

}

2.2 .6 .5 For

The syntax is

for start test next body

The start, next, and body arguments are commands. The test argument is an expression. The start expression is evaluated only once, before body is evaluated.. While the test expression evaluates to TRUE, then the bodycommands are executed followed by the next command. This is repeated until the test expression evaluates to FALSE.

set value 0

for {set j 0} {$j < 10} {incr j} {

set value [expr {$value + $j}]

}

(The incr command above increments the named variable, in this case j, by one. An optional second argument to incr would specify an alternate incremental value.)

The foreach command can operate on more than one loop variable. This allows you to write more compact Tcl code. For example:

foreach {var1 var2} {a 2 b 5 c 7} { puts "$var1: $val2"}a: 2b: 5c: 7


Tip

2.2 .6 .6 Break and Cont inue

Loop execution can be immediately exited with the break command. The continue command skips the remainder of the loop body and begins with the next iteration.

2.2 .7 Error Handl ing

Occasionally, an error will occur in a function such as when invalid values or the incorrect number of arguments are used. If uncaught, the error will cause the termination of the script execution. The catch command is used to trap and handle errors. Its syntax is

catch script ?resultVarNam? ?optionsVarName?

The script argument is a body of commands to be executed. If the commands return an error, catch returns a non-zero integer value. If the resultVarName argument is present, it names a variable which is set to the error message. If the commands execute successfully, catch returns a zero value and the resultVarName argument, if present, is set to the return value of the commands. A typical use is as follows:

if {[catch {command arg1 …} result]} {

puts "error: $result"

return

} else {

# no error, continue on with execution, result

# contains return value

}

An error condition is raised in a function with the error function. The syntax is

error ?message? ?info? ?code?

The message argument is a string that would be stored in the result variable of the catch command. The remaining arguments are optional and are beyond the scope of this primer.

2.2 .8 Procedures

Tcl functions can be defined within a script. The syntax for this is

proc name args body

This creates a new procedure, called name, replacing any previous command or procedure called name (so caution is advised). The name is case sensitive. The second argument, args, defines the formal parameter list. When the function is called, the arguments are assigned to the parameters defined by args and the contents of body are executed. The return command is used to return a value from the procedure.

proc xVal { pt } {

set x [lindex $pt 0]

It is always a good idea to write small procedures into your script for detecting and reporting errors. Make sure you define informative error message templates in a procedure so that you will receive useful feedback once an error occurs.

2.7

Tip

return $x

}

set ptA [list 1.2 3.4 5.6]

set x [xVal $ptA]

In this example, xVal is expected to be called with one argument, a list of values representing the X-, Y-, and Z-coordinates of a point. It uses the lindex function to extract the first element of the list (Tcl starts numbering list elements at 0) and returns the value. The example results in the variable x having the value of 1.2.

Procedures have a nested scope, one level above the global script. In the above example, the variable x inside of xVal is local to xVal and is separate from the variable x that is used outside of the procedure. To make a variable visible outside of a procedure, use the global command. The syntax is

global varname ?varname …?

This declares a global variable with the name varname for use in the current scope. You must use the global command in each scope in which you wish to access the variable except in the outermost scope. The global command has no effect outside the body of a procedure.

2.2 .9 Arrays

An array is a special type of variable that can be used to build complex data structures. Tcl arrays are associative arrays, using string-valued indices to access values. Since the index is a string, it can be any value: a number, a word, a phrase, or any combination. The index of an array is delimited by parentheses. The parentheses are not a grouping mechanism, so care should be exercised when using indices with spaces (or avoid them altogether). The syntax for defining an array element is

set arr(index) value

Once a variable has been defined as an array, it cannot be used as a regular (non-array) variable. The following will raise an error:

set myArray(1) 6.2

set myArray 5.3

The index of an array can be defined by a variable:

foreach part [list wing body tail] {

puts "$part: [$db($part) getName]"

}

2.2 .10 L is ts

Tcl lists are sequences of values. A list can be built several ways:

set list1 [list a b 1.2 foo]

set list2 "a b 1.2 foo"

Deleting elements from a list is not supported directly by Tcl. However, this can be achieved by using the lreplace command.


Example II.II in our Glyph2 Examples Appendix.


Tip

set list3 {a b 1.2 foo}

set list4 {a b {1.2 3.4 5.6} {foo bar}}

Note that the last example has lists within the list. Using the list command is the preferred method since it is slightly more efficient.

Elements of a list are accessed with the lindex command. The length of a list is determined with the llength command:

set myList [list a b c d e]

# Get the value 'c'

set el [lindex $myList 2]

# Get the length of the list (length is 5)

set len [llength $myList]

List indices are zero-based. Thus, the third element has an index of 2.

2.2 .11 F i lenames

The file naming conventions on UNIX and Windows platforms are different. Tcl provides functions to handle file naming conventions in a cross-platform manner (as well as file operations). The file command has several options for operating on file names and paths:

file dirname name

Returns the parent directory of path name.

file exists name

Returns 1 if name exists, 0 otherwise.

file extension name

Returns the extension of file name, including the dot.

file join path path …

Joins pathname components into a new pathname using the platform specific path separator.

file nativename name

Returns the platform-native version of name.

file readable name

Returns 1 if name has read permissions, 0 otherwise.

file rootname name

Returns all but the extension of name (includes directory if provided).

file tail name

Returns the last pathname component of name.

file writable name

Returns 1 if name has write permission, 0 otherwise.

The file command has other options as well. See Appendix I for more information.

Since a Tcl list can contain sublists, you can use the list to implement a collection of key/value pairs:proc listAppend {list key value} { lappend list [list $key $value] return $list}

2.9

Tip

2 .3 Tk Syntax

2.3 .1 Overview

Tk is Tcl's graphical toolkit for creating graphical user interfaces based on Tk 8.5 (Ref. 4). It is a set of Tcl commands for creating and manipulating widgets. A widget is a window in the interface with a particular appearance and behavior. Many different types of widgets are available including buttons, sliders, text input, menus, and a general canvas.

Since Tk was originally developed for the X window system, Tk widgets, like X widgets, are stored in a hierarchy. Typically, there is a parent window with several child windows. Each of these child windows may have additional child widgets in turn. This hierarchy forms the basis for identifying widgets as well as arranging them graphically on the screen. Adding a widget to the hierarchy consists of two steps: creation and placement. Each widget type has a specific creation routine. Geometry managers control the size and location of widgets relative to their parent widget.

Tk programming differs from straight Tcl programming in that Tk is event driven while Tcl is essentially serial in execution. A Tk program typically begins with the creation of the widgets and definition of routines to be called in response to specific events and then enters into an event loop awaiting user interaction.

The Pointwise distribution includes a standard interpreter, called wish, for running or testing Tk scripts.

2.3 .2 In i t ia l ize Tk

In order to initialize Tk within a Glyph script, use the following commands:

package require PWI_Glyph

pw::Script loadTk

This also works if a script is executed using wish.

An alternative is to call:

package require Tk

Initializing Tk causes Pointwise to expose the Tk commands to the script. If a Tk command is called prior to initialization, an error will be raised.

When Pointwise encounters the end of a script, script execution is terminated and control is returned back to the standard Pointwise interface.

2.3 .3 Create a Widget

To get started, look at the following example which creates a single pushbutton that prints out a message when pushed:

button .button1 -text "Push Me" -command {puts "Hello, World!"}

pack .button1

The first command creates a button widget named .button1 that has a label of Push Me and executes a function to print Hello, World! when pressed. The

The Tk graphics widgets are named in a tree fashion, similar to a file system. Widget and window names are separated by periods. Thus, the root window is named ., and a widget created in the root window could be named .widget1.

Some widgets can contain other widgets. In that case, the widget is identified by the complete name from the top dot to the referenced widget. For example, if widget1contains widget2, which contains widget3, you can access the last widget as .widget1.widget2.widget3.


Tip

second command, pack, makes the widget visible by placing it in the topmost Tk window. The period in the widget's name, .button1, is part of the widget hierarchy. The topmost widget is the main window with the name “.“. This is analogous to the / directory in the UNIX file system. Just as a full pathname starts with / and uses / to separate path components, a full Tk widget name starts with . and uses . to separate widget components.

Once a widget is created, the name of the widget becomes a command to access or configure the widget. In the example above, .button1 is now a command. You can change the label with the following command:

.button1 configure -text "Not so hard!"

For this reason, it is generally a good idea to assign the widget names to variables. Then if the hierarchy changes (which affects a widget’s name), the name only needs to be changed in one place. The following example shows this:

# Button callback 1

proc pushed { button } {

$button configure -text "Not so hard!"

$button configure -command [list again $button]

}

# Button callback 2

proc again { button } {

$button configure -text "That's better!"

$button configure -command [list pushed $button]

}

# Create the button widget

set push ".button1"

button $push -text "Push Me" -command [list pushed $push]

# Place it and make it visible

pack $push

When the button is first pressed, it calls the pushed procedure that changes the label and the callback function. When the button is pressed again, it calls the again procedure which changes the label and callback function back to the original values.

Note that when defining the -command value, the callback procedure and arguments are put into a list. That is so the variable button is substituted correctly. If braces had been used, the variable would not have been substituted until the button was pressed. If the variable had been changed after the definition, the wrong value would have been used. Worse, in the pushed and again procedures, the button variable will be undefined when the button is pushed (variables inside procedures are private to the procedure - callbacks are executed at the global level) resulting in a runtime script error.

The configure operations are used for querying or manipulating the configuration information for the widget. If configure is evaluated with no options, a list of Tcl lists of available option names and values will be returned:

puts [join [.button configure] “\n”]

2.11

Tip

2.3 .4 Geometry Manager

Geometry managers arrange widgets on the screen. It uses one widget as a parent, and it arranges multiple children (also called slaves) inside the parent. Tk provides three main geometry managers via the commands: pack, grid or place.

In general, either horizontal or vertical stacking is used within a frame. A frame is a container widget used to organize a group of other widgets. The following example creates .menubar frame then place two buttons side by side within this frame. It also creates a .body frame below the .menubar frame (Figure 2.1):

frame .menubar -bg white

frame .body -width 150 -height 50 -bg grey50

foreach b {alpha beta} {

button .menubar.$b -text $b

}

pack .menubar.alpha -side left -ipady 10

pack .menubar.beta -side right -ipadx 10

pack .menubar -side top -fill x -ipady 5

pack .body

The -side option allows a widget to be packed toward a specified side. The four possible sides are: top, right, bottom and left. The top is the default. The -ipadx and -ipady packing options allows specific display space to be added in the X and Y directions, repectively.

F igure 2.1: Tk widgets ar ranged by geometr y manager.

The packer maintains an order among the children that are packed into a frame. By default, each new child is appended to the end of the packing order. The most obvious effect of the order is that the children first in the packing order are closest to the side they are packed against. The -beforeand -after packing options can be used for controling the packing order. Widgets can be reorganized after they have been packed.

2.3 .5 Tk Scr ipt Example

The following script provides a more detailed example of Tk scripting for Pointwise. As seen in Figure 2.2, it creates a listbox of all the structured domains in a grid system. The user chooses on which domains the elliptic

The packer distinguishes between packing and display space when it arranges the widgets. The display space is the area requested by a widget for the purpose of painting itself. The packing space is the area the packer allows for the placement of the widget.

Such difference becomes important when a widget’s display does not take up all the packing space allocated to it. The -fill option can be used in this situation to force a widget to fill up the allocated packing space with its display.


Tip

solver will run and selects Run. Once finished, Done must be selected to exit the script.

F igure 2.2: Tk widget for running the so lver on se lected domains.

The number of iterations that the solver runs is currently hard-coded into this script example. As an exercise in Glyph scripting, try taking this script example and modifying it so that the number of iterations the elliptic solver should run can be specified within a field in the GUI.

# Example Pointwise Glyph script illustrating Tk use.

# Expects a grid system to already be present in memory,

# prompts for domain selection from a list box, and runs the

# Elliptic solver on the selected domains.

# Inform Pointwise we plan to use our own Tk widgets

package require PWI_Glyph 2.3

pw::Script loadTk

# Procedure for running the elliptic solver on domains

# selected in a list box.

proc solve { lb domList } {

# Get the index values of the selected entries

set entries [$lb curselection]

# Return if nothing selected

if {[llength $entries] < 1} {

return

}

# Build up the list of domains on which to run the

# Elliptic solver.

set doms [list]

foreach entry $entries {

Since the listbox does not allow variables or commands to be associated with its selection directly, it seems less useful than the button or menu widgets. However, it becomes important when you need to display a large number of selection values. The listbox widget is often used in conjunction with a scrollbarwidget.

2.13

Tip

# Get the text of the selected entry

set label [$lb get $entry]

# Scan out the domain number

scan $label {%d} n

# Pull that domain number out from the list of domains

# and append than number to the list.

lappend doms [lindex $domList [expr {$n - 1}]]

}

# Run the elliptic solver on the selected domains

set solveDom [pw::Application begin EllipticSolver $doms]

$solveDom run 5

$solveDom end

$lb selection clear 0 end

}

# Get all of the domains and exit right away if no domains

# are loaded.

set allDoms [pw::Grid getAll -type pw::Domain]

if {[llength $allDoms] < 1} {

puts "No domains are loaded. Execution halted."

exit

}

# Create a frame for holding the rest of the widgets

set frame .frame

frame $frame

# Create the listbox containing the domain descriptions

set lb "$frame.lb"

listbox $lb -height 10 -width 25 -selectmode extended

# Add a scroll bar if more than 10 domains

if {[llength $allDoms] > 10} {

set sb "$frame.ysb"

scrollbar $sb -orient vertical -command [list $lb yview]

# Connect the listbox to a vertical scrollbar.

$lb configure -yscrollcommand [list $sb set]

pack $sb -side right -fill y

The listbox supports several selectmode styles: single, browse, multiple, and extended. Of these styles, the extended option is one of the most useful as it allows either a a single entry to be selected or multiple contiguous entries simply by dragging the cursor over the entries.


Tip

}

# Fill the list box with domains

set n 0

foreach dom $allDoms {

incr n

if { [$dom isOfType pw::DomainStructured]} {

set dim [$dom getDimensions]

set idim [lindex $dim 0]

set jdim [lindex $dim 1]

set label [format "%3d - %3d x %3d" $n $idim $jdim]

$lb insert end $label

}

}

# Exit out if no structured domains are present

if {[$lb size] < 1} {

puts "No structured domains are loaded. Execution halted."

exit

}

pack $lb -side left -fill y

pack $frame -side top

# Add a separation line

set hr ".hr"

frame $hr -height 2

pack $hr -side top -fill x

# Add another frame for the buttons

set bframe ".bframe"

frame $bframe

# Add an exit button

set eb "$bframe.eb"

button $eb -text "Done" -command exit

pack $eb -side right -padx 5 -pady 5

# Add a run button

set rb "$bframe.rb"

The listbox operations use indices to reference lines in the listbox. The lines in a listbox are indexed from zero. The keyword index end addresses the last element. The most common task for a listbox is to insert text. If your data is in a list, you can loop through the list and insert each element at the end:

foreach item $list { $listbox insert end $item}

2.15

Tip

button $rb -text "Run" -command [list solve $lb $allDoms]

pack $rb -side right -padx 5 -pady 5

pack $bframe -side top -fill x

2.4 Scr ipt ing Convent ions

2.4 .1 Glyph2 Is Object-Or iented

Glyph2 is an object-oriented language used to control the Pointwise entities and settings. Tcl is not an explicitly object-oriented language, but can be made to work in an object-oriented way through the use of the command and parameter syntax. In order to work with Glyph2 in an object-oriented way we need to invent some terms to separate the different types of commands, even though from Tcl's perspective, these terms amount to commands with a list of parameters.

2.4 .2 Object

An Object is any entity that you interact with in Pointwise, like a connector or domain, but also includes other things such as a database segment or a connector distribution. An object is created by calling the static create action on the object’s type. Typically the object is held in a variable, which is then used later to execute actions on that object:

set con [pw::Connector create]

$con setName "leading-edge"

2.4 .3 Type

Types are used to group together defaults, attributes, and other similar actions that define a noun or entity. For example, an object (Section 2.4.2) is considered a specific instance of a type. Some types serve as the interface of the objects that you work with inside Pointwise, such as pw::Connector and pw::Curve, whereas others are used only to group static actions together such as pw::Application and pw::Display.

Types are hierarchical, in that a type can derive from another type (i.e. a childtype derives from a parent type), which means that any actions (Section 2.4.4) that can be performed on an object of a type can also be performed on an object of a derived type. Any non-static action you do with a parent type, you are also allowed to do with its child types. For instance, the child type pw::DomainStructured is derived from the parent type pw::Domain, thus any of the instance actions or instance attributes associated with pw::Domain can also be applied to pw::DomainStructured.

Glyph2 types are always of the form pw::<typename> with the first character capitalized.

A quick way to learn Tcl and Glyph2 syntax is to journal small meshing operations then examine the journaled scripts to see how commands are scripted.

Keep in mind that journaling produces scripts that are complete and functional, but contain some commands not normally needed for general-purpose scripts, like setting undo levels and inquiring about entities by name.


Tip

2.4 .4 Act ion

An Action is a verb that can be used to invoke a command or return information. There are two types of actions: static and instance. A staticaction is not specific to a single object and is called by specifying the type followed by the action and any parameters, such as pw::Database import file.iges. An instance action is specific to a single object and is called by specifying the object followed by the action and any parameters, such as $con getXYZ 3.

Actions always begin with a lower case character (e.g. exampleAction).

2.4 .5 Attr ibute

An Attribute is a special case of an action that can be used to get or set information of an object or global setting. An instance attribute is referred to by a single name such as Name, however it is accessed by adding get or setbefore the attribute name, and then calling it like an action, such as $con getName or $con setName “my-con”.

There are also type specific attributes that are grouped together such as render and solver attributes. These are accessed using a get/set action pair followed by the attribute name as the first parameter to the action, such as $con getRenderAttribute RenderMode and $con setRenderAttribute LineWidth 3.

2.4 .6 Default

A Default is a special case of a static attribute that is used to set values of an object when it is created. These are accessed using the getDefault and setDefault actions. The name of the default is given as the first parameter to these actions, such as pw::Connector setDefault Dimension 11. Then when the create action is used, the new object will use the values of the defaults in order to initialize its attributes and settings.

2.4 .7 Modes

In Glyph2, modes are used to put the application in a special state for operations like create, modification and extrusion. There are two types of modes: ones that create a sandbox environment, so that changes made in the mode do not affect pre-existing entities until the mode is ended, and others that facilitate a specific command. In both cases the modes are created by calling pw::Application begin <mode>. This returns an object that actions can be called on, including ending the mode. This is done by calling $mode end, to end the mode and save the settings or $mode abort, to end the mode without saving any of the results of the mode.

The first type of mode includes pw::Creator and pw::Modifier. These modes are started by using the parameters Create and Modify to the pw::Application begin action. They serve no other purpose other than to separate the created or modified entities from the rest of the entities in order to prevent merging or the update of dependent entities, until all changes have been made.

The utility functions pwu::Vector2 and pwu::Vector3were included in Glyph2 to make two and three dimensional vector calculations, such as cross products and dot products simpler for you.

2.17

Tip

The second type of mode includes pw::Copier, pw::Paster, pw::Merger, and pw::Dimensioner. These modes are started by using the parameters Copy, Paste, Merge, and Dimension to the pw::Application begin action. The pw::Copier mode is used to make copies of the entities given as the second parameter, without altering what is on the clipboard. The pw::Paster mode is the same as pw::Copier except that it makes copies of the current entities on the clipboard. The pw::Merger and pw::Dimensioner modes provide actions for merging and dimensioning connectors.

None of these modes are required when you create a script. However, they can provide advantages in the form of safety and performance. They provide safety because they keep the entity or entities being operated on from being integrated with the rest of your grid before they are ready. They help performance, like in the case of a Modify mode, because they can reduce the number of times dependent entities will have to be updated.

2.4 .8 Col lect ion

A Collection is a mechanism used to work on several entities at once. Collections are convenient since they allow actions to be applied to a group of entities without using a looping construct. To illustrate, look at the collection that was created below:

set my_collection [pw::Collection create]

$my_collection set [list $con1 $con2 $con3 $con4]

$my_collection do setDimension 15

$my_collection do setRenderAttribute ColorMode Entity

$my_collection do setColor 0x00ff0000

$my_collection delete

It creates a collection of connectors, applies the same dimension, color, and rendering attribute to all connectors within the collection, then deletes the collection. The updated connectors are not destroyed when the collection is deleted.

2.4 .9 Points

Points are represented in Glyph2 in two forms: free and database-constrained. A free point is a list of 3 floating-point values representing the X-, Y-, and Z-coordinates of the point (XYZ form):

set pt [list 1.5 2.3 -4.4]

A database-constrained point is a list of 2 floating point values and a third value representing the database entity identifier (UVD form). The 2 floating-point values represent the normalized U- and V-coordinates of the point. The valid range for these values is always between 0 and 1, inclusive.

Some Pointwise commands, such as pw::Segment addPoint, can take either form of point. Other commands, however, expect only the XYZ form. Use the pw::Application getXYZ command to convert from the UVD form to XYZ form:

The V-coordinate is 0.0 for database curves. The UVD form of a point constrained by db_curve, for example, can be written as either [list 0.5 0.0 $db_curve] or "0.5 0.0 $db_curve" using the double quote form.


Tip

set db_pt [list 0.5 1.0 $db_wing]

set xyz [pw::Application getXYZ $db_pt]

Conversely, to convert from XYZ form to UVD form, use the pw::Database closestPoint command:

set xyz [list 1 2.3 4.5]

set db_pt [pw::Database closestPoint $xyz]

If the XYZ point is on a surface, the returned value will be that point in UVD form. If the XYZ point is not on the surface, it returns the closest point on an enabled database entity. To find the closest point on a specific database entity, use -explicit $db before the $xyz parameter.

2.4 .10 I /O

Output to stdout and stderr are directed to the Messages window. Input from stdin comes from the console window only, but this is strongly discouraged for a general use script since the console window is only available when running the script from the Tcl shell.

If an uncaught error is encountered when running a script, execution of the script is halted immediately and Pointwise will post the Tcl error message. The full error message, including stack trace, is printed to the Messages window.

When debugging a script in Pointwise, pay careful attention to the Messages window. Failures and their location are reported there in detail and can be useful for determining where problems lie in your script.

3.1

Chapter 3

Journal Files


Tip

3 .1 Overv iew

As already discussed in Section 10.4 of the Pointwise User Manual, you can easily create a Glyph2 script by journaling the actions you perform within the Pointwise interface. Journaling in Pointwise describes, in script form, a very specific sequence of actions on a very specific set of entities. As such, journal files are constructed in a different fashion from a hand-written Tcl script. Understanding these differences can help you read and customize your journal files for your own use more effectively.

3.1 .1 Var iables

When storing entities and other objects, journal files use automatically generated variable names. For instance, if a connector is split in the user interface, the journal file will have lines similar to the following:

set _CN(1) [pw::GridEntity getByName {con-1}]

$_CN(1) split 0.5

In a hand-written script, more descriptive names should be used as variable names for entities of interest. Those names are assigned when the entity is created, whereas a journalled script has to look up the entity by name as seen in the example above.

Journal files also contain temporary variables that are unset after use. Take a look at the example below of how adding a segment to a connector, then performing some later operation (such as splitting) on the same connector would appear within a journal file.

set _TMP(con_1) [pw::Connector create]

$_TMP(con_1) addSegment $_TMP(PW_1)

unset _TMP(con_1)

set _CN(1) [pw::GridEntity getByName {con-1}]

$_CN(1) split 0.5

Notice that the connector is created with a temporary variable named $_TMP(con_1) that is unset when you are done. Later, when you wish to split the connector, it has to be looked up by name, then assigned to a another variable, $_CN(1). Another caveat with journal files is that some temporary variables can be local to a procedure, and are not exposed to the rest of the script.

In an hand-written script, the need for temporary variables is reduced since you will only set variables that you need later, and they should be named appropriately. To write a script that performs the same steps shown journaled above, you would do something similar to the following:

set wing_tip_con [pw::Connector create]

$wing_tip_con addSegment $seg

Journaling your actions in the Pointwise graphical user interface provides an easy way to learn basic Glyph commands. It also provides a useful tool debugging tool if a problem is encountered that you need to report.

3.3

Tip

$wing_tip_con split 0.5

As you can see the advantages of writing this by hand is that fewer lines of code are used and the code is easier to read and interpret.

3.1 .2 Undo Leve ls

When a journal file is created, Pointwise will insert markUndoLevel commands throughout the file at significant points in the script’s sequence. Undo checkpoints usually occur after some discrete set of actions in the user interface, such as creating a connector, and make a journal file easier to read. However, they are not typically necessary, so they may be removed from a journaled file. For hand-written scripts, these commands are generally not included.

3.1 .3 Undo and Delet ion

When journaling to a file from Pointwise, it is important to understand that the scripted form of the actions you execute within the user interface all are written to the file. If, at any point, an entity is deleted in the user interface or a previous state is restored through Undo, the previous states will still remain in the journal file since the journal is a complete sequence of actions, including undo and redo actions. The delete or undo operation will be recorded to the journal file by writing the command to delete or undo. This can lead to long journal files that contain operations that were ultimately undone, or entities created that were ultimately deleted.

Hand-written scripts typically have little need for undo or deletion, since the script should accomplish all intended results.

3.1 .4 Create and Modify Modes

When creating or modifying entities, journal files always use create and modify modes to ensure that a duplication check does not remove the entities until all operations on them are complete. This is due to the fact that whenever an entity is operated on within a mode, it is not a candidate for duplication checking until that mode has ended.

In an hand-written script, you can often skip using the create and modify modes, since you can avoid having an entity be a duplicate during construction or modification. However, if many changes are being made to a group of entities that are used by other entities (such as a connector that is part of a block), it is better to create a modify mode, make all the changes, and then end the mode, so that dependent entities only have to update once.

To monitor the performance of your script or a segment of it, consider adding some basic timing commands.


Example II.IV in our Glyph2 Examples Appendix.


4.1

Chapter 4

Glyph1 to Glyph2 Transition


Tip

4 .1 Overv iew

If you are used to using Gridgen’s Glyph1 scripting language, you will notice substantial differences with Pointwise’s Glyph2. This section will guide you through the major changes and provide some insight and comparisons on how to transition from programming in Glyph1 to Glyph2.

4.2 Programming Sty le

Glyph2 is an object-oriented language that closely mimics the interaction model seen within the Pointwise graphical user interface.

Glyph1, Gridgen’s script interface, is not object-oriented and uses a verb-noun style to reflect how interactions occur within the user interface. This style requires selection of the action (verb) you wish to apply followed by selection of the entity to which that action is applied. An example of dimensioning a connector in Glyph1:

gg::conDim $con 11

where gg::conDim is the verb or action and $con is the noun.

Glyph2, reflects how interactions occur within the Pointwise user interface, using noun-verb interaction method in which you first select an entity (noun), then choose and action (verb) to apply. The previous example, for Glyph2, would be written:

$con setDimension 11

Glyph2’s noun-verb interaction and object-oriented features provide consistency across multiple types of entities. One command, or action, can be applied to database, connectors, domains, and blocks instead of having a separate command for each entity type. For instance, to delete entities of different types in Glyph1 requires the following commands:

gg::dbDelete, gg::conDelete, gg::domDelete, gg::blkDelete

whereas in Glyph2, only one command is necessary:

pw::Entity delete list

where list is a list of connectors, domains, blocks, and/or database entities.

4.3 Di rect Compar isons

The easiest way to see the differences in how to transition from programming in Glyph1 to Glyph2 is to make some direct comparisons. The following sections break down operations where there are significant syntax differences in between Glyph1 and Glyph2.

When setting variables in a hand-written script, try to make sure you use brief but descriptive names for your variables, such as “conWingTip”, “domWingTip”, and “blkPylon”. These types of variable names will make debugging your script much easier later on.

4.3

Tip

4.3 .1 In i t ia l iz ing a scr ipt

When starting a new script, users choose to either begin with the existing settings in the application, such as entities stored in memory, defaults, and tolerances, or to clear all of data to begin anew. The option shown below illustrates the latter option of clearing all settings and data from memory:

Glyph1

#Initialize everythinggg::memCleargg::aswDeleteBC -glob "*"gg::aswDeleteVC -glob "*"gg::aswSet GENERIC -dim 3gg::defResetgg::tolReset

Glyph2package require PWI_Glyph 2.0

#Initialize everythingpw::Application reset

The first major difference you will notice is the “package require” line seen within Glyph2. This command is required at the beginning of every Pointwise script and tells Pointwise to load Glyph and its libraries so they may be accessed. Glyph2 is a Tcl package, where Glyph1 is a custom implementation of Tcl built into Gridgen. Since Glyph2 is a package, greater flexibility is provided in that other Tcl packages can be used.

In the remainder of the example, you can see it takes several lines of code to effectively remove all data and settings from memory in Glyph1. However, when coded for Glyph2, you can see that all of these settings can easily be bundled into a reset of the whole application. Note that, if needed, optional flags can be used in Glyph2 to selectively clear certain settings.

4.3 .2 Sett ing a CAE Solver

The pw::Application type is used with another of its actions to set the desired solver for this script.

Glyph1#Set CAE solvergg::aswSet CGNS

Glyph2

#Set CAE solverpw::Application setCAESolver CGNS

Notice that the main difference in using Glyph2 in this instance is that the command used is more explicit and uses less abbreviation which improves the readability of the code. This is true in general for all Glyph2 commands.

Depending on the design of your script, you may want to start with no database or grid entities in memory, or you may wish the script to execute on an existing grid. The initialization of your script with the pw::Application reset needs to be used with the flags necessary for keeping any startup data that is important to you.


Tip

4.3 .3 Ent i ty Creat ion

During the process of creating a grid, you will often find yourself making many connectors, domains, and blocks. In many situations using a procedure can easily save you time and lines of code. Below is a procedure for creating connectors in both Glyph1 and Glyph2. These procedures will be broken down and their differences discussed in the following sections. It is important to note that these differences are similar to what you would see for other entity types.

Glyph1

# Connector Generation Routineproc createTwoPtLineCon { pt1 pt2 dim {delta0 0.0} {delta1 0.0}} { gg::conBegin gg::segBegin -type 3D_LINE gg::segAddControlPt $pt1 gg::segAddControlPt $pt2 gg::segEnd set con [gg::conEnd]

gg::conDim $con $dim if {$delta0 > 0.0} { gg::conBeginSpacing $con $delta0 }

if {$delta1 > 0.0} { gg::conEndSpacing $con $delta1 }

return $con}

Glyph2

# Connector Generation Routineproc createTwoPtLineCon { pt1 pt2 dim {delta0 0.0} {delta1 0.0}} { set creator [pw::Application begin Create]

set con [pw::Connector create] set seg [pw::SegmentSpline create] $seg addPoint $pt1 $seg addPoint $pt2 $con addSegment $seg $con setDimension $dim

if {$delta0 > 0.0} { set df [$con getDistribution 1] $df setBeginSpacing $delta0 }

In Glyph1, commands typically only handled one type of entity. For example, gg::blkName would only accept blocks as valid input. In Glyph2, there are a variety of commands that will work on multiple entity types. For example, this is useful if you need to transform a database and grid simultaneously.

More details can be found in Example II.V in the Glyph2 Examples Appendix.

4.5

Tip if {$delta1 > 0.0} { [$con getDistribution 1] setEndingSpacing $delta1 } $creator end return $con}

4.3 .3 .1 Creat ion Modes

If you look at the way entities are created with Glyph1, you can see that the entity itself is not actually saved until the very end of the creation mode. Certain aspects of the entity have to be defined in order to save it. A connector’s segment type and segment control point locations are good examples of characteristics that define the entity.

Glyph1

gg::conBegin gg::segBegin -type 3D_LINE gg::segAddControlPt $pt1 gg::segAddControlPt $pt2 gg::segEnd set con [gg::conEnd]

In Glyph2, the connector and its segment are created first as objects. The characteristics that define these nouns, the connector and the segment, can all be set at a later date. For this example, we have defined the segment control points, the connector dimension, and some of its spacing constraints while still in the creation mode. The advantage is that the changes made to entities while in this mode do not affect dependent or duplicate entities until the mode is ended.

Glyph2

set creator [pw::Application begin Create] set con [pw::Connector create] set seg [pw::SegmentSpline create] $seg addPoint $pt1 $seg addPoint $pt2 $con addSegment $seg $creator end

4.3 .3 .2 Def in ing Ent i t i e s

Defining the characteristics of an entity in Glyph2 is always accomplished using an instance action or attribute that is applicable to that entity type. In the following example, a connector is dimensioned in Glyph1 and Glyph2. Glyph1 uses the command:

gg::conDim $con $dim

to apply a given dimension, $dim, to a connector or list of connectors, $con. This command, like many others in Glyph1, has some implicit functionality.

Even though using a creation mode is not necessary within Glyph2, it does provide a measure of safety. For example, when you create a connector sharing the same two endpoints as an existing connector outside a mode, duplication checking immediately occurs in Pointwise and the two connectors are merged. If created inside a mode, you have the opportunity to give the new connector a different dimension and/or distribution. Duplication checking only occurs on the new connector after the mode ends at which point the connector is different enough not to be merged.

Additionally, if an error is detected and the script is ended prematurely, any open mode will be aborted.


Tip

Not only can you apply a value to a given variable, you can also find out the current value of the variable if no new value is supplied. In this case, if $dimwas not supplied:

gg::conDim $con

the command would return the current dimension assigned to $con. This double-duty could be confusing since not all Glyph1 commands function in this manner and because this functionality is not intuitively obvious. In Glyph2, the commands to set and get values are explicit and exclusive from each other. To set the dimension of a connector in Glyph2, you would do so in the following manner:

$con setDimension $dim

However, to get the current dimension of $con, you use the get version of this action instead:

$con getDimension

Having all functionality explicitly defined makes the code not only easier to read but also easier to construct.

Another example of the explicit nature of Glyph2 can be seen in the ways spacing constraints are set on connectors. To apply spacing constraints in Glyph1:

gg::conBeginSpacing $con $delta0

There is an assumption that you are setting the beginning and ending spacings on the first subconnector. To set spacings on the beginning and ending of other subconnectors additional code is necessary. Whereas, for Glyph2, because it is a more explicit language, you always specify on which subconnector you will be applying a spacing constraint:

set df [$con getDistribution 1] $df setBeginSpacing $delta0

In the example above, the first of two methods is shown for specifying which subconnector’s distribution to modify. This method sets a variable df to the distribution function of the first subconnector of $con. The beginning and ending spacing constraints can now be applied to $df. If you wish to set the spacing constraints on another subconnector, you could simply set df equal to that subconnector’s distribution. This approach is best used if you will be setting multiple spacing constraints.

[$con getDistribution 1] setEndingSpacing $delta1

The second method, seen above, gets the distribution object and sets the end spacing in one line of code. These are two different ways to code roughly the same operation within Glyph2.

4.3 .4 Running a Solver

Running the grid solver on a structured or unstructured grid entity is modal in both Glyph1 and Glyph2. Looking at the code below, the two versions look quite similar. However, there is a difference in how these modes are handled and in how they are written.

In Tcl, variable names are not allowed to contain the dash (-) characters.

4.7

Tip

Glyph1

# Run the domain solvergg::domEllSolverBegin $dom gg::domEllSolverAtt $dom -relax 0.7 gg::domEllSolverStep -iterations 20gg::domEllSolverEnd

Glyph2

# Run the domain solverset solver [pw::Application begin EllipticSolver $dom] $dom setEllipticSolverAttribute RelaxationFactor 0.7 $solver run 20$solver end

In Glyph1, whenever you begin a mode with an entity you must specify that entity’s characteristics or attributes within the mode. When the mode ends, the new (or modified in this case) entity is saved. In Glyph2, an object’s attributes do not have to be specified within the mode. They can easily be specified before entering the solver for execution. As an example, the Glyph2 code seen above could be rewritten in the following manner without any changes to functionality:

$dom setEllipticSolverAttribute RelaxationFactor 0.7set solver [pw::Application begin EllipticSolver $dom] $solver run 20$solver end

The difference is that, if the solver mode is aborted in the first example, the attributes are not saved, where they are saved in the second example.

4.3 .5 Gr id Extrus ions

Extrusion has changed significantly from Glyph1 to Glyph2. In Glyph1, a block extrusion is performed by entering an extrusion mode with the set of grid entities from which you wish to extrude (connectors or domains). These entities are extruded into a domain or block based on the attributes set within the extrusion mode. The resulting domain or block is saved at the end of the mode.

Glyph1

# Extrude domains to create blocksgg::blkExtrusionBegin [list $domABCDE $domFGHI] -type STRUCTURED gg::blkExtrusionMode HYPERBOLIC gg::blkExtrusionAtt -s_init 0.01 gg::blkExtrusionAtt -growth_geometric 1.01 gg::blkExtrusionStep 10set blocks [gg::blkExtrusionEnd]

set blkUp [lindex $blocks 0]gg::blkName $blkUp “upstream”

set blkDown [lindex $blocks 1]

There are some functions available in Glyph2 that were not accessible in Glyph1. For instance, the function getConnectorFromNode is used in Glyph2 to locate connectors for domain assembly. This function will return a list of all connectors that use a specified node.


Example II.VI in the Glyph2 Examples Appendix.


Tip

gg::blkName $blkDown “downstream”

In Glyph2, the block is created prior to entering the extrusion mode. A single face, composed of one or more domains, is added to the block definition. When the extrusion mode is entered, the block is passed into the mode. Attributes for how the extrusion will proceed are set for the block (either inside or outside of the mode). When the run action is applied within the extrusion mode, the existing block that was passed in is filled with the extruded cells based on the extrusion attributes.

Glyph2

# Extrude domains to create blocksset blkUp [pw::BlockStructured create] set face [pw::FaceStructured create] $face addDomain $domABCDE $blkUp addFace $face

set blkDown [pw::BlockStructured create] set face [pw::FaceStructured create] $face addDomain $domFGHI $blkDown addFace $face

set ext [pw::Application begin ExtrusionSolver [list $blkUp $blkDown]] $blkUp setExtrusionSolverAttribute Mode NormalHyperbolic $blkUp setExtrusionSolverAttribute NormalInitialStepSize 0.01 $blkUp setExtrusionSolverAttribute SpacingGrowthFactor 1.01 $blkDown setExtrusionSolverAttribute Mode NormalHyperbolic $blkDown setExtrusionSolverAttribute NormalInitialStepSize 0.01 $blkDown setExtrusionSolverAttribute SpacingGrowthFactor 1.01

$ext run 10$ext end

$blkUp setName “upstream”$blkDown setName “downstream”

In the example above, you can see that if you are extruding multiple blocks, setting up the attributes can be quite tedious on a case by case basis. An alternative method for setting these attributes would be to place the blocks within a collection (Section 2.4.8), apply the attributes to the collection, then use the blocks within the extrusion. Rewriting the above example using this technique would yield the following code:

set blocks [pw::Collection create] $blocks set [list $blkUp $blkDown] $blocks do setExtrusionSolverAttribute Mode Normal Hyperbolic $blocks do setExtrusionSolverAttribute NormalInitialStepSize 0.01 $blocks do setExtrusionSolverAttribute SpacingGrowthFactor 1.01 $blocks delete

Converting grid entities into database entities can be a useful tool when you lack a database to project your grid onto or when you need to see where portions of a grid would intersect. You can convert your grid entities into database entities by exporting them into a segment or PLOT3D file format, then import it as a database file.


Example II.VII in the Glyph2 Examples Appendix.

4.9

Tipset ext [pw::Application begin ExtrusionSolver [list $blkUp $blkDown]] $ext run 10$ext end

Note that the $blocks delete command simply deletes the collection after attributes have been applied to its constituent entities. The entities themselves are not destroyed. Also note that the user interface applies extrusion attributes to multiple blocks using collections, so journaling such an operation would be a useful example.

Glyph2 contains functions for edge handling that were not available in Glyph1. For example, if you wished to reverse the order of the connectors that defined an edge you could do so through the getEdge and reversefunctions.


Example II.VIII in the Glyph2 Examples Appendix.


5.1

Chapter 5

Glyph2 Command Reference


Tip

5 .1 Documentat ion Convent ions

Glyph2 manual pages which describe each command, its usage, options, and restrictions, are available in HTML form at:

http://www.pointwise.com/glyph2/

The documentation conventions used for these manual pages are defined within this section.

Within the individual command (i.e. type) pages, there are certain standards that have been used to represent each command. Understanding these standards will help you to better navigate through the types and their functionality. For each type’s manual page, you will first see the type itself:

pw::Segment

followed by a description of the type:

Connector and Curve segment type

The Summary section for each type provides a brief description of its static actions, static attributes, instance actions, instance attributes, and any other kind of related attributes. Actions and attributes and how they are used with types is explained in Section 2.4.4 and Section 2.4.5.

F igure 5.1: The Summary tab le for the pw::Segment type.

Following the Summary table are sections that include complete descriptions for all the items seen within the table (Figure 5.2).

To obtain the number of control points of each segment in a connector, you may want to look for the strings “segment” and “connector” in the Function or Type indices. The segment type and its functions can be found in those areas.


Example II.IX in the Glyph2 Examples Appendix.

5.3

Tip

F igure 5.2: Each act ion/at t r ibute wi l l have a deta i led sect ion in the manual page descr ib ing i t s funct iona l i ty and parameters .

Text that appears initially in the action/attribute section in a Courier font is provided as a usage example of the command and any parameters or flags it accepts (optional or required). Text between question marks (?) in the usage example represents optional data. The pipe symbol (|) is used to delimit mutually exclusive options.

Glyph2’s boolean variables may be entered in a variety of ways. FALSE, OFF, NO, and the number zero are all synonymous as are TRUE, ON, YES, and non-zero numbers. Text-based booleans are case-insensitive. In other words, TRUE, True, and true all yield the same result.

5.2 Navigat ing the Documentat ion

The Glyph2 documentation is organized by both Type and Function. Types are described in detail within Section 2.4.3 and are indexed alphabetically within the About section (Figure 5.3).

F igure 5.3: The Type index i s one of two useful index ing ut i l i t ies wi th in the Glyph2 documentat ion.

Boolean variables can easily be used to hide database entities. A simple way to do this would be:set disp [pw::Display \ getShowDatabase]

if {$disp == 1} { pw::Display setShowDatabase false}


Tip

Types are divided between two Tcl namespaces: pw:: for “atomic” low level commands and pwu:: for utility commands.

Functions describe the actions that can be applied through these types. Each function is described in detail in the Glyph2 man page for its associated type. Note that a single function can be used across multiple types. Functions, like types, are also indexed alphabetically within the About section (Figure 5.4).

F igure 5.4: The Funct ion index prov ides a qu ick and easy way to look for an “act ion” you wish to apply and any assoc iated types .

The most effective way to find a particular type or function is often by browsing these two indices. However, if you know the category of your desired type you can browse through that category to find the appropriate commands. For instance, if you know that you wish to operate on a database curve, you would look within the Database Entity Types category (Figure 5.5).

F igure 5.5: Types are a l so l i s ted h ierarch ica l l y wi th in the i r re levant categor ies .

If you are looking for commands for assembling domains or blocks, look for keywords such as “addEdge” or “addFace” first. This will direct you to all the commands associated with the edge and face operations.

5.5

Tip

Notice within Figure 5.5 that some of the types listed are indented. This demarcation indicates that the higher level type is a parent type to those beneath it. This relationship can also be seen within the Derives From section of a type’s manual page. As an example, look at pw::Curve. Its parent type is pw::DatabaseEntity which is derived from pw::Entity which is derived from pw::Object (Figure 5.6).

F igure 5.6: The parent types that pw: :Curve are der ived f rom can be seen with in the Der ives From sect ion of i t s manual page.

Because of this class hierarchy, any of the actions or attributes belonging to the parent type are also applicable to any child type derived from it.

When working with a particular type, make sure you are familiar with the actions and attributes that belong to its “parent” type. For example, when working with the type pw::Connector, you would look at the actions associated with its parent type, pw::GridEntity. The type pw::GridEntity has a setName action that is applicable to pw::Connectorand can be very useful in connector operations.


I.I

Appendix I

References

I.II Pointwise Glyph Reference Manual

1. Ousterhout, John K., and Jones, Ken, Tcl and the Tk Toolkit, Second Edition, Addison-Wesley Professional 2009. Focuses on all aspects of Tcl and Tk from beginner to advanced. Considered one of the most authoritative resources and references for Tcl/Tk.

2. Foster-Johnson, Eric, Graphical Applications with Tcl & Tk, Second Edition, M & T Books 1997. Focuses primarily on Windows aspects of Tcl and Tk. Oriented towards beginners and experienced users.

3. Welsh, Brent B., Practical Programming in Tcl and Tk, Third Edition, Prentice-Hall, Inc. 2000. Focuses primarily on UNIX aspects of Tcl and Tk. Oriented towards beginnings and experienced users.

4. http://www.tcl.tk/. Primary website for Tcl and Tk distributions and source. Contains links to other websites focused on Tcl and Tk.

5. comp.lang.tcl. Primary newsgroup for discussions of Tcl and Tk. Covers optimization, future directions, bugs, and programmer help.

6. comp.lang.tcl.announce. Newsgroup for the announcement of new Tcl programs and packages.

II.I

Appendix II

Glyph2 Examples

II.II Pointwise Glyph Reference Manual

I I . I BC Query ing

The following piece of Glyph2 script illustrates how to use the string command determine whether a BC is set as undefined.

foreach bcName [pw::BoundaryCondition getNames] {

set bc [pw::BoundaryCondition getByName $bcName]

set bcType [$bc getPhysicalType]

if [string equal -nocase $bcType "Unspecified"] {

foreach entity [$bc getEntities] {

puts "[$entity getName] BC is \"$bcName\" which is \"$bcType\""

}

}

}

I I . I I De let ing a L is t E lement

The following piece of Glyph2 script illustrates how to remove an element from a list via the lreplace command.

proc ldelete {list ele} {

set eleID [lsearch -exact $list $ele]

if {$eleID >= 0} {

return [lreplace $list $eleID $eleID]

} else {

return $list

}

}

I I . I I I Sett ing the Scr ipt Di rectory

The following piece of Glyph2 script illustrates how to set a script to open a file from the current working directory instead of an explicit path.

set scriptDir [file dirname [info script]]

source [file join $scriptDir MyScript.glf]

I I . IV T iming a Scr ipt

The following piece of Glyph2 script illustrates how to time a script or a portion of a script.

set startTime [pwu::Time now]

II.III

# Insert scripting actions you wished to be timed here.

set elapsedTime [pwu::Time elapsed $startTime]

puts “Execution Time: [pwu::Time double $elapsedTime] secs”

I I .V Transforming Database and Gr id S imultaneous ly

The following piece of Glyph2 script illustrates how you can transform a set of database and grid entities simultaneously.

set dbList [pw::Database getAll]

set con [pw::GridEntity getByName “con-1”]

lappend dbList $con

set trans [pw::Application begin Modify $dbList]

pw::Entity transform [pwu::Transform translation {1 1 1}] [$trans getEntities]

$trans end

I I .V I Ident i fy ing Connectors for Domain Assembly

The following piece of Glyph2 script illustrates how to locate the connectors that form a loop. This capability is essential when assembling domains.


set node_1 [$con getNode Begin]

set node_2 [$con getNode End]

set nextCon_1 [pw::Connector getConnectorsFromNode $node_1]

set nextCon_1 [lreplace $nextCon_1 0 0]

set nextCon_2 [pw::Connector getConnectorsFromNode $node_2]

set nextCon_2 [lreplace $nextCon_2 0 0]

puts “Neighbor cons are $nextCon_1 and $nextCon_2.”

I I .V I I Convert ing Gr id Ent i t ies into Database Ent i t ies

The following piece of Glyph2 script illustrates how to export grid entities in a form that can be imported as database.


pw::Grid export -type Segment [list $con] [file join $scriptDir conToDB.dat]

set dbFromCon [pw::Database import -type Automatic [file join $scriptDir conToDB.dat]]

II.IV Pointwise Glyph Reference Manual

I I .V I I I Revers ing an Edge’s Connectors

The following piece of Glyph2 script illustrates how to reverse the connectors that define an edge in a domain.

set dom [pw::GridEntity getByName {dom-1}]

set EdgeCount [$dom getEdgeCount]

for {set i 1} {$i <= $EdgeCount} {incr i 1} {

set edge [$dom getEdge $i]

$edge reverse

}

I I . IX Ca lcu lat ing the Number of Segment Contro l Po ints

The following piece of Glyph2 script illustrates how to calculate the number of control points in each segment of a connector.


set segNum [$con getSegmentCount]

for {set i 1} {$i <= $segNum} {incr i 1} {

set seg [$con getSegment $i]

set ptNum [$seg getPointCount]

puts “# $i segment has $ptNum control points.”

}

I I .X Interact ive ly Se lect ing Structured Domains f rom Disp lay

The following piece of Glyph2 script illustrates how to interactively select structured domains from the main display.

# Creating a selection mask allows specific type(s) of entities to be selected, for

# example, structured domains.

set strucDomSelMask [pw::Display createSelectionMask -requireDomain Structured]

pw::Display selectEntities -selectionmask $strucDomSelMask selArray

set strucDomSel $selArray(Domains)

puts "The selected structured domains are: \n

$strucDomSel"

II.V

I I .X I Export CAE Data With User Def ined Attr ibutes

Pointwise’s IOMode exporters (i.e., CAE exporter) intend to leave out any attributes that are not supported. And as such, trying to access an undefined attribute will raise an error.

The following piece of Glyph2 script illustrates how to export data to the CGNS format with validated user defined CAE attributes.


set blkList [pw::Grid getAll -type "pw::Block"]

# Create an IOMode and initialize it with the file type and name.

set exportMode [pw::Application begin CaeExport $blkList]

$exportMode initialize -type Automatic [file join $scriptDir outputName.cgns]

# Set user defined attribute name and value.

set attrName "FilePrecision"

set attrVal "Single"

# Validate the user defined attribute and export data if correct. Note this section can be

# skipped if you are sure your attribute name and value are legitimate.

if { -1 != [lsearch [$exportMode getAttributeNames] $attrName] } {

# Set attribute value and print message if attribute name is valid.

$exportMode setAttribute $attrName $attrVal

} else {

# Otherwise, print a statement that the attribute name is invalid.

puts "Attribute '$attrName' does not exist!"

}

# Verify the IO mode attributes and the entities of the mode that should be exported.

if { ! [$exportMode verify] } {

puts “Data verification failed!”

}

# Write out entities of the mode into a target format.

$exportMode write

# End the export mode and save changes made during the mode.

$exportMode end

II.VI Pointwise Glyph Reference Manual

Chapter III

Index

III.2 Pointwise Glyph Reference Manual

A

abort 2action 16array 7attribute 16

B

boolean variables 3braces 3break 6

C

CAE solver 3catch 6collection 17command substitution 2comments 3continuation character 2continue 6control structures 3create 15

D

default 16deletion 3double quotes 3

E

entity creation 4entity definition 5error handling 6execute 2exit 2expr function 2extrude 7

F

file 8filenames 8for 5foreach 5function 3

G

global 7grouping 3

I

I/O 18If then else 3incr 5Input 18instance action 16instance attribute 16

L

listelements 8lindex 8

lists 7

M

manual pages 3, 2syntax 3

modecopier 17create 3, 5creator 16dimensioner 17merger 17modifier 16modify 3paster 17

modes 16

N

noun-verb 2

O

object 15object-oriented 15, 2Output 18

P

points 17procedures 6

R

return 6running the solver 6

S

script initialization 3static action 16switch 4

exact 4glob 4regexp 4

T

terminate 2type 15, 2, 3

U

undo 3utility commands 4

V

variables 2verb-noun 2

W

while 5

Documents

Pointwise Glyph Reference Manual