Optimization module for ProCAST

PAM-OPT coupling

Vincent Mathier
CALCOM ESI
Parc Scientifique EPFL
CH-1015 Lausanne, Switzerland
Phone : +41-21-693 8317
Fax : +41-21-693 4740
Email : vmt@esi-group.com
Web : www.calcom.ch / www.esi-group.com

Page 1/37

1.
1.1.
1.2.
1.3.
2.
2.1.
2.2.
2.3.
3.
3.1.
3.2.
3.3.
3.4.
4.
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
5.
5.1.
5.2.
6.

INTRODUCTION

CONCEPT AND DEFINITIONS

OPTIMIZATION SOFTWARE
POINT GENERATOR: EXTENSION TO PROCESS ROBUSTNESS AND PROCESS WINDOW
PAM-OPT : ESIS OPTIMIZATION SOFTWARE
GENERAL PRESENTATION
ALGORITHMS
USEFUL FEATURES

3
4
6
7
7
7
9

PROCAST FEATURES AVAILABLE FOR PAM-OPT COUPLING

PRECAST BATCH MODE
PRS EDITOR
COMPUTATION OF SIMPLE CRITERIA
USE OF LOCAL DATABASES

10
10
11
12
14

FLOWCHART FOR SETTING UP OPTIMIZATION CALCULATIONS

BASELINE CALCULATION
EXTRACTION OF CRITERIA
CREATION OF LOCAL DATABASES
INPUT MODIFICATION TEMPLATE
SETUP OF THE OPTIMIZATION LOOP
LAUNCH OF THE CALCULATION

15
15
18
19
20
21
31

POST-PROCESSING

31

PAM-OPT OUTPUT FILES

FURTHER POST-PROCESSING METHODS

31
32

NOTES ON INSTALLATION

33

Page 2/37

1. Introduction
This document is intended to describe the features of the ProCAST optimization module and
to give guidelines about its use. For further help about how to design optimization studies
specifically adapted to your needs, you are strongly advised to contact your local ESI support.
1.1. Concept and definitions
The concept of optimization (typically of a process) is quite clear as it is the goal of almost
any manufacturing industry, i.e. get its processes to be better and better. The definition of
better can have various inputs (economic factors, part quality, tooling durability) but is
essentially always in the mind of process engineers. Optimization can simply be seen as a
method to find the answer to the question: How do I make my manufacturing process
better?.
To make a process better, it is necessary to adjust the values of all the different parameters
that are involved in that process (temperatures, times, geometries,). Optimization can then
more specifically be seen as the way to answer the question What values to I give to my
process parameters to make my process better?. It is also interesting to note that optimization
is most often meant to improve an existing process. This means that a working manufacturing
method is already in place and working in a satisfactory manner. Optimization then allows
further fine tuning the process parameters to achieve an even better process design. In some
cases however, optimization is a tool that can prove useful when designing a brand now
process. Optimization can then be used to assist the process designer in finding appropriate
process parameters in a shorter time.
The target of the ProCAST optimization module is obviously optimization of casting
processes. More precisely, it focuses on what values should be given to process parameters to
achieve a better process. Such process parameters can be initial temperatures, cycle times,
heat transfer coefficients, Even though some modifications of geometric features are
possible in the optimization loop, they are not primarily developed (special techniques can be
tailored for specific problems). In addition to process optimization, generalized inverse
modeling allowing the determination of material properties from experiments is also possible.
In such a case, optimization is used to determine material properties (or other unknown
properties such as heat transfer coefficients) that are such that the agreement between
measured and simulated data (temperature records, distortion measurements,) is good. The
determined materials properties can then be used in further simulations.
At this stage, it is important to spend some time defining some of the terms that will be used
when discussing optimization. Up to this point, the present section is an attempt to define the
term optimization and how it is applied to casting using the ProCAST module. There are a
few other definitions that need to be clarified for that purpose. First of all, the idea of making
a process better implies that there exists an objective function. This objective function is a
well defined number that varies when the values of process parameters vary (and thus the
outcome of the process varies). The objective function is a rational measure of how good a
process is. Typical objectives include defects (porosity, cracks) in the final product but can
also be the price of producing a single part (which combines production time, wear of the
die,). When determining material properties, the objective will be the difference between
measured and simulated records. The objective function (often referred to as objective in

Page 3/37

short) has two other features that need to be kept in mind. First of all, the goal of optimization
is to make the objective function either maximum or minimum. In that sense, optimization
cannot proceed without an objective and the definition of the objective function is sometimes
one of the most complex aspects to be identified before running optimization calculations.
Moreover, there exists only one objective function in a given problem. Even though it is
possible, using slightly more advanced methods, to tackle true multi-objective problems
(determination of Pareto front for example), we will not focus on them here and the
framework presented will limit itself to single objective optimization (but it should be kept in
mind that the definition of the objective can be quite complex and incorporate several
aspects).
Even though the objective function is unique, it is possible to give more information to the
optimizer through constraint functions. A constraint function is again a well-defined number
(that depends upon the value of process parameters and quantifies the outcome of the process
itself). The idea of a constraint is to say that the value of the constraint function should not be
above (and/or below) a fixed value. Typically, a constraint can be I do not want more that
1% porosity in my final part. In that sense, the goal of an optimization problem will in fact
be to minimize or maximize the objective AND ensure that all constraints are met. The
interesting feature of constraints is that there can be several of them. Of course, it is also
possible to define none. Sometimes to refer to an objective or constraint function without
expressing specifically its nature, we will use the term criterion (or criterion function).
In summary, optimization can be viewed as the determination of suitable process parameters
(or material properties is some cases) values to minimize or maximize the objective and
respect all the constraints. The process parameters that are allowed to vary to achieve this goal
are often referred to as design parameters. It should be kept in mind that the term design
parameter is quite general in that sense and covers process parameters, material properties,
geometrical features (even though this is outside the scope of the document),
Without giving many details about the optimization technique itself, it is useful to define at
this stage the idea of direct run or solver call (or sometimes direct call or even point, all four
denominations being equivalent). It is indeed quite obvious that optimization will involve
several different numerical simulations of the given process in which the design parameters
are somehow modified. Each one of these simulations is going to be referred to as a solver
call, meaning that an optimization calculation consists of many solver calls (i.e. many casting
simulations). Please note also that a solver call does not necessary consist of a single
executable program. The concept of solver indeed corresponds to a chain of executable
programs whose job is to read the process parameters values and to compute the values of the
objective and constraints functions. In the present case, the chain PreCAST DataCAST
ProCAST will be the typical solver call.
1.2. Optimization software
Optimization of casting processes has classically been performed using trial and error
methods, producing full scale parts under real conditions and trying to alter a bit these
conditions. The quality of the various parts is then being assessed to select the best
combination of process parameters or imagine what a better tuning of the process could be.
This method often involves guessing and needs to be conducted by very experienced people.
This approach quickly becomes very costly.

Page 4/37

Nowadays, building virtual models for the simulation of a given process is standard industrial
practice. This means that experienced people can work with simulation engineers to perform
process optimization using the classical trial and error approach but producing only virtual
part and thus not wasting raw material or time on the production line. This is an improvement
but this method is still costly as it takes long working hours or highly qualified people to
make it progress. This method is illustrated on the figure below with the blue arrow indicating
the work done by the computer. This outlines that a lot of engineer work is required as he has
to analyze the outcome of each of one his process simulations to make the next attempt at
getting a better process (or design in more general terms).

Further added value of simulation software can be achieved when optimization software (an
optimizer) is coupled to the virtual manufacturing models. In such a case, the job of the
engineer is to define objective and constraints and to identify the unknown process parameters
(and indicate in which range their values can vary). The optimization software then does the
rest of the work, i.e. launching the process simulation, analyzing the outcome and guessing
what a better design could be. At the end of the optimization loop, the engineer retrieves the
result from the optimization software and this result is in fact the optimized process that can
then be implemented in full scale production. As suggested by the figure below this approach
saves valuable human time and transfers most of the workload to the computer. Using
optimization software is the best way to use nowadays computer power to both improve
process quality and save working time for valuable workers needed in other duties.

Page 5/37

1.3. Point generator: extension to process robustness and process window

Having established the standard framework that we will now refer to as optimization, it is
necessary to spend some time on an additional aspect that is often less obvious but still
valuable in the field of industrial process enhancement: the concept of process robustness. In
general, for industrial production, the manufacturing process will be performed using well
defined values of the various process parameters that come into play. Each one of the process
parameters indeed has its own target value such that, if the manufacturing process is
performed with all process parameters held at their target value, the result will be good. The
difference with optimization is that a good result is defined as respecting all the constraints
(part quality being one of them) without the idea of looking to maximize or minimize some
objective.
This means that, to start with, we know what value needs to be assigned to each process
parameter in order to manufacture a good component. How those target values have been
determined is not relevant here. The main concern is the fact that no matter how good the
manufacturing equipment is and how meticulous the factory workers are, the process
parameters never reach exactly their target value. It is indeed more accurate to say that the
values of process parameters vary (in a statistical manner) around these target values. These
variations can range from small to quite significant but they always exist.
The real question behind the concept of process robustness is to know how those variations of
process parameters can influence the part quality. Those statistical variations will indeed
trigger a variation of quality of the manufactured product. However, as the manufacturing
process is often very complex, it is difficult to evaluate how the variations of process
parameters values will translate into manufactured part quality. A robustness study thus
basically consists of running, in an automated way, several simulations of the same process
with slight variations of the input parameters (as it happens in real life) and to study the
outcome. Such a study is indeed intended to help characterize the stochastic variations in part
quality due to the fluctuations of process parameters around their target values. From this
description, it is obvious that such results will be statistical in nature. For example, as part
quality will vary, it is possible that some parts will be of too poor quality to be used. The first
information that comes from this quality distribution is the proportion of parts that are below
the quality standards. This corresponds to a prediction of the scrap rate. If it turns out that,
despite the variation in quality, all the parts still exhibit a satisfactory quality, then the process
is said to be 100% robust.
The concept of process robustness is linked with optimization because it can classically be
studied using an optimization software. Let us typically imagine that 100 thousands parts
must be produced, what is going to be the scrap rate? The challenge here is to be able to
evaluate accurately such statistical results. However, it is clearly not possible to run 1000
industrial casting simulations to make sure that our statistical evaluation is accurate enough.
The role of the optimizer is thus, given how many process parameters vary and how wide
their variations are, to determine which 20-50 (this number is specified by the user but such
order of magnitudes are quite typical) simulations should be run in order to obtain accurate
statistics concerning the part quality. It will also handle launching automatically all the
simulations (idea of the optimizer being a point generator).
The idea of process robustness can be extended to that of process window determination in
the case where the focus is not on an existing, implemented process, but rather on the
development of a new process. In this case, the variation of process parameters value will be

Page 6/37

allowed to be large (within the technical possibilities) and the study will look for which
window in combining the different values of design parameters leads to satisfactory process
designs.

2. PAM-OPT : ESIs optimization software

2.1. General presentation
The above section presents the tasks and advantages of optimization software. Within ESI
product line, such a piece of software, PAM-OPT, is available and has been used with success
to tackle many full scale industrial problems. This document thus presents in detail the
ProCAST optimization module which consists of an integrated and interfaced coupling
between ProCAST and PAM-OPT. It is not the present purpose to give a detailed PAM-OPT
manual (comprehensive documentation of this product is included in the software installation)
but rather to highlight critical points that are essential to understand how to use the ProCAST
optimization module.
PAM-OPT is available for both Linux and Windows (on that platform, a cygwin version
exists together with a native Windows once) and is an optimizer that has proven able to
handle optimization of full scale industrial models. Several features participate in this ability
and we shall come back to these later. Furthermore, it implements several algorithms that will
be presented in a bit more depth in the next section. The PAM-OPT suite is composed of an
actual solver (to do all the work that was described above) and of an input file editor which
can be useful for advanced cases. In simple process optimization however, the optimization
calculation may be setup using only the ProCAST GUI.
In the optimization module, the tasks of PAM-OPT are all those listed before when describing
optimization software in general : launching casting simulations, analyzing outcome, guessing
better process designs, The optimization calculation is thus going to be managed by PAMOPT. The setup of this calculation is contained entirely in a single ASCII file with a .cds
extension. The results that are produced are also contained in simple ASCII text files. The
content of these files is rather easy to interpret once the optimization approach has been well
understood.
A final comment at this stage is about the coupling mechanism between PAM-OPT (the
optimization brain) and ProCAST. This is a coupling in the sense that PAM-OPT must be
able to launch automatically casting simulations and retrieve the results. PAM-OPT must then
be able to tell ProCAST what values of design parameters to use to run the next casting
simulation and ProCAST has to communicate to PAM-OPT the results of that simulation.
These exchanges of information between the two pieces of software are achieved through
ASCII files (that PAM-OPT will write and read). ProCAST (as an executable chain involving
also PreCAST, DataCAST,) is thus required to be able to read and write selected
information using ASCII files. We will come back to that requirement later on.
2.2. Algorithms
The most difficult job of the PAM-OPT solver is obviously to analyze the outcome of the
previous casting simulations and guess how better design could possibly be achieved
(repeating this in an iterative way until an optimum solution is reached). This is performed
according to an algorithm. Since the results of a simulation can vary a lot even for small

Page 7/37

variations of the design parameters (e.g. when optimizing a flow problem), these algorithms
must not have a tendency to diverge (i.e. they must be able to progress towards a solution
even when the problem is very chaotic). Moreover, as they are calling casting simulations,
each one of which can be quite long, these algorithms should be able to find optimum
solutions without having to call too many times the ProCAST solver. Even though the use of
optimization software saves engineer time, it is usually not acceptable to wait several weeks
for the results of an optimization study and this time constraint must be taken into account.
The requirements of not diverging and using few solver calls are obviously contradictory but
must both be achieved, which is why the optimization algorithm faces a difficult challenge.
As PAM-OPT is a general optimization software (that can be applied to very well behaved
problems or to cases where each direct solver call is very short) it implements several
different algorithms, which are suited to different cases. In the framework of casting
optimization, the exploration, gradient (reaches a solution quickly but will diverge in chaotic
problems) and iterative random (will not diverge but involves a great number of solver calls)
will neither be used nor presented here.
The first optimization algorithm that can reasonably be applied to casting processes is referred
to as Adaptive RSM. The adaptive RSM algorithm is a special feature of PAM-OPT (as it is
not conventional) and combines well the requirements mentioned above. It will indeed always
find a solution (the algorithm cannot diverge) and the number of solver calls required to
achieve this is kept relatively low. It is thus very adapted for the kind of problems at hand and
is a strong added value feature of PAM-OPT. Details about the algorithm can be found in the
PAM-OPT documentation but it is useful to mention at this stage that it progresses by
iterations. During each iteration, a few direct calls are first calculated and (using some
interpolation method) a new optimum solution is guessed. The guessed optimum solution is
then calculated to check whether or not it indeed improved. Such iterations are performed
until convergence to the final optimum solution is found. The iterative progression towards
this solution is summarized in the file named File.history(.txt).
The adaptive RSM algorithm is the preferred optimization algorithm for casting applications
because of its ability to reach a solution with a limited number of solver calls without having
a tendency to diverge. In some cases, the genetic algorithm can also be useful. This algorithm
will also not diverge. However, it often requires quite a large number of solver calls to obtain
improved designs. This algorithm considers that each different process parameter is similar to
a gene (each of these gene can carry different influences on the process quality). Every solver
call is thus an individual consisting of several genes. An individual is considered fit when he
meets all the constraints and has good values of the objective function. This algorithm will
then progress by iterations (or generations). Each iteration consists of several individuals
(solver calls) whose genes were defined by breeding the fittest individual of the parent
generation. This favors the survival and transmission of the best genes (i.e. the best values of
the design parameters). Mutation processes are also included so that no degeneracy occurs.
The user chooses how many individuals he wants in a generation and how many iterations he
wants to breed. From this explanation, it is clearer why a lot of solver calls are often involved.
However, this approach can prove useful for very chaotic problems. It also has the advantage
of proposing a set of possible improved designs, which are in fact the individuals of the last
generation (each generation as a whole is fitter than the previous one).
These two algorithms are the optimization methods to be applied to the problem at hand. The
last PAM-OPT algorithm that is relevant here is the stochastic algorithm, which is used for
the study of process robustness (or process window). This algorithm indeed simulates the

Page 8/37

statistical variations of the design parameters and allows studying the resulting fluctuations of
various quality indicators. This calculation mode basically launches several casting
simulations according to the input process parameters variation. The added value of this
algorithm comes from the fact that it selects cleverly the solver calls to be launched so that
accurate statistics (e.g. scrap rate) concerning the quality of the casting process can be
computed even if the number of direct calls that the user can afford (due to time constraints)
is rather small.
2.3. Useful features
Beyond algorithms well suited to tackle industrial problems, PAM-OPT has some extra
features that make it applicable to full scale problems and it is worth mentioning those here.
PAM-OPT is available for both Linux and Windows. Under Windows, the user will find a
version running entirely in the standard environment and another one based on cygwin (free
software allowing the implementation of a Linux-like command line environment under
Windows). The pure Windows version is nice because of its simplicity (no need to install
third party software) but is more adapted to running optimization calculations on multiple
processors Windows machines.
When several machines are available and connected on a corporate network, the PAM-OPT
solver itself runs on one master computer. It can obviously launch casting simulations (solver
calls) on this same master machine. Moreover, it is able of launching casting simulation on a
pool of slave machines that are present on the LAN. This capability allows many processors
to be made available to the CPU intensive optimization calculation. The pool of slave
machines can contain both Linux and Windows platforms. Moreover, this pool can be
managed (the optimization calculation load can be suspended temporarily on selected slaves).
The handling of slave machines involves ssh communication which is why the Windows
PAM-OPT version requires cygwin to be installed on all Windows platforms if this
mechanism is to be used. The pure Windows version will be able to use only the master
Windows machine for the optimization study (no slaves) but will not require cygwin to be
installed. The difference between the more powerful (use of slaves) cygwin-Windows version
and the simpler to install 100% Windows version of PAM-OPT must be kept in mind upon
installation. Note that both versions can be installed together on a computer with cygwin
installed.
Another useful feature is the handling of failures of either a simulation or even a computer. If
one or several given casting simulations fail for some reason, this will be taken into account
by the algorithm in an appropriate manner (as long as some of the direct calls in the iteration
were successful). If one of the slave computers is turned off, the optimization calculation will
not be stopped (the duties of the turned off computers are transferred to other members of the
pool). If this machine is turned on again later, it will be automatically recaptured in the pool
and used again. Finally, if the master machine itself is powered off, the optimization study is
obviously stopped. However, a restart mechanism exists so that previous calculation results
are not lost. Similarly, if the user has attempted by hand several designs before resorting to
optimization, he can use these attempts as initial information that are taken into account by
the algorithm. This can shorten the time necessary to reach an optimum solution.

Page 9/37

3. ProCAST features available for PAM-OPT coupling

As previously mentioned, the coupling between PAM-OPT and any solver is to be achieved
through ASCII files. In one (or several if desired) of these files, PAM-OPT must be able to
provide the solver with the values of the design parameters it should use for the casting
simulation and the other (or others as several files can be used if necessary) should contain the
values of the criteria (objective or constraints) functions so that PAM-OPT can read them.
Please note that the format of these files is not constrained as PAM-OPT can be instructed to
use virtually any ASCII file structure. The possibility for ProCAST to use and generate such
ASCII files is thus the corner stone of the optimization module. This capability as well as
some other features were integrated to ProCAST to fulfill this goal. The present section will
thus be dedicated to presenting these features.
3.1. PreCAST batch mode
There are two ways in which an ASCII file can be used to modify the values of process
parameters. The first one is to use user function that code for the values of these design
parameters. As user functions are indeed ASCII files, they can be used for that purpose. The
other way of communicating input data to the ProCAST solver is by modifying the p.dat and
d.dat files. Even though they are also ASCII files, their large size and format makes them
unpractical to modify directly.
The batch mode of PreCAST, in which PreCAST is used to modify the d.dat and p.dat
without interaction with the GUI, is the most general and versatile approach. In that mode,
PreCAST will indeed perform operations on the d.dat and p.dat based on the instructions
contained in an ASCII .prs script file (see the dedicated ProCAST manual section). This PRS
script has a very practical format and can control the alterations of many process parameters
values. In fact, the batch mode of PreCAST was developed specifically for the purpose of
optimization coupling. This is the main reason why its use for pre-processing entire cases
from scratch may sometimes appear unsatisfactory. The PRS script can thus be regarded as
the most important ASCII file used by PAM-OPT to modify the ProCAST input data. Please
note that, in more advanced cases, the use of both a PRS script file and user functions are
possible (composite input).
As illustrated below, the batch mode can be invoked from the ProCAST manager (for testing
the effect of a given PRS script for example) by right-clicking the PreCAST button. From the
command line, this batch mode is also triggered by the precast.exe batch prefix
script.prs command (the prefixd.dat file is then open for modifications) or precast.exe
mesh_file batch prefix script.prs (in that case, prefix.mesh is opened to begin
with). Under cygwin or Linux, the precast batch prefix command can be used to obtain
the same behavior.

Page 10/37

3.2. PRS Editor

The creation of a PRS script can be performed using the information and description of
keywords provided in the ProCAST manual. This is however neither easy (except in very
simple cases) nor user-friendly. For that reason, a functionality referred to as PreCAST Script
Editor (PRS editor) has also been added. It is basically a GUI that looks very similar to
PreCAST and that will assist the user in creating a PRS script by recording all the operations
he performs. This feature is also invoked by right clicking the PreCAST button of the
ProCAST manager.

As illustrated below, the PRS editor GUI is very similar to the PreCAST GUI (note that the
same executable manages in fact both user interfaces). The general principle is that the user
will use this as it if were the usual PreCAST interface and modify the setup however he wants
to. Whenever he does a modification, the corresponding PRS keyword(s) will be
automatically added to the PRS script. The creation of the PRS can be followed in real time in
the bottom window. The latter window can also be used for manual script editing if necessary
(keywords can be added through the *GENERAL, *SEQUENTIAL and * FINAL menus). If
a standard menu from PreCAST cannot be found in the PRS editor GUI, this means that the
corresponding input data cannot be modified by the PRS script. Please see the corresponding
manual section for further details.

One final important comment on that topic is that all the modifications that are made in the
PRS editor GUI are visible and recorded in the PRS script file. However, they will not be
saved to the d.dat and p.dat files (i.e. after the PRS editor session, the input has not been

Page 11/37

modified but a PRS script now exists). The user can apply the modifications from the script to
the d.dat and p.dat files by running once the PreCAST batch mode.
3.3. Computation of simple criteria
Now that the ASCII files for controlling the input of ProCAST are known, it is necessary to
focus on the files that will contain values of criteria functions (objective or constraints). The
advanced approach is to create user functions (externalcompute being often very useful for
that purpose) that will compute criteria and dump their values to ASCII files. This method is
very useful in advanced cases, for example when trying to fit experimental data to find
material properties (inverse modeling). This is however not the most user-friendly approach
and is often a bit too sophisticated for the kind of problems encountered (typical objectives
such as part quality or process cost are simple functions of the ProCAST results).
Most often, optimization criteria are indeed rather simple quantities based on a given field
(e.g. maximum or average of a defect field is the casting domains can be used as a part quality
objective function). In that context, the user is provided with a simple way to extract such
information from the results of a ProCAST calculation. It is indeed possible to define as many
criteria functions as desired through the prefix_resdef.dat file (results definition file). This
ASCII file contains the user defined definitions of as many functions as desired (enclosed
between an *RESULT and *END keywords).
Each result is defined by which field it will use to extract results from. The available fields are
temperature, solid fraction, velocities, stresses, element volume (the sum of the element
volume field in a domain is the volume of the domain), defect fields (porosity, hot tears,
cracks, fatigue life), From this field, the user chooses to extract a minimum, maximum,
average or sum. This evaluation can be required throughout the calculation or at the last step
only. Moreover, the domains (a list of several domains can be provided, separated by blanks)
to be considered for this evaluation should be defined. It is the responsibility of the user to
consider fields only in domain in which they are defined (e.g. it does not make sense to
include a mold domain in the calculation of the average porosity). Similarly, the user must
ensure that the considered field is indeed part of the calculation (e.g. setup a single
JUNCTION if the average value of the flow junction field is to be considered).
For each one of these criteria, the user can also define an optional value name (if nothing is
defined these results will automatically be referred to as value1,) and an optional file name.
The file name is going to be the name of the file in which the considered results is going to be
written. It is possible to write several criteria in the same file. In fact, if no file name is
specified, all the criteria will be output to prefix_resout.dat (results output file). The
format of the output ASCII files will also be the same, starting with the number of criteria
output to the file followed, for each one, by the name of the value and the value itself.
The structure of the prefix_resdef.dat is not detailed here because there exists a GUI that
will help the user define the relevant criteria. This GUI can be accessed from the File menu of
the PRS editor, as illustrated below (File/Add output criterion). Please note that this menu
must be accessed to create every new criterion definition (with the possibility of erasing
previous definitions if necessary). This GUI guides the user in inputting all the necessary
information for the definition of a criterion and modifies accordingly the
prefix_resdef.dat file.

Page 12/37

The results definition file will be read and interpreted by the scalar version of the ProCAST
solver, which is able to use this input to generate the results output files. This provides the
user with a very simple way to obtain values of criteria functions (in ASCII files) that can be
used to be fed into PAM-OPT. Some recently implemented results in ProCAST might cause
the output by the ProCAST solver to fail. From version 2010.0 on, it is advised to use a
complementary tool, as will now be described.
This very simple approach is fast and efficient for many optimization problems. However, in
some cases, this technique exhibits some limitations. For that reason, a separate executable is
also available to compute results based on the prefix_resdef.dat file and referred to as
optcriteria. This tool rereads the ProCAST results files (.usf and .unf) and extracts the
required values from them (without displaying the fields or the model). One immediate
advantage of this tool is that it will work for both scalar and DMP results (while the previous
approach is only implemented in the scalar ProCAST solver).
There are two other advantages in using optcriteria, the first one being that it can use
solidification time (time spent between liquidus and solidus, field code : solidification_time)
and end of solidification time (time spent between the beginning of the casting simulation and
the solidification time, field code : end_of_solidification_time) as fields from which to extract
average, minimum or maximum. The other advantage is that it can consider not only entire
domains but also their interfaces or free surface (non-coincident interfaces are regarded as
free surfaces). This is handled through the definition of domain numbers. For example, 2 is
going to include domain number 2 as a whole (bulk and surface), 2s corresponds to the free
surface of domain 2 (equivalent and coincident interfaces are not part of the free surface) and
2i3 corresponds to the surface where domain 2 is in contact with domain 3.

Page 13/37

Furthermore, optcriteria handles correctly .usf files generated with recent ProCAST
versions. At this stage, it is however necessary to have only one field per usf file, which
implies mostly that only one output is to be defined through the JUNCTION run parameter.
3.4. Use of local databases
From the above description, it is now clear that the PRS script is the preferred way for PAMOPT to alter the input of ProCAST simulations during the optimization loop while the values
of objective and constraints functions will be provided by ProCAST through the use of a
results definition file (for both these aspects, user functions can also be introduced in more
advanced cases). Using these mechanisms, coupling between ProCAST and PAM-OPT can
thus be achieved.
One difficulty remains however in the case, quite frequent, where the optimization loop
studies a design parameter that is defined in a database entry (e.g. a characteristic defined in
the materials, stress, interface, process or boundary conditions database). The PRS script
indeed allows modifications of such parameters by referring to the database entry using their
names. Due to this handling method and the fact that several simulations may occur in
parallel, the database will often get polluted by multiple entries created during the
optimization loop. Moreover, problems can often arise when using a pool of slaves machines
is used to increase the computational power because the database entry names are most often
not transferred from one machine to another (i.e. from the databases installed on one
computer to the databases installed on another).
It is not relevant here to expose more details about these difficulties as they are all solved by a
simple approach that consist of using local databases. The full definition of a calculation will
then be given by a p.dat and d.dat files as well as the local directory named db that contains
stress.db, matls.db, intf.db, proc.db and bc.db files.
From a fully setup case, this local databases directory can be created extracting only the
entries that are actually used in the current setup (this creates a light local db directory). This
operation can be performed using again the PRS editor under the menu File/Create local
database (as illustrated below). This will allow the user to create the local databases directory
automatically. It also allows for the transfer of ownership of databases entry to some other
user (this may prove useful depending on the local IT environment). Please note that
whenever this menu is invoked, the local databases are created from scratch again.

Page 14/37

Once those local databases are created, the user needs to remember to instruct PreCAST to
use them instead of the centralized complete databases. To do so, the use local databases
check box must be activated in the right-click drop-down menu obtained from the Manager
PreCAST button (see below).

Please note that this additional check box is hidden in the standard ProCAST installation. To
have it appear, it is simply necessary to change (using a standard text editor) to line set
useLocalDbs 0 to set useLocalDbs 1 at the beginning of the manager.tcl file to be found
in the ProCAST installation bin directory.

4. Flowchart for setting up optimization calculations

This section presents a step by step methodology to setup optimization calculations. It is
strongly advised to follow these steps carefully and in a very systematic way in order to
minimize the risk of input mistakes (as optimization calculations can become quite long, this
is of particular importance). This method will be presented based on a simple follow through
example. For some specific issues, additional capabilities will also be mentioned. Moreover,
as shall be presented, standard optimization calculation can be setup all the way using a
simple GUI that directs the user.
4.1. Baseline calculation
The first step of the process of defining an optimization study is to setup a ProCAST
simulation of the casting process on interest. It s highly recommended to run this simulation

Page 15/37

and check that it is satisfactory from all points of view. All the interesting results (including
defect indicators) should be included and validated if possible. The mesh should be
satisfactory. It is also useful to spend some time making sure that no CPU time could be
easily saved from that setup. In typical optimization cases, the classical PreCAST
DataCAST ProCAST combination will be used (user functions can also be included without
any problem). Advanced modules such as CAFE or APM can also be included. However, this
makes the optimization problem less standard and it is advised to contact ESI in order to get
some help to setup such a case.
During the optimization loop, this baseline calculation will be repeated several times with
slightly varying input. It is thus necessary to have a rather robust casting simulation that will
converge even if the input parameters are slightly modified. It is not a problem if a few of the
casting simulations fail since this behavior can be handled by PAM-OPT. However, if most of
them are not properly completed, the optimization loop will either stop early or give wrong
results. To ensure robustness, there are various tips and traps (depending on the type of
process) that are known to trained ProCAST users. Another typical robustness issue is the
stopping criterion that has to be set in an efficient way.
Up to now, because of this robustness issue, remeshing of the geometry at the beginning of
each ProCAST simulation was not attempted. The most recent available meshing tools (STL
route, VisualMesh) will probably lift this limitation. However, not much testing on that topic
was performed at this stage. For this reason, optimization of geometric features is considered
as an advanced topic for the ProCAST optimization module. This means that such
optimization studies can be conducted but it is advised to contact ESI as they can involve
some more advanced technical aspects (true parametric geometry and meshing, boundary
condition selection technique, clip delete technique or mesh distortion technique).
At this stage, it is time to introduce the follow through example that shall be used to illustrate
the recommended method for setting up optimization calculations. We shall indeed use an
oversimplistic HPDC example to demonstrate this flowchart. It needs to be kept in mind
however that such concepts were successfully applied to optimization of real industrial
models (for HPDC and other processes) and that this example is purposely made somewhat
unrealistic for the sake of clarity and simplicity.
As illustrated below, a mold enclosing a casting cavity was designed with a running system.
Two overflows are added to the cavity to serve their usual purposes. The actual cast part
consists of two regions, one of which is assumed to be critical from the structural point of
view (the round region with a square hole highlighted in red on the image below). Each
overflow, the running system, the body of the part and the critical region of the part are all
assigned a different domain number. In general, when some regions of the part are more
important than others, it is advised to assign them a distinctive domain number as this will be
useful for the extraction of criteria function. As this aspect is to be handled at the meshing
stage, it is worth thinking about it from the very beginning.

Page 16/37

overflow
overflow
casting

critical
region

running
system

mold

This case is setup to correspond to the injection of aluminum in a steel mold. At the entry of
the running system, an inlet condition (liquid injection at 680C with a flow rate of 50 g/s ) is
applied so that filling will progress up to reaching a full cavity. The focus of this example will
indeed be to optimize results from the flow pattern and subsequent solidification. An
additional parameter to note is the preheating temperature of the mold of 320C. As far as the
run parameters are concerned, standard HPDC recommendations are used and POROS is set
to 1 (standard porosity model activated) and JUNCTION to 2 (trapped oxides) to compute
defect fields. The calculation is stopped when everything is solidified, setting TSTOP to
500C.
The image below illustrates two interesting fields, i.e. junction field (on the left, indicator of
defects generated during filling) and porosity (on the right, indicator of defects generated
during solidification). These results are satisfactory and the calculation can thus be considered
fully setup. This step is then finished and the setup of the optimization study can progress to
the next step.

Page 17/37

4.2. Extraction of criteria

The next step is to setup the extraction of criteria functions from the results obtained in the
baseline simulation. As previously mentioned, these values must be written to some ASCII
file. It can be a standard log file or a file generated by some user function. However, the
simplest method is to setup a prefix_resdef.dat file to be interpreted by either the
ProCAST scalar solver or, preferably, the optcriteria tool.
Let us illustrate this method by coming back to our simple HPDC example. As already
mentioned, there is a critical region in that part that will experience most of the solicitation
during service. As a consequence, we want to optimize our process to keep the amount of
defects in that region to a minimum. In particular, we want the amount of porosity in that area
to be a minimum. Moreover, the amount of oxides trapped in that domain must be kept below
an acceptable level (for that specific case, a value of 0.08 cm2/s on average was found to be
the maximum acceptable).
Based on this formulation of the problem, we need to output the average value of the porosity
and flow junction fields in that critical region of the cast part. For this purpose, a
prefix_resdef.dat file will be created using the PRS editor GUI as mentioned before. The
field shrinkage_porosity (junction will be selected when setting up the second criterion) is to
be averaged at the last stored step of the calculation. This average considers only domain 5
(critical region of the part). This is why it was important to think about it and isolate this
domain at the meshing stage (this helps a lot extracting information about this specific domain
later on). Please note that, even though this naming is optional, this average porosity is
labeled pores for future reference. The same procedure just needs to be repeated to setup the
extraction of the average of flow junction field under the same conditions. This is illustrated
below with a snapshot of the GUI on the left and the resulting prefix_resdef.dat file on
the right.

Page 18/37

Results definition file

*RESULT
field_name:
shrinkage_porosity
value_name: pores
option: average
timing: last_step
domains: 5
*END
*RESULT
field_name: junction
value_name: oxides
option: average
timing: all_steps
domains: 5
*END

After a run of the ProCAST scalar solver or of the optcriteria tool, a

prefix_resout.file (default output file as no file name were input in the above results
definition) is created. This ASCII files contains, as expected, the average of porosity (pores)
and flow junction (oxides) in the critical region of the final cast part. The results output file
looks like :
2
pores
2.715143e-002
oxides
6.605708e-002

This means that the average porosity is 2.7% in that case while the average amount of oxides
is indicated to be 0.066 cm2/s. This means that the amount of oxides is acceptable (below the
0.08 cm2/s limit). The challenge is now to minimize porosity without exceeding the oxides
acceptable limit. This will be the task of the optimization module in that example.
4.3. Creation of local databases
Once the baseline case is setup properly and that the user has made sure that the results of
interest can be extracted from the case, it is strongly advised to create a local database
directory and have PreCAST work with it from this point on. This will avoid risks of central
database pollution or problems when using distant machines for casting simulations. This
possibility was already presented above and is summarized again in the pictures below.

Page 19/37

4.4. Input modification template

The last preliminary step to the setup of an optimization study is then to create the template of
the ASCII file that will contain the values of the design parameters that we allow the
optimizer to modify to reach a solution. Again, this can be approached with user functions in
advanced cases, but the preferred method is to create a PRS script for the modification of the
desired process parameters. The creation of such a script using the PRS editor GUI is very
simple.
Going back to the example, let us assume that the only things the optimizer can modify to try
and produce better parts are the inlet flow rate and the mold preheating temperature. All the
other processing conditions cannot be altered. When defining these varying parameters, it is
worth to already think about within which bounds they will reasonably be allowed to vary.
Such limits can be due to various factors and defining them can sometimes become tricky. In
the present case, let us assume that the inlet flow rate can vary between 40 and 200 g/s while
the mold initial temperature can be anywhere between 250C and 450C.
By opening the PRS Editor and modifying the flow rate in the inlet condition and the initial
temperature for the mold domain as would be done in standard PreCAST, such a script is
automatically recorded. This script will have the following form:
*GENERAL
*VERSION
2009.1
*END_GENERAL
*SEQUENTIAL
*BCDB_MODIFY
hpdc-inlet cst_inletflowrate
135
*BCDB_MODIFY
hpdc-15-RST cst_inlettemp
6.800000e+002

Page 20/37

*INITIAL_CONDITIONS_CONSTANT
1
275.00
*END_SEQUENTIAL
*FINAL
*END_FINAL

The modified values of the inlet flow rate and mould preheating temperature appear in this
script as outlined in red.
4.5. Setup of the optimization loop
Once all the above steps have been successfully completed, it is safe to proceed with the
actual setup of the optimization calculation. To do this, PAM-OPT comes with an exhaustive
input file editor (PAM-OPT Editor) that is useful because it gives access to almost all of the
PAM-OPT features. It thus comes handy for setting up most advanced optimization studies.
However, the more standard casting optimization problems can be setup entirely using a
Wizard type GUI tool referred to as the cdsWizard (CDS is the file extension of the PAMOPT input file). This wizard is accessible from the ProCAST manager, under the PreCAST
right-click menu after the line set cdsWizard 0 has been replaced by set cdsWizard 1 at
the beginning of the manager.tcl file from the bin directory of the local ProCAST installation.
This GUI will assist the user (even inexperienced) in setting up an optimization problem.
Restart and backwards mechanisms exist in this wizard so that the setup can be performed in a
more flexible way.

We will now describe the functionality of this wizard by following through the example
illustrated above. The first panel (see image below) is simply a welcome banner summarizing
the different steps of the process of setting up an optimization study. As mentioned, a restart
mechanism exists so that previous setup will be reloaded each time. If the user wants to start a
brand new setup, erasing the restart information, the checkbox at the bottom of this panel
allows doing so.

Page 21/37

The next panel basically checks that all the steps presented up to now have been followed. It
will indeed look in the case directory for a p.dat and d.dat (baseline calculation is setup), a
PRS script (for automatic pre-processing), a local databases directory and a results definition
file for output criteria. For each one of these elements, a check box will automatically be
checked when the element is present. If they are not all detected, this panel will show a red
message advising the user to provide all these elements. To do so, the user can directly launch
the PRS editor from that panel. Once the new elements have been created, the detection
procedure can be repeated by using the Refresh button. At this stage, it should also be
remarked that just stopping the mouse over buttons whose functions are not obvious from
their label will cause a short help message to be displayed (yellow background online help
message). These features of the panel are displayed on the left hand side of the pictures
below.
If all the required elements are present in the case directory, a green message is displayed
encouraging the user to proceed. Please note that the green light is not mandatory for the user
to proceed with the optimization setup but strongly recommended. In some cases, the input
for ProCAST simulation will be modified by a user function (no PRS script) or the database
entries will not be modified (no local db directory is necessary) or advanced criteria functions
will be output by some user function (most likely externalcompute, no results definition file).
As a consequence, the red message will be displayed. If he knows what he is doing, the user
can manually check one or several of the boxes that correspond to these scenarios and he will
thus obtain the green light. In the present example, the standard steps have been properly
followed and the green light is obtained right away.

Page 22/37

Having spent a little time checking that the recommended steps have been properly followed,
the actual setup of the optimization study can be started. The first task is to select the proper
algorithm. For optimization, the preferred candidates are the adaptive RSM or genetic PAMOPT algorithms. For the study of process robustness or process window, the PAM-OPT
stochastic algorithm should be used. The panel illustrated on the pictures below prompts the
user to select one of these algorithms. Whenever the selection from the drop down list is
changed, the help message below shows a short description of the corresponding algorithm. It
is only possible to proceed to the next panel after validating a definitive choice of algorithm
by clicking the OK button on the right of the list. This choice can then not be undone. In the
present example, the optimization adaptive RSM algorithm is selected.

Page 23/37

When running the ProCAST simulations, PAM-OPT will work in intermediate directories
(name starting with DIRINTER_). One of these working directories needs to be created for
every CPU (or process) made available to PAM-OPT (including on slave machines). Before
any ProCAST simulation can be started in such an (initially empty) working directory, it is
necessary to have some files (input) copied in it. This copy operation will be done to each one
of the working directories from a single source only once at the very beginning of the
optimization loop. The task of the next panel is to indicate what are the files that need to be
copied. By default, the baseline p.dat and d.dat files are selected as well as the results
definition file. In most case, it is recommended to also check the local database directory box.
When database (e.g. value in a boundary condition) entries are being modified, checking the
local databases checkbox is mandatory. This is the case here and having this functionality
activated will cause the copy of the local db directory and its use by the PreCAST batch runs.
Other typical files to be selected include initial conditions file from an extract or an
externalcompute user function implementation to compute advanced criteria functions. Other
custom files (e.g. experimental records files when doing inverse modeling or header files used
in user functions implementation) present in the baseline case directory can also be selected as
custom files using the browse buttons. All these files can be selected or unselected manually
by using their corresponding check boxes.

The next panel is used to define the process parameters that will be allowed to vary during the
optimization loop. Each design parameter can vary between a maximum and a minimum
value. It can also be assigned a guess of what a good initial value could be. This is however
optional. Moreover, each design parameter is assigned a name by the user. When all the
corresponding entries have been filled, the design parameter definition can be stored by the
OK button. It will then appear on the list below. Please note that a label (referred to as a
sticker in the PAM-OPT terminology) is also automatically assigned to the design parameter
for later use. The list of defined parameters that appear below is a summary but can also be
used to delete a wrongly defined parameter by selecting it and clicking the Delete button.
All this is illustrated from the snapshot of the panel displayed below. In the case of a
stochastic study (process robustness), this panel will look slightly different as the definition of

Page 24/37

the statistical variation of the design parameter is required. In that case, the look of the panel
is slightly different but its use basically remains the same and the GUI is self explanatory
enough to be used without difficulty. In the present example, as already mentioned, the inlet
flow rate is allowed to vary between 40 ad 200 (g/s as this unit is defined in the baseline
calculation) while the mold temperature can be anywhere between 250C and 450C.

Having defined the design parameters is not enough since PAM-OPT has to be informed how
to format the ASCII files in which it will insert its custom selected values for those
parameters. This is exactly why a PRS script template had to be created earlier. Such a
definition is also the task of the next pane, which will look as illustrated on the left of the next
images. The list of design parameters (and their corresponding labels) is given at the bottom
of the panel. By using the Open file button and selecting the PRS script created earlier, the
script will be displayed in the window in the top half of the panel, as illustrated on the right.
The user must manually indicate where the values of the design parameters appear in this
template script. To do so, simply select the value in the script and highlight the corresponding
parameter in the list, then click the Assign button. This will cause a line starting by
#STICKER in the line above the selected value (this is the way for PAM-OPT to indicate
where to insert modified values). At the beginning of every ProCAST simulation, PAM-OPT
will thus insert the value its algorithms has selected for this specific process parameter in the
script at the right location. In the present case, each one of the design parameter appears once
in the script so that two assignments are necessary in total.
This assignment must be performed for each design parameter. If the value of the same
parameter appears several times in the script, the assignment must be performed separately for
each occurrence. Moreover, every design parameter of the list must be selected at least once
to assign it somewhere in the script. If an assignment is performed by mistake, the user will
not be able to delete it right away. However, one can just continue assigning and correct this
mistake by manually editing the CDS file at the very end. Please finally note that the
approach would be exactly the same if the ProCAST input were to be controlled through a
user function.

Page 25/37

The next task is to identify what are the objective and constraints
and where (i.e. from which ASCII files) they can be read by
PAM-OPT. A name has to be given to each one of the defined
criteria. In the case of the objective, one also has to decide
whether the value should be maximized or minimized. In order
to tell PAM-OT where to read the value of the objective
function, the Browse button can be used. After clicking this
button, the user can indeed navigate and open the file in which
the results are found (most often prefix_resout.dat). Once
the file is opened (as illustrated here), simply selecting the
correct value and clicking Store will insert all the necessary
information in the File name, Line and Column fields.
The constraint(s) definition works in exactly the same way except for the fact that a constraint
is not to be minimized or maximized but to be below an upper and/or above a lower bound.
Moreover, as the constraint definitions are optional, the check box before each constraint
definition must be checked before being able to set it up.
In the present example, the objective is to minimize the average porosity that can be found
(after each ProCAST simulation) on the 3rd line of the prefix_resout.dat file. Moreover,
the oxides indicator (found on the 5th line of the same file) must be kept below 0.08 (a single
constraint is used in that case). In the case of a process robustness study, there exist no real
objectives but rather a collection of output values that are being watched. The look of the
panel is thus slightly different but its function remains essentially the same.

Page 26/37

Having defined the varying design parameters and the way to introduce them into ProCAST
as well as the definition of objectives and constraints and their location of retrieval, the main
components of the optimization loop are in place. There remains some things to adjust, most
of which are to be found on the next panel. The first point is the definition of the different
steps involved in one solver call, i.e. what needs to be done to obtain the values of the criteria
functions from the values of the design parameters. This chain can be defined by activating
checkboxes corresponding to possible steps. The obvious executable chain (to be used in that
example) is first to create a PRS script with the correct design parameters values (the template
of this script has been defined before). Then PreCAST will be run in batch mode to modify
the p.dat and d.dat from this PRS script. Then DataCAST will be launched and finally the
ProCAST scalar solver, which will generate the prefix_resout.dat file to be read by PAMOPT to find the values of the objective and constraints functions.
Including advanced modules in that chain or running the DMP ProCAST solver cannot be
achieved with this GUI (manual intervention in the final CDS file will be necessary):
However, choosing to control the ProCAST input via a selected user function or resorting to
the optcriteria tool to compute the criteria functions can be included in the solver call at
this stage. Please also note that a time out (default of 90 minutes) is introduced. This means
that any simulation that lasts form more than 90 minutes (CPU time) will be forced to stop
and considered a failure. This is meant to avoid hanging the optimization loop if bad
convergence appears. For industrial optimization, this timeout can be manually modified in
order to be adapted to what typical solver times will be (with a large enough safety factor). It
is also possible to decide to the DMP version of the ProCAST solver (specifying the number
of CPUs to be used for each run).
The number of CPUs or processes available for ProCAST simulation on the local machine is
also defined on that panel. It is really the number of simultaneous solver calls that is defined
here. So 2 calls of ProCAST scalar will actually occupy 2 CPUs, but the same 2 calls to
ProCAST DMP 4 CPU will cost 8 CPUs on the local machine. Please note that a 0 can be
defined here if slave machines are used and the master machine (on which PAM-OPT is
running) must remain free of the intensive ProCAST simulation use.

Page 27/37

This panel also allows defining (by checking the corresponding box) to define the
characteristics of one machine in the slave pool (if several slaves are to be used, simple copy
and paste operations can later be performed manually in the CDS file). The communication
between the slave and the master machines is achieved using ssh (thus only available under
Linux or using cygwin under Windows) and should be properly setup (see installation
guide). The mandatory characteristics is the IP address of the machine within the local
network (a machine name can also be used provided proper DNS configuration exists) and the
number of simultaneous solver calls (processes) allowed to run on it. By default, the user
name currently in use on the master machine will be used to log on to the slaves. If this is not
desired, another user name can be specified (optional field). Moreover, the working
directories will be created in the users home directory. If this location is not satisfactory, an
(optional) path can also be provided.

The next (and almost final) panel guides the user for CPU time management. For industrial
scale optimization, the time constraint is indeed a critical aspect. Even though the PAM-OPT
algorithms are tailored to give the best results within the shortest possible time, it is possible
to set a maximum number of solver calls allowed to make sure that the optimization study
will be finished after a given period. Alternatively, if the user knows how many points he can
afford at most in his study, this panel will help him estimate the CPU time required for the
entire optimization study. It is possible to toggle between these two modes using the
checkbox that appears on this panel as illustrated below. As these conversions depend on
many factors, the number indicated on this panel are only approximate indicators.
The estimated solver call CPU time will be automatically filled by reading the baseline p.out.
If this file is not present or if the user feels that it is not representative, this number can be
changed by hand. Please note also that when units are changed using the drop down lists, the
corresponding numbers will be converted and not kept as such. By providing the maximum
allowed time for the optimization study (or the maximum number of calls in the alternative
configuration) and clicking the Calculate button, an estimate of the maximum number of
affordable solver calls (please note that obviously this estimate depends upon the number of
simultaneous processes, which cannot be input by hand here but is calculated automatically

Page 28/37

based on the information given on the previous panel). The Calculate button can be invoked
as many times as the user wants. Every time, the quality of the optimization study is
assessed (giving a red, orange or green message depending on the number of calls).

When satisfactory parameters have been calculated, the Apply button can be used to transfer
this number of solver calls to the limitation field that are given to the PAM-OPT algorithm. In
some cases, the user may also want to limit the number of iterations or the number of
simulations within one single iteration (what is typically limited is the total number given by
the number of casting simulations summed through all the iterations). This is however
optional and not used in the present example.

Page 29/37

The final panel simply displays the CDS (PAM-OPT input file) corresponding to the input
setup using this wizard. This file is created only when the Finish button is used (on Quit, the
restart information is saved but no CDS file is re-written). At this stage, the CDS file cannot
be edited. For detailed information about the syntax, please refer to the PAM-OPT manual.
This syntax is however not too exotic (it is just formatting the information given to the
wizard) so that simple manual corrections are possible using any text editor.

There are some other PAM-OPT features that can be useful in more advanced cases and that
are not part of that wizard. If they are required, the best way is to use the wizard first and then
use the PAM-OPT editor to add these features to the resulting CDS file. In particular, there
exist three PAM-OPT keywords that can be useful. The first one is OPTRUN. This keyword
is included in the CDS file generated by the Wizard but commented out (i.e. a $ character is
found at the beginning of this line). By uncommenting manually the OPTRUN/ 2 line the user
asks PAM-OPT to launch only one single test casting simulation instead of the whole
optimization loop. This is sometimes useful to make sure quickly that every step works
correctly. Another useful keyword is SVFILE, which instructs PAM-OPT to save a copy of
some file (for example the modified PRS script) for later post processing. A template for this
keyword is also added as a comment in the generated CDS file.
The last PAM-OPT keyword that should be mentioned here is the DATMOD keyword.
Sometimes, the PRS script can indeed contain a value that is a given function of a design
parameter. Let us for example imagine that the inlet temperature were to vary and that we
wanted the mold preheating temperature to always be 300C below the inlet temperature. This
DATMOD keyword allows the user to define a value that is always equal to some function of
the current design parameter value (here the mold temperature that is the inlet temperature
minus 300C) and to assign a STICKER to it. This parameter is thus not a degree of freedom
but can be referenced in the PRS script to control in more details how the user wants the
problem to behave.

Page 30/37

4.6. Launch of the calculation

All the above steps lead to the creation (in the case directory) of a CDS input file for PAMOPT. After having completed the setup of this file, the last step is to launch the PAM-OPT
calculation. Under Linux, the command pamopt prefix.cds > listing & will do just that.
Under Windows a very simple launcher (just browse to the CDS file and click Launch) is
available from the PAM-OPT start menu. This will start the PAM-OPT calculation, first
creating working directories, then copying the base files and starting a loop of ProCAST
simulations. Under Windows, one should choose between the Windows and the Cygwin
PAM-OPT solvers. At this stage, the decision must be coherent with what was used in the cds
Wizard (if the ckecbox use Linux/Cygwin) was left active, then the Cygwin version of PAMOPT should be launched.

5. Post-processing
The results of an optimization study need to be well studied and discussed before drawing
conclusions. Such results are indeed often quite interesting but their interpretation may not be
immediate. This section intends to draw attention to the most interesting information
available.
5.1. PAM-OPT output files
The PAM-OPT output files are ASCII file and their names start with File followed by some
extension. The most important one is the history file. For the example we have been following
through, it will look like:
PAM-OPT Algorithm 2009 (feb. 12 2009)
Executed on: 2009/10/21 - 08h20m38s
+----------------------------------+
| Adaptive Response Surface Method |
+----------------------------------+
********************************************************************************
* There are 2 design parameters :
Lower Bound / Upper Bound
* P1
--> &inletrate
40 /
200
* P2
--> &moldtemp
250 /
450
* There is 1 constraint function :
Upper Bound
* C1
--> &junction
0.08
* The objective function :
* Obj --> &porosity
********************************************************************************
****** HISTORY ******
iter
--->
0
1
2
3
4
-------------|----------------------------------------------------------------Point Nb
|
1
3
8
8
8
-------------|----------------------------------------------------------------P1:&inletrat | 50
193.535
156.821
156.821
156.821

Page 31/37

P2:&moldtemp | 300
288.384
263.592
263.592
263.592
-------------|----------------------------------------------------------------C1:&junction | 0.222619
0.0689172
0.0766371
0.0766371
0.0766371
-------------|----------------------------------------------------------------Obj:&porosit | 0.0231859
0.0278359
0.0269535
0.0269535
0.0269535
-------------|----------------------------------------------------------------+----------------------------+
|
End of the PAM-OPT run
|
+----------------------------+

This file basically indicates how PAM-OPT progressed towards an optimized solution. For
each iteration, it will show the best solver call (characterized by the values of the design
parameters as well as the objective and design functions) obtained at this stage. The example
illustrates this behavior. The initial guess (iteration 0, call number 1) was an inlet low rate of
50 and a preheating temperature of 300. This leads to a good porosity value but too high
oxides content (0.222619 cm2/s is way above the acceptable 0.08 cm2/s limit). After the first
iteration, point number 3 appears to be the best (2.78% of porosity and an acceptable oxides
content of 0.0689 cm2/s). After iteration 2, the best point is the solver call number 8 (156.8 g/s
as the inlet rate and the mold preheated at 263.59 C) with only 2.69% or porosity and an
acceptable 0.0766 cm2/s of oxides indicator. Afterwards, more tentative ProCAST simulations
are performed during iterations 3 and 4 but the best point remains number 8 (no further
improvement of the solution). The algorithm finally converges and point number 8 is the
optimum solution. Please note that this optimum has more porosity that the initial guess, but
the initial guess was not satisfying at all the oxides requirement. The trade off between
porosity and oxides is something that will happen very often in casting processes and that can
be very efficiently analyzed using the present approach.
The file called File.history(.txt under Windows) thus contains the progression of the
algorithm towards the solution as well as a summarized view of the optimum solution itself.
One information it lacks however is the number of ProCAST simulations (in total and at each
iteration) that were necessary to reach this solution. This information together with other
evolution indications can be found in the File.curves(.txt) file, which has a self explanatory
format. Another interesting PAM-OPT result file can be the File.doe file which basically
summarizes (input and output parameters) all of the ProCAST simulations that were
calculated during the optimization loop.
Finally, the file listing(.txt) contains all the standard output of PAM-OPT during a standard
run and can also contain some interesting complementary information (such as which
simulation is being run on which machine of the slave pool). This file is however mainly
useful for calculation monitoring.
5.2. Further post-processing methods
Beyond the PAM-OPT results file, it is often desired to be able to compare in more details the
baseline and optimized solution. As advised above, the baseline has been calculated in the
case directory. Moreover, PAM-OPT will automatically recalculate the optimum solution in
the first created working directory. These two cases can be post-processed side by side using
the standard method (VisualCAST) in order to be able to compare them in great detail.
Moreover, the SVFILE keyword mentioned above will, if defined, keep a copy (one for each
one of the solver calls) of the desired files in a File.save directory. In specific cases, this can
also be useful. This allows for example reconstructing and viewing all the intermediate steps
in the progression of the algorithm towards the solution.

Page 32/37

A final comment concerns post-processing of a stochastic study (process robustness or

process window). This result is statistical in nature and its analysis (to extract for example the
predicted scrap rate) needs some extra care (in order to fully exploit all the information). For
that purpose, Excel sheets containing analysis macros are available (together with
documentation about their use) from ESI.

6. Notes on installation
For optimization to be active, the standard installations of first ProCAST and then PAM-OPT
should be performed (documentation is available for this step with both products). In the
installation directory of ProCAST, the file manager.tcl should be modified after line 55 so that
the variables optimPre, cdsWizard and useLocalDbs all take a value of 1.

On Linux, this is all that is necessary to customize the environment to be able to use the
optimization module (provided ssh was already configured properly). Under Windows,
however, some more steps are required to complete the customization. After installation of
PAM-OPT, the start menu will have the appearance illustrated on the following picture:

Page 33/37

One finds the Windows and Cygwin versions of the PAM-OPT solver as expected. As PAMOPT works with links to the executables programs, those links now need to be defined (such
links, or aliases, are native undr the Linux ProCAST installation). This setup needs to be done
just once and is explained in greater details in the PAM-OPT documentation.
In order to setup the environment in the pure Windows version, the user should click on the
Configure PAM-OPT Solver Windows menu. This will open a command window and start a
procedure that automatically creates links to selected ESI aplications (those links are added to
a file contained in the user profile directory). Once this step is finished, pressing any key will
launch the GUI for adding custom links (added to the same user profile file), which we will
use in the case of casting.

This GUI is illustrated on the following image and lists the links already defined.

Page 34/37

The user needs to manually define (click add a link manually) the links precast, datacast,
procast, procastdmp and optcriteria using this interface. This can easily be done by typing the
name of the link (alias), browsing to opt_launch_scripts folder in the bin directory of the
ProCAST installation and selecting the corrresponding .bat file and finally clicking the Add
the new link button.

Page 35/37

Once all custom links have been properly defined, the user may Upgarde the PAM-OPT link
files and Exit.

Under cygwin, the setup of all these links is easier. It is indeed only necessary to copy all the
.sh scripts from the opt_launch_scripts/cygwin (in the bin directory of the ProCAST
installation) into the pamopt_cygwin/env-Cygwin of the PAM-OPT installation directoy.

Page 36/37

This summarizes the customization necessary at the installation step to be able to use the
PAM-OPT / ProCASt optimization module under Windows (again ssh is assumed to be
properly configured for cygwin use).

Page 37/37