NAME
Sim::OPT.
SYNOPSIS
use Sim::OPT;
opt;
DESCRIPTION
Sim::OPT is an optimization and morphing program that in principle may be used with any kind of simulation programs that can receive text files as input and emit text files ad output. Some of its optimization modules (Sim::OPT, Sim::OPT::Descent) pursue optimization by overlapping block coordinate descent (Gauss-Seidel method). Another optimization module (Sim::OPT::Takechange) seeks for the least explored search paths when exploring not-much-exploited exploited search spaces. The Sim::OPT morphing module (Sim::OPT::Morph) manipulates text files by targeting specific variables position and applying to them generic interpolation rules. The Sim::OPT::Parcoord3d module is dedicated to reporting and creating parallel coordinates plots in 3D.
At a more specific level, Sim::OPT is aimed to the detailed metadesign of buildings through the ESP-r building performance simulation platform. Because of that, a working knowledge of ESP-r (http://www.esru.strath.ac.uk/Programs/ESP-r.htm) is presently necessary to use most functionalitues of OPT. (Note that ESP-r must be compiled for text, not graphics, and for Linux.) Sim::OPT features several morphing functions mapping the functions of the ESP-r platform and can manage it not only by manipulating text input files, but also through the shell.
To install Sim::OPT, the command <cpanm Sim::OPT> has to be issued as a superuser. OPT can then be loaded through the command <use Sim::OPT> in a Perl repl. To ease the launch, the batch file "opt" (which can be found packed in the "optw.tar.gz" file in "example" folder in this distribution) may be copied in a work directory and the command <opt> may be issued. That command will activate the OPT's functions, following the settings specified in the configuration file, which had to be prepared in advance. When launched, OPT will ask the path to that file. Its activity will start after receiving that information. That file must contain a suitable description of the operations to be accomplished pointing to an existing ESP-r model.
In "optw.tar.gz" there is an example of OPT configuration file for an ESP-r model and another one for EnergyPlus (another building performance simulation program). The defined configuration file may be copied in a chosen work folder for OPT, in which the ESP-r models to be worked may reside. The "$mypath" variable in the configuration file must be set to that work directory.
To run OPT without making it launch ESP-r, the setting <$exeonfiles = "n";> should be specified in the configuration file. This can be aimed to inspect the morphing commands that OPTS would give to the simulation program. But that way a sequential block search cannot be performed, because it cannot be run "dry", without retrieving any information about the results at the end of each search cycle.
If $exeonfiles is set to "y", OPT will give instruction to ESP-r via shell to make it modify the building model in the specified steps. Then, if asked, it will run simulations, retrieve the results, extract some information from them and order it as requested.
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, and/or controls; and also, how those pieces of information affect each other and daylighting.
The ESP-r model folders and the result files that will be created in a parametric search will be named as the base building model, numbers and other characters to describe an instance. 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". Each case is listed inside square brackets. And each search subspace (block) in them is listed inside square brakets, nested in cases. For example: a sequence constituted by two 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 ] ] ). And a 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 } ).
Where Sim::OPT may be fit for the task? Where a certain exploration is complex and/or when it is to be confronted through decomposition, by dividing a problem in overallapping 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 Sim::OPT may not be fit for the task? In its present state, due to its crude interface, for quick shots at small explorations.
Gian Luca Brunetti
gianluca.brunetti@polimi.it
EXPORT
"opt".
SEE ALSO
The available examples are collected in the "example" directory in this distribution.
AUTHOR
Gian Luca Brunetti, <gianluca.brunetti@polimi.it>
COPYRIGHT AND LICENSE
Copyright (C) 2008-2015 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 2 or later.