Manual Pam Stamp

(1)

PAM-STAMP 2G 2012

(2)

(3)

October 2012 GR/PAST/12/03/00/A

PAM-STAMP 2G 2012

USER’S GUIDE

The documents and related know-how herein provided by ESI Group subject to contractual conditions are to remain confidential. The CLIENT shall not disclose the documentation and/or related know-how in whole or in part to any third party

(4)

(5)

CONTENTS

ABOUT THIS DOCUMENT

1

Attributes /Functionalities Chapters --- 1

INTRODUCTION

5

PAM-STAMP 2G Overview --- 5

PRODUCT START UP

15

ASCII Input --- 15 Customization --- 18 Files --- 23

Solver Manager Configuration --- 32

Solver Manager Start --- 40

Solver Manager Activity --- 43

Calculation Stop --- 44

FINITE ELEMENT AND NUMERICAL MODELS

45

Algorithm --- 45

Time Step & Increments --- 59

Elements --- 68

Material Properties --- 76

HILL 48 Material Law --- 80

HILL’s 90 Material Law --- 84

BARLAT89 Material Law --- 86

VEGTER Material Law --- 92

Matfem Failure Criterion --- 100

SUPERPLASTIC Material Law --- 106

Mooney-Rivlin Material Law --- 112

Material Hardening Laws --- 113

Thermal Material Option --- 130

MetallurgIcal Material Option --- 137

EWK Rupture Model --- 148

Material File Format (.psm) --- 155

SIMULATION CONCEPTS

175

Contact and Friction --- 175

Objects & Attributes --- 193

Kinematics --- 200

Force and Pressure --- 206

(6)

CONTENTS Rigid Body --- 217 Adaptive Meshing --- 223 Drawbead --- 232 Symmetry Plane --- 258 Picking --- 260

Distributed Memory Process (DMP) --- 265

Process Setup --- 271

Offset --- 285

Mesh Check and Cleanup --- 290

Filleting --- 297 Substructuring --- 301 Mapping --- 309 Mapping Files --- 317 User-Defined Attribute --- 332

ANALYSIS TOOLS

335

Contours--- 335

Forming Limit Diagram (FLD) --- 349

Draw-In Tools --- 356

Blank Shifting --- 362

Solver Analysis Tools --- 365

User Interface Analysis Tools --- 371

Scripting --- 383

Reporting --- 390

SIMULATION METHODOLOGY FOR DESIGN AND

STAMPING FEASIBILITY

397

Introduction --- 397

Customization --- 399

Die Design (PAM-DIEMAKER) --- 406

Part Preparation for Die Design (PAM-DIEMAKER) --- 411

Evaluation of the Tool Design (Pam-QuikStamp PLUS) --- 421

Process Verification (Pam-Autostamp) --- 441

Binder Generation for Die Design (PAM-DIEMAKER) --- 461

Run-Offs and Addendum Generation for Die Design (PAM-DIEMAKER) --- 465

Re-Engineering the Die Face (PAM-DIEMAKER) --- 479

Process Verification: Penalty Contact (Pam-autostamp) --- 484

Iteration on Design and Stamping Feasibility --- 488

SIMULATION METHODOLOGY FOR STANDARD

FORMING

497

Creation of the Tools --- 509

(7)

CONTENTS

Creation of DRAWBEADS --- 547

Analysis Entities --- 549

Process Setup --- 550

Simulation and Postprocess --- 564

SIMULATION METHODOLOGY FOR SPECIFIC

PROCESSES

567

Tailored and Patchwork Blanks --- 567

Hot Forming --- 582

Flanging --- 617

Roll Hemming --- 623

Hemming --- 663

Control Table --- 664

Die Compensation and Multi-op --- 670

Blank and Trimming Line Optimization --- 697

Springback Measurement --- 716

Cosmetic Defects Analysis --- 736

Press Force Analysis --- 751

Volume Blank --- 758

Simulation with Ironing - T.T.S Element --- 765

Gas Springs --- 768

Drawslit or Lancing --- 771

CRASHFORMING --- 773

Stamping Inverse --- 774

SIMULATION METHODOLOGY FOR TUBE

789

Tube Design Module (PAM-TUBEMAKER) --- 799

Bending Simulation Feasibility --- 826

Tube Bending --- 834

Tube Hydroforming --- 843

DELTAMESH

855

CAD Model Exchange from CAD Systems to DeltaMESH --- 858

Meshing Access --- 898

DeltaMESH Parameters --- 902

Mesh Check and Repair --- 919

The Remeshing Action --- 931

The Multipatching Action --- 937

Other DeltaMESH Actions --- 942

(8)

(9)

ABOUT THIS DOCUMENT Attributes /Functionalities Chapters

ABOUT THIS DOCUMENT

ATTRIBUTES /FUNCTIONALITIES CHAPTERS

Here is a list of the chapters on the User’s Guide describing the attributes and functionalities available in PAM-STAMP 2G.

For Pam Quikstamp plus project, the user must also refer to the Evaluation of the tool design (Pam Quikstamp) chapter in the Simulation Methodology for design and stamping feasibility section.

For Inverse project, the user must refer to the Stamping Inverse chapter in the Simulation concepts section and to the Tube Inverse chapter in the Simulation methodology for tube section.

ATTRIBUTES: /FUNCTIONALITIES

SECTION CHAPTER PAGE

Analysis _{Simulation methodology for} Standard Forming

Analysis entities ₅₅₆

Aquadraw Simulation Concepts

Fluid Cell 209

Autopositioning

Simulation methodology for Standard Forming

Process setup 557

Behavior

Simulation methodology for Specific Processes

Gas Springs 777

Blank Meshing Simulation methodology for

Standard Forming Evaluation of the _{tool design} 545

Simulation methodology for

Specific Processes Optimization 706 Boundary Condition on

points

Simulation concepts Kinematics 200

Springback measurement

(10)

ABOUT THIS DOCUMENT

Attributes /Functionalities Chapters

Cartesian kinematics Simulation concepts Kinematics 200 Contact Simulation concepts Contact and

Friction

175 Cooling Channel Simulation methodology for

Specific Processes

HotForming 609

CPU Control Finite element and numerical models

Time Step & Increments

59 Damage Finite element and

numerical models

EWK Rupture Model

137 Drawbead Forces Simulation concepts Drawbead 237 Drawbead definition Simulation concepts Drawbead 237

DMP Simulation concepts DMP 266

Simulation for Specific Processes

Rollhemming 631

Dynamic Freeze

Simulation concepts Kinematics 204

Simulation for Specific Processes /

Element elimination Analysis tools / Solver analysis tools

368 Fluid Cell Simulation concepts / Fluid Cell 209 Follower force

Simulation concepts / Force & Pressure 207

Rollhemming

Force Simulation concepts Force & Pressure 206

Freeze Simulation concepts Kinematics 203

Gravity Simulation methodology for Standard Forming

Process setup 557

Finite element and numerical models

Algorithms 45

Gluing Contact Simulation concepts Contact and Friction

175 Kinematic Path Simulation for Specific

Processes

Ironing Simulation for Specific Processes

Simulation with Ironing-TTS Element

774

Mapping Simulation concepts Mapping 311

Mesh

Simulation methodology for Standard Forming

process setup 557

Multi body system Simulation concepts Rigid Body 217

Optimization Simulation for Specific Processes

(11)

ABOUT THIS DOCUMENT Attributes /Functionalities Chapters Path Definition Simulation for Specific

Processes

Phase transformation Simulation for Numerical Models

Metallurgical material option

163

Picking Simulation concepts Picking 261

Press Force Analysis Simulation methodology for Specific Processes

Press Force analysis

760 Pressure Simulation concepts Force & Pressure 206 Quenching Simulation methodology for

Specific Processes

HotForming 590

Refinement Simulation concepts Adaptive meshing

264

Rigid Body Simulation concepts Rigid body 217

Robot Components Simulation for Specific Processes

Rotational kinematics Simulation concepts Kinematics 200 Solver Manager Product startup Solver

configuration

32 Springback

Springback measurement

725

Substructure Simulation concepts Substructure 303

Surface defect analysis

504

Symmetry Plane Simulation concepts Symmetry plane 259 Thermal properties Finite element and

numerical models

Thermal material option

Hotforming 590

Trimming Simulation methodology for Standard Forming

Process setup 557 User-Defined Simulation concepts User Defined

Attribute

130 Values scaling Simulation concepts Picking 261

(12)

(13)

INTRODUCTION PAM-STAMP 2G Overview

INTRODUCTION

PAM-STAMP 2G OVERVIEW

PAM-STAMP 2G is available as a ‘professional’ package. Essentially, it offers the user access to a significant number of options by using a flexible license ‘token’ approach. Included in PAM-STAMP 2G v2012:

 PAM-STAMP INVERSE: for estimation of the developed part blank shape and very early feasibility studies on part.

 PAM-DIEMAKER: for the design of the die

 DELTAMESH: as meshing module

 PAM-QUIKSTAMP: for feasibility analysis

 PAM-AUTOSTAMP: for validation and optimization of sheet metal forming processes

PamStamp 2G v2012 proposes:

the simulation of major sheet metal forming processes, like:

 Rollhemming

 Hotforming

 Super Plastic forming

 Hydro forming

 Tube forming

 The Stamp Toolkit enables the customization of all processes like Rubber pad

forming or stretch forming.

optimization and modification functionalities, like:

 Die compensation combined with surface reconstruction with iCapp PanelShop

 Blank and trim line optimization

 Morphing

 Filleting with Deltamesh fillet

 Substructuring for local iterations

(14)

INTRODUCTION

PAM-STAMP 2G Overview

dedicated analysis tools, like

 Cosmetic defect analysis

 Draw-in analysis

 Reporting tools

dedicated material models, like:

 Corus Vegter material Model

 Matfem Crach material Model

 Yoshida material Model

 Ito-Goya material model

 Superplastic material models

Environment

Common environment

All modules proposed within PAM-STAMP 2G share the same

environment.

Switching between modules is easy and guided when necessary

Dedicated contexts

Dedicated contexts are proposed for an automatic customization of the

environment based on the selected process.

(15)

Customized environment

PamStamp 2G environment is fully customizable by company or by user. It can be adapted to the customer needs, by creating his own toolbars, process macro-commands, user-defined contours, or by defining the default parameters he wants to use.

PAM-INVERSE

PAM-INVERSE is a one step or inverse solver, designed to make;

 Developed part blank shape estimation for costing purposes.

 Very early feasibility studies on PART geometry, prior to die design

Inverse solvers are designed to run very fast, but only to give 1st impression of component feasibility. Basic usage is to make 2 simulations to test the two extremes of material movement ‘free boundary’ and ‘locked’ boundary. In this sense it can be considered as a go / no-go gauge for component feasibility checking.

(16)

INTRODUCTION

PAM-DIEMAKER

From an imported CAD geometry, PAM-DIEMAKER allows the user to design and optimize the binder surface and die addendum in just minutes. Its rapid and iterative parametric approach generates a realistic simulation model, allowing the user to quickly evaluate the part’s formability with QUIKSTAMP. Tipping direction, binder surface and addendum geometry can easily be modified, allowing total control of upfront design processes such as the number of stages and multi-parts grouping.

Highlights:

Parametric modeling

PAM-DIEMAKER can be used starting from a CAD file of the part, with no tooling information available: the user constructs the die geometry from nothing by preparing the part geometry, by defining a binder surface and by constructing the run-off. In many cases, a new die design would be based on an already existing geometry. As such, it is much easier to just take this geometry as a reference and make the appropriate changes to certain zones rather than to entirely re-construct this die.

The parametric re-engineering covers this latter methodology and allows the user to re-construct a parametric surface model in very short time. The re-engineering starts from an existing die geometry (CAD or scanned data) and re-creates the necessary surface information step-by-step, resulting in a 3D parametric model of the initial tool, that can e.g. be used to perform binder or run-off modifications or to exchange the part geometry.

(17)

PAM-QUIKSTAMP Plus

PAM-QUIKSTAMP allows the die designer to check and evaluate different die geometry parameters like binder surface and die addendum, including swages and die walls. PAM-QUIKSTAMP provides a fast formability evaluation, and represents the optimal compromise between accuracy, time and computing resources.

Since PAM-QUIKSTAMP does not require high quality mesh for tools, it is very easy to iterate and optimize the process.

Taking into account elasto-plastic behavior, friction, blankholder pressure, drawbead and cutting pattern, it carries out a fast and reliable 3D evaluation within minutes and eliminates erroneous choices at the conceptual design stage.

(18)

INTRODUCTION

PAM-AUTOSTAMP

PAM-AUTOSTAMP allows the user to master virtual try-out of the stamping process taking into account the full process with industrial conditions such as gravity, binder development, multi-stage forming, draw, restrike, trimming, springback, flanging and hemming. PAM-AUTOSTAMP guides the user through the final validation of forming process, tolerances and overall quality control, helping to avoid costly and time-consuming downstream problems. PAM-AUTOSTAMP also includes a state-of-the-art implicit solver technology, enabling fast accurate springback predictions.

The scope of processes which could be modeled is continuously increasing, and includes hotforming, rollhemming, double blank forming, spot-welded blanks, rubber-pad forming, super-plastic forming and multistage tube forming processes, in addition to the standard stamping, tube bending, tube and sheet hydroforming processes.

Problems which can be detected include conventional formability issues of splits and wrinkles, but also subtle quality issues such as cosmetic defects, slip lines, marks, and dimensional stability after springback.

Optimization tools help finding solutions to the detected problems. Blank or trim line optimization are useful for designing the correct initial blank shape and right trim lines, and Die compensation modifies automatically the die for reaching the good final shape after springback.

(19)

PAM-TUBE

PAM-TUBE INVERSE

PAM-INVERSE offers a very fast simulation tool for non-critical bending operations and for general feasibility checks as a preforming step for hydroforming. An advisor is included that will determine if PAM-INVERSE is a suitable simulation method.

With PAM-INVERSE bending operations of any circular, conical or user-defined profile can be simulated.

PAM-TUBEMAKER

From an imported CAD geometry, PAM-TUBEMAKER allows the user to design and optimize the bending or hydroforming process in just minutes. Its rapid and iterative parametric approach generates a realistic simulation model, allowing the user to quickly evaluate the part’s formability. Process and tool design can easily be modified, allowing total control of upfront design processes such as the number of stages and multi-parts grouping.

PAM-TUBEMAKER easily reads CAD data in IGES and VDA format. While reading the CAD surface information, it automatically meshes the surfaces as well using state of the art meshing technology from DeltaMESH. Next to the direct treatment of CAD surfaces, TUBEMAKER also imports various mesh formats, such as PAM-SYSTEM, ‘universal (.unv)’ and ‘Nastran (.nas)’.

On user interface level, PAM-TUBEMAKER tries to propose for the user process and tool design parameters by following as much as possible the objective of finding a feasible process setup. At the same time full flexibility is given, and the user has at all points the full control on the design.

(20)

INTRODUCTION

DELTAMESH

The complete integration of DeltaMESH Stamping into PAM-STAMP 2G offers full functionality of automatic meshing within the software. With DeltaMESH meshing the user is certain to obtain a high quality mesh allowing to rapidly start the design process. As a good simulation result requires a good mesh, DeltaMESH will do just that: based on the initial CAD file, the program will automatically generate a connected mesh.

 Fully automatic surface mesher integrated into the PAM-STAMP 2G environment that

delivers high quality mesh results

 Consecutive steps for import / joining /

meshing can be handled automatically or

interactively:

o Reads IGES / VDA format

o Joins surfaces with thin surface, hole, gap or overlap tolerance

o Automatic meshing algorithms based on uniform, parametric and

progressive meshing

 Optional post-meshing operation:

Automatic localized re-meshing according to some element quality criteria

DeltaMESH Fillet

DeltaMESH Fillet integrated in PAM-STAMP 2G offers full functionality of automatic filleting. With DeltaMESH Fillet the user is certain to obtain a high quality fillet mesh on sharp edges allowing to start the process simulation as early as possible. Basically, good stamping simulation results require a good mesh on radii in order to accurately represent the metal flow phenomena and related physics. This will allow the user to control the global filleting and the local radii as well.

DeltaMESH Stamping Inverse

This integration of DeltaMESH Stamping Inverse into PAM-STAMP 2G allows generating fully automatically a FEM quality mesh dedicated to the inverse method solver. The generation of this patch-independent mesh, consists in importing either a CAD model or a DeltaMESH geometrical database and joining it (topological model creation). DeltaMESH Stamping Inverse will create zones from connected face groups (for example, blankholder …). Thus, we obtain a mesh coarser than DeltaMESH Stamping mesh but with finite element quality

(21)

Calculation Code

PAM-STAMP2G is a calculation code that uses the finite element method (FEM). All the components of a calculation (metal sheet or tube, tools, …) are shown as meshes, i.e. a discrete representation of the geometry.

For non-deformable tools, the mesh is only a representation of the geometry, and the finite elements are only facets to be used for contact description. On the contrary, for the blank, the tube or a deformable tool, the finite elements forming this mesh represent small pieces of the material with a prescribed behavior.

The mechanical phenomena that occur in a blank or in a tube are faithfully reproduced using a large number of these elements. Within reason, the finer the mesh to be

generated, the better the quality of the results, whereas the higher the number of elements, the longer the calculation time. Note that in a simulation, a detail whose size is smaller than that of the elements cannot be represented: the size of the elements defines the precision of the simulation.

A finite element can be a 2-node (bar), a 3-node element (triangle), a 4-node element (quadrangle), a 6- or 8-node volume element (hexahedron), and it is constructed from nodes that are defined in its corners. Each node has two types of degrees of freedom: translation and rotation. The translation degree of freedom of a node represents its ability to move in translation along a direction, whereas a rotation degree of freedom of a node represents its ability to rotate about an axis. A node with three degrees of

freedom in translation and three degrees of freedom in rotation can move along three axes – X, Y and Z – and can rotate about these three axes.

Depending on the calculation type (implicit or explicit) the calculation is sub-divided into increments or time-steps. Generally, implicit increments are large with respect to the explicit time-steps.

Positions, velocities, accelerations and forces are permanently calculated at the nodes, which are points linked to the material. Within the elements, strains are calculated from positions.

element nodes

mesh

Corresponding stresses are then obtained, which result in forces on the nodes. This calculation is repeated over all the elements for the entire duration of the calculation. Boundary conditions are used to remove degrees of freedom (locking), while velocities and forces further define the kinematic behavior of the finite element model.

To describe the actual deformation process, material properties and thickness must be assigned to an element.

(22)

(23)

PRODUCT START UP ASCII Input

PRODUCT START UP

ASCII INPUT

Purpose

For all projects, the data set-up is stored in the .pre file of the project, which is a binary file. However, the application offers the user the possibility of having ASCII input files, enabling him to modify manually or automatically the data set-up without opening the GUI.

Data Input File

The data set-up of a simulation is described with the attributes. The .att file is the ASCII file that contains the multistage data set-up that means the attributes of all the simulations that will be launched one after each other.

Writing of the file

The .att file is automatically written when starting the simulation if the option Write the input file and start the

calculation is activated.

It is also possible to write the .att file without running the simulation, with the option Write input file only.

Default

· By default the option Write the input file and start the calculation

(24)

Simulation launching

When the simulation is launched, if there are in the same project directory both the projectname.pre and a projectname.att files, the information of the .att file is transmitted to the solver instead of the information of the .pre file.

Data reading

If there are in the same project directory both a projectname.pre and a projectname.att files, the information of the .att file is read instead of the

information of the .pre file. The user can so modify manually the .att file and update then the .pre file by opening the project and saving it.

Mesh Input File

The mesh used for a simulation is contained in the .pre file. However it is possible to write ASCII mesh input file (.mif).

Writing of the file

The .mif file can be exported using the Export mesh menu with the mesh input file format (.mif). A name different from the project name can be given.

The Mif format is as follow:

- The .mif file contains all the mesh needed by the solver to run a calculation (nodes, elements, 3D curves, objects, and picked restart files information).

- The file is divided in sections starting by a keyword with DEF_ prefix, and ending by the start of another section or the end of the file. Each section can occur once in the file. The section can be associated to a parameter, which is the count of entities that are written in the section (to accelerate the loading time in allocating once the entities).

- Within each section, several entries can be defined, with associated parameters (each parameter which is preceded by ‘/’ character).

- Blank lines are authorized (i.e. lines without character or with space or tab characters).

- Comment lines can be added, if they start with a ‘#’ character. They will not be read by the GUI nor the solver.

- The lines must not exceed 256 characters.

Remarks:

· The difference with the other export formats management is that not only the

visible entities will be exported, but all the mesh, and that picking data will be exported also.

(25)

Simulation launching

The launch of a simulation with a MIF file, is done by a command line using the .att file instead of the .pre file.

The .att file must be modified to specify the mesh input file that the user wants to use for the simulation:

After the section DEF_SOLVER, the following section has to be manually added: DEF_MODEL_INPUT_FILE

FILENAME = ‘name of the .mif file to be used’

Data reading

The results of the simulation will be loaded, when the user loads any of the result files. A .psp file is then automatically created.

Note:

· It is possible to import the mesh with the .mif format via the import mesh menu, using the options Keep identifiers and Keep thicknesses.

(26)

PRODUCT START UP Customization

CUSTOMIZATION

The software allows the user to adapt the program to his needs, by creating his own toolbars and process macro-commands, or by easily defining the default parameters he wants to use. All such customizations are described in this chapter.

Some of the customization data is stored in a separate configuration file (both in the installation directory and the main users’ directory) and can be manually modified. This is also further explained.

Customization stored in the ‘users’ file, can be copied into the ‘installation’ file if you require specific ‘site’ customization, for example to implement standards across a company.

Toolbars

It is possible for the user to create his own toolbars with the View / Toolbars /

Customize option. This dialog box contains five tabs:

- Commands: All the options available for pre-processing, solver and post-processing are summarized according to their order in the Menu Bar. Individual tasks are

chosen and added to the new user’s toolbar from this list.

- Toolbars: Default toolbars available in the program are listed. They can be activated or not. If activated, the toolbar tasks are shown in the upper part of a graphical window. If the user prefers to have icons of tasks coupled with text labels, the Show text labels option has to be activated too. New toolbars can be created, the options available in this toolbar must be chosen in the Commands list. These custom toolbars can be modified, renamed or deleted whenever necessary.

- External tools: This allows the user to define links from within the GUI to external software tools, for example a calculator, or a spreadsheet etc.

- Keyboard: This allows the user to define shortcut keys, which can be assigned to any action, making routine work more efficient.

(27)

PRODUCT START UP Customization - Menu: It is used for the Menu Bar and a Context menus definition:

· Menu Bar: It can be chosen from several menu types (Curve Editor, Macro edit, etc.) specified for each kind of user’s work.

· Context menu: Four context menu options (2D Settings, 2D View, 3D View and FLD View) can be used. The 3D View Menu called "right-click" menu is

automatically activated. Most of the options of this "right-click" menu are also accessible through the Menu Bar, but some of them can only be used through the former. New items can be added from the Commands list.

- Positions: Enables reset all windows and toolbar positions.

- Options: Enables defining some menu properties like displaying screen tips on toolbars, large icons, etc.

Advanced Mode

Advanced mode currently is used to access the Stamp Tool Kit options. This function is generally designed to be used by the site Advanced User. If Advanced user mode is not activated, the Stamp Tool Kit options will not be available.

It is possible to activate permanently the Advanced Mode in the Customize Macro page

Licenses

It is possible to select here which options will be available; the corresponding tokens will be taken by the program.

If the user does not have enough tokens, a message will be displayed in the console. The status of the Customize tokens menu is stored in the configuration file.

If there are not enough tokens when launching the application with the saved license

customize configuration, a message appears and the Customize tokens menu is opened.

Warning:

· The license configuration is saved

when a user saves a new configuration in the general customize menu.

(28)

Default Parameters

The default parameters and settings

proposed by the program can be defined for each user (user login). They are stored in the configuration file.

The Customize / Options menu allows the user to specify the following parameters:

- Design: Default PAM-DIEMAKER and PAM-TUBEMAKER parameters can be defined in this page. See Simulation Methodology for Design and Stamping feasability and Simulation Methodology for Tube sections for further information. - DeltaMesh: The Import, Joining, Meshing, Inverse meshing and Remeshing default

parameters are defined here. The Meshing strategy can also be created and customized as default in this page. See Deltamesh section for further information. - Process: Default values of AutoStamp attributes are defined in the Process page.

The Default unit system is also defined here, as the Check data before starting option (It forces an attribute check to be done prior to launching the solver, giving the user the possibility to detect input errors without wasting solver time). Automatic Blank meshing can be deactivated here. See Blank editor chapter for further information. Parameters of Die compensation are defined on this page as well. Users, who want to use Tool editor before Blank editor in general workflow can deactivate Blank editor before Tool editor option through this page.

- Files location: This page enables the user to define the default files location, especially when using Import Export and functionalities. It is also used when opening a Project or the Material Database. The Solver Host definition with the location of the executable used for the simulation as the eventual equivalences between disk names must be defined here.

- GUI Parameters: All the default Display options are saved in this page, as the Camera movement and the 2D Section display. Reporting tools setting are defined here. The Activate ‘undo’ feature allows the user to activate the ‘undo’ function. By

(29)

PRODUCT START UP Customization default it is on. See User interface analysis tools chapter for further information. It is possible to define Search radius for Local Min/Max annotations here as well.

- Geometry: In this page are saved the default values used for the mesh Orientation, for the Offset functionality and for the 3D curve editor. See offset chapter for further information.

- Contours: Each contours option is by default activated or not in this page. See Contours chapter for further information. FLD contours options and Maximum angle on a face for Thickness of solids contour are defined on this page.

- ToolEditor: Default Tool editor values are saved in this page. See the offset chapter for further information. Default initial blank mesh size (used if automatic meshing is not active) can be set here. See Blank editor chapter for further information. It is possible to define Flanging tool parameters on this page as well.

- Macro: Process macro options are defined here. See Process macro chapter for further information.

Note :

· Refer to the Reference manual for more detailed information on each

functionality of the Custom options menu.

Customization File

All of the above customizations are actually stored in an ASCII file that can reside in two locations. The main customization file is located within the installation directory and ensures general customization for all users. For more personalized customization the software also generates a customization file in the user’s main directory. For Windows it is:

C:\Documents and Settings\<user_name>

while on Unix this would be depending on the system that is used, e.g.: /usr/local/<user_name>

The name of the personal configuration file is defined by default as stamp2G.cfg, but can be modified by the user. For Windows users, modifying the startup batch script that resides in the installation directory can do this.

When starting the application, the main configuration file is read first, followed by the personal customization file. Any settings already defined by the main customization are overwritten by the personal customization file.

The customization files are in ASCII format, so they can be read and modified by administrators if necessary.

(30)

Macro-Command

The software is able to automatically perform successive operations, which generally occur during the data setup of each step of a ‘standard’ simulation. These tools, thanks to which the user does not have to perform several manipulations during the data setup, are the macros. For ‘standard’ processes, nearly the whole data setup is performed by the process macro; therefore a full data setup can be done in a few minutes.

Further explanations about the Stamp Tool Kit are given in the Process Macro and offsetchapters of this document.

(31)

PRODUCT START UP Files

FILES

Numerous files are used by PAM-STAMP 2G. Each has a very precise function. Herein, the generic name of the project will be designated as “gn”.

Data Bases

Material

- material.psm: · Material data. · ASCII files.

· One file per material.

Macro from Stamp Tool Kit

- macro.ksa:

· Definition of PAM-AUTOSTAMP standard forming macro. · ASCII file.

· One file per process macro-command. - Macro.ksp

· Definition of PAM-QUIKSTAMP Plus macro · ASCII file.

· One file per process macro-command. - macro.ktf:

· Definition of PAM-AUTOSTAMP tube hydroforming macro. · ASCII file.

· One file per process macro-command. - macro.ktb:

· Definition of PAM-AUTOSTAMP tube bending macro. · ASCII file.

· One file per process macro-command. - macro.ksi:

· Definition of PAM-INVERSE standard forming macro. · ASCII file.

(32)

· One file per process macro-command. - macro.kti:

· Definition of PAM-INVERSE tube bending macro. · ASCII file.

· One file per process macro-command.

Template from PAM-DIEMAKER

- profile.udt:

· Definition of user-defined profile template. · ASCII file.

· One file per profile. - profile.pfl:

· Definition of parameters of standard profile template. · ASCII file.

· One file per profile.

Project

- gn.psp:

· Data common to all modules of the project (for example alarms, section planes, active state).

Preprocessor

- gn.pre:

· Setting up of the project data and mesh description of the project. · Binary file.

· Multistage file.

· It is used to run a simulation. - gn.att:

· Project data setup. · ASCII file.

· Multistage file.

· It can be used with the gn.pre file or with the gn.mif file to run the calculation.

(33)

PRODUCT START UP Files - gn.mif:

· Mesh description of the project. · ASCII file.

· It can be used with the gn.att file to run the calculation. - gn.[i].und:

· Temporary undo file that contains information for undo. If n undo are possible there are n files from gn.1.und to gn.n.und. Files are removed when closing the project.

· Binary file.

· Deleted when the project is closed.

CAD Meshing Module

If the project comprises several modules, the following files correspond to the Ith module:

- gn.I.msh:

· Definition of the CAD model, the elements, nodes and groups of the module. · Binary file.

- gn.I.cmd:

· Command file of DeltaMESH containing the input for meshing. · ASCII file.

- gn.Ir.dtc:

· DeltaMESH data base after import. Results of CAD import. · Binary file.

- gn.Ia.dtc:

· DeltaMESH data base after joining. Results of CAD joining. · Binary file.

- gn.Im.dtc:

· DeltaMESH data base after meshing. Results of CAD meshing. · Binary file.

- gn.Im.fma:

· Results of CAD meshing. · ASCII file.

(34)

- gn.I.his:

· DeltaMESH Stamping messages file for all operations. · ASCII file.

Design Module (DIEMAKER and

PAM-TUBEMAKER)

If the project comprises several modules, the following files correspond to the Jth module:

- gn.J.add:

· Definition of the model used by PAM-DIEMAKER and PAM-TUBEMAKER (mesh, profiles, …).

· Binary file. - gn.J.msh:

· Definition of the CAD model, the elements, nodes and groups of the module. · Binary file.

- gn.Jr.dtc:

· DeltaMESH data base after import. Results of CAD import. · Binary file.

- gn.Jm.dtc:

· DeltaMESH data base after meshing. Results of CAD meshing. · Binary file.

- gn.Jm.fma:

· Results of CAD meshing. · ASCII file.

· PAM-STAMP 2G temporary file that can be imported. - gn.J.trm:

· Definition of the model used for Die Trimming. · ASCII file.

- gn.J.ptl:

· Definition of the user-defined PTL. · ASCII file.

- gn.bending:

(35)

PRODUCT START UP Files · ASCII file.

Die Compensation

- Gn_Outifo.input:

· Input file for Outifo containing the settings. · ASCII file.

- Gn_Outifo.lis:

· Output file of Outifo, containing all information about the computation. Used by the GUI in “Show all messages”

· ASCII file.

- Gn_Outifo.output:

· Output file of Outifo containing the status of the computation. It can be seen in the GUI, in the Outifo console.

· ASCII file.

- Gn_Outifo.history:

· History file written by Outifo, containing the points of Outifo history curves (max distance, average distance ….).

· ASCII file.

- Gn_Outifo.results: · Contours results of Outifo. · ASCII file.

- Gn_linear.asc & Gn_linear_depla.asc: · Files used by the linear solver

· ASCII file.

- Linearsolver.LOG:

· Output file of linear solver · ASCII file.

Substructure

- Gn.ini:

· File containing the data stored from the main simulation (Id of node, position and Id of center of gravity). There is one file per stage.

(36)

- Gn.S0i:

· File containing the data stored from the main simulation (border node displacement). There is one file per stage.

· Binary file. - Gn_ids.bf:

· File used by the subrun simulation to do correspondence between node

identification of main run and node identification of subrun. There is one file per stage.

· Binary file.

Solver restart

- gn.irs:

· input file to restart a calculation, contains the restart file identifier and possibly new calculation parameters · ASCII file

- gn.[i].rst:

· ith RESTART file written by the solver. · Binary file.

Warning:

· When the maximum number of restart files is n, and the solver wants to write the

(n + 1)th restart file, it will overwrite the first restart file, then overwrite the second, etc. Thus, the user should not just rely on the filename for identifying the most recent file, but look also for the progression value to which they

correspond.

- gn.[i].rst_P: · DMP calculation

· ith RESTART file on the node P written by the solver. All these restart files per node must be located in the same physical disk space (be careful /home can correspond to different disk for each node of a cluster).

(37)

Post-Processor

- gn.[i].res:

· ith state file written by the solver, contains the results of a given state. · Binary file.

- gn.end.res:

· State file written by the solver at the end of the calculation. · Binary file.

- gn.0.res:

· Scanner state file written by the solver on user’s request during the calculation. · Binary file.

· Temporary file. - gn.0[j].res:

· Instant state file written by the solver on user’s request during the calculation. · Binary file.

· Saved file. - gn.his:

· History file written by the solver, contains the points of history curves. · Binary file.

· The size depends on the number of points, on the number of entities stored and on the settings defined for history.

- gn.out:

· Solver listing. · ASCII file. - gn.err:

· Solver messages. Written if the solver stops with an error message after cycle 0. · Binary file.

- gn.msg:

· Solver messages. · Binary file. - gn.qst:

(38)

· Temporary status file that contains the request from the interface to the solver, for example when solver interaction is requested. File is removed after action is performed.

· ASCII file.

· Deleted when the solver reads the request. - gn.asw:

· File which contains the answer of the solver to the request from the interface. · ASCII file.

- gn_M01:

· Mapping result file, contains requested data for computed model at end of calculation.

· ASCII file. - gn.pda:

· Post-processing data archive, contains modifications in post-processing stage with respect to main project file (created curves, modified objects etc.) · Binary file.

- gn*.rib:

· input files for the renderer (master file, model definition, lights definition, scene definition)

(39)

Archiving a Project

- Pre-processor: · gn.pre.

- CAD meshing module, for each selected module: · gn.I.msh.

- Design Module, for each selected module: · gn.J.msh.

· gn.J.add. - For the post-processor:

· gn.1.res.

· a few intermediate view files, for PAM-AUTOSTAMP projects. · gn.end.res.

· gn.his, for PAM-AUTOSTAMP projects. · gn.err.

· gn.out. · gn.msg.

· gn.[i].rst : The restart file used for the picking of the next project, if necessary, for PAM-AUTOSTAMP projects.

· gn_M01, if available. · gn.pda.

- Data common to all modules: · gn.psp.

(40)

PRODUCT START UP Solver Manager Configuration

SOLVER MANAGER CONFIGURATION

Introduction

The solver manager is a daemon that runs on a calculation host.

Its purpose is to wait for and then process the calculation requests sent by GUIs running on the same machine or on remote machines.

The solver manager is a single executable file delivered with the standard installation. In the following, this executable file name is assumed to be solvermanager.exe.

Configuration Modes

The solver manager can be configured either:

- by arguments in the command line used to launch the solver manager - by a configuration file

Configuration priority:

- the configuration file options redefine the default options.

- the command line arguments redefine the configuration file options.

Warning:

· On Windows systems, if the solver manager is started as a service (see the

Solver Manager start chapter), no option can be set by the command line, except

the log file path. The configuration file is then the only way to configure the solver manager for other options.

The configuration file read by the solver manager is either :

- the file specified by the -config argument in the command line used to launch the solver manager.

or

- a file named solvermanager.exe.cfg if no file was specified in the command line. This file must be located in the same directory as the solver manager.

The presence of a configuration file is not mandatory but if it is necessary, a default configuration file can be generated by typing the command:

solvermanager.exe -genconfig [-config <file>]

The name of the generated file is solvermanager.exe.cfg if no filename is

specified by the optional -config argument (.cfg is appended to the solver manager executable file name)

(41)

Configuration File Description

This is a default configuration file:

############################################################# ## ## ## ## ## E S I S O F T W A R E ## ## ## ## ## ############################################################# ############################################################# ## ## ## ## ## SOLVER MANAGER CONFIGURATION FILE ## ## ## ## ## ############################################################# # ################################################## # # # SERVER PARAMETERS # # # ################################################## # # SERVER_PORT | 1201 # SERVER_PROTOCOL_VERSION | 2 # SERVER_LOG_FILE | # ################################################## # # # SOLVER LAUNCHING PARAMETERS # # # ################################################## #

# SCRIPT_TEMPLATE |

(42)

A '#' character at the beginning of a line means that the line is commented and therefore ignored.

To modify an option, the user must remove the '#' character and set the option value after the '|' character.

An option value containing space characters must appear within double quotes.

Available Options

The following items can be configured:

Usage of a template for launch script generation [New in v2.2]

configuration file line : SCRIPT_TEMPLATE | <template file path>

command line argument : -script <template file path>

default value : no script template

<template file path> is the path of a template file containing keywords that are replaced

by the solver manager with the launch parameters received from the GUI. The filled template is then executed by the solver manager. If no template file is specified, the solver manager uses its own built-in template (same behavior than previous versions). This option is available on Unix/Linux systems only.

See Defining a Template File for the Launch Script, below, for more details about defining a template file.

(43)

PRODUCT START UP Solver Manager Configuration Command used to launch a calculation in "batch" mode

configuration file line : BATCH_COMMAND | <batch cmd>

command line argument : -batchcmd <batch cmd>

default value : batch

<batch cmd> is the name of the command used in batch mode to launch the solver.

Name of the linked library path environment variable on Unix/Linux systems configuration file line : LIBRARY_VARIABLE | <lib var>

command line argument : -libvariable <lib var>

default value : DEFAULT

<lib var> can be an environment variable name (LD_LIBRARY_PATH for example) or a keyword:

DEFAULT : the environment variable name depends on the operating system: - IRIX : LD_LIBRARY_PATH

- HPUX : SHLIB_PATH and LD_LIBRARY_PATH are both set - SOLARIS : LD_LIBRARY_PATH

- AIX : LIBPATH and LD_LIBRARY_PATH are both set - DIGITAL : LD_LIBRARY_PATH

Automatic setting of the linked library path environment variable on Unix/Linux systems

configuration file line : LIBRARY_PATH | <lib path>

command line argument : -libpath <lib path>

default value : NONE

<lib path> can be a standard path (/usr/lib for example) or a keyword: NONE : do not set the library path environment variable SOLVER_DIRECTORY : set the library path environment variable as the solver

directory path

Automatic setting of the multi-processor environment variable configuration file line : MP_VARIABLE | <mp var>

command line argument : -mpvariable <mp var>

default value : NONE

<mp var> can be an environment variable name or a keyword:

(44)

DEFAULT : set an environment variable whose name depends on the operating system: - IRIX : MP_SET_NUMTHREADS - HPUX : MP_NUMBER_OF_THREADS - SOLARIS : PARALLEL - AIX : XLSMPOPTS='parthds... - DIGITAL : MP_STACK_SIZE

Path and name of the solver manager log file

configuration file line : SERVER_LOG_FILE | <log file>

command line argument : -output <log file>

default value : blank (no file)

<log file> is the full name of the log file (eg: /usr/tmp/solvermanager.log) Port number on which the solver manager listens to requests

configuration file line : SERVER_PORT | <port id>

command line argument : -port <port id>

default value : 1201

<port id> is the port number on which the solver manager listens to the requests.

Version of the communication with the GUIs protocol

configuration file line : SERVER_PROTOCOL_VERSION | <version>

command line argument : not available by command line

default value : depends on the version of the solver manager (2 for v2.2)

<version> is a number from 1 to n.

Note:

· A GUI and a solver manager can always communicate whatever their version is

(full compatibility). The user should never need to modify this option.

Path of the temporary directory

configuration file line : TEMP_DIRECTORY | <tmp dir>

command line argument : -tmpdir <tmp dir>

default value : /usr/tmp

<tmp dir> is the path of the directory where the solver manager will write launch

(45)

PRODUCT START UP Solver Manager Configuration Save the launch script generated by the solver manager

configuration file line : SAVE_LAUNCH_SCRIPT | YES / NO command line argument : -savelaunchscript

default value : NO

When this option is enabled, the launch script generated by the solver manager in its temporary directory is not deleted once the solver is launched but renamed to

smgr_launch_script. This allows for example to check / modify this script and restart it in a console to track a launch problem. Note that all scripts are renamed to the same name; it is advised to work with a copy of smgr_launch_script which will be overwritten by subsequent launches.

Enable the sourcing of profiles files (sh and ksh environments)

configuration file line : SOURCE_PROFILE | YES / NO command line argument : -nosourceprofile

default value : YES

When this option is disabled, the launch script generated by the solver manager will not include execution of /etc/.profile and $HOME/.profile files. This can be useful

if these files contain instructions that make the launch fail.

Force automount before entering directories [New in v2.2]

configuration file line : FORCE_AUTOMOUNT | YES / NO command line argument : -forceautomount

default value : NO

When this option is enabled, the solver manager calls some “list directory” commands to trigger automount of some directories before trying to enter them (just entering a directory might not trigger automount on old systems). This option should not be activated if no problem occurs with automount.

Delay before deleting scripts [New in v2.2]

configuration file line : SCRIPT_CLEANUP_DELAY | <delay>

command line argument : -scriptcleanupdelay <delay>

default value : 5 (seconds)

This option allows defining the delay (in seconds) before the solver manager deletes a script it has just launched.

(46)

Defining a Template File for the Launch Script

This option is available on Unix/Linux systems only.

A template file is a text file that can be located anywhere. It can contain keywords that are replaced by the solver manager with the launch parameters received from the GUI. To enable the usage of a template file, define its path in the solver manager’s

configuration file or in the solver manager’s command line or simply copy it in the same directory than solvermanager.exe and name it solvermanager_script.tpl (this is the default name for templates)

A default template file, very close to the built-in script, can be generated by the command:

solvermanager.exe –genscript [-script <new template’s name>]

This is an example of a template file (the keywords that will be replaced by the solver manager are highlighted in this example):

#!/bin/sh case $SHELL in

/bin/sh | /bin/ksh | /bin/bsh ) if [ -f /etc/profile ] ; then $SHELL /etc/profile fi if [ -f $HOME/.profile ] ; then $SHELL $HOME/.profile fi ;; /bin/bash ) if [ -f /etc/profile ] ; then $SHELL /etc/profile fi if [ -f $HOME/.bash_profile ] ; then $SHELL $HOME/.bash_profile fi ;; esac

# --- Enter work directory cd $PAMPARAM_WORKDIR

(47)

PRODUCT START UP Solver Manager Configuration PAMPARAM_VAR1_LABEL="PAMPARAM_VAR1_VALUE";export PAMPARAM_VAR1_LABEL PAMPARAM_VAR2_LABEL="PAMPARAM_VAR2_VALUE";export PAMPARAM_VAR2_LABEL PAMPARAM_VAR3_LABEL="PAMPARAM_VAR3_VALUE";export PAMPARAM_VAR3_LABEL PAMPARAM_VAR4_LABEL="PAMPARAM_VAR4_VALUE";export PAMPARAM_VAR4_LABEL PAMPARAM_VAR5_LABEL="PAMPARAM_VAR5_VALUE";export PAMPARAM_VAR5_LABEL # --- Run the command

nohup $PAMPARAM_CMDLINE > $PAMPARAM_OUTPUT # --- Normal termination

exit 0

Note:

· If a keyword is preceded by a ‘$’ character, this ‘$’ character will also be

removed by the solver manager. This allows writing a template file, based on environment variables, that could also be directly executed from a terminal or from another script, just by setting the environment variables corresponding to the keywords before calling the script (for testing...)

Example:

setenv PAMPARAM_WORKDIR /usr/temp setenv PAMPARAM_CMDLINE ls

setenv PAMPARAM_OUTPUT ls.out ./solvermanager_script.tpl

The keywords that are accepted in this version are:

- PAMPARAM_WORKDIR : work directory of the calculation

- PAMPARAM_CMDLINE : full command line that launches the solver - PAMPARAM_OUTPUT : file where solver output must be written

- PAMPARAM_NBPROC : number of processors requested for the calculation - PAMPARAM_RUNMODE : launch mode (0 for immediate, 1 for batch)

- PAMPARAM_USER : name of the user which sent the calculation request - PAMPARAM_SHELL : user’s shell (/bin/sh, /bin/csh, ...), equivalent to

(48)

PRODUCT START UP Solver Manager Start

SOLVER MANAGER START

The solver manager is a single executable file that is launched differently according to the host operating system.

On Unix/Linux Systems

Start the solver manager from a term window:

- logon as the root user

- type the command: cd <manager directory>

where <manager directory> is the directory where the solver manager executable file is located.

- type the command:

nohup solvermanager.exe [-output <manager logfile>] > /dev/null & where <manager logfile> is the full path of the solver manager log file

(/usr/tmp/solvermanager.out for example)

The –output <manager logfile> argument is optional (the user can also define the log

file path in a configuration file). If the user does define any log file path, no solver manager messages will be stored or displayed.

Start the solver manager at boot time:

- locate in the system the script file whose purpose is to start the daemons at boot time (consult the system administrator)

- insert the following command in this file:

<manager directory>/solvermanager.exe [-output <manager logfile>] > /dev/null &

where <manager directory> is the full path of the solver manager executable file directory and <manager logfile> is the full path of the solver manager log file (/usr/tmp/solvermanager.out for example)

file path in a configuration file). If the user does define any log file path, no solver manager messages will be stored or displayed.

(49)

On Windows Systems

The solver manager is normally installed as a service and launched by the installation tool. This is however the procedure to install and/or launch it manually.

Start the solver manager from a command window:

- type the command:

cd <manager directory>

- type the command:

solvermanager.exe –noservice -output <manager logfile>

where <manager logfile> is the full path of the solver manager log file (/usr/tmp/solvermanager.out for example)

file path in a configuration file). If the user does not add it to the command line and no log file is specified in a configuration file, the solver manager messages will be

displayed in the command window.

Warning:

· If the user starts the solver manager from a command window, all the

calculations launched by the solver manager will be attached to the user

account the user is logged on. Therefore, these calculations will be killed by the system when the user closes his session.

Start the solver manager as a Windows service:

A specific user account must have been created with the “log on as a service” privilege. This account is named pamservice in the following.

The pamservice account will be assigned to the solver manager service so that the calculations launched by the solver manager are also attached to this account. This prevents the calculations from being killed when a session is closed (assuming that the

pamservice account is reserved to calculations and that nobody logs on this account).

Note that the calculations are attached to pamservice, not to the user that requests the calculation. This must be taken into account, particularly for network access settings. This is the procedure to install and start the solver manager as a service:

- open a command window - type the command:

(50)

- type the command:

solvermanager.exe –service –user pamservice - enter the password of pamservice

If another solver manager service is installed and is running (whatever its version is), this service is first stopped and removed before installing and starting the new one. If no configuration file is present or if the log file is not specified in this configuration file, the solver manager messages will be saved in a default log file. This default log file is located in user profile directory and it is named solvermanager.out.

More generally, the user cannot configure the solver manager by command line arguments if the he starts it as a service, except the log file path. If the user needs to modify some other options, he must generate a configuration file and set the options inside it (see the Solver Manager Configuration chapter).

(51)

PRODUCT START UP Solver Manager Activity

SOLVER MANAGER ACTIVITY

If the user has defined a log file path when starting the solver manager (in the command line or in the configuration file), he can read in this file a processing report of all the requests received by the solver manager.

Example of log file:

### 12/03/2003 13:57:58 : Starting the solver manager... -> Solver manager started (Version 2.2 Protocol v2) [ Copyright ESI GROUP 2007 ]

-> Waiting for requests on port 1201...

### 12/03/2003 13:58:45 : Request received from 'remote GUI' -> Processing script...

+ Action requested : Start a calculation + User name : 'user1'

+ Executable path : '/usr/local/bin/solver.exe'

+ Command line : '/usr/local/bin/solver.exe -if "test.pre"' + Work directory : '/usr/projects/'

+ Output file : 'test.out' + Nb of processors : 1

+ Execute action immediately -> Setting work directory : OK

-> Script template loaded : OK (solvermanager_script.tpl) -> Writing script : OK

-> Creating output file : OK -> Creating the process : OK

The lines beginning with ‘###’ report the solver manager start-up and termination and the date and origin of all the requests.

The lines beginning with ‘+’ describe the requests.

The lines beginning with ‘->’ report the solver manager actions and the result (success or failure with error message) of these actions.

Moreover, version 2.0 and later of the solver manager sends a full report to the GUI so that a clear message can be displayed in the GUI to inform the user about the success or failure of his request (and the reason it failed if necessary).

(52)

PRODUCT START UP Calculation Stop

CALCULATION STOP

A calculation should normally be stopped by the GUI so that the process can cleanly terminate (writing of restart files…), using the solver/stop option.

The user might however need to kill the calculation process because it does not respond anymore, he does not need a clean termination or because he does not want to use the GUI.

On Unix/Linux systems, the user can use the system command kill provided if the he has the right to kill the process. If the user is not logged on the calculation account (or he is not the super user), he will have to switch to the calculation account before. On Windows systems, the user can use the task manager provided if he has the right to kill the process. If the solver manager is running as a service with a different account than the one he is logged on, he will not have the right to kill the calculation because it is attached to the service account. In this case, the solver manager executable file must be used to send a kill request to the running solver manager. This is the procedure: - get the process id of the calculation (get it from the task manager window) - open a command window

- go to the solver manager executable file directory - type the following command:

solvermanager.exe –killpid <pid> [-port <port number>]

where <pid> is the process id of the calculation and <port number> is the port number on which the solver manager listens to requests.

Note:

· –port <port number> is optional. If it is not specified, the default port is used.