MSC - Acumen 2006 Application Author's Guide

MSC.
Acumen 2006
Application Author’s Guide
Main Index
Corporate
MSC.Software Corporation
2 MacArthur Place
Santa Ana, CA 92707 USA
Telephone: (800) 345-2078
Fax: (714) 784-4056
Europe
MSC.Software GmbH
Am Moosfeld 13
81829 Munich, Germany
Telephone: (49) (89) 43 19 87 0
Fax: (49) (89) 43 61 71 6
Asia Pacific
MSC.Software Japan Ltd.
Entsuji-Gadelius Building
2-39, Akasaka 5-chome
Minato-ku, Tokyo 107-0052, Japan
Telephone: (81) (3) 3505 0266
Fax: (81) (3) 3505 0914
Worldwide Web
www.mscsoftware.com
Disclaimer
MSC.Software Corporation reserves the right to make changes in specifications and other information
contained in this document without prior notice.
The concepts, methods, and examples presented in this text are for illustrative and educational purposes
only, and are not intended to be exhaustive or to apply to any particular engineering problem or design.
MSC.Software Corporation assumes no liability or responsibility to any person or company for direct or
indirect damages resulting from the use of any information contained herein.
User Documentation: Copyright 2006 MSC.Software Corporation. Printed in U.S.A. All Rights
Reserved.
This notice shall be marked on any reproduction of this documentation, in whole or in part. Any
reproduction or distribution of this document, in whole or in part, without the prior written consent of
MSC.Software Corporation is prohibited.
MSC is a registered trademark of the MSC.Software Corporation. NASTRAN is a registered trademark
of the National Aeronautics and Space Administration. MSC.Nastran is an enhanced proprietary version
developed and maintained by MSC.Software Corporation. MSC., MSC.Patran, and MSC.Acumen are
trademarks of MSC.Software Corporation.
All other trademarks are the property of their respective owners.
ACM*V2006*Z*Z*Z*DC-904001
Main Index
C O N T E N T S
MSC.Acumen Application Author’s Guide
MSC.Acumen Application Author’s
Guide,
Preface ■ Technical Support, x

■ www.mscsoftware.com, xii
■ Permission to Copy and Distribute MSC Documentation, xiii
1
Authoring ■ Definitions, 2
MSC.Acumen
■ Product Overview, 3
Applications
❑ Typical File Structure for an MSC.Acumen Installation, 3
❑ Core Run –Time Software Libraries Installation and File
Structure, 4
❑ Specific MSC.Acumen Applications Installation and File
Structure, 5
❑ Run-Time Environment Variables Set by the Invoking Script
File, 6
■ What is an MSC.Acumen Application?, 9
■ Why an MSC.Acumen Application?, 10
■ Principles for Effective Application Development, 12
■ MSC.Acumen Data Flow Diagrams, 15
❑ General Dataflow, 15
❑ Detailed Data Flow, 16
2
Drive Pages ■ Drive Page Overview, 18
■ Elements of a Drive Page, 19
❑ Element Relations, 20
■ Drive Page Style Guide, 23

■ How is PCL called from drive pages?, 25
■ AANAV and AACHECK class functions, 26
■ Philosophy of Drive Page vs. AANAV Class, 27
■ Example of a Home Drive Page (Step 1), 28
Main Index
■ Example of a Home Drive Page (Steps 2-n), 32
■ XML Tag Definitions, 51
❑ Advisor Tag, 51
❑ <advisor>, 51
❑ Defsteps Tag, 53
❑ <defsteps>, 53
❑ Ds Tag, 53
❑ <ds>, 53
❑ Step Tag, 54
❑ <step>, 54
❑ UresponseTag, 55
❑ <uresponse>, 55
❑ Response Tag, 57
❑ <response>, 57
❑ Lrule Tag, 57
❑ <lrule>, 57
❑ Dialog Tag, 58
❑ <dialog>, 58
❑ Returnerror Tag, 61
❑ <returnerror>, 61
■ Supported HTML tags and options, 62
3
Function ■ Function Definitions File Overview, 68
Definitions Text
■ Function Definitions File Example, 69
File
■ Syntax of Keywords, 72
❑ Syntax for the Different Widget Types, 76
❑ Specification of call parameters for which no widgets are
displayed, 78
4
Introduction to ■ What is HTML, and why do I need to know about it for
HTML MSC.Acumen?, 82
■ Example of a Simple HTML Page, 83
■ Document Tags, 84
■ Lists, 86
■ Anchors, 88
Main Index
5
State Table ■ State Table Overview, 90
Functional
■ Record User Response Variable, 92
Interface
❑ AASTATE.record_ur_real, 92
❑ AASTATE.record_ur_realarray, 92
❑ AASTATE.record_ur_integer, 93
❑ AASTATE.record_ur_integerarray, 93
❑ AASTATE.record_ur_string, 95
❑ AASTATE.record_ur_stringarray, 95
❑ AASTATE.record_uresponse, 96
■ Retrieve User Response Variable, 97

❑ AASTATE.get_ur_real, 97
❑ AASTATE.get_ur_realarray, 97
❑ AASTATE.get_ur_integer, 98
❑ AASTATE.get_ur_integerarray, 99
❑ AASTATE.get_ur_string, 99
❑ AASTATE.get_ur_stringarray, 100
❑ AASTATE.get_uresponse, 101
■ Overwrite User Response Variable, 102

❑ AASTATE.overwrite_ur_real, 102
❑ AASTATE.overwrite_ur_realarray, 102
❑ AASTATE.overwrite_ur_integer, 103
❑ AASTATE.overwrite_ur_integerarray, 104
❑ AASTATE.overwrite_ur_string, 104
❑ AASTATE.overwrite_ur_stringarray, 105
❑ AASTATE.overwrite_uresponse, 106
■ General Access to the State Table, 107

❑ AASTATE.record_dialog, 107
❑ AASTATE.record_lrule, 107
❑ AASTATE.previous_dialog, 108
❑ AASTATE.dumphistory, 108
❑ AASTATE.store_objectives, 110
❑ AASTATE.restore_oldstate, 110
6
User Interface ■ Main Panel, 112
Functions ❑ AAUI.mainpanel_include_steps, 112
❑ AAUI.mainpanel_current_step, 112
❑ AAUI.mainpanel_step_complete, 113
❑ AAUI.mainpanel_lock_steps, 113
❑ AAUI.mainpanel_unlock_steps, 114
Main Index
❑ AAUI.mainpanel_unselect_steps, 114
❑ AAUI.switch_highlight, 115
❑ AAUI.switch_highlight_restorer, 115
■ Buttons, 117
❑ AAUI.sthelp_helpcb, 117
❑ AAUI.helpdoc_display, 117
❑ AAUI.quickreview_quickcb, 119
❑ AAUI.quit_quitcb, 119
❑ AAUI.backup_backupcb, 120
❑ AAUI.backup_status, 120
❑ AAUI.notify_backup_done, 121
❑ AAUI.backup_enable, 121
■ Dialog Box, 123

❑ AAUI.dialog_put_text, 123
■ Inputs Box, 124

❑ AAUI.inputs_refresh, 124
❑ AAUI.inputs_applycb, 124
❑ AAUI.selectdatabox_read_raw, 125
❑ AAUI.selectdatabox_read_ids, 125
❑ AAUI.selectdatabox_read_coords, 126
❑ AAUI.selectdatabox_assread_raw, 128
❑ AAUI.selectdatabox_assread_ids, 129
❑ AAUI.selectdatabox_assread_coords, 130
7
Drive Page ■ Introduction, 134
Interpreting ■ PCL Function Descriptions, 135
Functions
❑ AAI.html_calls, 135
❑ AAI.get_step1id, 136
❑ AAI.allsteps_display, 137
❑ AAI.init_step_dialog, 137
❑ AAI.step_help_doc, 138
❑ AAI.next_dialog, 138
❑ AAI.dynamic_next_dialog, 140
❑ AAI.queued_dialog, 141
❑ AAI.queued_msg, 141
❑ AAI.queued_ftn, 142
❑ AAI.initiate_ftn, 142
❑ AAI.exit_ftn, 143
Main Index
8
General Utility ■ Introduction, 146
Functions
■ PCL Function Descriptions, 147
❑ acumen_drive_page_trans, 147
❑ aa_env.ret_acumen_app, 148
❑ aa_env.ret_acumen_brw, 149
❑ aa_env.ret_acumen_home, 150
❑ aa_env.ret_acumen_int, 151
❑ aa_env.validate_path, 152
INDEX ■ MSC.Acumen Author’s Guide
Main Index
Main Index
MSC/PATRAN User’s Guide, Part 4: Finite Element Modeling
Preface
■ List of MSC.Patran Books

■ Technical Support
■ Internet Resources
■ Permission to Copy and Distribute MSC Documentation
Main Index
iv
List of MSC.Patran Books

Below is a list of some of the MSC.Nastran documents. You may order any of these documents
from the MSC.Software BooksMart site at www.engineering-e.com.
Installation and Release Guides

❏ Installation and Operations Guide
❏ Release Guide
User’s Guides and Reference Manuals

❏ MSC.Patran User’s Guide
❏ MSC.Patran Reference Manual
❏ MSC.Patran Analysis Manager
❏ MSC.Patran FEA
❏ MSC.Patran Materials
❏ MSC.Patran Thermal
Preference Guides
❏ ABAQUS
❏ ANSYS
❏ LS-DYNA
❏ MSC.Marc
❏ MSC.Dytran
❏ MSC.Nastran
❏ PAMCRASH
❏ SAMCEF
❏ PATRAN 2 Neutral File
Main Index
CHAPTER v
Preface
Technical Support
For help with installing or using an MSC.Software product, contact your local technical support
services. Our technical support provides the following services:
• Resolution of installation problems
• Advice on specific analysis capabilities
• Advice on modeling techniques
• Resolution of specific analysis problems (e.g., fatal messages)
• Verification of code error.
If you have concerns about an analysis, we suggest that you contact us at an early stage.
You can reach technical support services on the web, by telephone, or e-mail:
Web Go to the MSC.Software website at www.mscsoftware.com, and click on Support. Here, you can
find a wide variety of support resources including application examples, technical application
notes, available training courses, and documentation updates at the MSC.Software Training,
Technical Support, and Documentation web page.
Phone United States Frimley, Camberley
and Telephone: (800) 732-7284 Surrey, United Kingdom
Fax Fax: (714) 784-4343 Telephone: (44) (1276) 67 10 00
Fax: (44) (1276) 69 11 11
Munich, Germany Tokyo, Japan
Telephone: (49) (89) 43 19 87 0 Telephone: (81) (3) 3505 02 66
Fax: (49) (89) 43 61 71 6 Fax: (81) (3) 3505 09 14
Rome, Italy Paris, France
Telephone: (390) (6) 5 91 64 50 Telephone: (33) (1) 69 36 69 36
Fax: (390) (6) 5 91 25 05 Fax: (33) (1) 69 36 45 17
Moscow, Russia Gouda, The Netherlands
Telephone: (7) (095) 236 6177 Telephone: (31) (18) 2543700
Fax: (7) (095) 236 9762 Fax: (31) (18) 2543707
Madrid, Spain
Telephone: (34) (91) 5560919
Fax: (34) (91) 5567280
Main Index
vi
Email Send a detailed description of the problem to the email address below that corresponds to the
product you are using. You should receive an acknowledgement that your message was
received, followed by an email from one of our Technical Support Engineers.
MSC.Patran Support mscpatran.support@mscsoftware.com

MSC.Nastran Support mscnastran.support@mscsoftware.com
MSC.Nastran for Windows Support vn4w.support@mscsoftware.com
MSC.visualNastran Desktop 2D Support vn2d.support@mscsoftware.com
MSC.visualNastran Desktop 4D Support vndesktop.support@mscsoftware.com
MSC.Abaqus Support mscabaqus.support@mscsoftware.com
MSC.Dytran Support mscdytran.support@mscsoftware.com
MSC.Fatigue Support mscfatigue.support@mscsoftware.com
MSC.Interactive Physics Support ip.support@mscsoftware.com
MSC.Marc Support mscmarc.support@mscsoftware.com
MSC.Mvision Support mscmvision.support@mscsoftware.com
MSC.SuperForge Support mscsuperforge.support@mscsoftware.com
MSC Institute Course Information msctraining.support@mscsoftware.com
Training
The MSC Institute of Technology is the world's largest global supplier of
CAD/CAM/CAE/PDM training products and services for the product design, analysis and
manufacturing market. We offer over 100 courses through a global network of education
centers. The Institute is uniquely positioned to optimize your investment in design and
simulation software tools.
Our industry experienced expert staff is available to customize our course offerings to meet your
unique training requirements. For the most effective training, The Institute also offers many of
our courses at our customer's facilities.
The MSC Institute of Technology is located at:
2 MacArthur Place
Santa Ana, CA 92707
Phone: (800) 732-7211
Fax: (714) 784-4028
The Institute maintains state-of-the-art classroom facilities and individual computer graphics
laboratories at training centers throughout the world. All of our courses emphasize hands-on
computer laboratory work to facility skills development.
We specialize in customized training based on our evaluation of your design and simulation
processes, which yields courses that are geared to your business.
In addition to traditional instructor-led classes, we also offer video and DVD courses, interactive
multimedia training, web-based training, and a specialized instructor's program.
Course Information and Registration. For detailed course descriptions, schedule

information, and registration call the Training Specialist at (800) 732-7211 or visit
www.mscsoftware.com.
Main Index
CHAPTER vii
Preface
Internet Resources
MSC.Software (www.mscsoftware.com)
MSC.Software corporate site with information on the latest events, products and services for the
CAD/CAE/CAM marketplace.
Simulation Center (simulate.engineering-e.com)

Simulate Online. The Simulation Center provides all your simulation, FEA, and other
engineering tools over the Internet.
Engineering-e.com (www.engineering-e.com)
Engineering-e.com is the first virtual marketplace where clients can find engineering expertise,
and engineers can find the goods and services they need to do their job
MSC.Linux (www.mscsoftware.com/hpc)
Now with almost 40-years of unparalleled experience in scientific and technical computing,
MSC.Software is leveraging this knowledge to deliver its customers state-of-the-art, high
performance computing solutions based on clustered computing for running engineering and
life sciences applications.
CATIASOURCE (plm.mscsoftware.com)
Your SOURCE for Total Product Lifecycle Management Solutions.
Process Architecture Lab (PAL) (pal.mscsoftware.com/services/pal)

PAL is a virtual product development environment that enables PAL participants and
customers to define, validate, and demonstrate advanced tools, processes, and e-business
solutions.
Main Index
viii
Main Index
CHAPTER ix
Preface
Permission to Copy and Distribute MSC Documentation

If you wish to make copies of this documentation for distribution to co-workers, complete this
form and send it to MSC.Software Corporation. MSC will grant written permission if the
following conditions are met:
• All copyright notices must be included on all copies.
• Copies may be made only for fellow employees.
• No copies of this manual, or excerpts thereof, will be given to anyone who is not an
employee of the requesting company.
Please complete and mail to MSC for approval:

Attention: Legal Department
2 MacArthur Place
Santa Ana, CA 92707
Name:_____________________________________________________________
Title: ______________________________________________________________
Company: _________________________________________________________
Address:___________________________________________________________
__________________________________________________________________
Telephone:_________________Email: __________________________________
Signature:______________________________ Date: ______________________
Please do not write below this line.
APPROVED: MSC.Software Corporation
Name:_____________________________________________________________
Title: ______________________________________________________________
Signature:______________________________ Date: ______________________
Main Index
x
Fold here
_______________________
_______________________ Place
Stamp
_______________________ Here
Attention: Legal Department
2 MacArthur Place
Santa Ana, CA 92707
Fold here
Main Index
MSC.Acumen Author’s Guide
CHAPTER
Authoring MSC.Acumen Applications
1
■ Definitions
■ Product Overview
■ What is an MSC.Acumen Application?
■ Why an MSC.Acumen Application?

■ Principles for Effective Application Development
Main Index
2
1.1 Definitions
SGML - Standard Generalized Markup Language.
HTML - Hypertext Markup Language (a particular implementation of SGML).
XML - Extensible Markup Language, enhanced SGML implementation employing HTML-like
tags.
Tags - used in HTML and XML to identify elements according to their content and purpose. The
following is an XML tag:
<step stepid="2." stephelp="brakeparts/html/st2help.html">
For XML tag definitions, see <hypertext>XML Tag Definitions (p. 46).
For HTML tag definitions, see <hypertext>Supported HTML tags and options (p. 54).
Elements/Attributes - parts of a tag (in the above example, "step" is an element; "stepid" and
"stephelp" are attributes).
.png - portable network graphics file (replaces .gif).
Drive Page - a file (.xml) which scripts the work flow, sending control to sub-pages for common
or repetitive tasks.
State Table - persistent memory method of recording and retrieving information
acumen_drive_page_trans - a program that creates an indexed version (.xio) of drive pages
(.xml) for efficient reading by the platform software.
Automated Link Rules - used in the drive page to make automated hypertext-like links to the
correct starting HTML dialog for each step.
Step- A scripted analysis process is divided up into manageable units called “steps”.
MSC.Acumen provides a process control by presenting steps as defined by an expert author
through the XML <step> tags. Steps may have enforced prerequisites to their execution. A step
may hold the user captive in that part of the application until it is successfully completed.
Dialog- A new display event in the MSC.Acumen interface results from the transition to a new
“dialog”. A dialog always has a “mini web page” HTML display associated with it. The
philosophy of MSC.Acumen is that the interface is always talking to the user, giving clear
instructions about what to do next. A dialog event is encoded in XML through the <dialog> tag.
A step may have several dialogs. The author has available several logic processing operations
for controlling the transition between dialogs including the automated link rules.
Page- In the context of this document, the word “page” refers to a physical file as opposed to one
display event. A single drive page may contain several steps and many diaogs encoded in XML.
Therefore, from one XML page written by the author, numerous separate displays can be shown
on the user interface.
Main Index
CHAPTER 1 3
1.2 Product Overview

The original goal for developing MSC.Acumen was to make MSC.Patran usable for the novice
or occasional user. The MSC.Acumen environment makes that possible though its extreme ease
of use for the end user, based on the options and information presented by the author.
MSC.Acumen applications present a single form interface for the user. It limits the options
available to the user to only those provided by the author. The HTML display widget allows for
greater explanations at each step to help guide the user. The explanations can be written in a
language the end user understands, whether that is a foreign language such as Japanese, or the
terminology of a particular technical discipline such as that used in design of airplane wings.
The MSC.Acumen platform software allows for the capture of the expert’s knowledge and
methods. It has features built in allowing the author to enforce these expert methods and best
practices. The author is in control of the options presented to the user, and can use bitmap
pictures and text to help explain each step, all on the single user interface form. There are also
error checking and work-flow management capabilities available to keep the end user from
straying too far from the allowable design space.
With all of this control comes a responsibility. The author must provide the appropriate
knowledge and information to guide the end user. The author must provide all necessary
options for scenarios that the application might cover. The HTML text explanations are written
using terms the end user is familiar with. A great amount of trust is placed in application author
to insure that simulations performed by non-experts will result in the same fidelity and accuracy
that the dedicated experts provide. This requires a high level of professional practice for
MSC.Acumen authoring.
Typical File Structure for an MSC.Acumen Installation

To run an MSC.Acumen application, the user must have installed:
• A particular application (XML "drive pages" plus PCL automation functions in a
library)
• The MSC.Acumen run-time software (.plb libraries plus dynlib shared object library
plus initialization script that sets default environment variables)
• "Application Core" (MSC.Patran without the standard UI ) -or- full MSC.Patran as of
version-8.5, plus any solvers like MSC.Nastran, plus a commercial web browser like
Netscape or IE for any auxiliary information or help display.
The MSC.Patran or the alternative “Application Core” software that MSC.Acumen uses as
“middleware” is installed in a standard pre-defined location. The installation procedure for this
component is supplied with the MSC.Patran commercial software. The P3_HOME environment
variable is used to point to that installation path. The commercial web browser is installed in its
own standard location. Therefore, to accomplish a MSC.Acumen installation, certain additional
directory paths must be allocated for the core MSC.Acumen run-time software libraries, plus
separate directories to contain the particular vertical application.
The commercial MSC.Acumen delivery includes an “acumen_core” directory that contains the
core run-time software libraries, plus an example “brk_lvr” directory that contains all files
Main Index required for an example automotive park brake lever analysis application.
4
Core Run –Time Software Libraries Installation and File Structure

A suggested location for the core run-time software libraries is in an “acumen_core” directory
located parallel to the path defined by the P3_HOME environment variable. This means that a
system administrator with root privilege installs the run-time software in a new branch parallel
to the MSC.Patran installation.
Resident in the “acumen_core” directory are the following files:
• aa_init.pcl - Special initialization script for MSC.Patran that loads in the run-time
libraries
• aa_message_core.dat - External file of standard error messages. This file is available
for customizing to foreign languages, etc.
• aa_platform.plb - Library of core run-time functions to operate the user interface, state
table, drive page interpretation, etc.
• aa_uiprimary.plb - Library of core run-time functions to invoke the “single form drive
page interface” that replaces the primary interface form of MSC.Patran
Resident in the “/acumen_core/bin” directory are the following files:
• acumen_drive_page_trans.exe - Stand-alone executable to convert and index XML
“drive pages” for efficient processing by software. All new or modified drive pages
must go through this conversion function. A PCL call from within the MSC.Acumen
environment can also accomplish this. See the documentation for the
acumen_drive_page_trans (“filename.xml”, “filename.xio”) call in Chapter 8. Use of
the stand-alone executable is also documented there.
• acumen.dll - a dynamic linked library on Windows NT platforms or shared object files
like “acumen.so” on UNIX platforms. This is a library of compiled C-code functions
that are linked into the MSC.Patran executable at run-time. Most of the functions are
involved with XML drive page reading and interpreting.
Specific MSC.Acumen Applications Installation and File Structure

A particular MSC.Acumen application or suite of applications can be installed in any location.
For a large audience of users, installing on a machine with a mapped network drive is
recommended. On a NT network this drive could be labeled J: for example. The demonstration
brake lever application offers an example of application file structure. Say that it is installed on
J:\Acumen_Applications\brk_lvr. Opening up the “brk_lvr” folder, you will see local files plus
the “help” and “app_images” folders. The “help” folder contains local HTML web page
documents that are used for auxiliary information or help to each analysis step. An “images”
folder below contains the images for these web documents. The “app_images” folder contains
PNG format images that get displayed directly on the “single form drive page interface”. The
following file types are found in the “brk_lvr” or any particular application folder:
• .pcl type files - These are PCL automation function source files
• .plb file - This is the compiled library of PCL automation functions
Main Index • .def file - This is a PCL function call definitions file with “inputid” indexes that
correspond to references made on the XML drive pages
CHAPTER 1 5
• .dwn file - This is the MSC.Acumen pull-down labels file. This is used for invoking
MSC.Acumen in the “Authoring mode” where all of the standard MSC.Patran forms
are available along with the MSC.Acumen “single form drive page interface”. The
labels file allows for customizing with a foreign language.
• .labels file - This text file contains the labels that are displayed on the MSC.Acumen
“single form drive page interface”. This file allows for customizing with a foreign
language. It also allows a relative sizing control of the three main interface scroll boxes
(work flow manager, dialog, inputs) through changing two integer values.
• .xml files - These are the source “drive page” files that govern the process flow and user
interface display during the execution of an application.
• .xio files - These are the indexed or compiled version of .XML drive pages. They are
pre-processed by a special C-code function for purposes of efficient reading.
• .bat file - This is the “batch” script file that sets certain environment variables and then
invokes MSC.Patran or “Application Core” with the special “aa_init,pcl” initiation
script operating. The environment variables are described below. This .bat file must
be edited for any new installation to make all path descriptions consistent.
Run-Time Environment Variables Set by the Invoking Script File

Listed below is an example for the contents of the NT version .bat invoking script file.
set P3_HOME=c:\msc\patranv85
set ACUMEN_HOME=c:\msc\acumen_core
set ACUMEN_APPLICATIONS=c:\msc\brk_lvr\acumen_drive.xio
set ACUMEN_BROWSER=c:\ProgramFiles\Netscape\Communicator\Program\netscape.exe
set ACUMEN_INTERFACE=DISABLE
set HTML_IMAGE_PATH=c:\msc\brk_lvr\app_images
set ACUMEN_Y_SCALE=.95
c:\msc\patranv85\bin\patran -ifile c:\msc\acumen_core\aa_init.pcl
The final line of this file invokes the commercial MSC.Patran executable with the special
“aa_init.pcl” initialization script. The correct path to “init.pcl” in the core MSC.Acumen
run-time software installation must be specified.
The environment variable declarations that define file paths must also be edited to define those
paths correctly according to the installation. Following are descriptions for what the
environment variables are used for.
1. P3_HOME - This defines the installation path for commercial MSC.Patran or the
alternative “Application Core”.
2. ACUMEN_HOME - This defines the installation path for the core MSC.Acumen
run-time software libraries. Files such as “aa_platform.plb” and “aa_uiprimary.plb”
are located in this defined directory.
• Assumed file locations and names:
• All core .plb and status message files will be placed directly in the
Main Index
ACUMEN_HOME directory.
• It will be assumed that the status message file will have the name
“aa_message_core.dat”
• It will be assumed that the core shared libraries will be placed in the location
6
“ACUMEN_HOME”/lib for UNIX and “ACUMEN_HOME”/bin for

WINNT, allowing the location to be consistent with the rules currently used
by MSC.Patran.
• Default value.
• If the environment variable “ACUMEN_HOME” is not defined, the default
value of “P3_HOME” will be used. If “P3_HOME” is not defined,
“/patran/patran3” will be used for UNIX, “c:\msc” for WINNT.
3. ACUMEN_APPLICATIONS - This defines the complete path to the starting
(pre-processed) Step-1 XML drive page for the MSC.Acumen application. Note that
the Step-1 drive page can ask the user what type of simulation is desired and lead to
any possible home drive page for the subsequent steps.
• Assumed file locations and names:
• The Step-1 home drive page directory is determined from the
ACUMEN_APPLICATIONS environment variable. If the environment
variable is defined as c:/msc/brk_lvr/step1_drive.xio, then the Step-1
home drive page directory is c:/msc/brk_lvr.
• It will be assumed that the function definitions file (.def) will have the same
path and base file name as the home drive page with a .def extension.
• It will be assumed that the labels file will have the same path and base file
name as the home drive page with a .labels extension.
• It will be assumed that all .html help files will be in a subdirectory named
“help” under the home drive page directory.
• It will be assumed that the pulldown menu title definitions file will have the
same path and base file name as the home drive page with a .dwn extension.
• It will be assumed that the application specific .plb file will have the same
path and base file name as the home drive page with a .plb extension. If a
file with the specified extension cannot be found, no applicaton specific
.plb’s will be linked in.
• It will be assumed that application specific image files (.png) will be in a
subdirectory named “app_images” located under the home drive page
directory.
• Default value.
• If the environment variable ”ACUMEN_APPLICATIONS” is not defined,
the value of “ACUMEN_HOME/acumen_applications/master.xio” will be
used where “master” will be the default application name.
4. ACUMEN_BROWSER - This defines the invoke command for the desired commercial
web browser that is used to display auxiliary help or other documents.
5. ACUMEN_INTERFACE - This variable acts as user interface mode switch between the
“single form drive page interface” that is appropriate for novice users, and a display of
the full featured MSC.Patran user interface with the “single form drive page interface”
form as a pull-down option from the top-screen form. The full featured MSC.Patran
interface with the pull-down mode for running MSC.Acumen is very useful for
application authors. It allows a history window viewing for debugging, and
Main Index exploration of modeling progress through free-form MSC.Patran functionality. Note
that full commercial MSC.Patran is required for this option. The “Application Core”
alternative does not support this mode. The two settings for this variable are:
• DISABLE - Display the novice mode “single form drive page interface” only.
CHAPTER 1 7
• ENABLE - Display the full featured MSC.Patran interface with an

MSC.Acumen pull-down option.
6. HTML_IMAGE_PATH - This defines the path location to find the .PNG image format
files that are referenced on the XML drive pages and are displayed in the “Dialog” area
of the interface. Relative path references to PNG images will specify the location
relative to the path defined by HTML_IMAGE_PATH. For example, the image path
specified by <IMG SRC= "images/companylogo.png"> results in finding the
companylogo.png file in a images folder as a sub-directory to the environment variable
specified path.
7. ACUMEN_Y_SCALE - This environment variable is used to adjust the overall height
of the displayed MSC.Acumen form. The value can range from 0.5 to 1.5. This variable
provides an optional form scaling factor, and provides the user with a way to adjust the
vertical UI form height if needed.
The recommendation is to NOT explicitely set this ACUMEN_Y_SCALE environment
variable from the invoking script for most installation cases. This variable should only
be used to correct a form height display problem that obscures part of the form from
user access. On NT platforms, first check the display settings to make sure that the
desktop area is assigned the maximum number of display pixels, like 1280x1024 on
desktop monitors, or 1024x768 on laptops. The default MSC.Acumen software behavior
when ACUMEN_Y_SCALE is not explicitely set, is to apply a value of 0.95 times the
computed full screen height when the variable ACUMEN_INTERFACE is set to the
DISABLE mode. When ACUMEN_INTERFACE is set to the ENABLE mode, a factor of
1.1 times the computed full form height, as measured underneath the top-screen form,
is applied. If, for example, ACUMEN_Y_SCALE is explicitely set to 0.95 in the invoking
script, and then subsequently the script is changed by setting ACUMEN_INTERFACE
to ENABLE as opposed to DISABLE with no further adjustment to
ACUMEN_Y_SCALE, the UI form height will appear too small, and will be difficult to
work with.
8. ACUMEN_MOTIF - This environment variable needs to be set only when running
MSC.Acumen with V8.5 of MSC.Patran on Windows NT.
Main Index
8
1.3 What is an MSC.Acumen Application?

A finished MSC.Acumen application is a combination of XML and PCL that runs with the
platform software. It is an application which captures specific processes and presents only the
limited information necessary for completing the specific task at hand.
The XML elements that are made available by the MSC.Acumen platform software allow the
author to query the user for information, store that information and make logical decisions based
on that information. It is recommended that the author start with a process flow chart to help
facilitate the development of the XML drive page logic.
The PCL functions required for MSC.Acumen application development are comprised mostly of
function calls from interactive MSC.Patran session files. Some additional rudimentary PCL
programming knowledge is required to set up the functions and variables necessary. A good
review of this material can be found in the MSC.Patran help files, <hypertext>Basic Concepts
(p. 7) in the <emphasis>PCL and Customization.
Main Index
CHAPTER 1 9
1.4 Why an MSC.Acumen Application?

The fundamental business need that MSC.Acumen addresses is to improve product design
processes. Product simulation is required earlier in the design cycle in order to shorten cycle
time. A well written MSC.Acumen application makes it easy for anyone to run a simulation.
Thus, simulations can be performed early with rough design estimates. This enables the
designers to run more simulations earlier in the design process and identify poor designs earlier.
The simulation expert is then relieved of supporting the design cycle with this simulation and
able to focus on other more challenging analyses.
The MSC.Acumen Application enables novice users and design engineers to perform complex
simulation without training. The single user interface form (see below) can explain each task
necessary for a complex simulation using words the user will understand. The error checking
and logical decision making available will assure the application author that the user is within
the design space.
The MSC.Acumen application environment allows the author to capture and leverage
engineering process knowledge and simulation expertise throughout the enterprise. The author
can control the application to guarantee that the best practices they used to create the application
will be used every time the application is used.
Step Selection Box
Dialog Box
Inputs Box
Main Index
10
1.5 Principles for Effective Application Development

Authoring MSC.Acumen applications requires two distinct phases:
• The definition phase
• The implementation phase
Following are principles that apply to these two development phases.
DEFINITION PHASE:
1. Maximize application value per investment of authoring. Look at the business goal for
creating applications. We are generally seeking to reduce design cycle time and to
shorten the time-to-market for new products by moving product simulation into the
early design phases. When considering which applications to write, look at the
business case first. Choose first those applications that will enjoy frequent usage and
will impact the design process most.
2. Make sure that a thorough job is done in the definition phase. The user group has an
idea of what they want, but they also need some help at refining their goals and
specifying the best applications to improve the product design processes. They may not
have a clear idea of the options possible in MSC.Acumen solutions. An independent
look at the design process often results in ideas for improvement that are not obvious
to those using the existing process and conditioned to the process assumptions. The
independent observer challenges assumptions in order to understand the process.
3. The application author must learn the culture, relevant technology, definition of terms,
and units employed by the end users. The applications must deliver the knowledge
and methods of the simulation expert to non-expert simulators in terms that they can
understand. Authors must sometimes capture the expert methods of others and deliver
them through an application to the end users. Sufficient attention is required to capture
all methods and options with good fidelity.
4. Consider how the application fits into the design process as opposed to viewing it as
an isolated tool. Ask questions such as:
• Where does the input data come from?
• Where do output results data go, and how are they used?
• Is special results processing required? Would an HTML output report help the process
and documentation effort?
• What form of geometry data is available? Are process changes required to make more
suitable geometry data available?
• Would it better serve the design process to run a parameter driven idealized geometry
generation using native MSC.Patran constructions? The CAE evolved geometry is then
transmitted to CAD via AP203 export/import.
Answering these questions will suggest writing an application that reaches past its
FEA solution boundaries to better interface with the design process. Typically, a
significant amount of work should be given to special analysis results processing, and
exporting those processed results in a format that enhances the design and
Main Index
documentation process.
CHAPTER 1 11
5. Be sensitive to the needs of all affected by the work that you are doing. Change can be
disruptive and difficult, but can bring great value. Seek maximum benefit to the
organization. The simulation experts can become more effective by leveraging their
knowledge and methods into widely used applications. The design staff can increase
their efficiency by using the applications. Seek the win-win situations.
IMPLEMENTATION PHASE:
6. Start the implementation phase by creating a simulation process flow chart. The flow
chart is useful to insure that all important logical options or scenarios are considered.
Also, a flow chart helps to eliminate logical process errors. Currently we are
investigating the possibility for employing a flow charting software that will
automatically output a skeleton XML corresponding to the flow chart symbols used. A
XML editor loaded with the MSC.Acumen drive page DTD (Data Type Definition) will
be used to conveniently fill in drive page details.
7. Format the XML page with blank lines and comments so that it reads with visual ease.
Make the logical paths look obvious by spacing and naming. See the example brake
lever application drive page as a style guide, <hypertext>Example of a Home Drive
Page (Step 1) (p. 27).
8. Use terms and phrases that are familiar to the end user. Avoid specialized CAE jargon
and acronyms. Speak the language of the product designers who will use the
application.
9. Request data in the units and terms that are commonly available and familiar to the
users. Let the computer do the work of making conversions and combining terms. A
representative of the end users will best dictate what these terms and units are.
10. Try to represent all important logical branches on the XML drive pages in terms of
<lrule> branches, <dialog> tag attributes, <returnerror> branches, hypertext links, etc.
 as opposed to hiding them inside of PCL
functions.
11. In general, all HTML dialog displayed should come from <dialog> tags on the XML
drive pages. An exception is the dynamic dialog capability enabled by the
AAI.dynamic_next_dialog() call. The HTML can have a dynamic computed part
followed by a static part that is read from the drive page.
12. Never leave the user hanging with nowhere to go. You are dictating the scenario and
all options. Always display an HTML dialog that tells the user what to do next.
13. Plan for and schedule prototype testing and evaluation by representatives of the
application users. We recommend adapting the approach documented by the ASTM
E1340-96 rapid prototyping standard. This process validates the specification and the
software at major milestones to insure on-target development and to avoid
misconceptions, miscommunications, and unwanted surprises. The end users feel
included and become supportive and eager to adapt the developed applications.
Main Index
12
1.6 MSC.Acumen Data Flow Diagrams

General Dataflow
The diagram below represents at a high level how data flows through the MSC.Acumen
platform software. The specific knowledge and simulation methods of an expert are captured in
a work flow application in terms of XML drive pages and PCL automation functions.
• The platform software interprets the XML content and makes a display to the single
form interface.
• User interactions result in the launching of automation functions.
Main Index
CHAPTER 1 13
Detailed Data Flow

The diagram below provides more data flow detail. For clarity only the most basic flow paths
are diagrammed . Considering the memory State Table interactions for example, the AASTATE
class functions are called by virtually all system components.
• AAI class functions interpret the XML tags finding the appropriate HTML dialog
packet for display. They also invoke or set up for invocation PCL automation functions
referenced by the <dialog> tag attributes.
• AAUI class functions take care of display on the interface.
• The external function definitions file (xxx.def) provides the information required for
display of widgets in the Inputs Box, and for invoking of any PCL automation functions
requiring user inputs.
• All custom automation functions are compiled into the library. AANAV and
AACHECK are two function classes established for this purpose. Authors may add
others.
Main Index
14
Main Index
MSC..Acumen Author’s Guide
CHAPTER
Drive Pages
2
■ Drive Page Overview
■ Elements of a Drive Page
■ Drive Page Style Guide
■ How is PCL called from drive pages?

■ AANAV and AACHECK class functions
■ Philosophy of Drive Page vs. AANAV Class
■ Example of a Home Drive Page (Step 1)
■ Example of a Home Drive Page (Steps 2-n)
■ XML Tag Definitions
■ Supported HTML tags and options
Main Index
18
2.1 Drive Page Overview

MSC.Acumen Drive pages are a medium for scripting the work flow and important logical
options of a simulation sequence. The pages are informative as well as active. They convey
knowledge captured from the simulation expert and they automatically initiate actions
governed by automation functions that are referenced as tag attributes.
Drive pages are modular autonomous units containing their own logical sequences. “Home“
drive pages can send control to sub-pages for common repetitive or special tasks. This
de-centralized logic scheme follows the methodology of the Internet. Page-driven sequences can
scale to any simulation complexity. By contrast, a centralized rules-based KBE or inference
engine approach degrades in performance as rules are added. The rules based approach has
proven not to scale for CAE.
Standard Generalized Markup Language, or SGML, as established by ISO Standard 8879:1986 is
the “mother of all markup languages”. HTML is a particular implementation of the SGML
standard. Recently, Extensible Markup Language, or XML, was introduced to enhance the usage
of SGML. Essentially, XML is an SGML implementation employing HTML like tags. XML tags
can be invented for various purposes, but they must follow the familiar HTML syntax rules.
MSC.Acumen drive pages are written with certain defined XML tags to script a simulation work
flow. The <HTML> sub elements within <dialog> tags provide packets of text and graphics
information that are displayed to the user.
Main Index
CHAPTER 2 19
Drive Pages
2.2 Elements of a Drive Page

Extended HTML technology (XML) is employed to capture process knowledge.
Authoring analysis scenarios is similar to writing web pages.
No UI graphics programming is required.
The platform is flexible enough to handle any workflow scenario.
A drive page file name uses the extension .xml. The word “page” in this context refers to a
physical file. Several HTML dialog packets that are displayed separately by the MSC.Acumen
platform may exist on a single physical file “page”.
Element Relations
Home Drive Page (Step 1)
<advisor>
<defsteps>
<ds>
<Step>
<Uresponse>
<response>
<response>
<Dialog> <Dialog>
<HTML> <HTML>
</HTML> </HTML>
<Dialog> <Dialog>
<HTML> <HTML>
</HTML> </HTML>
Main Index
20
Page 1, as defined by the ACUMEN_APPLICATIONS environment variable, is the “Home

Page” physical XML file that contains the first analysis step only. This step opens up a database
and determines what type of analysis the user will perform. See <hypertext>Example of a Home
Drive Page (Step 1) (p. 27).
Depending upon the user’s response, the NEXTPAGE string variable (defined in the Step 1 drive
page) is stored to the State Table indicating the particular “Home Page” to use for steps 2
through n.
Home Drive Page (Steps 2 through n)
<advisor>
<defsteps>
<ds>
<ds>
<ds>
<Step> <Step>
<Uresponse> <Uresponse>
<response> <response>
<lrule> <lrule>
<lrule> <lrule>
<Dialog>
<HTML>
<Dialog>
<HTML>
<Dialog>
<HTML>
<Dialog>
<HTML>
</HTML> </HTML> </HTML> </HTML>
<Dialog> <Dialog> <Dialog> <Dialog>

<HTML> <HTML> <HTML> <HTML>
<Step> <Step>
<Uresponse> <Uresponse>
<lrule> <lrule>
<lrule> <lrule>
<Dialog> <Dialog> <Dialog> <Dialog>

<HTML> <HTML> <HTML> <HTML>
<Dialog>
<HTML>
<Dialog>
<HTML>
<Dialog>
<HTML>
<Dialog>
<HTML>
Main Index
This page uses the <defsteps> tag to define analysis steps 2 through n that are displayed in the
UI form step selection box. The home page must contain separate <step> tag entries
corresponding to all steps defined in the <defsteps> tag. These separate <step> tags may
possibly transfer control to other sub-pages. Sub-pages have independent <step> tags but do not
CHAPTER 2 21
Drive Pages
have <defsteps> tags. The Step-1 Home page and the Home page for Steps 2-n are the only two
pages (physical XML files) that use <defsteps> tags. See <hypertext>Example of a Home Drive
Page (Steps 2-n) (p. 30).
“Home Drive Page” versus sub pages
When the application user selects a step on the user interface form, or alternatively the
AAUI.switch-highlight (stepid) function is called for automated step selection, the software first
reads a “home drive page” XML file to find the corresponding <step> tag. Home drive pages are
where the processing of each analysis step starts.
<defsteps> tags to define the steps displayed on the user interface form are only valid and only
read from home drive pages.
Once the appropriate <step> tag is located on a home drive page, an automated link rule or a
hypertext link invoking the AAI.next_dialog ( ) function can transfer control to a sub page.
Going to a sub page is analogous to a gosub call in programming languages. <step> tags listed
on a sub page are independent of the <step> tags on home pages and may have completely
different IDs. <step> tag IDs from sub pages do not appear on the user interface step selection
panel.
PCL function calls are available to determine path names to the Step-1 home drive page and the
home drive page for all subsequent steps.
The Step-1 home drive page is defined by the environment variable
ACUMEN_APPLICATIONS. The pcl function aa_env.ret_acumen_app ( ) as documented in
Chapter 8 will return the Step-1 home drive page.
A relative path of the home drive page for Steps 2-n is defined by the user response string
variable “NEXTPAGE” stored under Step-1 in the state table. A PCL call to the state table
AASTATE.get_ur_string is used to obtain this relative path.
Main Index
22
2.3 Drive Page Style Guide

Place a <defsteps> tag at the top of the “Home Page” file. Each <ds> tag contained in the
<defsteps> should be on one line, and formatted so that each attribute lines up vertically.
<advisor>
<defsteps>
<ds stepid="2." steplabel="Acquire Geometry"> </ds>
<ds stepid="3." steplabel="Extract Surface(s)"> </ds>
<ds stepid="4." steplabel="Finite Element Mesh"> </ds>
<ds stepid="5." steplabel="Strut Reaction Constraint"> </ds>
<ds stepid="6." steplabel="Shaft Pivot Constraint"> </ds>
<ds stepid="7." steplabel="Cable Load"> </ds>
<ds stepid="8." steplabel="Analyze"> </ds>
<ds stepid="9." steplabel="Show Results"> </ds>
</defsteps>
A <step> tag for each stepid should follow in order. Place a comment at the top of each step to
clearly mark the beginning of the step tag.

<step stepid = "2."
stephelp = "helpdocs/st2help.html">
The first tag within the <step> tag should be the <uresponse> tag. Each <response> tag should
be on one line, and formatted so that each attribute lines up vertically.
<uresponse>
<response name="thickness" type="REAL"> </response>
<response name="complete" type="STRING" values="C,X" readonly>
</response>
<response name="geomsource" type="STRING" values="ug,express" readonly>
</response>
</uresponse>
The next tag within the <step> tag should be the <lrule> tags. Each ‘if’ should be indented, and
each body of the ‘if’ statement should be indented. Always end with an ‘else’ statement to
guarantee that the logic rule will send the program flow to a dialog or another <lrule>. Note that
<lrule> tags are optional.
<lrule ruleid="gchk">
if(step("8.").uresponse("Complete")=="C")
page(".").step("8.").dialog("exclude");
else if(step("3.").uresponse("complete")=="C")
page(".").step(".").dialog("doover");
else if(step("3.").uresponse("complete")=="X")
page(".").step(".").dialog("undostep");
page(".").step(".").dialog("extract");
else page(".").step(".").dialog("exclude");
</lrule>
Finally, the <step> tag can contain one or many <dialog> tags. Each attribute should be
Main Index indented. If a function attribute has more then one function, those should be indented to have
the ‘F’ start in the same column and should only have one function per line.
The <dialog> tags should be grouped in such a way that makes sense to someone trying to
follow the logic flow of the drive page.
CHAPTER 2 23
Drive Pages
<dialog dlgid="mesh"
inputid="lever_automesh"
quedlg=".#4.#st4ck1"
errordlg=".#4.#st4ck2"
initftn="F:ga_view_aa_set;R:0.;R:0.;R:0.;
F:gu_fit_view" >
Main Index
24
2.4 How is PCL called from drive pages?

There are several ways for drive pages to call PCL functions. In a <dialog> tag, certain attributes
can invoke PCL:
• inputid
• initftn
• queftn
• exitftn
For a full description of these dialog tag attributes, see <hypertext>Dialog Tag (p. 51).
The initftn PCL calls will be made before the body of the dialog is displayed in the Dialog Box.
When the user clicks on the Apply Inputs button, the value assigned to the inputid attribute is
found in the Function Definitions file [.def]. For instance, in the following example, the inputid
attribute is set to “readthickness” on the drive page.
<dialog dlgid="cad2"
inputid="readthickness"
...
</dialog>
There must be a corresponding *INPUTID entry in the Function Definitions file (xxx.def) which
sets up the parameters for the PCL function call which may or may not have the same name as
the *INPUTID name. In the example below, it does have the same name.
*INPUTID=readthickness
*CLASS=AANAV
*FUNCTION=readthickness
*DBOX=REAL,Type: Thickness,1,3.
...
This information is then used to call the PCL function “readthickness” which is defined in the
file AANAV.pcl.
FUNCTIONreadthickness(thick)
REAL thick
IF(thick < 1. || thick > 5. ) THEN
...
END FUNCTION
PCL calls reference the Function Definitions file for calls that require user inputs and
corresponding widgets display. When this execution is completed, the optional queftn
referenced PCL calls will be made. Finally, when the dialog is exited, the optional exitftn
referenced PCL calls will be made.
PCL calls with fixed call sequence arguments can also be invoked through user selection of
hypertext links. The MSC.Patran embedded HTML widget supports a particular syntax in HREF
attributes to anchors for PCL call invocation. See the <hypertext>AAI.html_calls (p. 135) for the
syntax and use of the AAI.html_calls function.
Main Index
CHAPTER 2 25
Drive Pages
2.5 AANAV and AACHECK class functions

AANAV.pcl and AACHECK.pcl are two files containing PCL functions which are called from
drive pages.
AANAV.pcl - contains functionality navigation functions.
AACHECK.pcl - contains progress checking functions.
The user may create new classes for applications, however all custom PCL gets compiled into
the automation functions library (.plb file).
Main Index
26
2.6 Philosophy of Drive Page vs. AANAV Class

Drive pages should contain enough information to show the logical flow from one dialog to the
next.
In general, avoid making calls to AAI.next_dialog() from within AANAV class PCL functions.
The reason for this is that following the logic flow of <dialog> tags will become difficult if logic
operations are hidden within PCL functions and not visible on the drive pages.
Make use of the available <dialog> tag attributes quedlg, errordlg and the <returnerror>
elements on drive pages, so that a reader can follow the logic scenario. Calls to AAI.next_dialog
listed on HREF hypertext links also enable following logic scenarios on drive pages.
Finally, use of blank line spacing and  can help delineate logic blocks
on drive pages.
Main Index
CHAPTER 2 27
Drive Pages
2.7 Example of a Home Drive Page (Step 1)

<advisor>

<defsteps>
<ds stepid="1." steplabel="Open Component Modeling Database"> </ds>
</defsteps>
<step stepid="1." stephelp="st1help.html" >
<uresponse>
</uresponse>
<lrule ruleid="reentry">
if (step(".").uresponse("Complete")=="C")
page(".").step(".").dialog("exclude");
else
page(".").step(".").dialog("start");
</lrule>
<dialog dlgid="exclude"
inputid="null"
initftn="F:AAUI.mainpanel_unselect_steps">
<HTML><BODY BGCOLOR="#FFFFFF">
Step-1: (Open Database) has already been completed.
If you would like to start over with a different database,
select the Quit button above.
 Otherwise, please select a
different step from above.</BODY></HTML>
</dialog>
<dialog dlgid="start"
inputid="null"
initftn="F:AAUI.mainpanel_lock_steps">
<CENTER>Brake Components Simulation Workflow</CENTER>
<TABLE WIDTH="342" HEIGHT="200" BORDER="0" CELLSPACING="2" CELLPADDING="0">
<TR>
<TD WIDTH="53%" HEIGHT="195"><IMG SRC="brakelogo.png"></TD>
<TD WIDTH="47%">Welcome to the automotive brake components simulation workflow
Main Index package.
These pages are maintained by the XXX Brakes Inc. Engineering Technology Center.
Please direct all technical questions or problem reports to the Tech. Center.
</TD></TR></TABLE>
Are you starting a new analysis model, or reopening an existing modeling database?
Please answer by selecting a hypertext below.
28
<ul>
<li><a HREF="PCL:AAI.html_calls(
FUNC:AAI.next_dialog;STR:step1_drive.xml;STR:1.;STR:new2)">New</a>
<li><a HREF="PCL:AAI.html_calls(
FUNC:AAI.next_dialog;STR:step1_drive.xml;STR:1.;STR:old2)">Existing</a>
<li><a HREF="PCL:AAI.html_calls(FUNC:AAUI.helpdoc_display;STR:st1help.html)">First,
help me</a> understand this step, and how the drive pages work.
</ul> </BODY></HTML>
</dialog>
<dialog dlgid="new2" inputid="new_db_open_nastranpref"

quedlg=".#.#new3" errordlg=".#.#new2err"
undo="F:uil_file_close.go">
<CENTER><IMG SRC="brakesinc.png"></CENTER>
Open a New Database:
Please type in a name for the new model database in the text box below.
Select the "Apply Inputs" 
button below after typing it in.
Note: MSC/PATRAN databases use the .db file name extension. 
Example Filename: levermodel1.db 
UNIX rules for file names apply. No blanks, double-byte, or special characters are
allowed.
</BODY></HTML>
</dialog>
<dialog dlgid="new2err" inputid="new_db_open_nastranpref"

quedlg=".#.#new3" errordlg=".#.#new2err"
undo="F:uil_file_close.go">
Error Condition:
The file name that you gave has blanks, special characters,
or represents an existing file. Please re-type a different name, and then select
"Apply Inputs".</BODY></HTML>
</dialog>
<dialog dlgid="new3" inputid="null">

Please select the component design that you will
evaluate:

Drum Brake Components:
<ol>
<li>Brake Shoe Substrate
<li>Shoe <a href="PCL:AAI.html_calls(
FUNC:AASTATE.record_ur_string;STR:nextpage;STR:parklever_drive.xml;
F:AAUI.mainpanel_unlock_steps;FUNC:AACHECK.step1_uchk;
FUNC:AANAV.step_wrapup;FUNC:AAI.allsteps_display)"> Park Brake Lever</a>
<li>Brake Drum
<li>Wheel Cyl. Housing
<li>Backing Plate
</ol>
Disk Brake Components:
Main Index <ol>
<li>Caliper Housing
<li>Caliper Piston
<li><a href="PCL:AAI.html_calls(
FUNC:AASTATE.record_ur_string;STR:nextpage;STR:rotor_drive.xml;
F:AAUI.mainpanel_unlock_steps;FUNC:AACHECK.step1_uchk;
CHAPTER 2 29
Drive Pages
FUNC:AANAV.step_wrapup;FUNC:AAI.allsteps_display)">Rotor</a> Thermal Dimensioning

<li>Pad Tension Spring
<li>Pad Retaining Pin
</ol>
Brake System Components:
<ol>
<li>Master Cyl. Housing
<li>Master Cyl. Piston
<li>Pedal Lever
<li>Pedal Bracket
</ol></BODY></HTML>
</dialog>
<dialog dlgid="old2" inputid="existing_db_open"

quedlg=".#.#st1ck1" errordlg=".#.#old2err"
queftn="F:AAUI.mainpanel_unlock_steps;
FUNC:AACHECK.step1_do_restore">
Please select the existing database from the available "Files" box below.
The selected file will appear in the "Selected File" box.
Next, select the "Apply Inputs" button.
Note that you can navigate through directories to find the database by
selecting a path in the "Directories" box and then selecting the "Filter"
button.</BODY></HTML>
</dialog>
<dialog dlgid="old2err"
inputid="existing_db_open"
quedlg=".#.#st1ck1" errordlg=".#.#old2err"
FUNC:AASTATE.restore_oldstate;
FUNC:AACHECK.step1_uchk"
exitftn="FUNC:AANAV.step_wrapup;FUNC:AAI.allsteps_display">
The database file selection was not valid.
Please select again from the "Files" box below, and then select "Apply Inputs".
Note that you can navigate through directories by
selecting a path in the "Directories" box and then selecting the "Filter"
button.</BODY></HTML>
</dialog>
<dialog dlgid="st1ck1" inputid="null">

This step is complete. Please select your next analysis step from the list
above.</BODY></HTML>
</dialog>
<dialog dlgid="st1ck2" inputid="null">

A MSC/PATRAN database was not opened. You must go back and repeat
step-1.</BODY></HTML>
Main Index </dialog>
</step>
</advisor>
30
2.8 Example of a Home Drive Page (Steps 2-n)
<advisor>

<defsteps>
<ds stepid="2." steplabel="Acquire Geometry"> </ds>
<ds stepid="3." steplabel="Extract Surface(s)"> </ds>
<ds stepid="4." steplabel="Build Simulation Model"> </ds>
<ds stepid="5." steplabel="Strut Reaction Constraint"> </ds>
<ds stepid="6." steplabel="Shaft Pivot Constraint"> </ds>
<ds stepid="7." steplabel="Cable Load"> </ds>
<ds stepid="8." steplabel="Evaluate"> </ds>
<ds stepid="9." steplabel="Show Results"> </ds>
</defsteps>

<uresponse>
<response name="thickness" type="REAL">
<response name="geomsource" type="STRING" values="ug,express" readonly>
</uresponse>
<lrule ruleid="reentry">
if (step(".").uresponse("Complete")=="C")
else
page(".").step(".").dialog("cad1");
</lrule>
inputid="null">
Step-2: (Acquire Geometry) has already been completed.
If you would like to start over with a different geometry file, select the
Quit button above.
Otherwise, please select a
different step from above.</BODY></HTML>
</dialog>
initftn="F:ga_group_create;STR:geometry;
F:ga_group_current_set;STR:geometry;"
inputid="null">
Acquire Geometry:
Geometry is obtained from CAD files for automotive brake components analysis.
Please indicate, by selecting the appropriate hypertext link, which type of CAD
Main Index file you will use.
<UL>
<LI><A
HREF="PCL:AAI.html_calls(FUNC:AAI.next_dialog;STR:parklever_drive.xml;STR:2.;ST
R:ug1;
FUNC:AASTATE.record_ur_string;STR:geomsource;STR:ug;
FUNC:AAUI.mainpanel_lock_steps)">
CHAPTER 2 31
Drive Pages
UNIGRAPHICS </A> part file ( xxxx.prt )

<LI><A
HREF="PCL:AAI.html_calls(FUNC:AAI.next_dialog;STR:parklever_drive.xml;STR:2.;ST
R:exp1;
FUNC:AASTATE.record_ur_string;STR:geomsource;STR:express;
FUNC:AAUI.mainpanel_lock_steps)">
EXPRESS </A> format neutral file ( xxxx.bxp )
</UL> </BODY></HTML>
</dialog>
<dialog dlgid="exp1"
initftn="F:AANAV.clear_geometry_group;"
inputid="express_bin_import"
quedlg=".#2.#cad2"
errordlg=".#2.#experror"
queftn="FUNC:ga_view_aa_set;R:0;R:19.;R:0"
undo="F:AANAV.remove_solids" >
EXPRESS neutral file import of a B-REP solid:
Please select the binary EXPRESS file (Example: brakelever.bxp) from the files
available below.
button below after selecting the file.
Note that you can navigate through directories by selecting in the "Directory
Lable" box and
then the filter button.</BODY></HTML>
</dialog>
<dialog dlgid="ug1"
initftn="F:AANAV.clear_geometry_group;"
inputid="ugimport_method1"
quedlg=".#2.#cad2"
errordlg=".#2.#ugerror"
queftn="FUNC:ga_view_aa_set;R:0;R:19.;R:0"
undo="F:AANAV.remove_solids" >
UG CAD geometry import of a B-REP solid:
Please select the CAD file (Example: brakelever.prt) from the files available
below.
Select the "Apply Inputs" button below after selecting the CAD file.
Note that you can navigate through directories by selecting in the directories
box and
then the filter button.</BODY></HTML>
</dialog>

errordlg=".#2.#badthick"
F:AACHECK.geom_imported" >
Input Thickness:
Please enter a value for the brake lever sheet metal thickness (millimeters) in
the box below.
Select "Apply Inputs" after
entering the value.</BODY></HTML>
Main Index </dialog>
<dialog dlgid="experror"
inputid="null" >
The CAD file name was either not selected or incorrect. Please try again.
32
<DL>
<DD><A HREF="PCL:AAI.html_calls(FUNC:AAI.next_dialog;STR:parklever_drive.xml;
STR:2.;STR:exp1)">OK</A>
</DL>
</dialog>
<dialog dlgid="ugerror"
inputid="null" >
The CAD file name was either not selected or incorrect. Please try again.
<DL>
<DD><A HREF="PCL:AAI.html_calls(FUNC:AAI.next_dialog;STR:parklever_drive.xml;
STR:2.;STR:ug1)">OK</A>
</DL>
</dialog>
<dialog dlgid="badthick"
errordlg=".#2.#badthick"
F:AACHECK.geom_imported" >
The thickness value input was not in a valid range. 
The thickness must be between 1. and 5. millimeters for a practical brake lever
design.
Please enter again a value for the thickness in the box below.
Select "Apply Inputs" after
entering the value.</BODY></HTML>
</dialog>
<dialog dlgid="gick1"
inputid="null" >
This step is complete. Please select your next step from the list
above.</BODY></HTML>
</dialog>
<dialog dlgid="gick2"
inputid="null" >
Geometry was NOT found in your database. You must go back and repeat the
geometry acquisition step.</BODY></HTML>
</dialog>
</step>

<uresponse>
Main Index </uresponse>

<lrule ruleid="gchk">
CHAPTER 2 33
Drive Pages
page(".").step(".").dialog("extract");
</lrule>
inputid="null" >
Step-2: (Acquire Geometry) was not completed.

You must successfully complete step-2 before performing this step. 
Please select step-2 above.</BODY></HTML>
</dialog>
<dialog dlgid="doover"
inputid="null" >
Step-3: (Extract Surface(s)) has already been completed.
<UL><LI>
<A HREF="PCL:AAI.html_calls(FUNC:AAI.next_dialog;STR:parklever_drive.xml;
STR:3.;STR:undostep)">
Continuing</A> with this step also requires redoing steps 4-7 if they have been
completed
<LI>
 Otherwise select a different step
from above.
</UL>
</dialog>
<dialog dlgid="undostep"
inputid="null"
initftn="F:AANAV.change_C_to_X;STR:4.;
F:AANAV.change_C_to_X;STR:5.;
F:AASTATE.record_ur_string;STR:complete;STR:X;
F:AAUI.mainpanel_step_complete;STR:3.;STR:X;
F:AAUI.mainpanel_lock_steps;
F:AANAV.lever_step_3_undo;
F:ga_view_aa_set;R:0;R:19.;R:0;
F:gu_fit_view;
F:AAI.next_dialog;STR:parklever_drive.xml;STR:3.;STR:extract" >
<HTML></HTML>
</dialog>

<dialog dlgid="extract"
inputid="extract_face"
Main Index initftn="F:AANAV.lever_post_only_geometry;
"
queftn= "F:ga_view_aa_set;R:0.;R:0.;R:0.;
F:gu_fit_view;" >
<returnerror retvalue="2" retdlg=".#3.#allfaces">
Pick a Surface:
34
Please screen pick the outside surface face or faces representing a planform
view of the design.
Your selection will be used to construct a 2-dimensional model.
You may select multiple faces of a complex design by holding the shift key
down.
Finally, select the "Apply Inputs" 
button.
<CENTER><img src="pickface.png"></CENTER></BODY></HTML>
</dialog>

<dialog dlgid="st3ck1"
inputid="null"
initftn="F:AAUI.mainpanel_unlock_steps;
FUNC:AASTATE.record_ur_string;STR:complete;STR:C;
FUNC:AAUI.mainpanel_step_complete;STR:3.;STR:C;
FUNC:AANAV.step_wrapup">
</dialog>

<dialog dlgid="allfaces"
inputid="null" >
You have selected too many faces to represent a 2-D model of the lever.
A common error is to select ALL faces.
You must <A
HREF="PCL:AAI.html_calls(FUNC:AAI.next_dialog;STR:parklever_drive.xml;
REDO the surface selection.</A>
</dialog>
inputid="null"
FUNC:AASTATE.record_ur_string;STR:complete;STR:X;
FUNC:AAUI.mainpanel_step_complete;STR:3.;STR:X;
Surface extraction failed. Your screen selections may have not been valid.
You may try and repeat this step.</BODY></HTML>
</dialog>
</step>

<uresponse>
Main Index <response name="complete" type="STRING" values="C,X" readonly>
</uresponse>

You must first have Extracted surfaces before building the model.
CHAPTER 2 35
Drive Pages
<lrule ruleid="surfck">
else if(step("3.").uresponse("complete")!="C")
else page(".").step(".").dialog("mesh");
</lrule>
inputid="null" >
Step-3: (Extract Surface(s)) was not completed.
You must successfully complete step-3. before performing this step.
Please select step-3. above.</BODY></HTML>
</dialog>
inputid="null" >
Step-4: (Build Simulation Model) has already been completed.
<UL><LI>
Continuing</A> with this step also requires redoing steps 5-7 if they have been
completed
<LI>
from above.
</UL>
</dialog>
inputid="null"
initftn="F:AANAV.change_C_to_X;STR:5.;
F:AASTATE.record_ur_string;STR:complete;STR:X;
F:AAI.next_dialog;STR:parklever_drive.xml;STR:4.;STR:mesh" >
<HTML></HTML>
</dialog>
<dialog dlgid="mesh"
inputid="lever_automesh"
initftn="F:ga_view_aa_set;R:0.;R:0.;R:0.;
F:gu_fit_view" >
<CENTER><img src="seededges.png"></CENTER>
Identify strut and cable areas:
Main Index Please identify by screen picks, two particular edges of the lever geometry.
See the example image above.
<OL>
<LI>
Select the first box below, then
screen pick the edge where a strut reacts against the lever.
<LI>
36
Select the second box, then screen

pick the curved edge where the cable applies load to the lever.
</OL>
Finally, select the "Apply Inputs"
button when finished.
Model building will proceed automatically. 
</BODY></HTML>
</dialog>

inputid="null"
</dialog>
inputid="null"
Model building failed. Your selection of edges may have been incorrect.
You may select and perform this step again. </BODY></HTML>
</dialog>
</step>

<uresponse>
<response name="loadaxis" type="INTEGER">
</uresponse>

<lrule ruleid="meshck">
Main Index else page(".").step(".").dialog("strut1");
</lrule>
inputid="null" >
Step-4: (Build Simulation Model) was not completed.
CHAPTER 2 37
Drive Pages
</dialog>
inputid="null" >
Step-5: (Strut Reaction Constraint) has already been completed.
<UL><LI>
Continue</A> with this step
<LI>
from above.
</UL>
</dialog>
inputid="null"
initftn="F:AASTATE.record_ur_string;STR:complete;STR:X;
F:AAI.next_dialog;STR:parklever_drive.xml;STR:5.;STR:strut1" >
<HTML></HTML>
</dialog>
<dialog dlgid="strut1"
inputid="lever_strut"
initftn="F:AASTATE.record_ur_integer;STR:loadaxis;INT:1;
F:AANAV.lever_zoom_in" >
Pick Strut Reaction Point:
Please select on the graphics screen, a point representing where the strut
reacts.
See the example image below.
Finally, select the "Apply Inputs"
button. 
<CENTER><img src="strutpt.png"></CENTER></BODY></HTML>
</dialog>
inputid = "null"
</dialog>
inputid = "null"
Main Index FUNC:AASTATE.record_ur_string;STR:complete;STR:X;
This step failed. The screen picking must not have worked. Please try the step
again.</BODY></HTML>
38
</dialog>
</step>

<uresponse>
</uresponse>

<lrule ruleid="femck">
else page(".").step(".").dialog("shaft1");
</lrule>
inputid="null" >
</dialog>
inputid="null">
Step-6: (Shaft Pivot Constraint) has already been completed.
<UL><LI>
<LI>
from above.
</UL>
</dialog>
inputid="null"
F:AAI.next_dialog;STR:parklever_drive.xml;STR:6.;STR:shaft1" >
Main Index <HTML></HTML>
</dialog>
<dialog dlgid="shaft1"
inputid="cyl_coord_in_circle"
quedlg=".#6.#shaft2"
errordlg=".#6.#cylerror"
CHAPTER 2 39
Drive Pages
initftn="F:AANAV.lever_zoom_in;
F:AAUI.mainpanel_lock_steps;" >
Establish Cylindrical Coordinates for Pivot Action:
Please screen pick the circular geometry edge(s) representing the circumference
of the shaft hole.
You may drag a box just around the hole to perform this selection.
See the example image below.
Finally, select the "Apply Inputs" 
button. 
<CENTER><img src="pickcircle.png"></CENTER></BODY></HTML>
</dialog>
<dialog dlgid="cylerror"
inputid="null" >
The circular edge(s) screen pick was either not selected or incorrect. Please
try again.
<DL>
<DD>
STR:6.;STR:shaft1)">OK</A>
</DL>
</dialog>
inputid="null" >
Approximation for Points to Constrain:
This shaft pivot simulation is an approximation.
Note that the shaft contacts only a portion of the hole in compression.
A better shaft contact simulation requires a nonlinear simulation using special
gap elements.
You are invited however, to use your judgement and to specify the points that
react in compresion against the shaft.
How do you want to constrain points?
<UL> <LI>
Constrain <A HREF="PCL:AAI.html_calls(FUNC:AANAV.shaft_pivot_allconstr)"> all
points </A>
on the hole circumference.
<LI>
Select <A
STR:6.;STR:shaft3;)"> particular </A> node points to constrain.
</UL></BODY></HTML>
</dialog>
inputid="shaft_pivot_constr"
initftn="F:AANAV.lever_zoom_in" >
Constrain Specific Points:

Please screen pick the points to constrain as reacting against the shaft.
Main Index Hold the shift key down to make successive picks.
button when all desired points are listed in the box below.
</dialog>
40
inputid="null"
</dialog>
inputid="null"
The shaft pivot constraint application failed. Please repeat this
step.</BODY></HTML>
</dialog>
inputid="null" >
You must select and constrain more then one point to obtain a valid
solution. 
Please choose again:
<UL> <LI>
Constrain <A HREF="PCL:AAI.html_calls(FUNC:AANAV.shaft_pivot_allconstr)"> all
points </A>
on the hole circumference.
<LI>
Select <A
STR:6.;STR:shaft3;)"> particular </A> node points to constrain.
</UL>
</dialog>
</step>

<uresponse>
</uresponse>

<lrule ruleid="femck">
Main Index page(".").step(".").dialog("exclude");
else page(".").step(".").dialog("cable1");
</lrule>
CHAPTER 2 41
Drive Pages
inputid="null">
</dialog>
inputid="null" >
Step-7: (Cable Load) has already been completed.
<UL><LI>
<LI>
from above.
</UL>
</dialog>
inputid="null"
F:AAI.next_dialog;STR:parklever_drive.xml;STR:7.;STR:cable1" >
<HTML></HTML>
</dialog>
<dialog dlgid="cable1"
inputid="lever_cable_load"
initftn="F:AANAV.lever_zoom_in" >
<CENTER><img src="cablept.png"></CENTER>
Apply the Cable Loading:
Please use the boxes below to specify the cable loading.
The image above shows an example -2220 Newton load application.
<OL> <LI>
Select the first box and then screen pick the load application point.
<LI>
Type X,Y,Z force components (Newtons) into the following three boxes.
<LI>
Select the "Apply Inputs" button
when all inputs are ready.
</OL>
Please take note and use the appropriate sign for component values.
For example, a negative X-component pulls towards the left. 
</dialog>
inputid="null"
Main Index initftn="F:AAUI.mainpanel_unlock_steps;
42
</dialog>
inputid="null"
This step failed. Note that a valid cable total load must be between 1000. and
3000. Newtons. The out-of-plane components must be less than 25% of the in-plane
value.
Please try this step again with new inputs. </BODY></HTML>
</dialog>
</step>

<step stepid="8." >
<uresponse>
</uresponse>

<lrule ruleid="sudam">
if(step("5.").uresponse("complete")!="C")
page(".").step(".").dialog("finish5");
else if(step(".").uresponse("Complete")=="C")
else
page(".").step(".").dialog("submit");
</lrule>
initftn="F:AAUI.mainpanel_unselect_steps;"
inputid="null" >
Step-8: (Evaluate) has already been completed.
Making model changes now is not allowed because this application is written as
a design check
procedure as opposed to an iterative design application. 
If you wish start over with a different database, select the Quit button above.
 Otherwise, please select step 9
(Show Results) from above.</BODY></HTML>
</dialog>
<dialog dlgid="finish5"
inputid="null" >
Main Index <HTML><BODY BGCOLOR="#FFFFFF">
Step-5: (Strut Reaction Constraint) was not
completed.
You must successfully complete steps 5.,6., and 7. before performing this
step.
</dialog>
CHAPTER 2 43
Drive Pages
inputid="null" >
Step-6: (Shaft Pivot Constraint) was not completed.
step.
</dialog>
inputid="null" >
Step-7: (Cable Load) was not completed.
step.
</dialog>
<dialog dlgid="submit"
inputid="null" >
Job Submittal:
This step will submit the model to a MSC/NASTRAN batch process for solution,
and then automatically read in the results.
Please select the "GO" hypertext link below to start the solution sequence.
<DL>
<DD><A HREF="PCL:AAI.html_calls(F:gu_fit_view;
F:AAI.next_dialog;STR:parklever_drive.xml;STR:8.;STR:st8mon;
F:AANAV.lever_submit)">
GO</A>
</DL>
</dialog>
<dialog dlgid="st8mon"
inputid="null" >
Please Wait. The analysis is running.
If you have the Analysis Manager software installed on your machine,
then you can follow the job progress by observing the pop-up form.
When you observe the job finish, you must dismiss the pop-up form with the
"Close" button.
</dialog>
inputid="null"
This step is complete. Please select the final results display step from the
list above.</BODY></HTML>
</dialog>
inputid="null"
Main Index initftn="F:AAUI.mainpanel_unlock_steps;
Simulation Results were NOT successfully read back into the database. 
44
If you closed the "Analysis Manager" pop-up window and aborted the run, then
you must redo this step.
You cannot continue on and display results until you have a successful
simulation sequence.
If your direct actions did not cause the failure, please contact your system
administrator to check your MSC/NASTRAN installation.</BODY></HTML>
</dialog>
<dialog dlgid="st8done"
inputid="null" >
This Step has already been completed before. 
The automated analysis submittal is not allowed for a second
time.</BODY></HTML>
</dialog>
<dialog dlgid="nodb"
inputid="null" >
No database was found open. You are advised to quit and to start over.
</dialog>
</step>

<step stepid="9." >
<uresponse>
</uresponse>

You must first have performed the analysis and read in the results.
<lrule ruleid="achk">
if(step("8.").uresponse("complete")=="C")
page(".").step(".").dialog("results");
</lrule>
inputid="null" >
Step-8: (Evaluate) was not completed.
You must successfully run the simulation before performing this step.
Please select step-8 above.</BODY></HTML>
</dialog>
<dialog dlgid="results"
inputid="null" >
Results Display:
Please select the type of results display desired.
Main Index <UL>
<LI><A HREF="PCL:AAI.html_calls(FUNC:AANAV.lever_results;INT:1)">
Exaggerated </A> deformed shape.
<LI><A HREF="PCL:AAI.html_calls(FUNC:AANAV.lever_results;INT:2)">
Animation </A> of exaggerated deformation.
<LI>Von Mises <A HREF="PCL:AAI.html_calls(FUNC:AANAV.lever_results;INT:3)">
stress fringe plot.</A> 
CHAPTER 2 45
Drive Pages
<LI>I'm <A
HREF="PCL:AAI.html_calls(FUNC:AAUI.mainpanel_step_complete;STR:9.;STR:C;
FUNC:AANAV.step_wrapup;
FUNC:AAI.next_dialog;STR:parklever_drive.xml;STR:9.;STR:st9ck1)">
all finished </A> with displaying results.
</UL></BODY></HTML>
</dialog>
inputid="null" >
<HTML><BODY BGCOLOR="#FFFFFF">Good Bye.
You may close down by selecting the "Quit" button on the top of this form.
</dialog>
</step>
</advisor>
Main Index
46
2.9 XML Tag Definitions

The Acronym XML stands for Extensible Markup Language. The World Wide Web Consortium
(W3C) announced on February 10, 1998 the XML 1.0 specification as the first Recommendation
for the Extensible Markup Language, a system for defining, validating, and sharing document
formats on the Web.
The W3C press release can be viewed at:
http://www.w3.org/Press/1998/XML10-REC.html
XML was created and developed by the W3C XML Working Group, which includes key
industry players such as Adobe, ArborText, DataChannel, Inso, Hewlett-Packard, Isogen,
Microsoft, NCSA, Netscape, SoftQuad, Sun Microsystems, Texcel, Vignette, and Fuji Xerox; as
well as experts in structured documents and electronic publishing.
The motivation for developing XML was to overcome limitations experienced with the defined
HTML markup tags. Essentially, XML allows the author to define markup tags for special
purposes as long as those tags conform to certain HTML syntax conventions. The W3C press
release states the following; "XML is primarily intended to meet the requirements of large-scale
Web content providers for industry-specific markup, vendor-neutral data exchange,
media-independent publishing, one-on-one marketing, workflow management in collaborative
authoring environments, and the processing of Web documents by intelligent clients. It is also
expected to find use in metadata applications. XML is fully internationalized for both European
and Asian languages, with all conforming processors required to support the Unicode character
set. The language is designed for the quickest possible client-side processing consistent with its
primary purpose as an electronic publishing and data interchange format."
The XML tags defined for the MSC.Acumen "drive pages" are used to describe a simulation
process work flow. Tags such as <defsteps>, <step>, <lrule>, and <dialog> describe the various
steps of the process, the logic to follow for finding the first display dialog in a step, and the
various dialog displays for each step. A <dialog> tag may contain attributes defining PCL
functions to invoke. The actual HTML packet displayed for each dialog is listed as an <HTML>
sub element to each <dialog>. This represents a powerful use of XML. Not only does it capture
process knowledge in documentation form, it serves to actively drive and control the process.
Advisor Tag
<advisor>
Description:
Advisor is the top level element and contains optional defsteps and one or more step
elements. All drive pages are delimited by <advisor> and </advisor> tags.
Elements:
<defsteps> Optional
<step> Required
Main Index
CHAPTER 2 47
Drive Pages
Remarks:
<defsteps> elements are only made use of on the “Home” Step-1 and “nextpage” drive pages.
The Step-1 drive page is defined by the ACUMEN_APPLICATIONS environment variable. The
“nextpage” home drive page for steps 2-n is defined by the NEXTPAGE string user response
variable stored in the State Table during the execution of Step-1.
Example:
None
Defsteps Tag
<defsteps>
Description:
Defsteps contain one or more ds elements.
Elements:
<ds> Required One or more <ds> tags are required to define the steps.
Remarks:
<defsteps> elements appear on “Home” “Step-1” or “Nextpage” drive pages only.
Example:
<defsteps>
<ds stepid=”2.” steplabel = “Acquire Geometry” > </ds>
<ds stepid=”3.” steplabel = “Geometry Check, Repair” > </ds>
<ds stepid=”4.” steplabel = “Geometry Idealization” > </ds>
...
</defsteps>
Ds Tag
<ds>
Description
<ds> elements define the IDs and descriptions for analysis steps that will appear in the UI form
main step selection box.
Attributes:
stepid Required
steplabel Required
Remarks:
<ds> elements are only included within <defsteps> and </defsteps> tags.
Main Index
Example:
See example for <defsteps>.
48
Step Tag
<step>
Description:
<step> tags are used to contain the work flow description of each defined step of the
process
Attributes:
stepid Required
stephelp Implied
Elements:
<uresponse> Required
<lrule> Optional
<dialog> Optional
Remarks:
<step> tags corresponding to each step ID defined in the <defsteps> list must exist on the same
“Home” drive page. Automated link rules <lrule> or other next_dialog calls can transfer control
to sub-pages. Sub-pages are separate physical files. A “page” in this context refers to a physical
file. <step> tags must also exist on sub-pages. The step IDs used on sub-pages are arbitrary and
can differ from the IDs on the “Home” page.
The stephelp attribute to the <step> tag can reference either a local file (relative or absolute path)
or a http address. For relative path references, the home drive page directory defined by the
environment variable ACUMEN_APPLICATIONS is appended onto the beginning of the
relative path.
IMPORTANT: because of parsing issues, the format for http references needs to be
“http_//www....” instead of http://www....”.
Example of a relative path for stephelp:
<step stepid = “2.” stephelp = “helpdocs/st2help.html”>

<uresponse>
<response name =”thickness” type=”REAL”> </response>
<response name =”complete” type=”STRING” values=”C,X” readonly> </response>
<response name =”geomsource” type=”STRING” vlaues=ug,express” readonly>
</response>
</uresponse>
...
</step>
Example of an absolute path for stephelp:

Main Index <step stepid = “2.” stephelp = “d:/testing/step_test/helpdocs/st2help.html”>
...
</step>
CHAPTER 2 49
Drive Pages
Example of a web address for stephelp:

<step stepid = “2.” stephelp = “http_//www.macsch.com/helpdocs/st2help.html”>
...
</step>
UresponseTag
<uresponse>
Description:
Establishes a set of variables for each step tag to support the “Quick Review” functionality.
Elements:
<response> Optional A uresponse tag may contain zero to many response tags.
The response tag declares a user reponse variable as stored
in the State Table to display on the Quick Review form.
Remarks:
All user response variables that are utilized in automated link rules (within <1rule> tags) must
be listed in the <uresponse> tags.
This tag supports the “Quick Review” functionality. Note that variables may be stored in the
State Table with out listing them in <uresponse> tags.
Example:
<uresponse>
<response
name = “geomsource”
type = “STRING”
values = “ug,catia,proe”> </response>
<response
name = “thickness”
type = “REAL”> </response>
<response
name = “complete”
type = “STRING”
values = “C,X”
readonly = “yes”> </response>
</uresponse>
Main Index
50
Response Tag
<response>
Description:
The response tag is associated with a <uresponse> tag. It defines variables to display for
the “Quick Review” functionality.
Attributes:
NAME Required Name of the variable.
TYPE Required The type of the variable, which must be scalar: STRING,
REAL, INTEGER
VALUES Implied If the type is STRING, a list of values is required, separated
by comma delimiters.
READONLY Optional This attribute will prevent the user from making value
changes with the Quick Review functionality.
Remarks:
None.
Example:
See example for <uresponse>.
Lrule Tag
<lrule>
Description:
Automated Link Rules are used to allow the drive page interpreter to make automated
selections of hypertext like links and locate the correct initial dialog packet for an analysis
step.
Attributes:
ruleid Required An identifying rule ID, 8 characters maximum.
Remarks:
The only boolean operators allowed are == and !=. The current implementation does not allow
for nested IF statements, or logical operators AND or OR. Note that AND or OR logic operations
are accomplished by the IF conditional in one <lrule> block giving the destination address as
another <lrule>.
The only statements that are allowed to follow the first IF are: an address statement
page(“XXX”).step(“XXX”).dialog(“XXX”); an ELSE IF statement; or an ELSE statement. There
can be any number of ELSE IF statements.
Main Index
If a boolean match is NOT found for a link rule, the control drops down to the next <lrule> tag
or <dialog> tag found below for this step on this page.
CHAPTER 2 51
Drive Pages
Each full address destination consists of three fields. The first address field (page) is an XML
drive page file name. A file name or a full page name is allowed. The home drive page directory
as defined by the enviroment variable ACUMEN_APPLICATIONS is appended to the front of
the filename unless a slash (/) is the first character of the field. A period (“.”) is an acceptable
filename which stands for “this page” (the current drive page that contains the link rule). The
second address field (step) is a 4 character maximum step ID. A period (“.”) is also an acceptable
step ID entry which means “this step”. The third field (lrule or dialog) is a link rule or dialog
address of 8 characters maximum.
All state table variables listed in logic operations within <lrule> tags must also be listed in
<response> sub-elements to the <uresponse> tags for the respective steps. This allows the
automated link rule interpreter to determine the variable type that is used in the logic operation.
Example:
<lrule ruleid=”tagid1”>
if (step(“stepid1”).uresponse(“varname1”) == “somevalue”)
page ( “filepath”).step(“stepid2”).lrule(“tagid2”);
else if ( step(“stepid1”).uresponse(“varname2”) != 4)
page ( “filepath”).step(“stepid3”).dialog(“tagid3”);
else page(“filepath2”).step(“stepid4”).dialog(“tagid4”);
</lrule>
Dialog Tag
<dialog>
Description:
The dialog tag has required and optional attributes which support an enhanced UI
functionality. All character data assigned to attributes are delimited by quotes (“). The attribute
declarations are NOT separated by a comma delimiter. The attributes for a dialog tag can be in
any order.
Attributes:
dlgid Required The dialog id. 8 character maximum.
inputid Required The PCL Function Definitions file look up ID associated with this
dialog. 32 character maximum. An assigned value of “null” denotes
that no “Inputs Box” functionality is used, and no widgets for user
interaction will be displayed.
quedlg Optional This is the address of a queued dialog to be displayed in the “Dialog
Box” after the Apply Inputs button is selected and after the
associated “Inputs Box” referenced PCL functions are executed. The
address consists of three fields: 1) the page file, 2) the step ID, 3) the
dialog ID. Note that the # is the delimiter. A dot (.) indicates “this
one”. For example “.#.#next_dia” would indicate this file, this step,
next_dia dialog. Note that if inputid = “null” then this attribute is
not used.
errordlg Optional This is the address of a queued error message to display in the
“Dialog Box” in the case input function returns an error code after
Main Index
the “Apply Inputs” button is selected. The address consists of three
fields: 1) the page file, 2) the step ID, 3) the dialog ID. Note that the #
is the delimiter. A dot (.) indicates “this one”. For example
“.#.#errormsg” would indicate this file, this step, errormsg dialog.
52
initftn Optional This attribute is set equal to a character string representing any
number of requested PCL function calls with fixed value arguments.
The PCL calls requested by the tag are dialog precursor calls made
at the time the new dialog is displayed in the “Dialog Box”.
queftn Optional This attribute is set equal to a character string representing any
number of queued PCL function calls with fixed value arguments.
The PCL calls requested by the tag are executed after calls made by
the “Inputs Box” referenced function.
NOTE: if inputid = “null” then this attribute is not used.
NOTE: two conditions are necessary for calls under this to be
invoked; (1) inputid must not be = “null”, (2) the PCL function call
specified by inputid must return a success status, or no status
checking is called for.
exitftn Optional This attribute is set equal to a character string representing any
The PCL calls requested by the tag are executed right at the time the
dialog is exited from the “Dialog Box”.
NOTE: even if inputid=”null”, this attribute is still used. Function
calls listed under this attribute are invoked regardless of success or
failure status from any inputid listed calls.
undo Optional This attribute is set equal to a character string representing any
The PCL calls requested by the tag are executed when the user hits
the “Dialog Backup” button, and this <dialog> is displayed as a
result.
Elements:
<returnerror> Optional This element will override the errdlg attribute and more precisely
handle various return value conditions.
<HTML> Required This element will provide a text and/or graphics display to the UI
form “Dialog Box”.
Remarks:
The <returnerror> element is allowed within <dialog> tags.
Main Index
CHAPTER 2 53
Drive Pages
Example:
<dialog dlgid = “start”

inputid = “ugfileopen”
quedlg = “.#2.#ug2”
errordlg = “errors/ugimport.xml#stp1#err1”
initftn = “FUNC:gu_fit_view”
queftn = “F:AASTATE.record_ur_string;STR:geomsource;STR:ug;
F:AACHECK.nas101_st2;
F:AANAV.step_wrapup;”
exitftn = “F:ga_view+aa+set;R:30;R:30;R:0
undo = “F:AANAV.undo_ugfile”>
<returnerror
retvalue=1
retdlg = “.#2.#er1”>
<returnerror
retvalue=2
retdlg = “.#2.#er2”>
<HTML
Please select the CAD file from the list below.
</HTML>
</dialog>
Returnerror Tag
<returnerror>
Description:
This sub element to the <dialog> tag provides a precise way to handle different return
conditions from the execution of a PCL function associated with the “Inputs Box” functionality.
A non-zero return directs display of different dialogs depending upon the return value.
Attributes:
retvalue Required Possible integer return value from the referenced PCL function
retdlg Required Address of the <dialog> to display for this return value.
Remarks:
Any number of <returnerror> elements can be listed for the various integer return values. If the
return value is a non-zero value not covered by <returnerror> elements then the <dialog>
referenced by the errordlg attribute of the current <dialog> will be displayed. If no errordlg
attribute was listed in this case, then a default platform software supplied error message is
displayed.
Example:
See <dialog> example.
Main Index
54
2.10 Supported HTML tags and options

The current HTML widget that is integrated into MSC.Patran supports HTML 2.0 plus tables.
Following is a list of supported HTML tags.
Table 2-1 Standard HTML tags supported by the HTML widget
Tag Attributes Notes
A HREF="<url>" Anchor. A special syntax for HREF will invoke a PCL
/A NAME=”<text>” call with string arguments.
HREF=”PCL:funct1(string1,string2,string3)”
Note: See example for AAI.html_calls.
ADDRESS none Address style - causes a switch to italic font.
/ADDRESS
B none Bolds the current font, looks for best fit among
/B available fonts.
BLOCKQUOTE none Indents left margin 5 font spaces. A blank line

/BLOCKQUOT precedes and follows the block.
E
BODY BGCOLOR=<color The various attributes of the display are changed:
/BODY > background color, text color, unvisited text color, and
TEXT=<color> visited text color. Colors may be specified in #rrggbb
format or as color names recognized by the font alias
LINK=<color> file.
VLINK=<color>
BR none Line Break - The current line is ended, new text
/BR appears as a new line. Multiple breaks do not cause
further line feeds.
CAPTION Table Caption - text Table Caption - text between <CAPTION> and
/CAPTION between </CAPTION> is rendered before the table. These
<CAPTION> tags must appear in the scope of a table or they are
ignored.
CENTER The text between The text between the opening and closing center tag
/CENTER the opening and is centered. This is similar to 
closing except no paragraph is started. Tables and images
may also be centered using the center tag.
CITE none Citation style - causes a switch to italic font
/CITE
CODE none Coding style - causes a switch to a fixed font
/CODE
Main Index
DD Definition Definition Description - Used within a <DL> </DL>
/DD Description - Used block, the text that follows is the definition
within a description for the term of the previous term given
by the <DT>. The <DD> text is indented.
CHAPTER 2 55
Drive Pages
Table 2-1 Standard HTML tags supported by the HTML widget (continued)
DL COMPACT Definition List - Encloses a definition list block
/DL containing pairs of <DT> and <DD> tags. The
COMPACT attribute causes HView to suppress the
normal line feed between the <DT> and <DD> when
the <DT> text would not run into the <DD> start of
text.
DT none Definition Term - Used within a <DL> </DL> block,
/DT the text that follows is the definition term. Normally,
a <DD> tag follows which contains the definition
description of this term.
EM none Emphasis - causes a switch to italics.
/EM
FONT BGCOLOR=<color Changes font size and/or color. Colors may be
/FONT > specified in #rrggbb format or as color names
SIZE=<n> recognized by the font alias file. The size parameter
ranges from 1 (smallest) to 7 (largest). Size may also
have a leading sign (+/-) in which case the resulting
size is the sum of this value and basefont which
defaults to 3.
H1 H2 H3 ALIGN=CENTER Level n Heading - Switch to corresponding font as
H4 H5 H6 ALIGN=RIGHT given by the resources XcgNh1Font ... XcgNh6Font.
Headers appear on new lines with vertical space
/H1 /H2 /H3 before and after. ALIGN=CENTER causes the text to
/H4 /H5 /H6 be centered while ALIGN=RIGHT causes the text to
be right justified.
HEAD none Header Information - The text contained within is
/HEAD information regarding the document. These tags are
ignored by HView.
HR Horizontal Rule - Horizontal Rule - Draws a horizontal line. The line
/HR Draws a horizontal spans the current left and right margins.
HTML HTML Block - The HTML Block - The text between the tags is an HTML
/HTML text between the document. These tags are ignored by HView.
tags
I none Italic - causes a switch to italics.
/I
IDENT ORIGIN="<string> Identification - A CGI enhanced tag which functions
/IDENT " as a comment to identify the document that was
used to generate this HTML. See the function
Main Index XcgHViewFindIdent
IMG SRC="URL" Include Graphic image - The application callback
/IMG defined by the getImageCallback resource is called. It
must return a Pixmap which is displayed.
56
KBD none Keyboard Font - causes a switch to a fixed font.
/KBD
LI none list Item - Used within a <OL> <MENU> or <UL>
/LI block, the text that follows is a list item
MENU none Menu Block - same as unordered list <UL>.

/MENU
OL none Ordered List - Indented numbered list. Each item is
/OL preceded by <LI> tag.
P ALIGN=CENTER Paragraph - A new paragraph is begun. Normally, a

/P ALIGN=RIGHT blank line precedes the paragraph. The
ALIGN=CENTER causes the text to be centered (see
also <CENTER>). ALIGN=RIGHT causes the text to
be right justified.
PRE none Preformatted style - rendered literally (respecting
/PRE tabs and linefeeds of input stream) in a fixed font.
SAMP none Sample style - causes a switch to fixed font.

/SAMP
SKIP_IF DEF="<string>" Run time text exclusion - A CGI enhanced tag which
/SKIP_IF SKIP_MASK allows the section of HTML text and tags between
<SKIP_IF> and </SKIP_IF> to be excluded form
processing depending on the conditions given in the
attributes.
If neither attribute is present, skip is performed
unconditionally. If both are present, they are logically
ORed. No nesting of this tag is allowed at this time.
DEF="<string>":<string> is an environment symbol
-skip is performed if symbol is defined and is
non-empty.
SKIP_MASK:skip is performed if skipMask resource
is non-zero.
STRONG none Emphasis - causes switch to bold font.
/STRONG
SUB none Subscript. Text between and is
/SUB rendered as a subscript or slightly lower but in the
same font of the preceding text. Nesting of 
and is not permitted.
Main Index
SUP none Superscript. Text between and is
/SUP rendered as a superscript or slightly elevated but in
the same font of the preceding text. Nesting of
 and is not permitted.
CHAPTER 2 57
Drive Pages
TABLE BORDER Table - Specifies the definition of a table containing
/TABLE columns (<TD> and <TH> tags) and rows (<TR>
tags). The border option causes a border to be drawn
in the table.
TD NOWRAP Table Column - Begins a table column. Text within
/TD ALIGN=LEFT (def) the column is aligned as specified. The NOWRAP
attribute forces the text in the column to be on a
ALIGN=RIGHT single line.
ALIGN=CENTER
TH See TD Table Column Header - Functions exactly like <TD>
/TH except that the text is also bolded.
TITLE none Document Title - The text within is captured and

/TITLE returned to the application via the titleCallback. A
browser typically displays this text in the window
decoration.
TR none Table Row - Concludes a table row. Used within a
/TR <TABLE> </TABLE> block. The final <TR> prior to
</TABLE> is optional
TT none Typewrite Style - causes a switch to a fixed font.
/TT
U none Underline - The text within is underlined.
/U
UL none Unordered List Block - a bullet list is begun. Each
/UL item is designated by a <LI> tag and is preceded by a
bullet.
VAR none Variable style - causes a switch to bold font.
/VAR
 and closing > is ignored. This includes text and tags.
Comments may be nested allowing large sections of
HTML to be safely omitted.
Main Index
58
Main Index
CHAPTER
Function Definitions Text File
3
■ Function Definitions File Overview
■ Function Definitions File Example
■ Syntax of Keywords
Main Index
68
3.1 Function Definitions File Overview

A method is needed to display dialog to the user and simultaneously display and accept data
from input boxes or other devices for user interaction such as screen picks, selecting toggle
options or typing input values. These user inputs are used as arguments to PCL calls.
MSC.Acumen provides an easy method of specifying this information without low level
graphics programming. A Function Definitions text file accomplishes this.
The home drive page directory as defined by the environment variable
ACUMEN_APPLICATIONS defines the path to the Function Definitions file. This text file is
simply a listing of function call definitions.
An example of a function definition called “readthickness” in the Function Definitions (*.def) file
is:
#
#Read in a real value input by the user to define a thickness.
#
*INPUTID = readthickness
*CLASS=AANAV
*FUNCTION = readthickness
*DBOX = REAL,Type: Thickness,1,3.
*STATUSCHECK
*DYNAMIC = DFLT.dbox_wid
*LOAD ITEM
This function definition is referenced from the inputid attribute of a <dialog> tag on a drive
page. In the following example from a drive page, ”inputid = readthickness ” is used to reference
the function definition “readthickness” defined above:
<dialog dlgid=”cad2”
inputid=”readthickness”
errordlg=.#2.#badthick”
...
</dialog>
In this example, the value assigned to the inputid attribute (inputid=”readthickness”) references
a corresponding *INPUTID entry line in the Function Definitions file (*INPUTID =
readthickness). This is how the platform software uses the Function Definitions file to determine
what PCL function to call, what the call sequence parameters are, and what widgets (and
defaults) need to be displayed to accept the inputs.
Different widget types are supported by this functionality:
• Databox • Option Menu

• Select Databox • Slide Bar
• File Widget • Toggle
• List Box • Textbox
Main Index
CHAPTER 3 69
3.2 Function Definitions File Example

The easiest way to learn the format of the Function Definitions file is to look at some examples.
Following are entries taken from the automotive brake lever demonstration problem. A few
entries are shown followed by explanations.
# PCL Function call definitions for the UI Module "Inputs Box".
# This definitions file is written for the example automotive
# park brake lever case.
#
# open up a new database with an MSC/NASTRAN preference
# Modeling tolerance is set to 0.005
*INPUTID = new_db_open_nastranpref
*CLASS = AANAV
*FUNCTION = openup_nastrandb
*DBOX = STRING,Type: file name, 1
*STATUSCHECK
*DYNAMIC = AANAV.fil_wid
*LOAD ITEM
#
Comment lines in the file are designated by a # character in column 1. The platform software will
accept a STRING user input value from a single displayed databox and then construct and issue
the following PCL call: AANAV.openup_nastrandb( inputstring ). The value of inputstring is
passed to the function through the databox. Note that the *INPUTID index and the *FUNCTION
name can be different. This allows the same function to be called in different ways with different
defaults, etc.
The databox is displayed with a title reading: "Type: file name". The databox accepts a single
STRING type input. Note that Multi-byte foreign language font characters are allowed only in
the display labels listed for the input widgets.
When the function (openup_nastrandb in this example) is executed, a status check is made. The
default success status is 0. The *STATUSCHECK flag signals the platform software to use the
<dialog> tag attributes: quedlg, errordlg, or <returnerror> to display the next <dialog> after this
function executes and control is returned to the drive page.
The *DYNAMIC flag signals the platform software to call the function AANAV.fil_wid() to
return a default value to display in the databox widget. This feature allows the dynamic
computation of default widget values. The author must write the 'fil_wid' function to provide
the default values in a single string array, with one string for each widget. A blank entry in the
array will indicate that the default value given in the *.def file for that widget should be used.
The *DYNAMIC functionality will support all widget types.
The *LOAD ITEM line signals the end of this PCL call specification. It is a keyword used to
indicate the end of the function call listing under a particular *INPUTID reference listing.
************************************************************************
This is an example case requiring use of the file widget.

#
# Read in a UG CAD file by the Direct Parasolids option
Main Index *INPUTID = ugimport_method1
*CLASS = AANAV
*FUNCTION = ugimport_direct1
*FILE=*.prt,File Filter Specification,Directories,Files,Selected File,Filter
*STATUSCHECK
*LOAD ITEM
70
#
************************************************************************
In this example, the databox widget accepts a single REAL value. The label which appears above
the widget is "Type: Thickness". The fixed default value is 3.
#
# Read in a part thickness value input by the user.
# Store it as a user response variable.
*INPUTID = readthickness
*CLASS = AANAV
*FUNCTION = readthickness
*DBOX =REAL,Type: Thickness,1,3.
*STATUSCHECK
*LOAD ITEM
#
************************************************************************
Two select databoxes are displayed for this function. Each one will accept a surface edge pick.
#
# Receive definitions of 2 particular brake lever edges and then
# perform automated 2D shell meshing and properties assignment.
*INPUTID = lever_automesh
*CLASS = AANAV
*FUNCTION = lever_automesh
*SDBOX =EDGE,1) Pick: Edge (Strut)
*SDBOX =EDGE,2) Pick: Edge (Cable)
*STATUSCHECK
*LOAD ITEM
#
************************************************************************
In this example, one select databox for a node and three databoxes for REAL values are
displayed. The three databoxes will have default values displayed. For novice users it is better
to display separate boxes for the separate components rather than accept an input like -2200.,0.,0.
in one single box.
#
# Apply a point load simulating the park brake lever cable attachment.
*INPUTID = lever_cable_load
*CLASS = AANAV
*FUNCTION = lever_cable_load
*SDBOX =NODE,Pick: Node Point to Load
*DBOX =REAL,Type in: X Force,1,-2200.
*DBOX =REAL,Type in: Y Force,1,0.
*DBOX =REAL,Type in: Z Force,1,0.
*STATUSCHECK
*LOAD ITEM
************************************************************************
Main Index
CHAPTER 3 71
3.3 Syntax of Keywords

• Any line beginning with a # character is treated as a comment line.
• An asterisk (*) character as the first non-blank character in a line flags the start of a
keyword.
• Values assigned to a keyword follow an equals sign (=).
• All function definitions need to include *INPUTID, *CLASS, *FUNCTION, and the
appropriate number of widgets or hard-wired parameters which correspond to the
PCL call arguments.
************************************************************************
The keyword *INPUTID is used to specify the function call index (cyl_coords_method1),
32-characters maximum.
*INPUTID = cyl_coords_method1
ASCII non-blank characters are required for the value listed under *INPUTID. 'null' will be the
4-character index name reserved for the case of no function call and a disabled "Apply Inputs"
action button.
************************************************************************
The keywords *CLASS and *FUNCTION are used to specify the PCL function class and
function name to call.
*CLASS = AANAV
*FUNCTION = make_cyl_coords
The PCL class name can be left blank indicating a global class function. A function name of 'null'
means to disable the "Apply Inputs" action button and display no widgets in the "Inputs Box".
************************************************************************
The keyword *STATUSCHECK is an error status checking flag. When this keyword is listed,
the integer return value is received into a global variable, and a status check is made with it.
*STATUSCHECK [=0]
The integer value flags a normal successful exit by this particular PCL function. A value of zero
(0) is the most common. If the integer value associated with normal exit is not listed on the
*STATUSCHECK line, then a value of zero is assumed.
This is an ***optional keyword***.
If *STATUSCHECK IS NOT used when the function is called:
• next dialog is quedlg no matter what (see <dialog> tag attributes)
• queftn (if listed) is invoked no matter what
If *STATUSCHECK IS used when the function is called (Encouraged!!!):
• next dialog is quedlg for success, errdlg or <returnerror> for failure
Main Index
• queftn (if listed) is invoked for success, not for failure
************************************************************************
The keyword *DYNAMIC calls the referenced function to return a default value to be displayed
in the widget. All widget types are supported by this keyword. This feature allows the dynamic
computation of default widget values.
72
The author must write the *DYNAMIC referenced function to give the default values in a single
string array, with each element of the array corresponding to a different displayed widget or
HPARAM (hard wired parameter), which in turn corresponds to a different call sequence
argument of the *INPUTID referenced PCL function. The STRING array elements are in the
order of the call sequence arguments for the particular *INPUTID referenced function. For the
listbox widget, the multiple values for default will be a single string where the individual values
are comma separated. e.g. "load case1,load case2,load case3". A blank entry in the array will
indicate that the default value given in the *.def file for that widget should be used.
For databox widgets with dynamic assignments, the following rules apply:
When a dynamic assignment is being used with a REAL or INTEGER databox, the value given
to the number of values (NumVals) in the .def file has a special meaning.
- If NumVals is defined as 0 in the .def file, any number of values can be dynamically assigned,
and the corresponding function is called with an array containing the values.
- If NumVals is set to 1 in the .def file, a single non-array value of INTEGER or REAL can be
dynamically assigned.
- If NumVals is set to a value >1 in the .def file, the platform software will check the number of
inputs received from the databox to make sure it matches the value set in NumVals.
For listbox or option menu widgets with dynamic assignments, the following rules apply:
When dynamically assigning values, the original displayed selectable label definitions are
overwritten and the item values and labels become the same thing.
Main Index
CHAPTER 3 73
*DYNAMIC example with a single widget:

This is how the function definition in the .def file is referenced by the .xml
file:
<dialog dlgid=”dlbtest”
inputid=”dyn_test_single”
quedlg=.#1.#dlbtest1”
...
</dialog>
This is how the 4 original listbox items are defined in the .def file:
*INPUTID = dyn_test_single
*CLASS = AANAV
*FUNCTION = dyn_test_single
*LBOX = Available Options,EXTEND,4
*LBOXITEMS = 4,YES,NO,MAYBE,NEVER
*LBOXLABS = YES,NO,MAYBE,NEVER
*DYNAMIC = AANAV.new_list_single
*STATUSCHECK
*LOAD ITEM
This is how the 4new listbox items are defined in the .pcl file:
FUNCTION new_list_single(new_string)
STRING new_string[]()
/* Allocate a string array for a single string entry which will contain the 5
new values for the listbox widget which are defined below */
sys_allocate_string(new_string,50)
sys_allocate_array(new_string,1,1)
/* These are the 4 new values that will appear in the listbox widget. */
new_string(1) = “test1,test2,test3,test4”
END FUNCTION
This is the .pcl file which receives the item selected from the listbox:
FUNCTION dyn_test_single(value)
/* Although value is a STRING ARRAY, it will be receiving only one value from
the listbox */
STRING value[]()
...
END FUNCTION
*DYNAMIC example with multiple widgets:
Main Index
This is how the function definition in the .def file is referenced by the .xml
file:
<dialog dlgid=”dlbtest1”
inputid=”dyn_test_multiple”
74
quedlg=.#1.#st1ck1”
...
</dialog>
This is how the original widget values are defined in the .def file:
*INPUTID = dyn_test_multiple
*CLASS = AANAV
*FUNCTION = dyn_test_multiple
*TOG = Toggle, TRUE
*LBOX = Listbox Picks,EXTEND,5
*LBOXITEMS = 5,YES,NO,MAYBE,NEVER,SOMETIMES
*LBOXLABS = YES,NO,MAYBE,NEVER,SOMETIMES
*DBOX = REAL,Type: Real Value,3,1.,2.,3.
*OPT = Option Menu Picks,EXTEND,1
*OPTITEMS = 4,YES,NO,MAYBE,NEVER
*OPTLABS = YES,NO,MAYBE,NEVER
*HPARAM = REAL,7.
*DYNAMIC = AANAV.new_list_multiple
*STATUSCHECK
*LOAD ITEM
This is how the new widget values are defined in the .pcl file:
FUNCTION new_list_multiple(new_string)
STRING new_string[]()
/* Allocate a string array for the 5 string entries which will contain the new
values for the widgets */
sys_allocate_string(new_string,50)
sys_allocate_array(new_string,1,5)
/* These are the new values that will appear in the widgets */
new_string(1) = “FALSE”
new_string(2) = “list1,list2,list3,list4,list5”
new_string(3) = “100.,200.,300.”
new_string(4) = “opt1,opt2,opt3,opt4”
new_string(5) = “700.”
END FUNCTION
This is the .pcl file which receives the values from the multiple widgets:
FUNCTION dyn_test_multiple(toggle,listbox,databox,option,hparam)
INTEGER null_flag
STRING value[]()
STRING page[VIRTUAL]
STRING stepid[4]
STRING dyn_test_multiple_value[VIRTUAL]
LOGICAL toggle
STRING listbox[]()
Main Index REAL databox()
STRING option[]()
REAL hparam
...
CHAPTER 3 75
END FUNCTION
************************************************************************
The keyword *LOADITEM is used to specify the end of a PCL function call definition under a
specific *INPUTID listing.
Syntax for the Different Widget Types

Every call sequence argument in a PCL function must have a corresponding widget or
hard-wired parameter. The widget types are explained below:
Data Box Widget

*DBOX = TypeOfInput, DboxLabel, NumVals, InitVal1, InitVal2, InitVal3,
...
Note that the type of input (datatype) can be: STRING, INTEGER, REAL. A STRING data type
results in a single VIRTUAL STRING function call argument. Multiple REAL or INTEGER initial
values (NumVals values) can be listed. If no intial value is listed, then the resulting data box will
display as initially empty. Data is extracted from widgets as a VIRTUAL STRING. PCL list
processor routines are used to evaluate the extracted data. The DboxLabel label value ONLY
may be in multi-byte foreign language characters. The label is displayed above the databox.
NumVals is the upper limit of the number of INTEGER or REAL values. For NumVals=1, a
scalar REAL or INTEGER parameter is given to the function call. For NumVals > 1, a REAL or
INTEGER ARRAY argument is given. List a value of 1 for NumVals for the case of a STRING
data type. If a dynamic assignment (*DYNAMIC) is used with a REAL or INTEGER data type,
special rules apply (please see the description for *DYNAMIC above).
Select Data Box Widget

*SDBOX = TypeofSelect, Label, InitValue
TypeofSelect may be: ANY, POINT, CURVE, SURFACE,....etc. InitValue is a STRING which
may contain blanks, e.g. Curve 6. If no initial value is listed, the box will have no initial value.
The label ONLY may be multi-byte font (displayed above the databox).
Toggle Widget
*TOG = Label, InitialValue
The data type for the initial value and the value read from the widget is LOGICAL. List
InitialValue as TRUE or FALSE. The label ONLY can be multi-byte characters.
File Selection Widget

*FILE = Filtermask,Filterlabel,Dirlabel,Fileslabel,Filenamelabel,
Filterbuttonlabel
Filtermask is a STRING argument controlling file selection, e.g. '*.db'. The 5 labels for widget
Main Index display may use multi-byte font. Note that the default directory that this widget points to for
files is the user directory window that the user is running the MSC.Patran application from.
Slide Bar Widget

*SBAR = Label, Minval, Maxval, Initval, DecPnts
76
Label may be multi-byte characters. Initval=initial numeric value. DecPnts=number of display

digits beyond decimal. Minval and Maxval are the limit values for the slide bar.
List Box Widget

*LBOX = Label, SelectType, NumRows
*LBOXITEMS = NumItems, name1,name2,name3, ... , namen
*LBOXLABS = lab1, lab2, lab3, ... , labn
Three successive key word entries: LBOX, LBOXITEMS, LBOXLABS are required to specify a
listbox widget display. The listbox is used to obtain a STRING array output of the selected list
items. Label can be multi-byte characters. NumRows is the number of visible rows to display.
SelectType can be BROWSE, EXTEND, MULTIPLE, or SINGLE. NumItems is the number of
displayed items to select from. The actual STRING item values are listed with *LBOXITEMS.
Corresponding displayed STRING labels are listed with *LBOXLABS. The labels are often the
same as item values, but multi-byte characters are allowed for the labels only.
Option Menu Widget

*OPT = Label,SelectType,NumRows
*OPTITEMS = NumItems, name1, name2, name3, ...., namen
*OPTLABS = lab1, lab2, lab3, ..., labn
Three successive key word entries: OPT, OPTITEMS,OPTLABS are required to specify an option
menu widget display. The option menu is used to obtain a single STRING value in a controlled
fashion from an available list. Incorrect user typing is avoided. Label can be multi-byte. It
appears above the widget. NumRows is the number of visible rows to display SelectType can be
BROWSE, EXTEND, MULTIPLE, or SINGLE. NumItems is the number of item values to select
from. Ui_item_create is used to create the items. The actual STRING item values (names) are
listed with OPTITEMS. Corresponding displayed STRING labels are listed with OPTLABS. The
default displayed item is the first one listed under OPTITEMS. The labels are often the same as
item values, but multi-byte characters are allowed for the labels only.
Textbox Widget
*TBOX = Label, DefaultText, NumRows
The label can be composed of multi-byte characters. DefaultText is the actual text to be displayed
in the widget. The default text should NOT contain "," or "=" characters. NumRows is the total
number of rows to be displayed in the textbox widget.
Specification of call parameters for which no widgets are

displayed
Hard-wired (hidden) call list parameters
The keyword *HPARAM is used to specify a PCL function input parameter which is hidden or
"hard wired" and not available for the user to change via displayed widgets. The referenced
function is called with specified fixed values as listed on HPARAM, and no corresponding
Main Index widgets are displayed for user input.
Format for specifying a single value hard-wire parameter:
*HPARAM = DataType, Value
where for a single value parameter, DataType is STRING, REAL, INTEGER, or LOGICAL.
CHAPTER 3 77
Format for specifying an array of hard-wired parameters:

*HPARAM = DataTypeA, NumVals, val1, val2, val3, ... , valn
where for an array or values, DataTypeA is STRINGA, REALA, LOGICALA, or INTEGERA.

NumVals is the number of values listed for the input parameter array.
This is how the hidden parameter (*HPARAM)in the .def file is referenced by the
.xml file:
<dialog dlgid=”hparam”
inputid=”hparam_test”
quedlg=.#1.#st1ck1”
...
</dialog>
This is how the hidden parameter (*HPARAM) is defined in the .def file:
*INPUTID = hparam_test
*CLASS = AANAV
*FUNCTION = hparam_test
# User can’t see the HPARAM value, it’s passed into the function
# without a widget
*HPARAM = REAL,111.
*STATUSCHECK
*LOAD ITEM
This is how the hidden value from *HPARAM is passed into the .pcl file:
FUNCTION hparam_test(arg1)
REAL arg1
/* The value arg1 is set in the .def file by using the keyword *HPARAM. This
shows how a value can be passed into a function without the use of a widget */
END FUNCTION
Output return arguments

The keyword RETVAR is used to specify use of a global variable for a function return value or
array of values. This creates a placeholder in the list of call sequence arguments to the function.
This is useful for calling standard built-in functions because they typically have call sequence
arguments for return values. Note that this automatically creates a global variable and uses it as
a call sequence argument to the function, and functions of any class can subsequently access
them.
Format for specifying a single valued parameter:
*RETVAR = VarName,DataType
VarName is the ASCII character name given to the global variable. DataType is listed as
STRING, INTEGER, or REAL. A VIRTUAL STRING variable is declared and used as the
parameter argument when a STRING type is specified. The called function will reallocate the
string.
Main Index Format for specifying an array of parameters:

*RETVAR = VarName, DataTypeA, NumVals
78
VarName is the ASCII character name given to the global variable. DataTypeA is STRINGA,
REALA, LOGICALA, or INTEGERA. A GLOBAL variable array of type DataType and
dimension NumVals is declared and echoed to the session file before the function call is made.
Main Index
CHAPTER
Introduction to HTML
4
■ What is HTML, and why do I need to know about it for
MSC.Acumen?
■ Example of a Simple HTML Page

■ Document Tags
■ Lists
■ Anchors
Main Index
82
4.1 What is HTML, and why do I need to know about it for

MSC.Acumen?
The acronym HTML stands for "HyperText Markup Language". The World Wide Web is built
of web pages, and those pages are themselves written in HTML. HTML is the fundamental
language of the web. Although people refer to “HTML Programming” with a capital P, HTML
is really not a programming language at all. HTML is exactly what it claims to be: a markup
language. One uses HTML to mark up a text document, analogous to how an editor would by
using a red pencil. The marks, applied in the form of HTML tags, indicate which format (or
presentation style) should be used when displaying the marked text.
HTML has become the ubiquitous document formatting standard. Most word processors now
support an HTML export option. The growing use of the company Intranet for communication
demands the conversion to HTML for a wide variety of documents.
MSC.Acumen applications use HTML as an effective means for communicating information and
instructions to the user. The applications are written to fit particular work flow scenarios. They
must control the simulation process while communicating a language and terminology
understood by the targeted users. HTML facilitates a flexible text and graphics display that
makes the communication task much easier.
Small packets of HTML are displayed on the MSC.Acumen form as individual dialog items.
Typically, using only the most basic HTML markup tags are sufficient to produce pleasing and
readable dialog. Such basic tags include those for creating paragraph breaks and for creating lists
of items. In addition, using font control tags to color particular text for emphasis is quite
effective. The example "drive pages" listed in this document include the recommended tags for
general text and background color control for all HTML dialog packets. See Example of a Home
Drive Page (Step 1) (p. 27) and Example of a Home Drive Page (Steps 2-n) (p. 30). The only
special item that the application author includes within the MSC.Acumen HTML dialog packets
is the special syntax for invoking fixed-argument PCL function calls from hypertext links. This
syntax is shown on AAI.html_calls (p. 135).
The MSC.Acumen application author may also provide auxiliary help documents for each step
of the simulation process. These help documents are written as HTML web pages. They are
displayed in a commercial web browser which opens up as a separate application when the
"Help" button is selected. The author also has the ability to write web pages for any auxiliary
information required, and to display it in the commercial browser automatically at any point
during the process. It is not difficult to write out text information from a PCL function to an
external HTML format file. This method facilitates the dynamic display of auxiliary information.
The preformatted tag <pre> is useful for this.
Main Index
CHAPTER 4 83
4.2 Example of a Simple HTML Page

The required elements of an HTML document are <html>, <head>, <title> and <body> with
their corresponding end tags. For example:
<html>
<head>
<TITLE> A Simple HTML Example </TITLE>
</head>
<body>
<H1> HTML is fun! </H1>

This is the first paragraph.
 And this is the second paragraph.

</body>
</html>
An HTML document contains two distinct parts, the head and the body. The head contains
information about the document that isn’t displayed to the screen. The body contains everything
displayed as the web page.
For additional information, there are several web-based HTML training sites:
• http://www.mcli.dist.maricopa.edu/tut/index.html
• http://www.ncsa.uiuc.edu/General/Internet/WWW/HTMLPrimer.html
• http://www.cwru.edu/help/introHTML/toc.html
• http://www-pcd.stanford.edu/mogens/intro/tutorial.html
• http://archon.educ.kent.edu/Midwest/Resc/Training/educhtml/pages/htmlhome.
htm
• http://www.lakefieldcs.on.ca/dept/computers/dst-3a/introhtml/intro.htm
• http://borg.lib.vt.edu/reports/soasis-slides/HTML-Intro.html
Main Index
84
4.3 Document Tags

Below are some rules and guidelines for using document tags. For a full list of supported tags,
see Supported HTML tags and options (p. 54).
• Tags are used within an HTML document to divide a web page into its basic sections,
such as headers, paragraphs, lists, etc.
• Tags consist of a left angle-bracket (<), a tag name, and a right angle-bracket (>)
• Tags need to be paired to start and end the tag instruction, <tag> ... </tag>, in order to
guarantee well formed XML format for future portability of the drive pages
• These pairs define the format rules which are applied to the information between the
<tag> and the </tag>
• Tags are not case sensitive, but future XML parsing is. Use consistent upper case for
future compatibility.
Tag Definitions
HTML
The first and last tags in a document should be <html> tags. This tells the web browser that the
file contains HTML information.
HEAD
The <head> tag contains all the document header information.
TITLE
The <title> tag defines the title of the document, and will appear at the top of the browser in the
title bar. The contents of this tag will appear if the page is bookmarked. There can only be one
<title> defined per document.
BODY
Everything within the <body> tags defines what gets displayed to the browser window, such as
paragraphs, headings, lists and graphics.
Comments
Comments can be put in the body of the HTML file with a <! > tag:

Paragraphs
The beginning of a paragraph is marked by a , and ends with a . Unlike word
processors, HTML doesn’t recognize carriage returns within a paragraph. All spaces, line feeds
and carriage returns are compressed into a single space when the HTML document is displayed
in a web browser.
Preformatted Text
Main Index
Use of the <PRE> tag will produce a display just as the text is formatted in the source HTML file.
For example:
<PRE>
Node ID Stress(psi)
CHAPTER 4 85
24113, 264
35612, 675
71110, 534
</PRE>
will display in the web browser as:

Node ID Stress(psi)
24113, 264
35612, 675
71110, 534
Main Index
86
4.4 Lists
Unordered Lists (Bulleted)
An unordered list <UL> is a list of items where each item is preceeded by a bullet. The list begins
and ends with the tags <UL> and </UL>. Then, each item in the list is marked using the <LI>
tag (list item).
<UL>
<LI>Monday</LI>
<LI>Tuesday</LI>
<LI>Wednesday</LI>
</UL>
When used in a valid HTML file, the list would look like:
• Monday
• Tuesday
• Wednesday
Nested Lists
Lists can also be nested. Remember that including leading blanks in the HTML text file will make
it easier to read, but will not be displayed:
<UL>
<LI>Monday</LI>
<LI>Tuesday</LI>
<UL>
<LI>8am - 12pm</LI>
<LI>12pm - 1pm</LI>
<LI>1pm - 5pm</LI>
</UL>
<LI>Wednesday</LI>
</UL>
When used in a valid HTML file, the list would look like:
• Monday
• Tuesday
•8am - 12pm
•12pm - 1pm
•1pm - 5pm
• Wednesday
Ordered Lists (Numbered)
An ordered list <OL> is much like an unordered list, except that the list items are numbered
instead of bulleted. For example:
Main Index
<OL>
<LI>Monday</LI>
<LI>Tuesday</LI>
<LI>Wednesday</LI>
</OL>
CHAPTER 4 87
will look like this when displayed in an HTML browser:

1. Monday
2. Tuesday
3. Wednesday
Main Index
88
4.5 Anchors
The real power of the web is to be able to link to another document, another place in the same
document, or other type of file such as a graphic or video clip. This is done through a hypertext
link defined with an anchor tag <A> and a hypertext reference tag attribute, HREF, which
defines the function of the anchor. This example shows an anchor that points to a file called
example1.html, with “Example1” as the name of the hyperlink.
<A HREF=”example1.html”>Example1</A>
• Start the anchor with <A (you must put a space after the A)
• Specify the document to link to by entering HREF=”filename”>
• Enter the text that will be the name of the hyperlink
• Close the anchor tag /A>
Combining what we know of lists and anchors, review the following example:
<UL>
<LI><A HREF=”apples.html”>Apples</A></LI>
<LI><A HREF=”oranges.html”>Oranges</A></LI>
<LI><A HREF=”bananas.html”>Bananas</A></LI>
</UL>
This example would look like the following in a web browser, where each item would be a
hyperlink to another HTML document.
• Apples
• Oranges
• Bananas
Main Index
CHAPTER
State Table Functional Interface
5
■ State Table Overview
■ Record User Response Variable
■ Retrieve User Response Variable
■ Overwrite User Response Variable
■ General Access to the State Table
Main Index
90
5.1 State Table Overview

The State Table provides a persistent memory method of recording and retrieving information
associated with and organized in terms of the steps of analysis. As the user makes choices or
answers questions, “user response” variables, either string, integer, or real, are stored to the State
Table. The contents of the memory State Table are typically written to the database at the
conclusion of each analysis step by means of the AASTATE.store_objectives() call. This allows a
restoration of the current modeling state upon closing down and then reopening of a database.
State Table recorded values are used for logic control of the analysis workflow. Step completion
indicators are stored as the single character string variable “complete” for each step. The
processing of automated link rules on the XML “drive pages” uses the State Table.
The state table is designed to organize stored data in terms of two sorting parameters (1) an
analysis process step ID (4 characters or less), and (2) a string character name designated as a
“variable name”. In general, this scheme serves well for MSC.Acumen applications because the
analysis process itself is organized in terms of steps. It is advantageous to use a common
“variable name” such as “complete” as the step completion indicator for each step. Storing many
of these values under the same “variable name”, but for different “Step IDs” keeps them all
separate and unique.
A difficulty arises when PCL automation functions that make use of data values read in from the
state table are targeted for reuse in other separate MSC.Acumen applications. The key process
steps that store the values required for subsequent use in the automation functions may not have
the same IDs from application to application.
Two simple techniques have been employed to resolve the automation function reuse difficulty:
(1) use of a fictitious Step ID, and (2) storage and use of a pointer value to the required Step ID.
To use the first technique, simply store the particular values as required by an automation
function to a “Step ID” that does not correspond to any real process step. The state table does not
care whether or not the ID corresponds to any real process step. It simply stoes and retrieves by
the ID name that you give. To do this, use the AASTATE.overwrite_ur... type call functions as
opposed to the AASTATE.record_ur... type functions. The only difference is that the
overwrite_ur... type functions take an explicit input call argument for the Step ID. The
record_ur... type functions do not take a Step ID argument. Instead, they automatically use the
current process Step ID when storing data for convenience.
The second approach is more elegant. The application is written so that certain Step ID pointer
values are initially stored in an agreed upon Step ID, say “1.”, or in a fictitious Step ID name like
“ids”. Stored in association with this special agreed upon Step ID are variables holding the
particular Step ID values where certain key operations take place. Subsequent execution of the
key process steps then results in State Table storage of the particular data variables naturally
associated with those process Step IDs as programmed by the application author. After finding
the key Step ID pointer values stored associated with the special agreed upon Step ID, any
subsequently executed automation functions will know which Step ID to retrieve their required
data from.
For example, initially store the string Step ID value of “3.” in the variable name “meshstep”, and
the value of “4.” in the variable name “loadstep”, both associated with fictitious Step ID “ids”.
Main Index Having accomplished this, any subsequently called PCL automation function can call the State
Table to obtain the values assigned to “meshstep” and “loadstep”, associated with the fictitious
Step ID “ids”. The reuseable function then knows to retrieve the required storage values from
CHAPTER 5 91
Step IDs “3.” and “4.” for this application. When the very same PCL function is reused in a
different application, the Step ID value retrieved from the “meshstep” variable could be
something different like “7.”, and the value from “loadstep” might be “10.”.
Main Index
92
5.2 Record User Response Variable

AASTATE.record_ur_real (variable_name, value)
Description:
This function will record a REAL State Table variable called <variable_name>
associated with the current step.
Input:
STRING variable_name[128] This value specifies the name of the user response
variable.
REAL value This value specifies the value to record for the
<variable_name>.
Output:
Error Conditions:
None
Remarks:
The State Table automatically associates the variable recording with the current analysis step as
selected in the UI form main step selection box.
Example:
None.
AASTATE.record_ur_realarray (variable_name, num, values)
Description:
This function will record an array State Table variable REALs called <variable_name>
Input:
STRING variable_name[12 This value specifies the name of the user response
8] variable.
INTEGER num This value specifies the number of values to store.
REAL values(num) This value specifies the values to record for the
<variable_name>.
Output:
Error Conditions:
None
Remarks:
Main Index
Example:
None.
CHAPTER 5 93
AASTATE.record_ur_integer (variable_name, value)
Description:
This function will record an INTEGER State Table variable called <variable_name>
Input:
variable.
INTEGER value This value specifies the value to record for the
<variable_name>.
Output:
Error Conditions:
None
Remarks:
Example:
None.
AASTATE.record_ur_integerarray (variable_name, num, values)
Description:
This function will record an array State Table variable of INTEGERs called
<variable_name> associated with the current step.
Input:
variable.
INTEGER values(num) This value specifies the values to record for the
<variable_name>.
Output:
Error Conditions:
None
Remarks:
Example:
Main Index
None.
94
AASTATE.record_ur_string (variable_name, value)
Description:
This function will record a virtual STRING State Table variable called
Input:
variable.
STRING value[virtual] This value specifies the value to record for the
<variable_name>.
Output:
Error Conditions:
None
Remarks:
Example:
None.
AASTATE.record_ur_stringarray (variable_name, num, values)
Description:
This function will record a virtual length array of virtual strings called
Input:
STRING variable_name[128] This value specifies the name of the user
response variable.
INTEGER num This value specifies the number of values to
store.
STRING values[virtual](virtual) This value specifies the values to record for the
<variable_name>.
Output:
Error Conditions:
None
Remarks:
Example:
None.
Main Index
AASTATE.record_uresponse (variable_name, real_val, i_val, str_val, data_type)
CHAPTER 5 95
Description:
This function will record either a real, integer, or a string value associated with the
current selected analysis step. Place holder arguments are given for all 3 data types.
Only one of the values arguments is used based upon the <data_type> argument.
Input:
STRING variable_name[128]This value specifies the name of the user response
variable.
REAL real_val This value specifies the real value to record for the
<variable_name>, if the data_type = 1.
INTEGER i_val This value specifies the value to record for the
STRING str_val[virtual] This value specifies the value to record for the
INTEGER data_type Flag for type of data to record for the
<variable_name>. The other two values will not be
accessed.
Output:
Error Conditions:
None
Remarks:
The application author is not expected to favor this call option because of its complexity.
Example:
None.
Main Index
96
5.3 Retrieve User Response Variable

AASTATE.get_ur_real (step_id, variable_name, value, null_flag)
Description:
This function will retrieve a REAL State Table variable called <variable_name>
associated with the given step.
Input:
STRING step_id[4] This value specifies the step id.
variable.
Output:
REAL value This value specifies the value retrieved for the
<variable_name>.
INTEGER null_flag This value specifies whether data was returned for
this variable. If null_flag = 0, then a value was
returned. If null_flag = 1 then no value was returned.
Error Conditions:
None.
Remarks:
None.
Example:
None.
AASTATE.get_ur_realarray (step_id, variable_name, num, values)
Description:
This function will retrieve an array State Table variable of REALs called
<variable_name> associated with the given step. The size of the array will be
allocated by this function.
Input:
response variable.
Output:
INTEGER num This value specifies the number of values
returned.
REAL values(VIRTUAL) This value specifies the values retrieved for the
<variable_name>. The size of this array will be
Error Conditions:
Main Index
None.
Remarks:
None.
CHAPTER 5 97
Example:
None.
AASTATE.get_ur_integer (step_id, variable_name, value, null_flag)
Description:
This function will retrieve a INTEGER State Table variable called <variable_name>
associated with the given step.
Input:
variable.
Output:
INTEGER value This value specifies the value to record for the
<variable_name>.
INTEGER null_flag This value specifies whether data was returned
for this variable. If null_flag = 0, then a value was
returned. If null_flag = 1 then no value was
returned.
Error Conditions:
None.
Remarks:
None.
Example:
None.
Main Index
98
AASTATE.get_ur_integerarray (step_id, variable_name, num, values)
Description:
This function will retrieve an array State Table variable of INTEGERs called
Input:
variable.
Output:
returned.
INTEGER values(VIRTUAL) This value specifies the values retrieved for the
<variable_name>. The size of this array will be
Error Conditions:
None.
Remarks:
None.
Example:
None.
AASTATE.get_ur_string (step_id, variable_name, value, null_flag)
Description:
This function will retrieve a virtual length string called <variable_name> associated
with the given step.
Input:
variable.
Output:
<variable_name>.
INTEGER null_flag This value specifies whether data was returned
for this variable. If null_flag = 0, then a value was
returned.
Error Conditions:
Main Index None.
Remarks:
None.
CHAPTER 5 99
Example:
None.
AASTATE.get_ur_stringarray (step_id, variable_name, num, values)
Description:
This function will retrieve a virtual array of virtual length strings called
Input:
response variable.
Output:
returned.
STRING values[virtual](VIRTUAL) This value specifies the values retrieved for
the <variable_name>. The size of this array
will be allocated by this function.
Error Conditions:
None.
Remarks:
None.
Example:
None.
Main Index
100
AASTATE.get_uresponse (step_id, variable_name, real_val, i_val, str_val,

data_type, null_flag)
Description:
This function will retrieve either a real, integer, or string value associated with a
specified analysis step. Place holder arguments are given for all three data types.
Output is written to only one of the place holder arguments depending upon the
data_type value that is returned.
Input:
variable.
Output:
REAL real_val This value returns the real value if <data_type> = 1.
INTEGER i_val This value returns the integer value if <data_type>
= 2.
STRING str_val[virtual] This value returns the string value if the
<data_type> = 3.
INTEGER data_type Flag for type of data retrieved for
accessed.
INTEGER null_flag This value returns whether data was returned for
this variable. If null_flag = 0, then a value was
returned.
Error Conditions:
None.
Remarks:
The application author is not expected to favor this interface call because of its complexity. The
automated link rule processing software uses this call as the most efficient method for obtaining
values for evaluating conditionals. However, by storing state table variables to a dummy step id,
this call can be used to retrieve values from the state table without knowing the variable type.
Example:
None.
Main Index
CHAPTER 5 101
5.4 Overwrite User Response Variable

AASTATE.overwrite_ur_real (step_id, variable_name, value)
Description:
This function will overwrite a REAL State Table variable called <variable_name>
associated with the given step. It differs from the record_ur_real function in that the
associated analysis step ID is given explicitly as a call argument. Thus, user responses
can be recorded or overwritten for steps that are not the current assigned step.
Input:
variable.
REAL value This value specifies the value to record for the
<variable_name>.
Output:
INTEGER <Return Value> This function returns a value of 0 when executed
successfully and a non zero value to indicate a
change in status or an error.
Error Conditions:
Remarks:
None.
Example:
None.
AASTATE.overwrite_ur_realarray (step_id, variable_name, num, values)
Description:
This function will overwrite an array State Table variable of REALs called
<variable_name> associated with the given step. It differs from the record_ur_integer
function in that the associated analysis step ID is given explicitly as a call argument.
Thus, user responses can be recorded or overwritten for steps that are not the current
assigned step.
Input:
variable.
REAL values(num) This value specifies the value to record for the
Main Index
<variable_name>.
Output:
102

Error Conditions:
None.
Remarks:
None.
Example:
None.
AASTATE.overwrite_ur_integer (step_id, variable_name, value)
Description:
This function will overwrite an INTEGER State Table variable called
assigned step.
Input:
STRING variable_name[12 This value specifies the name of the user response
8] variable.
INTEGER value This value specifies the values to record for the
<variable_name>.
Output:
successfully and a non zero value to indicate a change
in status or an error.
Error Conditions:
None.
Remarks:
None.
Example:
None.
Main Index
CHAPTER 5 103
AASTATE.overwrite_ur_integerarray (step_id, variable_name, num, values)
Description:
This function will overwrite an array State Table variable of INTEGERs called
assigned step.
Input:
variable.
INTEGER values(num) This value specifies the values to record for the
<variable_name>.
Output:
Error Conditions:
None.
Remarks:
None.
Example:
None.
AASTATE.overwrite_ur_string (step_id, variable_name, value)
Description:
This function will overwrite a virtual length STRING called <variable_name>
associated with the given step. It differs from the record_ur_string function in that
the associated analysis step ID is given explicitly as a call argument. Thus, user
responses can be recorded or overwritten for steps that are not the current assigned
step.
Input:
response variable.
<variable_name>.
Main Index
Output:
104

Error Conditions:
None.
Remarks:
None.
Example:
None.
AASTATE.overwrite_ur_stringarray (step_id, variable_name, num, values)
Description:
This function will overwrite a virtual array of virtual length strings called
assigned step.
Input:
response variable.
INTEGER num This value specifies the number of values to
store.
STRING values[virtual](virtual) This value specifies the values to record for
the <variable_name>.
Output:
INTEGER <Return Value> This function returns a value of 0 when
executed successfully and a non zero value to
indicate a change in status or an error.
Error Conditions:
Remarks:
None.
Example:
None.
Main Index
CHAPTER 5 105
AASTATE.overwrite_uresponse (step_id, variable_name, real_val, i_val, str_val,

data_type)
Description:
This function will overwrite either a real, integer, or string value associated with a
specified analysis step. Place holder arguments are given for all three data types.
Only one of the value arguments is used based upon the <data_type> argument. This
call differs from the record_uresponse call in that the associated analysis step ID is
given explicitly as a call argument. Thus, user responses can be recorded or
overwritten for steps that are not the current assigned step.
Input:
variable.
Output:
REAL real_val This value returns the real value if <data_type> = 1.
INTEGER i_val This value returns the integer value if <data_type>
= 2.
STRING str_val[virtual] This value returns the string value if the
<data_type> = 3.
INTEGER data_type Flag for type of data to record for the
accessed.
Error Conditions:
None.
Remarks:
The application author is not expected to prefer this interface call because of its complexity.
Example:
None.
Main Index
106
5.5 General Access to the State Table

AASTATE.record_dialog (file_name, step_id, dialog_id)
Description:
This function will record dialog id as encountered. This is used to establish a work
flow history.
Input:
STRING file_name[128] This value specifies file name to the XML drive page.
If the <file_name> starts with a “/” then it is
assumed to be a full path, otherwise, the value for the
environment variable AdvisorLIB is prepended to
the file name.
STRING step_id[4] This value specifies the step id as listed on the page.
STRING dialog_id[8] This value specifies the dialog id as listed on the
page.
Output:
Error Conditions:
None.
Remarks:
The application author is not expected to use this interface call. The platform software
automatically makes this call while processing <dialog>.
Example:
None.
AASTATE.record_lrule (file_name, step_id, rule_id)
Description:
This function will record link rule id as encountered and processed. This is used to
establish a work flow history.
Input:
STRING file_name[128] This value specifies file name to the XML drive page.
If the <file_name> starts with a “/” then it is
assumed to be a full path, otherwise, the value for
the environment variable AdvisorLIB is prepended
to the file name.
STRING step_id[4] This value specifies the step id as listed on the page.
STRING rule_id[8] This value specifies the rule id as listed on the page.
Output:
Error Conditions:
None.
Main Index
Remarks:
The application author is not expected to make this interface call. The platform software
automatically makes this call upon processing automated link rules when the user selects an
analysis step.
Example:
CHAPTER 5 107
None.
AASTATE.previous_dialog (file_name, step_id, dialog_id, null_flag)
Description:
This function will return the address of the previous dialog as recorded in the dialog
history of the State Table
Input:
Output:
STRING file_name[128] This value returns file name to the XML drive page.
STRING step_id[4] This value returns the step id as listed on the page.
STRING dialog_id[8] This value returns the dialog id as listed on the page.
Error Conditions:
None.
Remarks:
The application author is not expected to make this interface call. The platform software uses this
call to obtain previous dialog when the user selects the “Dialog Backup” button.
Example:
None.
AASTATE.dumphistory ()
Description:
This function will print the history of link rule IDs and dialog IDs encountered plus
the recorded user responses to a file or the history window for debug purposes.
Input:
Output:
Error Conditions:
None.
Remarks:
This call is useful for debugging purposes, or for obtaining a modeling session history of user
choices made.
Example:
None.
Main Index
108
AASTATE.store_objectives ()
Description:
This function will write the State Table in present form to the database.
Input:
Output:
Error Conditions:
Remarks:
The application author is expected to call this function at the close of each analysis step.
Example:
None.
AASTATE.restore_oldstate ()
Description:
This function reads a previously recorded State Table from an exiting database back
into memory. The application author should call this function after re-opening an
existing database.
Input:
Output:
Error Conditions:
Remarks:
After obtaining all State Table data and determining which steps have been completed, this
function makes the lower level function call STATEUT.nextstep_switch_on(current_step) to
automatically select the next uncompleted step and to display the first dialog of that step.
Example:
None.
Main Index
CHAPTER
User Interface Functions
6
■ Main Panel
■ Buttons
■ Dialog Box
■ Inputs Box
Main Index
112
6.1 Main Panel

AAUI.mainpanel_include_steps (num_steps, step_ids, completed, step_names)
Description:
This function will display the analysis steps in the main step selection box. It is called
by the function AAI.allsteps_display() which reads the drive pages and obtains the
information to display.
Input:
INTEGER num_steps This value specifies the number of
analysis steps to create switch items for.
STRING step_ids[4](num_steps) This value specifies the step ids or labels
for the switch items. Note: multi-byte
characters are NOT allowed for step ids.
STRING completed[1](num_steps) This value specifies whether a step is
completed or not. The single character
values will be a blank, a ‘C’ or an ‘X’
indicating “not tested yet”, “completed”,
or “completion test failed” respectively.
STRING step_names[36](num_steps) This value specifies the descriptions
assigned to the steps.
Output:
Error Conditions:
None.
Remarks:
Note that the application author is not expected to make this call. The function
AAI.allsteps_display is typically called upon completion of analysis step-1 after the
“NEXTPAGE” user response variable is recorded.
Example:
None.
AAUI.mainpanel_current_step (step_id)
Description:
This function will provide the step id label for the current step as selected on the UI
main panel. If no step is currently selected, the value returned will be the last step
that was previously selected.
Input:
Output:
STRING step_id[4] This value returns the current step id.
Error Conditions:
Main Index
None.
Remarks:
None.
CHAPTER 6 113
Example:
None.
AAUI.mainpanel_step_complete (step_id, complete)
Description:
This function will change the display of the completeness indicator for an analysis
step displayed in the main step selection box.
Input:
STRING step_id[4] This value specifies the step id that will be modified.
STRING complete[1] This value specifies the value the completion indicator
will be set to. The values “ “ (blank), “C” or “X” are
expected in normal practice.
Output:
Error Conditions:
None.
Remarks:
Note that calling this function changes the “main panel” display only. Usually an additional call
to <hypertext>AASTATE.record_ur_string (p. 94) is also made to record the completion
indicator in the State Table.
Example:
None.
AAUI.mainpanel_lock_steps ()
Description:
This function will disable the main step selection box widget so that a user cannot
make a new step selection. This is useful to force the completion of one step before
another can be selected.
Input:
Output:
Error Conditions:
None.
Remarks:
Note that a call to <hypertext>AAUI.mainpanel_step_complete (p. 113) will not successfully
change the display while steps are locked. Steps must be unlocked before changing the display.
Example:
Main Index None.
AAUI.mainpanel_unlock_steps ()
114
Description:
This function will reverse the action of the lock_steps function, enabling the main
step selection box switches to be selected. Unlocking also enables any subsequent
display change of completion indicators.
Input:
Output:
Error Conditions:
None.
Remarks:
None.
Example:
None.
AAUI.mainpanel_unselect_steps ()
Description:
This function will change the state of the main step selection box switch widget to a
null state, so that no analysis step is currently selected.
Input:
Output:
Error Conditions:
None.
Remarks:
This call is typically made as part of a step_wrapup() function at the conclusion of each analysis
step. It is also useful to call in conjunction with an error dialog that excludes the user from
executing the selected step.
Example:
None.
AAUI.switch_highlight (step_id)
Description:
This function selects a step on the UI form “main step selection box” in an automated
mode. This is a software method of selecting a step as opposed to having the user
select the step manually.
Input:
STRING step_id[4] This value specifies the step id that will be highlighted.
Main Index Output:
CHAPTER 6 115

Error Conditions:
None.
Remarks:
A good use for this function is to create an automatic process which cycles until a particular
condition has been satisfied. Alternatively, the author may choose to write applications with all
automated step selection. In this case, the step selection box serves as a status indicator only.
Example:
None.
AAUI.switch_highlight_restorer (step_id)
Description:
This function is automatically called by the platform software upon re-opening an
existing database. This function automatically selects the correct step for continuing,
and precisely the next dialog for the user to act upon.
Input:
STRING step_id[4] This value specifies the step id that will be
highlighted.
Output:
Error Conditions:
None.
Remarks:
The application author is not expected to use this function call. The platform software
automatically invokes this call upon re-opening of an existing database. See the function
<hypertext>AAUI.switch_highlight (p. 114) for automated cycling through steps.
Example:
None
Main Index
116
6.2 Buttons
AAUI.sthelp_helpcb ()
Description:
This function will be called as part of the call back from the Help button. It will call
<hypertext>AAI.step_help_doc (p. 138) in order to display a help document in the
Browser.
Input:
Output:
Error Conditions:
None.
Remarks:
The application author is not expected to use this call.
Example:
None.
AAUI.helpdoc_display (doc_URL)
Description:
This function will display any specified HTML document available on the file system,
or display any http: URL address.
Input:
STRING doc_URL[] This value specifies the path or URL address for the
document to be displayed by the commercial browser
that is used for auxiliary display.
Output:
Error Conditions:
None.
Remarks:
This call spawns the auxiliary HTML browser display as a separate process. Once initiated there
is no further communication available to change the browser display or to close the process.
The format for the doc_URL argument can reference either a local file (relative or absolute path)
or a http address. For relative path references, the home drive page directory defined by the
environment variable ACUMEN_APPLICATIONS is appended onto the beginning of the
relative path.
IMPORTANT: because of parsing issues, the format for http references needs to be
“http_//www....” instead of http://www....”.
Example of a relative path for doc_URL:
Main Index
AAUI.helpdoc_display(“helpdocs/st2help.html”)
Example of an absolute path for doc_URL:

CHAPTER 6 117
AAUI.helpdoc_display(“d:/testing/step_test/helpdocs/st2help.html”)
Example of a web address for doc_URL:

AAUI.helpdoc_display(“http_//www.macsch.com/helpdocs/st2help.html”)
Main Index
118
AAUI.quickreview_quickcb ()
Description:
This function will post the Quick Review form to the screen. This is called as part of
the callback from the “Quick Review” button. The Quick Review form displays user
response variables from the State Table as indicated by the <uresponse> tags for each
analysis step.
Input:
Output:
Error Conditions:
None.
Remarks:
The application author is not expected to make this call.
Example:
None.
AAUI.quit_quitcb ()
Description:
This function will close down the MSC.Acumen GUI. This is called as part of the
callback for the “Quit” button.
Input:
Output:
Error Conditions:
None.
Remarks:
This call is also useful as a method to close down the application from a hyertext link selection.
This method of quitting is preferred over the MSC.Patran built-in PCL call to close down the
database and quit, because it also provides for storing the current contents of the memory State
Table to the modeling database before shutting down.
Example:
None.
Main Index
CHAPTER 6 119
AAUI.backup_backupcb ()
Description:
This function will cause the dialog to back up to the previous dialog. This call is made
as part of the callback to the “Dialog Backup” button.
Input:
Output:
Error Conditions:
None.
Remarks:
Example:
None.
AAUI.backup_status (backup)
Description:
This function will indicate whether or not a backup action is in progress.
Input:
Output:
LOGICAL backup This value returns TRUE if the dialog backup action is
in progress, or a FALSE if a dialog backup action is not
in progress.
Error Conditions:
None.
Remarks:
A call to this function indicates whether or not the current dialog arrived at through action of the
“Dialog Backup” button. Note that functions indicated as the value of an undo attribute to the
<dialog> tag are automatically executed upon a “Dialog Backup” action. The platform software
uses this interface call to determine such backup status. As soon as the new dialog is displayed,
then a <hypertext>AAUI.notify_backup_done (p. 120) call is automatically made.
Example:
None.
Main Index
120
AAUI.notify_backup_done ()
Description:
This function will reset the backup status to FALSE, so any subsequent call to
AAUI.backup_status() will return FALSE.
Input:
Output:
Error Conditions:
None.
Remarks:
The application author is not expected to use this call.
Example:
None.
AAUI.backup_enable (on_off)
Description:
This function provides a mechanism for independent enabling and disabling of the
UI form "Dialog Backup" button. Use this function to guard against <dialog> backup
actions within a step where the workflow sequence is not designed to support a
backup.
Input:
STRING on_off[] If this value is "ON" then the “Dialog Backup” button is
enabled so that a user can select it. If this value is "OFF"
(actually any value other than "ON") then the button is
disabled so that no backup action selection is possible.
Output:
Error Conditions:
None.
Remarks:
Use of this function is recommended only as an exception to normal operation. Note that the
"Dialog Backup" button is automatically enabled upon step selection and display of the first step
<dialog>. The button is automatically disabled at the termination of a step when the
AAUI.mainpanel_unselect_steps() call is made.
Example:
Following is an example of how a call to this function which disables backups is made in the
initftn attribute of a <dialog>.
Main Index <dialog dlgid="first"
inputid="null"
initftn="FUNC:AAUI.backup_enable;STR:off"
CHAPTER 6 121
...
Main Index
122
6.3 Dialog Box

AAUI.dialog_put_text (HTML_text)
Description:
This function will display the HTML data in the UI form dialog box widget.
Input:
STRING HTML_text[] This value specifies the HTML data in the form of
“<HTML> ....insert your text here.... </HTML>”.
Output:
Error Conditions:
None.
Remarks:
The application author is discouraged from using this lower level interface call. Please see the
<hypertext>AAI.next_dialog (p. 138) and <hypertext>AAI.dynamic_next_dialog (p. 140)
functions as methods for displaying HTML listed with “drive page” <dialog> tags.
Example:
None.
Main Index
CHAPTER 6 123
6.4 Inputs Box

AAUI.inputs_refresh (input_id)
Description:
This function will display the required user input widgets in the Inputs Box and
prepare the PCL function associated with input_id. This call is made automatically by
the platform software when a new <dialog> is obtained.
Input:
STRING input_id[32] This value specifies the index id located in the function
definitions file.
Output:
Error Conditions:
None.
Remarks:
Example:
None.
AAUI.inputs_applycb ()
Description:
This function will call the function referenced by the inputid index on the functions
definitions text file. This call is made as part of the callback to the “Apply Inputs”
button.
Input:
Output:
Error Conditions:
None.
Remarks:
Example:
None.
Main Index
124
AAUI.selectdatabox_read_raw (num_select_databox, vstring)
Description:
This function will return the value in the specified select databox that is displayed in
the UI form “Inputs” area.
Input:
INTEGER num_select_databox This value specifies which displayed select
databox to read data from. 1 for the first select
databox displayed, 2 for the second select
databox displayed, etc.
Output:
STRING vstring[VIRTUAL] This value returns the data in the specified
select databox. The memory is allocated with in
this function.
Error Conditions:
None.
Remarks:
This is an auxiliary utility function that may be used inside of a custom PCL function that is
called by the “Apply Inputs” action. This method of obtaining data is in addition to the normal
call sequence argument value passing.
Example:
None.
AAUI.selectdatabox_read_ids (num_select_databox, num_ids, ids)
Description:
This function will process data that is displayed in a select databox on the “Inputs”
area of the UI form. It will return the ids of the entities selected. It is only supported
for specific data types, like Point, Node, Element, Curve, Surface, Solid. Duplicate
entries are eliminated.
Input:
INTEGER num_select_databox This value specifies the displayed select
databox to read data from. 1 for the first select
Output:
Main Index INTEGER num_ids This value returns the number of id values
returned.
INTEGER ids(VIRTUAL) This value returns the ids. The memory is
allocated within this function.
CHAPTER 6 125

Error Conditions:
None.
Remarks:
Example:
None.
AAUI.selectdatabox_read_coords (num_select_databox, num, x_comp,

y_comp, z_comp)
Description:
This function will process data that is displayed in a select databox on the “Inputs”
area of the UI form. It will return the global coordinate positions for either Nodes or
Points that were screen selected and displayed in a select databox.
Input:
databox to read data from.1 for the first select
Output:
INTEGER num This value returns the number of coordinates
returned.
REAL x_comp(VIRTUAL) This value returns the X coordinate values. The
memory is allocated within this function.
REAL y_comp(VIRTUAL) This value returns the Y coordinate values. The
REAL z_comp(VIRTUAL) This value returns the Z coordinate values. The
Error Conditions:
None
Remarks:
Main Index
Example:
None.
126
AAUI.selectdatabox_assread_raw (num_select_databox, entity, parent,

entity_type, assoc_entities)
Description:
This function will return a list of all entities associated with the parent entities that
were selected in the select databox.
Input:
STRING entity[] This value specifies the desired entity type.
The supported values are: “curve”, “elem”,
“node”, “point” and “surface”.
STRING parent[] This value specifies the general type of
entities contained by the select databox. The
supported values are: “geo”, and “elem”.
INTEGER entity_type This value specifies the element shape to filter
on when the entity is set to “elem”. Otherwise
it is ignored. See the remarks below for more
information.
Output:
STRING assoc_entities[VIRTUAL]This value returns a pick list of entities that
match the given criteria.
Error Conditions:
None.
Remarks:
The input value entity_type controls which element type will be returned. This data is only used
when the entity is set to “elem”. The following table identifies the entity type for each value.:
Value Entity type
0 Any Element
1 Point Element
2 Beam Element
3 Tri Element
4 Quad Element
Main Index
5 Tet Element
6 Wedge Element
7 (not used)
8 Hex Element
CHAPTER 6 127
Example:
None.
AAUI.selectdatabox_assread_ids (num_select_databox, entity, parent,

entity_type, num_ids, ids)
Description:
This function will return all the entity ids associated with the parent entities in the
select databox.
Input:
STRING entity[] This value specifies the desired entity type. The
supported values are: “curve”, “elem”, “node”,
“point” and “surface”.
STRING parent[] This value specifies the general type of entities
contained by the select databox. The supported
values are: “geo”, and “elem”.
INTEGER entity_type This value specifies the element shape to filter
on when the entity is set to “elem”. Otherwise it
is ignored. See the remarks below for more
information.
Output:
INTEGER num_ids This value returns the number of id values
returned.
INTEGER ids(VITRUAL) This value returns the ids. The memory is
allocated within this function.
Error Conditions:
None.
Remarks:
The input value entity_type controls which element type will be returned. This data is only used
when the entity is set to “elem”. The following table identifies the entity type for each value:
Value Entity type
0 Any Element
Main Index 1 Point Element
2 Beam Element
3 Tri Element
4 Quad Element
128
5 Tet Element
6 Wedge Element
7 (not used)
8 Hex Element
Example:
None.
AAUI.selectdatabox_assread_coords (num_select_databox, entity, parent,

num, x_comp, y_comp, z_comp)
Description:
This function will return the global coordinate positions for either nodes or points
associated with parent entities in the specified select databox.
Input:
INTEGER num_select_databox This value specifies the displayed select databox to
read data from.1 for the first select databox
displayed, 2 for the second select databox
displayed, etc.
STRING entity[] This value specifies the desired entity type. The
supported values are: “node” or “point”.
STRING parent[] This value specifies the general type of entities
contained by the select databox. The supported
values are: “geo”, and “elem”.
Output:
INTEGER num This value returns the number of coordinates
returned.
REAL x_comp(VIRTUAL) This value returns the X coordinate values. The
REAL y_comp(VIRTUAL) This value returns the Y coordinate values. The
REAL z_comp(VIRTUAL) This value returns the Z coordinate values. The
Error Conditions:
None.
Remarks:
Main Index
Example:
None.
CHAPTER
Drive Page Interpreting Functions
7
■ Introduction
■ PCL Function Descriptions
Main Index
134
7.1 Introduction
The PCL functions described below are the API utility functions for the drive page interpreter
functionality. Generally these functions obtain information from the XML “drive pages” and
make use of this information by executing referenced PCL function calls, or by displaying HTML
dialog to the user.
Main Index
CHAPTER 7 135
7.2 PCL Function Descriptions

AAI.html_calls (pclcalls)
Description:
This function will execute the function or functions described by the string argument
pclcalls. This call is typically listed on an HREF anchor of HTML dialog packets. This
function will parse the argument supplied into the indicated PCL function calls with
their arguments, and then make the calls.
Input:
STRING pclcalls[] This value specifies the PCL functions and all
parameters for those functions. The format is given in
the Remarks section below.
Output:
Error Conditions:
None.
Remarks:
The ‘;’(semicolon) character partitions the STRING argument into the sub strings which are then
interpreted as function names or various types of function arguments depending upon the sub
string prefixes. Since the ‘)’ character indicates the end of the call sequence to the HTML widget
hypertext reference interpreter function, this character is NOT allowed in any string type
substring or other arguments.
The FUNC: sub string prefix signifies the start of a function call name. Parse on the “F” and “:”
characters so that F: or FN: or FUNCTION: are also valid function name prefixes
The STR: sub string prefix signifies the start of a string argument., Parse on the “S” and “:”
characters so that S: or STRING: are also valid.
The REAL: sub string prefix signifies the start of a real number argument. Parse on the “R” and
“:” characters so that R: is also valid.
The INT: sub string prefix signifies the start of an integer number argument. Parse on the “I” and
“:” characters so that I: or INTEGER: are also valid.
The LOG: sub string prefix signifies the start of a logical variable argument (TRUE or FALSE).
Parse on the “L” and “:” characters so that L: or LOGICAL: are also valid
Example:
AAI.html_calls(“FUNC:function1;STR:arg1;REAL:5.05;INT:12;FUNC:function2;LOG:TRUE;FU
NC:function3;STR:string2;FUNC:function4”)
When the AAI.html_calls function processes this particular call, the following four PCL calls
are made in sequential order:
function1(“arg1”, 5.05, 12)
function2(TRUE)
function3(“string2”)
Main Index function4()
Note: Only fixed value arguments are available to PCL calls made directly by this method.
When function calls require the user to input or change argument values, the “Input Box”
functionality is used to display the required widgets and to automatically construct the
corresponding PCL calls.
136
The intended use for AAI.html_calls is to allow PCL calls to be made from HTML anchors as
shown below:
<A HREF="PCL:AAI.html_calls(FUNC:AANAV.lever_results;INT:1)">
Exaggerated </A> deformed shape.
AAI.get_step1id (step1id)
Description:
This function will return the ID of the first analysis step. A separate, special XML
drive page exists for the first analysis step. This function reads that page and searches
for the stepid tag.
Input:
Output:
STRING step1id[4] This value returns the ID found in the step tag.
Error Conditions:
None.
Remarks:
If this function fails to find the Step-1 XML page and the step ID from the step tag, then an error
message will be issued to the UI form Dialog Box HTML widget.
Note: The XML drive page for the first step is defined through the environment variable
AdvisorPAGE1.
Example:
None.
Main Index
CHAPTER 7 137
AAI.allsteps_display ()
Description:
This function will search for the <defsteps> tag on an XML page. It reads the 4
character ID and 36 character definition of steps for all analysis steps. It obtains the
step completion indications from the STATE TABLE. It calls the
AAUI.mainpanel_include_steps function to cause a display of the steps on the Main
Panel.
Input:
Output:
Error Conditions:
None.
Remarks:
A call to this function is typically made upon completion of the first analysis step on the separate
step-1 “drive page”. Step-1 determines the particular analysis type that the user will undertake,
and assigns a “nextpage” user response variable to the State Table pointing to the “home drive
page” file for all subsequent steps.
Example:
None.
AAI.init_step_dialog ()
Description:
This function will read the XML solution sequence page and follow the automated
link rules to select the correct initial dialog for a selected step. This function is called
by the user interface model in response to a user selecting an analysis step.
Input:
Output:
Error Conditions:
None.
Remarks:
Main Index This call is automatically made by the platform software when an analysis step is selected from
the main panel. Application authors are not expected to call this function directly.
Example:
None.
138
AAI.step_help_doc ()
Description:
This function will display the supplemental HTML help document associated with
the current operational analysis step, if one is specified, by launching the
MSC.Acumen BROWSER application.
Input:
Output:
Error Conditions:
None.
Remarks:
This function is called automatically as a result of selecting the “Help” button. It will display
only the document defined by an attribute to the <step> tag. Please see the
<hypertext>AAUI.helpdoc_display (p. 116) call for displaying alternative HTML documents
with a pop-up commercial browser.
Example:
None.
AAI.next_dialog (filename, filestep, dialog_id)
Description:
This function will read the XML page file, extract the HTML dialog called for, and
feed it to the UI Dialog Box HTML widget. The dialog is selected by direct reference
to the page “filename”, the step tag ID on that page file “filestep”, and the dialog tag
ID within the step tag “dialog_id”. No automated link rules are followed to get to the
dialog.
Input:
STRING filename[128] This value specifies the name of the XML file. If
the first character is a ‘/’, it is a full path,
otherwise it is a relative path from the
AdvisorLIB environment variable path.
STRING filestep[4] This value specifies the step ID.
STRING dialog_id[8] This value specifies the dialog ID.
Output:
Main Index
Error Conditions:
None.
Remarks:
CHAPTER 7 139
This call is the mechanism used to arrive at a subsequent HTML dialog upon user selection of a
hypertext link. It supports all “background” PCL calls listed as attributes to a <dialog> tag.
When widgets are displayed for a dialog, the “quedlg” or “errordlg” attributes to the <dialog>
tag automatically point to the next HTML dialog. This function is automatically called in that
case. Note the general nature of this call allows for the creation of sub-pages for common or
complex processes.
Example:
None.
Main Index
140
AAI.dynamic_next_dialog (htmlstring, filename, filestep, dialog_id)
Description:
This function will find and display HTML dialog and handle function calls associated
with the referenced <dialog> tag. In addition, this call appends the HTML contained
in the “htmlstring” argument to the front of the any HTML found in the referenced
“drive page” dialog. The <HTML> </HTML> tags from the two sources are
consolidated into one set bounding the total constructed dialog. This call enables the
dynamic construction and display of HTML dialog from automation functions. The
dialog may present information that was obtained through recent computations. To
use double quotes, “, within a PCL string that is being passed, two double quotes , ““,
are used and will be converted to one double quote within the string. See example
below.
Input:
STRING htmlstring[] This value specifies dynamically generated
HTML data to append in the front of any fixed
HTML contained in the referenced <dialog>
tag.
STRING filename[128] This value specifies the name of the XML file. If
the first character is a ‘/’, it is a full path,
otherwise it is a relative path from the
AdvisorLIB environment variable path.
STRING filestep[4] This value specifies the step ID.
STRING dialog_id[8] This value specifies the dialog ID.
Output:
Error Conditions:
None.
Remarks:
The intended use for this function is calls from an automation function as opposed to referenced
calls on “drive page” hyperlinks or tag attributes.
Example:
This is an example of how to use double quotes within a PCL dynamic string definition:
htmlstring=”<HTML><BODY BGCOLOR=””#FFFFFF””>” // @
“You have selected the material: “ // mat // ”</HTML>”
AAI.dynamic_next_dialog(htmlstring,page,stepid,”finish”)
Main Index
CHAPTER 7 141
AAI.queued_dialog ()
Description:
This function will display the next dialog HTML packet in the UI form Dialog Box
associated with the quedlg argument for the current dialog.
Input:
Output:
Error Conditions:
None.
Remarks:
This call is automatically made by the MSC.Acumen platform software as a consequence of
selecting the “Apply Inputs” button. The application author is not expected to use this call.
Example:
None.
AAI.queued_msg ()
Description:
This function will display an error condition warning dialog HTML packet in the UI
form Dialog Box. It is called when user inputs to the Inputs Box result in an error
return value.
Input:
Output:
Error Conditions:
None.
Remarks:
Example:
None.
Main Index
142
AAI.queued_ftn ()
Description:
This function will execute optional supplemental PCL function calls as requested
through the queftn argument in the dialog tag.
Input:
Output:
successfully and a non zero value to indicate a change in
status or an error.
Error Conditions:
None.
Remarks:
Example:
None.
AAI.initiate_ftn ()
Description:
through the initftn argument in the dialog tag.
Input:
Output:
Error Conditions:
None.
Remarks:
navigation to a “drive page” <dialog> tag. The application author is not expected to use this call.
Example:
None.
Main Index
CHAPTER 7 143
AAI.exit_ftn ()
Description:
through the exitftn argument in the dialog tag.
Input:
Output:
Error Conditions:
None.
Remarks:
selecting the “Apply Inputs” button or through navigating to the next dialog through an
AAI.next_dialog call. The application author is not expected to use this call.
Example:
None.
Main Index
144
Main Index
CHAPTER
General Utility Functions
8
■ Introduction
■ PCL Function Descriptions
Main Index
146
8.1 Introduction
The few PCL functions described below perform general tasks useful to authoring MSC.Acumen
applications such as converting drive pages to an indexed form for operations, and retrieving
environment information.
Main Index
CHAPTER 8 147
8.2 PCL Function Descriptions

acumen_drive_page_trans (source_page, converted_page)
Description:
This function serves as a PCL environment interface to the utility function that
compiles or indexes XML “drive pages” for more efficient reading by the
MSC.Acumen software. The first argument references a source file with the .xml file
extension. The second argument names the output indexed file with a .xio file
extension. It is convenient for application authors to invoke this call from full
featured MSC.Patran by typing it into the command line.
Input:
STRING source_page[ ] This is a string representing the name of the XML
drive page source file, for example,
“model1.xml”
STRING converted_page[ ] This is a string representing the name of the
indexed or converted drive page, for example,
“model1.xio”
Output:
An indexed .xio file is written out.
Remarks:
ALTERNATIVE METHOD - acumen_drive_page_trans.exe
In addition to the PCL call that converts or indexes drive pages, a stand-alone executable
function is available to perform the conversion. The executable code is delivered with
"application_core" directory of a MSC.Acumen installation. The name given is
"acumen_drive_page_trans.exe".
On a windows NT platform, this executable is invoked via a DOS command in a DOS window.
On UNIX, the command is typed into the command window.
Following is an example of the command invoking the stand-alone drive page converter from
the DOS prompt:
>acumen_drive_page_trans.exe placeholder filename.xml
where
placeholder: Any string value. It is not currently used by the translator.

filename: The input file name, typically drive_page.xml. The file can have any
extension.
The translator will display an output message similar to:

>acumen_drive_page_trans.exe placeholder filename.xml
Input file name: drive_page.xml
Output file name: drive_page.xio
Extension: xml
Main Index Extension delimeter: 0
Translator return value: 0
If the translation was successful, the “Translator return value” will be “0”. The output file name
will always have the .xio extension.
148
aa_env.ret_acumen_app (s_acumen_app, s_acumen_master, s_acumen_ext)
Description:
This function will retrieve the ACUMEN_APPLICATIONS directory and home drive
page file name values. This function will also verify that the named directory and file
exist.
Status: Public
Input:
None.
Output:
STRING s_acumen_app [ 1024 ]
This argument will return the
ACUMEN_APPLICATIONS directory value.
STRING s_acumen_master [ 1024 ]
This argument will return the body of the home drive
page file name defined by the
ACUMEN_APPLICATIONS environment variable.
STRING s_acumen_ext [ 1024 ]
This argument will return the extension of the home
drive page file name defined by the
ACUMEN_APPLICATIONS environment variable.
Error Conditions:
This function may return a nonzero value if an error occurs.
This function will retrieve and display to the user any error messages associated with an error
value.
The error value will be returned for flow of control purposes. Any errors that occur will be
reported directly to the user through the user interface.
This environment variable provides the path and file name for the home drive page of a user
developed MSC.Acumen application.
Main Index
CHAPTER 8 149
The following file location and name asumptions are made:

1. The master .xio and .xml files will be located directly in the home drive page directory
defined by the environment variable ACUMEN_APPLICATIONS.
2. The .def file will have the same path and base file name as the application home drive
page with a .def extension.
3. The labels file will have the same path and base file name as the application home drive
page with a .labels extension.
4. All .html help files will be in a subdirectory named "help" under the home drive page
directory.
5. The pulldown menu title definitions file will have the same path and base file name as
the home drive page with a .dwn extension.
6. Application specific .plb files will have the same path and base file name as the home
drive page with a .plb extension. If a file with the specified extension cannot be found, no
application specific .plb’s will be linked in.
7. Application specific image files (.png) will be in a subdirectory named “app_images”
located under the home drive page directory.
The default acumen_applications value will be retrieved from the environment variable
"ACUMEN_APPLICATIONS". If the environment variable "ACUMEN_APPLICATIONS" is
not defined, the value of "ACUMEN_HOME/acumen_applications/master.xio" will be used
where "master.xio" will be the default application home page name.
Example:
aa_env.ret_acumen_brw (s_acumen_brw)
Description:
This function will retrieve the acumen_browser directory and file name value. This
function will verify that the named directory and file exist.
Status: Public
Input:
None.
Output:
STRING s_acumen_brw [ 1024 ]
This argument will return the path and filename of
the browser application used to display MSC
Acumen application help messages.
Error Conditions:
Remarks:
Main Index This function will call code to retrieve and display to the user any error messages associated with
an error value.
150
The acumen_browser value will be retrieved every time this function is called, allowing the
corresponding value to be changed "on the fly". Please see the description for the PCL function
set_acumen_brw ( )
This environment variable provides the path and file name for the executable used to display
help pages for a user developed MSC.Acumen application.
Example:
aa_env.ret_acumen_home (s_acumen_home)
Description:
This function will retrieve the acumen_home directory value and will check for the
existance of the directory used to contain the MSC Acumen core shared component.
Status: Public
Input:
None.
Output:
STRING s_acumen_home [ 1024 ]
This argument will return the current acumen_home
value.
Error Conditions:
This function will return a nonzero value if an error occurs.
Remarks:
This function will call code to retrieve and display to the user any error messages associated
with an error value.
The acumen_home value will be retrieved every time this function is called, allowing the
corresponding value to be changed "on the fly"..Please see the description for the PCL function
set_acumen_home ( ).
All core .plb and status message files will be placed directly in the acumen_home directory. It is
assumed that the status message file will have the name "aa_message_core.dat".
The default acumen_home value will be retrieved from the environment variable
"ACUMEN_HOME". If the "ACUMEN_HOME" environment variable is not defined, the
default value of "P3_HOME" will be used. If "P3_HOME" is not defined, "/patran/patran3" will
be used for UNIX, "c:\msc" for WINNT.
The directory used to contain the MSC Acumen core shared component is <acumen_home>/lib
on UNIX platforms, or <acumen_home>/bin on Windows NT.
Main Index
The acumen_home will be retrieved every time this function is called, allowing the
corresponding environment variable to be changed "on the fly". Please see the description for
the PCL function set_acumen_home ( ).
CHAPTER 8 151
Example:
aa_env.ret_acumen_int ( s_acumen_int )
Description:
This function will retrieve the acumen_interface value
Status: Public
Input:
None.
Output:
STRING s_acumen_int This argument will return the path and filename of
[1024 ] the browser application used to display MSC
Acumen application help messages.
Error Conditions:
Remarks:
This function will call code to retrieve and display to the user any error messages associated
with an error value.
The acumen_interface value will be retrieved every time this function is called, allowing the
corresponding value to be changed "on the fly"..Please see the description for the PCL function
set_acumen_int ( ).
Currently MSC Acumen will accept either ENABLE or DISABLE for the acumen_interface
value.
Example:
Main Index
152
aa_env.validate_path ( s_src_path_file, s_trg_path_file)
Description:
This function will validate the existance of file with either no path, a partial path, or a
full path really exists.
Status: Public
Input:
STRING s_src_path_file [ 1024 ]
This value contains a file name with either no path,
a partial path, or a full path
Output:
STRING s_trg_path_file [ 1024 ]
This value returns a string representing the path
used for the test.
Error Conditions:
Remarks:
This function will check the input string for the following condition:
1. The first character is either a UNIX style “/” or a WINNT style”\”.
2. The second character is a colon (“:”).
If either one of these conditions is meet, it will be assumed that the input string represents a full
path.
If neither of these conditions are met, it will be assumed that the path is relative to the
ACUMEN_APPLICATIONS directory.
Example:
Main Index
I N D E X
MSC.Acumen Application Author’s Guide
I N D E X
MSC.Acumen
Application
Author’s Guide A 105
AASTATE.overwrite_uresponse, 106
Authoring PCL AASTATE.record_ur_integer, 93
AAI.allsteps_display, 137 AASTATE.record_ur_integerarray, 93
AAI.dynamic_next_dialog, 140 AASTATE.record_ur_real, 92, 147
AAI.get_step1id, 136 AASTATE.record_ur_realarray, 92
AAI.html_calls, 135 AASTATE.record_ur_string, 95
AAI.init_step_dialog, 137 AASTATE.record_ur_stringarray, 95
AAI.next_dialog, 138 AASTATE.record_uresponse, 96
AAI.step_help_doc, 138 AASTATE.restore_oldstate, 110
AASTATE.dumphistory, 108 AASTATE.store_objectives, 110
AASTATE.get_ur_integer, 98 AAUI.backup_enable, 121
AASTATE.get_ur_integerarray, 99 AAUI.backup_status, 120
AASTATE.get_ur_real, 97 AAUI.helpdoc_display, 117
AASTATE.get_ur_realarray, 97 AAUI.mainpanel_currentstep, 112
AASTATE.get_ur_string, 99 AAUI.mainpanel_include_steps, 112
AASTATE.get_ur_stringarray, 100 AAUI.mainpanel_lock_steps, 113
AASTATE.get_uresponse, 101 AAUI.mainpanel_step_complete, 113
AASTATE.overwrite_ur_integer, 103 AAUI.mainpanel_unlock_steps, 114
AASTATE.overwrite_ur_integerarray, AAUI.mainpanel_unselect_steps, 114
104 AAUI.quit_quitcb, 119
AASTATE.overwrite_ur_real, 102 AAUI.selectdatabox_assread_coords,
AASTATE.overwrite_ur_realarray, 102 130
AASTATE.overwrite_ur_string, 104 AAUI.selectdatabox_assread_ids, 129
AASTATE.overwrite_ur_stringarray, AAUI.selectdatabox_assread_raw, 128
AAUI.selectdatabox_read_coords, 126
AAUI.selectdatabox_read_ids, 125
AAUI.selectdatabox_read_raw, 125
AAUI.switch_highlight, 115
AAUI.switch_highlight_restorer, 115
Main Index
INDEX 154
H
HTML
<advisor>, 51
<defsteps>, 53
<dialog>, 58
<ds>, 53
<lrule>, 57
<response>, 57
<returnerror>, 61
<step>, 54
<uresponse>, 55
Standard HTML tags supported, 62
N
Not Recommended for Authors
AAI.exit_ftn, 143
AAI.initiate_ftn, 142
AAI.queued_dialog, 141
AAI.queued_ftn, 142
AAI.queued_msg, 141
AASTATE.previous_dialog, 108
AASTATE.record_dialog, 107
AASTATE.record_lrule, 107
AAUI.backup_backupcb, 120
AAUI.dialog_put_text, 123
AAUI.inputs_applycb, 124
AAUI.inputs_refresh, 124
AAUI.notify_backup_done, 121
AAUI.quickreview_quickcb, 119
AAUI.sthelp_helpcb, 117
Main Index

MSC - Acumen 2006 Application Author's Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MSC - Acumen 2006 Application Author's Guide

Hochgeladen von

Copyright:

Verfügbare Formate

MSC.

Preface ■ Technical Support, x

■ Drive Page Style Guide, 23

■ Supported HTML tags and options, 62

■ Retrieve User Response Variable, 97

■ Overwrite User Response Variable, 102

■ General Access to the State Table, 107

■ Dialog Box, 123

■ Inputs Box, 124

INDEX ■ MSC.Acumen Author’s Guide

■ List of MSC.Patran Books

■ Permission to Copy and Distribute MSC Documentation

List of MSC.Patran Books

Installation and Release Guides

User’s Guides and Reference Manuals

MSC.Patran Support mscpatran.support@mscsoftware.com

Course Information and Registration. For detailed course descriptions, schedule

Simulation Center (simulate.engineering-e.com)

Process Architecture Lab (PAL) (pal.mscsoftware.com/services/pal)

Permission to Copy and Distribute MSC Documentation

Please complete and mail to MSC for approval:

Please do not write below this line.

APPROVED: MSC.Software Corporation

■ Why an MSC.Acumen Application?

1.2 Product Overview

Typical File Structure for an MSC.Acumen Installation

Core Run –Time Software Libraries Installation and File Structure

Specific MSC.Acumen Applications Installation and File Structure

Run-Time Environment Variables Set by the Invoking Script File

“ACUMEN_HOME”/lib for UNIX and “ACUMEN_HOME”/bin for

• ENABLE - Display the full featured MSC.Patran interface with an

1.3 What is an MSC.Acumen Application?

1.4 Why an MSC.Acumen Application?

Step Selection Box

1.5 Principles for Effective Application Development

1.6 MSC.Acumen Data Flow Diagrams

Detailed Data Flow

■ How is PCL called from drive pages?

■ Supported HTML tags and options

2.1 Drive Page Overview

2.2 Elements of a Drive Page

Page 1, as defined by the ACUMEN_APPLICATIONS environment variable, is the “Home

</HTML> </HTML> </HTML> </HTML>

<Dialog> <Dialog> <Dialog> <Dialog>

</HTML> </HTML> </HTML> </HTML>

<Dialog> <Dialog> <Dialog> <Dialog>

</HTML> </HTML> </HTML> </HTML>

</HTML> </HTML> </HTML> </HTML>

2.3 Drive Page Style Guide

2.4 How is PCL called from drive pages?

2.5 AANAV and AACHECK class functions

2.6 Philosophy of Drive Page vs. AANAV Class

2.7 Example of a Home Drive Page (Step 1)

Added lrule to prevent 'reentry' into step one

Last Revision Date: 2/18/99 -->

<step stepid="1." stephelp="st1help.html" >

<dialog dlgid="new2" inputid="new_db_open_nastranpref"

<dialog dlgid="new2err" inputid="new_db_open_nastranpref"

<dialog dlgid="new3" inputid="null">

FUNC:AANAV.step_wrapup;FUNC:AAI.allsteps_display)">Rotor</a> Thermal Dimensioning

<dialog dlgid="old2" inputid="existing_db_open"

<dialog dlgid="st1ck1" inputid="null">

<dialog dlgid="st1ck2" inputid="null">