Filip Claeys

Top-level parameters can only be created for scalars. Vectors are indeed not supported in this context.

Maybe you can add an extra scalar parameter to your model, assign it to the desired vector element inside your model code, and then create a top-level parameter association for this extra scalar parameter?

[ In the upcoming WEST 2017 release, there will be another way around this, i.e. through the new concept of "top-level equations" ]

Please open your BlockLib.xml file in a regular text editor and have a look at the tag [tt]<BlockLib Name="...[/tt] somewhere near the top. Normally you should see something like [tt]<BlockLib Name="WEST.WWTP" Version="3.0">[/tt], but I think that in your case [tt]Name[/tt] will be a full absolute path name for some reason. So please change it to the actual name of your BlockLib (without extension and without path).

The exact problem is that when using the Turkish locale, the upper case of the letter "i" is a capital "I" with a dot on it (Turkish is a so-called bicameral language), which is not a valid ASCII character. This causes a problem in the sentinel of MSL files, since here the automatically capitalized project name is used.

What is the name of your project? Does it contain special characters maybe? Are you using a special locale (cf. Regional Settings), e.g. Turkish?

SRT and HRT can be computed by placing a ProcessCalculator block (cf. Sensors palette) on the layout's canvas, and subsequently feeding the following data items to it:
[list]
[li]V & TSS of ASU's[/li]
[li]Q_in[/li]
[li]Q_out and TSS_out[/li]
[li]Q_waste and TSS_waste[/li]
[/list]
Have a look at [url=http://userarea.west.mikebydhi.com/Download/Public/SRT-HRT.jpg]http://userarea.west.mikebydhi.com/Download/Public/SRT-HRT.jpg[/url]. You will notice that in this screenshot SRT is additionally fed into a block that implements a moving average, in order to smooth its dynamic variation.

You may want to place the ProcessCalculator block and its connections on a different layer that can optionally be hidden, in order to avoid too much clutter.

There is no traditional documentation on WESTforAUTOMATION, as we normally train WESTforAUTOMATION users "by example", based on their specific needs, in the scope of a commercial training session.

That being said, WEST can be automated in a least 4 ways:

- The simplest consists in executing the "texec.exe" command-line tool that is included in every WEST installation, for instance from a batch file.

- Another possibility is to use the "TornadoMEX" MEX DLL from MATLAB. TornadoMEX is included in recent versions of the WEST installer.

- Third possibility is to use "WESTforAUTOMATION", which basically is the "TornadoNET" .NET assembly that is part of every WEST installation, but can only be used with the proper license. This assembly allows for WEST experiments to be run from any .NET-enabled language, such as C#, F#, VB.NET, IronPython, IronRuby, C++/CLI and recent MATLAB versions. Also included in every recent WEST installer is the "TornadoCOM" assembly, which sits on top of the "TornadoNET" assembly and allows for WEST experiments to be run from COM-enabled programs such as MS Excel.

- Lastly it is also possible to run WEST experiments from languages such as C, C++, Java, CLIPS and R. For this, specific libraries and DLL's are required that are only available within the scope of a bilateral agreement.

In your case, since you mentioned Python as your first preference, it seems most appropriate to use the TornadoNET assembly from IronPython. I will send you an example program to illustrate how this works.

MSL does not have WHILE loops. Nor does it have FOR or IF-THEN constructs. As you mentioned, it does have FOREACH and IF-THEN-ELSE though.

MSL is not a regular procedural language such as C(++), FORTRAN, Pascal, VB, Java, ... in the sense that we are not dealing with [u]statements[/u] that are executed one after the other. Instead, we have [u]equations[/u] that are automatically sorted. Consequences of this are that we always need a left-hand-side as well as a right-hand-side for any equation at any time (which is why the ELSE part in IF-THEN-ELSE constructs is indispensable) and that FOREACH constructs lead to an expansion (unrolling) of the equation set. WHILE and plain FOR (non-expanded) are therefore not possible.

I see 2 possibilities:
[list]
[li]Use the MSLUMatrixRead() function somewhere in your MSL code (typically somewhere in the initial section) to load data from a text file directly into your parameter vector[/li]
[li]Convert a text file with parameter values to a parameter library (.ParamLib.xml) using Tornado's tfile2paramlib command-line tool (not included in the standard WEST installer), and subsequently load that parameter library into the block containing the actual parameter vector through the Load button in WEST's Model Explorer window.[/li]
[/list]

This is an advanced feature that is supported by the Tornado kernel (and hence also by the "Experimenter" GUI tool - see the EnableRepetition, RepetitionIntervalStartTime, RepetitionIntervalStopTime, RepetitionStartTime properties), but is not accessible through the "WEST" GUI app.

This is a frequently recurring question that can however not be answered without further clarification of what is specifically intended, as possibilities are many. Below are a number of options that have been explored in the past:

[list]
[li]Calling the Tornado command-line experiment executor from MATLAB[/li]
[li]Integration of Tornado with MATLAB through Tornado’s MEX wrapper[/li]
[li]Integration of Tornado with MATLAB through .NET[/li]
[li]Conversion of flat MSL / Modelica models to S-functions (for use with MATLAB/Simulink)[/li]
[li]Conversion of a MATLAB fuzzy inference system (FIS) to executable code for Tornado[/li]
[li]Generating a C-callable DLL from MATLAB M code that can be invoked from MSL / Modelica models[/li]
[/list]

Please have a look at the attached document for further information on these options.