XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''"> Principles for Effective Application Development
Authoring Tutorial applications requires two distinct phases:
• The definition phase.
• The implementation phase.
• And for Tutorial applications that will be included in the “Help”/”Tutorials” pull down menu, the integration phase.
Following are principles that apply to these two development phases.
DEFINITION PHASE:
2. 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.
3. 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.
4. 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.
5. 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 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 documentation process.
6. 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.
7. Patran includes demonstration session files under the “Analysis” “Run Demo” form. These session files and the demonstration presentations that were used to make them can be translated directly into Tutorial applications that can be integrated into Patran through the “Help” “Tutorials” pull down menu. For more information about translating session files into PCL files please see,
Session Files to PCL Files (p. 16) in the PCL Reference Manual.
IMPLEMENTATION PHASE:
1. 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. A Patran demo or presentation can often be used as a flow chart to get the design process started.
2. 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,
Example of a Home Drive Page (Step 1), 25.
3. 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.
4. 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.
5. 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. <!--accentuated with comment statements --> as opposed to hiding them inside of PCL functions.
6. 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.
7. 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.
8. 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.
INTEGRATION PHASE:
A Tutorial application can be integrated into the “Help” “Tutorials” application in the following manner:
2. Decide where the application will reside in <P3_HOME>/tutorial_apps/<your_app_here>
3. Create a .pcl file with some kind of setup function that will be called:
• An example of a function like this is in <P3_HOME>/tutorial_apps/clevis_pin.pcl
• Use file_add_path() to add the application directory <P3_HOME>/tutorial_apps/<your_app_here> to the list of paths searched by Patran for file I/O operations.
• Load the application specific .plb file.
• Call ui_htmlbrsr_set_image_path () to redefine the HTML_IMAGE_PATH to point to the appropriate directory for application images.
• Call set_acumen_app () to define the ACUMEN_APPLICATIONS path and file name.
• Call the following functions:
AAUI.mainpanel_unlock_steps ( )
AAUI.reset_step_label ( "1.", "Open a Database" )
AAUI.mainpanel_lock_steps ( )
AAI.next_dialog ( "pcc.xio", "1.", "start" )
4. Compile the pcl file that you created and add it to the tutorial.plb file using patran with the following command.
!!compile <your_source>.pcl into tutorial.plb
5. Edit <P3_HOME>/tutorial_apps/tutorial.xml. The main tutorial drive page is a bulleted list of applications HREF links. Your application can be added to this list with something similar to the following lines of code:
<LI>
<A HREF="PCL:AAI.html_calls( FUNC:break_lever.setup_app )">Break Lever</A>
</LI>
6. Concatenate your application .def file onto the <P3_HOME>/tutorial_apps/tutorial.def file.
7. Start up Patran, go to “Help” “Tutorials” to start up the Tutorial application. The Tutorial core code will compile the modified tutorial.xml into the appropriate tutorial.xio, load it and start the applicaton. Scroll down to your application, select the link, and start debugging.
The Tutorial application is really an application of applications. The home drive page for the Tutorial application is intended only for use in launching other applications.