Filip Claeys

Although this question has already been asked a number of times, we have no knowledge of cases in which couplings have been realized in practice.

I suppose that in principle coupling WEST with a CFD tool (Fluent, OpenFOAM, COMSOL, ...) could mean 2 things: either the CFD tool is called from WEST to provide a more detailed modeling of a certain unit process (e.g. clarifier), or the CFD tool calls WEST to perform some additional computations for each grid cell. Both are most likely technically possible.

In the case of WEST calling a CFD tool for detailed modeling of a unit process, a piece of MSL code could be written that calls an external C-callable function. In this function the CFD tool would then be called. Some CFD tools may have an API through which such calls can be performed, others may have a command-line executable version that can be launched as an external OS process.

In the case of a CFD tool calling WEST, one would have to use the CFD's tool mechanism for calling custom functions (in Fluent these are called UDF's I believe). From such a custom function, the WEST API (*not* WEST as a whole) can then either be invoked to perform certain computations, or the WEST command-line executor (texec.exe) can be launched as an external OS process.

For your information, DHI in general has ample experience with CFD modeling, as is attested by the document below. Information about commercial services (e.g. in relation to coupling to WEST or any other MIKE by DHI software) is available upon request.

[url=http://userarea.west.mikebydhi.com/Download/Public/CFD%20Modelling%20by%20DHI%20SOQ.pdf]http://userarea.west.mikebydhi.com/Download/Public/CFD%20Modelling%20by%20DHI%20SOQ.pdf[/url]

The problem is somehow related to array indexing using variable indices.

Nearly all the indexing that takes place in WEST models is done on the basis of indices that are known at compile-time. Verification of these indices against the size of the corresponding array dimensions can therefore also be done at compile-time. In case of problems, error messages will be generated by the model compiler.

In a very limited number of WEST models, array indexing is also done based on indices that are *not* known at compile-time, e.g. because the actual index is a state variable, input variable or parameter. Retrieving the array element related to the index, and verification of the validity of the index can therefore only be done at run-time. This run-time process is taken care of by a routine named "MSLUCalcOffset".

As far as I know, the only MSL files in which array indexing is done on the basis of indices that are not known at compile-time, are the following:

  IUWS\iuws.connectors.msl
  IUWS\Sewer\sewer.generators.msl

In both of these, state variables are used to index arrays with flow, evaporation, pollution, ... patterns or arrays with TSS, COD, ... norms. If you scan the model library for "[state." you should be able to find the affected locations. So, the problem you are experiencing must be with one of these.

Maybe someone with more expertise regarding the IUWS library can help you further?

It may also be worthwhile to have a look at your integrator settings (use another algorithm and/or crank up the accuracy).

Percentile computations on time series only make sense when time points are equidistant. This is however not necessarily the case, as the integrator may use a variable stepsize. For percentile computations (lower, upper, median), the software will therefore resample the time series on the basis of a time interval provided explicitly by the user, or a number of time points from which the interval can be derived.

In WEST 2011/2012 it is not possible to get those values into a file, unless one would do some copy/pasting of the grid that is shown in the "Analysis Properties" / "Variables" / "Time series Criteria" tab. Problem with this tab however is that it doesn't show the aggregated quantity objective values, nor the aggregated overall objective value.

In the upcoming WEST 2014, the "Analysis Properties" have been extended with a new "Run" tab, next to the already existing "Variables" and "Data files" tabs. The "Run" tab gives an overview of all computed objective values (including aggregated objective values), and can be exported through a dedicated button to a variety of formats (Excel, HTML, Text).

For any WEST version, it is of course also possible to create a 1-run Scenario Analysis experiment, from which an output file with objective values can be directly obtained.

Praxis is available through Netlib. The original reference is probably the following:

[i]Richard Brent, Algorithms for Minimization without Derivatives (Prentice-Hall, 1972). (Reprinted by Dover, 2002.) [/i]

The meaning of the properties you mentioned is the following:

- Maximum Number of Function Evaluations: Maximum number of evaluations of the objective function. This is typically almost the same as the number of runs, although not entirely, as some objective function evaluation pre-runs may be done during initialization of the algorithm.
- Print Level: Determines the level of detail of the algorithm's log file (*.Optim.log.txt).
- Maximum Number of Stops: Determines the maximum number of times the stopping criterion is allowed to evaluate to true before the algorithm is actually terminated.
- Seed for Random Number Generator: Initial seed for the RNG used by the algorithm. This generator partly determines the next parameter vector that will be applied to the objective function. It is important to have a seed that is set non-automatically in order to be able to deterministically replay the algorithm.

The difference is computed internally and can currently not be visualized in the user interface. However, if it is felt that visualizing the difference would be generally helpful, we could implement it in a future version of the software.

Sensitivity functions are computed at equidistant time points (which are unrelated to the integration time points of the reference and perturbed simulations), starting at "Minimum Time" and ending at "Maximum Time". The user can either set the interval between time points, or the number of time points (from which the system will automatically derive the interval).

For more information on how sensitivity functions are computed, you may want to read through pp. 120 - 126 of

  [i]Filip Claeys. A Generic Framework for Modeling and Virtual Experimentation with Environmental Systems. PhD thesis. Ghent University,
  Department of Applied Mathematics, Biometrics and Process Control (BIOMATH), Coupure Links 653, B-9000 Gent, Belgium, January 2008.[/i]

  [url=http://biomath.ugent.be/publications/download/claeysfilip_phd.pdf]http://biomath.ugent.be/publications/download/claeysfilip_phd.pdf[/url]

For more information on the objective value computation process, you may also want to refer to pp. 104-110 of

  [i]Filip Claeys. A Generic Framework for Modeling and Virtual Experimentation with Environmental Systems. PhD thesis. Ghent University,
  Department of Applied Mathematics, Biometrics and Process Control (BIOMATH), Coupure Links 653, B-9000 Gent, Belgium, January 2008.[/i]

  [url=http://biomath.ugent.be/publications/download/claeysfilip_phd.pdf]http://biomath.ugent.be/publications/download/claeysfilip_phd.pdf[/url]

In WEST 2012, one can read data from a file into temporary memory through ID = MSLUMatrixLoad(FileName) and hence use MSLUMatrixGet(ID, i, j) to get a value at position (i, j). So, in this case no interpolation is possible, unless it is implemented in MSL by the user.

In the upcoming WEST 2014,  in addition to the above, one will be able to read data from a file into a MSL-declared matrix through MSLUMatrixRead(ref(Matrix), NumRows, NumColumns, FileID) and hence use MSLUMatrixGetValue(ref(Matrix), NumRows, NumColumns, x, ColumnNo, Interpolated, Extrapolated) to interpolate and/or extrapolate, depending on the 2 last arguments.