Encyclopaedia Index

COSP comprises a set of subroutines attached to PHOENICS for the purpose of solving so-called "inverse problems", such as:

1. Determining what values of constants in empirically-based physical models, utilised by PHOENICS, best fit a prescribed set of experimental data.
2. What geometrical or boundary-condition input data will cause the predicted performance of some equipment to be closest to some desired specification.
3. What values of numerical values such as relaxation factors promote the most rapid convergence?

• When the COSP feature of PHOENICS is used for constant-optimising tasks of type 1 above, it takes as inputs:

1. a Q1 file of multi-run type, which defines the experimental conditions which PHOENICS is required to simulate;
2. a "target data" file which contains the experimental data, for each of these conditions, with which it is desired that the PHOENICS predictions should agree;
3. a preliminary set of values of the constants which it is desired to optimise;
4. information about how close a fit it is desired to achieve.

• PHOENICS multi-runs are then performed in repeated cycles. At the end of each cycle, the predictions are compared with the target data;
• a new set of constants is then selected in accordance with a systematic error-minimising strategy;
• the EARDAT file is correspondingly changed; and a new multi-run is then conducted;
• Cycles are terminated when the errors have been sufficiently reduced.
• Similar proceedings take place when the optimisation task is of type2 or type 3.

COSP has been evaluated through worked examples and also applied to the tobacco industry for the filter design.

In order to run COSP, users need the following files:

• Q1 file,
• Data input files for setting up the investigated systems,
• Data input files for the optimisation process

The q1 file is used for the user to set up the all the input date for the numerical simulation of the experiments. These settings include geometry, properties and boundary conditions as well as numerical settings.

The multi-run facility is required for running COSP and it can be set by RUN(1, …), the second command (after TALK=F) on the first effective line of the Q1 file. For example, for 5 runs, the user should set

TALK=F; RUN(1,5)

then the user should also provide 5 sets of statements corresponding to experimental conditions with a STOP statement at the end of each set of statements. Thus, RUN(1,5) will cause SATELLITE to read the 5 sets of statements.

In-Form is used to specify, in the q1 file, the expression where the unknown constants, which is to be searched by COSP, appear.

Apart from setting all the input data into the q1 file, the user may specify the input data in separate data files and utilise PIL command INTRPT(R, PATH/file-name) to read in these data. These data files can contain any information for the CFD simulation, from geometry, properties to numerical settings. The data files can be located anywhere as long as the PATH which points to the data file in the bracket of the INTRPT command is set correctly.

In the COSP package provided with PHOENICS, there is an example showing how the data files structure is used. 

There are two data files used for the optimisation purpose.

This file is named as COSPDAT. It contains only one integer, denoting the maximum EARTH cycles that could possibly take place. Usually a very large value, for example 10000 will be input to COSPDAT file, so as to make sure EARTH will be running in a perpetuum mobile mode.

If the integer in COSPDAT is set to less than 2, or if the COSPDAT file is not present in the working directory, COSP will not be activated, and EARTH will terminate prematurely. On the other hand, if the integer in COSPDAT is greater than 2, but smaller than MaxNoRun set in COSP.INP file (which will be explained below), EARTH will terminate when the EARTH cycle reaches the integer in COSPDAT, and a Fortran Run-time Error message will appear on screen. Thus the above-mentioned situations should be avoide d

A data file called COSP.INP is needed for the configuration of the optimisation process.

As this data file contains information pertaining to the optimising method employed by COSP, it is necessary to describe the mechanism behind COSP first.

In order to find the optimum values of the constants embedded in mathematical models employed for the numerical simulation, COSP tries to minimize the objective function by changing the value of the constants. The objective function is the root mean square of the normalised residuals between the predictions, which depend on the searched constants, and experiments.

COSP has been designed so that it will carry out a systematic search over a given range of constants, until a specified criterion for the objective function is satisfied.

The optimisation process will end when any one of the 3 following criteria is satisfied:

(1) The currently calculated objective function value is equal to or less than the minimum function value pre-set in COSP.INP file,

(2) The number of EARTH cycles has exceeded the maximum earth cycle pre-set in COSP.INP file,

(3) The iteration number of the mathematical method used by COSP exceeds the value pre-set in COSP.INP file.

The above three criteria have different priority during the optimisation process, but they all cause the termination of the optimisation process. The actual cause is reported in an output data file, COSP.LST.

Information contained in COSP.INP file is divided into 6 categories, they are:

(1) Title group

(2) Experimental data group

(3) Constant group

(4) External solver group

(5) Optimisation parameters group

(6) In-Form Group

For the purpose of clarity, an example is given below to illustrate the components of COSP.INP. The right column is added for the explanation of each group of the COSP.INP file.

COSP has specific limitation towards the parameters in the COSP input file:

NoExpVariant should be less than or equal to 128.

NoMeasurVar should be less than or equal to 4.

NoConst should be less than or equal to 10.

Once PHOENICS is installed on your local drive, you will be able to see the following directory on your drive:

D_ac3d

D_allpro

D_bodym

D_chmkin

D_cosp ------- contains COSP data files, examples, executable and source files

D_earth

D_enviro

D_include

D_intfac

D_photon

D_polis ------- contains the COSP documentation including this document

D_priv1

D_shapem

D_satell

Before starting the simulation, the user needs to create an icon for RESLOOK.EXE, which resides in D_cosp and is used to check the result during the optimisation process.

The user is advised to run examples supplied before using COSP to run his own cases. To run the examples, the user should only inspect the files involved, but does not need to modify any of these files. The user is recommended to run examples in the directory D_cosp (or D_priv1) although COSP can be run in any working directory.

There are several sub-directories under D_cops/examples. To run an example case, the user should copy the following files from corresponding sub-directory of D_cosp/examples to D_cosp (or D_priv1):

Q1 file

COSPDAT

COSP.INP

A readme file in each sub-directory of the examples describes the example and explains how to run it.

Once the data files are ready, the following steps start the simulation:

1. Start the SATELLITE run by typing RUNSAT at the command prompt and then press RETURN. A short description of the current case will appear on the screen.
2. Start the COSP by typing RUNCOS at the command prompt and then press RETURN. The graphical monitoring window will appear on the screen.

As mentioned earlier, the computation will be carried out in a perpetuum mobile mode until the requirement set in COSP.INP is satisfied. During this operation, you can check the result by using a program called RESLOOK.EXE. Double click the RESLOOK icon (which was advised to create in section 4.1) to activate it. A window similar to the following Find File window, shown in Figure 2, will appear, and the user will need to locate the result file "cosp.res" in the correct path.

Figure 2. Window for opening "cosp.res" file

Once you click the COSP.RES file, a "Cosp controls" window similar to Figure 3 will appear.

Figure 3. "Cosp controls" window

In the "Cosp controls" window, each button has its own function.

 To reload from COSP.RES file.

During the optimisation process, results are written to COSP.RES continuously. Clicking on this button will reload data from COSP.RES file and reveal the latest result.

To change the font of the result shown in the "Cosp controls" window.

To terminate the optimisation process

Once this button is clicked, a dialogue box will appear, asking whether to "Break process of Cosp iterations". If you click the Yes button, the optimisation process will terminate.

It should be noted that the optimisation process will not terminate immediately after you have confirmed to "break process of Cosp iterations". The simulation will only stop when the current cycle of the multi-runs has finished.

To quit "Cosp controls" window

It should be noted that clicking this button will only close "Cosp controls" window, it will not terminate the optimisation process.

The user should check the following output files:

1. COSP.LST

   This file contains a summarisation of the investigated problem and final result. If the optimisation process failed, it will also describe the cause.

2. COSP.RES

   This file contains a list of the values of the searched constants and their corresponding objective function. The user can also examine its content via the RESLOOK window during the execution as described above.

3. COSP.EAR

   This file contains the values of the variables which COSP uses to compare with experimental data.

4. RESULT file

   contains results from the simulation in the form of tables of numbers and line-printer plots. The results calculated with the last set of the constants during the optimisation process are included.

5. PHI file

The user can use PHOTON to load this file in order to display the results graphically. An alternative name for PHI from each run can be specified in Q1 by CSG1 command.

3. How to run user's own case

When the user is ready to run his own case, he should first create input files or modify the input files of the examples according to his own requirement.

(1) Q1 file

As mentioned in section 3.1, there can be several sets of statements in Q1, each corresponding to a different set of experimental data.

(2) Data files inside DATA directory (D_cosp/data) (this is required only if the user uses the DATA file structure)

The user should provide the data files as necessary.

(3) COSPDAT

The setting of 10000 in COSPDAT does not need to be changed.

(4) COSP.INP

The user will need to modify all the groups in his COSP.INP file as described in section 3.3. The following points deserve a special attention:

• Experimental data group

It is important to ensure that the experimental data specified are consistent with the specifications in data files if the user uses the data file structure. If the user activates 4 runs in the Q1 file RUN command, he should select the same runs in the experimental data group in COSP.INP.

• Optimisation parameter group

MinFunVal is the first criteria that the optimisation process uses to terminate the optimisation process. It is recommended that a minimum function value, 0.01 to 0.05, is set. Too large a value for MinFunVal produces inaccurate results; too small a value requires a long computational time, or even fails to reach the minimum function value.

MaxNoRun is another criteria used to terminate the optimisation process. It can take values up to what is specified (10000) in COSPDAT. However, usually a much smaller value than 10000, will be sufficient. This is mainly to limit the computational time.

• In-Form group

The mathematical formulae expressed by In-Form should be inserted in the line InFormStrx immediately after C=. ;and Typeesp in External solver group should be PINform

During the searching process cycle, COSP compares the predictions with experiments. The user needs to insert his own Fortran coding in Group 19, section 8 of the ground.for file in order to produce the calculated values of variables which COSP reads and compares with experimental data specified in COSP.INP. Then ground.for should be compiled and the executable, cosexe.exe should be re-linked by using command bldcos.

Once the files are prepared, the rest of steps, regarding running COSP and checking results, are the same as described above in section 4.2

This example is to show how COSP has been used to search the correct boundary value for a convection-diffusion problem for which the exact solution is available for comparison with the numerical prediction.

The mathematical descriptions for the convection-diffusion problem is as follows.

dJ/dx=1/Pe*d(dJ/dx)/dx+S,

where

S= 1-2/Pe+2x+pi*cos(pi*x)+pi**2*sin(pi*x)/Pe

Boundary conditions:

x= 0, J = 1+exp(-Pe)

x= 1, J = 4

The exact solution is :

J = 1+x+x**2+exp(-Pe(1-x))+sin(pi*x)

The exact solutions of J at x=0.5 with various Pe values are listed in table 1 and used for the COSP process

Table 1

At the start of the searching process, an arbitrary initial value, 2 has been given and the searching range has been set as

1 < J (at x=1) < 8

The task of COSP is to find the best boundary value, J (at x=1) (ideally the value should be 4) which makes the difference between the prediction and experiments be regarded as negligible.

For this case, the grid of 40x2 has been used. The boundary values chosen by COSP at different number of runs are shown in the table 2 where F is the objective function which is used to measure the difference between predictions and experiments, and its tolerance can be specified by the user.

Table 2

COSP stopped at 105th run as the tolerance for F has been set to 0.001.

The best value at the boundary x= 1 found by COSP is 3.99 which is very close to the theoretical value 4.

The comparison between the exact solution and the calculated values at x=0.5 for various number of runs are shown in the table 3.

Table 3

The run-time for 105-runs took 107 sec on a Petium III 600MHz.

This example is to show how COSP has been applied to a 2D pipe turbulent flow for optimisation of two constants in the wall function calculation.

The following expression by Filonenko has been employed to provide the experimental data, with which the PHOENICS predictions should agree

DP (exp) = (A * L/2*Rp + 0.065)* Rho* Wo**2 / 2;

where A = 1./(1.82*Lg(Re)-1.64)**2; Re = Wo*2.*Rp / Vis

L and Rp is the length and radius of the pipe respectively; Rho is the density, Vis is the viscosity and Wo is the velocity.

At L = 5 m; Rp= 0.5 m ; Rho= 1.22 kg/m3; Vis =1.465E-5 m2/s;

the values of DP at 6 different velocities,

W₀ = 10, 20, 30, 40, 50,60 m/s

are given in the table 4. These values serve a prescribed set of data for the comparison with predictions during the COSP searching process.

Table 4

The standard K-E model with the Blasius wall functions has been used for the numerical simulation. The following is the equation for the skin-friction factor:

Cf = C1/ Re**C2.

with the known constants, C1=0.023 and C2=0.25.

At the start of the constant-searching process, the initial guess values, C=0.02 and C2= -0.05 have been given and the following searching ranges have been set,

0.01 < C1 < 0.05; -0.1 < C2 < 0.3

The task for COSP is to find, by performing the above-described 'multi-runs', the constants, C1 and C2 which fit the predictions best to the experiments.

For this case, the grid of 20x20 has been used. The results of the constant-searching for different number runs are shown in the table 5.

Table 5

The comparison between the experimental and the calculated DP for different number of runs are shown in the table 6.

Table 6

The run-time for 3072-runs is 17 hr on a Petium III 600MHz.

The above examples have shown that COSP can be used to reliably choose, from arbitrary initial values, the boundary value for the first case and the constants for the second which best fit the prescribed set of the data.

It might reasonably be said the COSP represents the first step towards answering the designer's real CFD question, which is often not, 'What will the flow be if I choose these inflow conditions?' but rather 'What inflow conditions will give me the flow that I want?'

That being so, the future for COSP appears very bright. Being new, it has only a modest track record at present. Once its capabilities are recognised by PHOENICS users however, that situation can be expected soon to change.