Sim::OPT.
use Sim::OPT; opt;
Sim::OPT is an optimization and parametric exploration program oriented to problem decomposition. It can be used with simulation programs receiving text files as input and emitting text files as output. Some of Sim::OPT's optimization modules (Sim::OPT, Sim::OPT::Descent) pursue optimization through block search, allowing blocks (subspaces) to overlap, and allowing a free intermix of sequential searches (inexact Gauss-Seidel method) and parallell ones (inexact Jacobi method). The Sim::OPT::Takechange module seeks for the least explored search paths when exploring new search spaces sequentially (following rules presented in: http://dx.doi.org/10.1016/j.autcon.2016.08.014). Sim::OPT::Morph, the morphingchange module, manipulates chosen parameters in the configuration files (constituted by text files) describing models for simulation programs, recognizing variables by position. The Sim::OPT::Parcoord3d module converts 2D parallel coordinates plots in Autolisp instructions for obtaining 3D plots as Autocad drawings. The Sim::OPT::Modish module alters the shading values calculated with the ESP-r simulation platform in order to take into account the solar reflections from obstructions.
The Sim::OPT's morphing and reporting modules contain several additional functions specifically targeting the ESP-r building performance simulation platform. A working knowledge of ESP-r (http://www.esru.strath.ac.uk/Programs/ESP-r.htm) is necessary to use those functionalities.
To install Sim::OPT, the command <cpanm Sim::OPT> has to be issued as a superuser. Sim::OPT can then be loaded through the command <use Sim::OPT> in a Perl repl. But to ease the launch, the batch file "opt" (which can be found packed in the "optw.tar.gz" file in "examples" folder in this distribution) may be copied in a work directory and the command <opt> may be issued. That command will call OPT with the settings specified in the configuration file. When launched, Sim::OPT will ask the path to that file, which must contain a suitable description of the operations to be accomplished and point to an existing simulation model.
The "$mypath" variable in the configuration file must be set to the work directory where the base model reside.
To run the morphing functions of OPT without making OPT launch the simulation program, the setting <$exeonfiles = "n";> should be specified in the configuration file. That way, the commands will only be printed to a file. This can be aimed to inspect the commands that OPT would give the simulation program, and for debugging.
Besides an OPT configuration file, separate configuration files for propagation of constraints may be created. Those can be useful to give the morphing operations greater flexibility. Propagation of constraints can regard the geometry of a model, solar shadings, mass/flow network, controls, and generic text files descripting a simulation model.
The simulation model folders and the result files that will be created in a parametric search will be named as the base model, plus numbers and other characters naming model instances. For example, the instance produced in the first iteration for a root model named "model" in a search constituted by 3 morphing phases and 5 iteration steps each will be named "model_1-1_2-1_3-1"; and the last one "model_1-5_2-5_3-5".
The structure of the block searches is described through the variable "@sweeps" in the configuration file. Each case is listed inside square brackets. And each search subspace (block) in each case is listed inside square brakets. For example: a sequence constituted by two sequential brute force searches, one regarding parameters 1, 2, 3 and the other regarding parameters 1, 4, 5, 7 would be described with: @sweeps = ( [ [ 1, 2, 3 ] ] , [ [ 1, 4, 5, 7 ] ] ) (1). And a sequential block search with the first subspace regarding parameters 1, 2, 3 and the second regarding parameters 3, 4, 5, 6 would be described with: @sweeps = ( [ [ 1, 2, 3 ] , [ 3, 4, 5, 6 ] ] ).
The number of iterations to be taken into account for each parameter for each case is specified in the "@varinumbers" variable. To specifiy that the parameters of the last example are to be tried for three values (iterations) each, @varinumbers has to be set to ( { 1 => 3, 2 => 3, 3 => 3, 4 => 3, 5 => 3, 6 => 3 } ).
The instance number that has to considered the basic one, corresponding to the root case, is specified by the variable "@miditers". "@miditers" for the last example may be for instance set to ( { 1 => 2, 2 => 2, 3 => 2, 4 => 2, 5 => 2, 6 => 2 } ).
By default the behaviour of the program is sequential. To make it parallel locally, subspaces may be named, so as to work as collector cells. A name named "name" must be written ">name" and placed at the end of the block from which it is receiving the value produced by the block. Clearly, one named block (cell) can receive inputs by more than one block. The name named "name" should instead be written "name>" and placed at the beginning of the block in the case that it brings into it the values it contains.
An example: @sweeps = ( [ [ "0>", 1, 2, 3, ">a" ] , [ "0>", 3, 4, 5, 6, ">a" ] , [ "a>" 6, 7, 8, 9 ] , [ 11, 12, 13, ">b" ] , [ ">b", 14, 15, 16, ">c" ], [ ">b", 15, 16, 17, ">c" ], [">c"] ] ); The ">"s signalling the named blocks can be seen as a visual aid for a sort of markup language for blocks which allows to nest parts of a search. But they can be omitted.
Numerical blocks, for example [ 1, 2, 3 ], are automatically named, in the sense that they can also be used as container cells. The name of the block in question, for example, is "1, 2, 3", so there is no need to create new containers and names esplicitly. For this reason, there is also no need of specifying a container block at the beginning of a block or at the end of a block for describing directed graphs. Only specifying collectors at the entry or at the exit of some blocks is necessary when there is parallelism involved. For example, the last cited search could also have been written in the following manner: @sweeps = ( [ [ 1, 2, 3, ">6, 7, 8, 9" ] , [ "0>", 3, 4, 5, 6, ">6, 7, 8, 9" ] , [ 6, 7, 8, 9 ] , [ 11, 12, 13, ">14, 15, 16" ] , [ 14, 15, 16, ">c" ], [ 11, 12, 13, ">15, 16, 17" ] ,[ 15, 16, 17, ">c" ] ] ). But sometimes it may be worth adding extra containers for the sake of clarity.
The collector-like block "0>" is a particular case: it is the base case. The beginning of a search always begins with a "0>", explicitly or implicitly. Other "0>"s can be present along the search graph as inner starting points. But it is cleaner not to alter the block "0", not to use it as a collector cell.
Any groups of parameters can be renamed in the configuration file (before the variable @sweeps is specified), and that name can be used in place of the parameters. For example: $group1 = (1, 2, 3); $group2 = (2, 3, 4); In that case, writing ( [ [ 1, 2, 3 ] , [ 2, 3, 4 ] ] ) is equivalent to ([["$group1"]], [["$group2"]]).
What counts in describing a search is the fact that the blocks are named (i.e. they are strings - even if they contain numbers) or not, i.e. they are constituted by sequences of numbers (parameters, variables) or they are aliases directing to them. If they are named, they are just containers which generate no action. If they are constituted by numbers, block search takes place in them, and they also can work as containers. In the case the blocks are named, they get spliced (pasted) into other blocks, and they can only be placed at the beginning and/or at the end of them, but not in the middle.
The consequence of all this is that there is more than one way for describing a search. For example, the search written in the two versions above can also be described in the further manners, using named containers at the end of each block (a) or at the beginning (b): (a): @sweeps = ( [ [ "0", "1, 2, 3" ], [ 1, 2, 3, "6, 7, 8, 9" ] , [ "0", "3, 4, 5, 6" ], [ 3, 4, 5, 6, "6, 7, 8, 9" ] , [ 6, 7, 8, 9 , "11, 12, 13" ] , [ 11, 12, 13, "14, 15, 16" ] , [ 14, 15, 16, "c" ], [ 11, 12, 13, "15, 16, 17" ] ,[ 15, 16, 17, "c" ] ] ); (b): @sweeps = ( [ [ "0", 1, 2, 3 ], [ "1, 2, 3", 6, 7, 8, 9 ] , [ "0", 3, 4, 5, 6 ], [ "3, 4, 5, 6 ", 6, 7, 8, 9 ] , [ "6, 7, 8, 9", 11, 12, 13 ], [ "11, 12, 13 ", 14, 15, 16 ], [ "14, 15, 16", "c" ], [ "11, 12, 13", 15, 16, 17 ] ,[ "15, 16, 17", "c" ] ] ).
The possibility of articulating a mix of parallel and sequential searches is more fundamental that can be expressed with words, because it makes possible to design search structures with a depth, embodying precedence, and therefore procedural time, in them. Deriving from this, there is the fact that the representation tools in question are sufficient for describing directed graphs.
Where Sim::OPT may be fit for a task? Where a certain exploration is complex and/or when it is to be confronted through decomposition, by dividing a problem in overlapping subproblems; when there aren't slick tools suitable to decomposition-based, simulation-based optimization; when spending a day, or two, or three setting up a model may spare months of work.
Where it may not be suitable for the task? Due to the investment which is necessary for getting acquainted with its raw interface, for quick shots at small explorations.
The program works under Linux.
"opt".
Annotated examples ("esp.pl" for ESP-r, "ep.pl" for EnergyPlus - the two perform the same morphing operations on models describing the same building -, and "des.pl" about block search) can be found packed in the "optw.tar.gz" file in "examples" directory in this distribution. They constitute the available documentation. For more information, reference to the source code should be made.
Gian Luca Brunetti, <gianluca.brunetti@polimi.it>
Copyright (C) 2008-2017 by Gian Luca Brunetti and Politecnico di Milano. This is free software. You can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.
To install Sim::OPT, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Sim::OPT
CPAN shell
perl -MCPAN -e shell install Sim::OPT
For more information on module installation, please visit the detailed CPAN module installation guide.