This is a collection of links/information to help get an overview of modelica and how it integrates with the ctrl-flow widget (formerly called "Linkage").
Modelica templates are special .mo files that have inputs to allow a component to be configured.
These templates exist in the modelica-buildings repo on the master branch.
The ctrl-flow widget interacts with these templates parsed as modelica-json.
All examples are from the most complete template, VAVMultizone.
For additional details about template inputs refer to the requirements website for detailed information on Parameter Dialog Annotations.
/*
From Templates/AirHandlersFans/Interfaces/PartialAirHandler.mo
*/
parameter Buildings.Templates.AirHandlersFans.Types.Configuration typ
"Type of system"
annotation (Evaluate=true, Dialog(group="Configuration"));From this parameter we extract the following:
- Input title is "Type of System"
- This is put in the 'configuration' group
- parameter type is an enum of type
Buildings.Templates.AirHandlersFans.Types.Configuration - NOTE: tab can also be specified, e.g.
annotation (Dialog(tab="Assumptions", group="Heat transfer"))
Additional details on variables and how we translate into UI in the requirements
final keyword: TODO
Templates can have 'replacable' sub-components, that look as follows:
inner replaceable Buildings.Templates.Components.Fans.SingleVariable fanSupDra
constrainedby Buildings.Templates.Components.Fans.Interfaces.PartialFan(
redeclare final package Medium = MediumAir,
final dat=dat.fanSup,
final have_senFlo=ctl.typCtlFanRet==
Buildings.Templates.AirHandlersFans.Types.ControlFanReturn.AirflowTracking)
"Supply fan - Draw through"
annotation (
choices(
choice(redeclare replaceable Buildings.Templates.Components.Fans.None fanSupDra
"No fan"),
choice(redeclare replaceable Buildings.Templates.Components.Fans.SingleVariable fanSupDra
"Single fan - Variable speed"),
choice(redeclare replaceable Buildings.Templates.Components.Fans.ArrayVariable fanSupDra
"Fan array - Variable speed")),
Dialog(group="Supply air section",
enable=fanSupBlo.typ==Buildings.Templates.Components.Types.Fan.None),
Placement(transformation(extent={{172,-210},{192,-190}})));
...used to identify components in a model whose type can be changed (or “redeclared”) in the future. One way to think about replaceable is that it allows the model developer to define “slots” in the model that are either “blank” to begin with (where an interface model is the original type in the declaration) or at least “configurable”.
The annotation below with the keyword 'choices' has a list of modelica models referenced by a path (e.g. 'Buildings.Templates.Components.Fans.SingleVariable').
Upon selection, the previous 'replacable' block is replaced with a 'redeclare' block:
redeclare replaceable Buildings.Templates.Components.Fans.SingleVariable
fanSupDra,
Available template selections are NOT all listed in a single file. To get the full tree of available options, extended models, subcomponents, and records need to be traversed recursively.
Throughout the templates qualified names are used to reference other parameters in a modelica package. We can use these names as package relative paths to determine what other json files need to be traversed to get all available options.
An example modelica path:
"Buildings.Templates.AirHandlersFans.Interfaces.PartialAirHandler"
Doing so will generate a tree of options for the model and subcomponents.
An example of extending a model - Multizone VAV extends PartialAirHandler:
within Buildings.Templates.AirHandlersFans;
model VAVMultiZone "Multiple-zone VAV"
extends Buildings.Templates.AirHandlersFans.Interfaces.PartialAirHandler(
The configuration will need to render three types of input fields:
- Replacables ('Choices')
- Booleans
- Enums
Templates will have a parameter pointing to a Record. The general pattern being followed is to name this parameter dat. Any subcomponent that has a record with a paremter dat is extracted as a schedule option. These records will contain all related control and mechanical points for the schedule
Within a dat Record parameters will be be structured in the following way:
Record datparam1Record subgroup1param2param3
Record Subgroup2param4param5
The dat Record will contain sub Records that group parameters together, and these sub-groupings will be what we use to organize table headings in the schedules table.
The above listing of parameters and sub Records when rendered should become:
| subgroup1 | subgroup2 |
|--------|-----------------|--------|--------|
| param1 | param2 | param3 | param4 | param5 |
|-------|--------|--------|--------|--------|--------|
| row1 | val1 | val2 | val3 | val4 | val4 |
| row2 | ...
modelica-json is able to take modelica and convert to json and back. This tool is integrated with the server but can be used as a command line tool.
For standalone use refer to the modelica-json readme.
The tool can also be used in the container (make sure docker is installed). As an example, here's how to convert the VAVMultiZone modelica template getting converted to modelica-json:
# starting from the root of this repo
cd server
npm i # make sure server dependencies are installed
npm run docker:start
# get an interactive shell in the running container
npm run docker:shell
# now in the container:
cd /dependencies/modelica-json
node app.js -f /dependencies/modelica-buildings/Buildings/Templates/AirHandlersFans/VAVMultiZone.mo -o json -d out
# json outputs into the 'out' folder
-
Modelica University - collection of resources for Modelica
-
Modelica by Example - Nice practical introduction to modelica that incrementally walks through features in the language
-
Modelica literals and Arrays:
-
Operators and Expressions:
-
Modelica Language Specifcation - in particular operators and expressions, also here.