ecobee / building-controls-simulator Goto Github PK

tearing down the EnergyPlus FMU and re-initializing for each data period (period where all input data exists) is too slow. Should try to keep FMU models initialized and backwards-fill input data then optionally not log output data from those periods when input data is backwards-filled.

Hi @TStesco,

I, Kunind, and Emma are trying to build the docker image on the latest updates. We are getting the same error, so opened this issue and request you to guide on how to move forward. I am attaching an image below for your reference, but just reading through the error message it seems the repo is missing requirements.txt file. Do you know what's wrong here?

New version of DYD has changed. Add the new schema to DataSpec.py as DonateYourDataV2Spec and archive old schema for backwards compatibility.

EnergyPlus Weather files (.epw) require all radiation units in Wh/m2 (https://bigladdersoftware.com/epx/docs/9-4/auxiliary-programs/energyplus-weather-file-epw-data-dictionary.html#field-direct-normal-radiation), yet by default solar radiation data is internally in W/m2 (more common outside .epw format). This causes generated .epw files to have far too much radiation when upsampled from 3600s period to 300 or 60s periods.

The radiation data must be converted to Wh/m2 before being saved in generated .epw file.

I used docker-compose run --service-ports building-controls-simulator bash to start building the image. .env was edited for local directory. Gitbash was used to execute the commands. I am running into this error at step 23 (attached: Build fail error.png and env.png)

https://github.com/lbl-srg/EnergyPlusToFMU/releases/tag/v3.1.0 adds support for python3, can now remove python2 dependency.

tzwhere (https://github.com/pegler/pytzwhere) is very slow, replace with timezonefinder (https://github.com/jannikmi/timezonefinder) using numba.

I find it a bit strange to call do_step twice in slightly different contexts. Maybe do_step should be called something different for the two calls?

As BCS moves from alpha to beta, its user base will be less interested in development and more interested in using BCS. Should we consider spitting BCS into the bcs-core of the docker container and everything needed to run the bcs-simulator . For example, if the data and scripts directories made up bcs-simulator were in a separate repo that was a submodule to bcs-core then it would be more clear to day-to-day users what they should be 'allowed' to touch. This would also more clearly enable branches/forks of scripts without needing to have all of the bcs-core in the repo.

tldr; Moving the day-to-day scripts of BCS to their own repo would reduce the learning curve for new users.

PyFMI fmu.initialize hangs on EnergyPlusBuildingModel if fmu has been initialized before. Potentially an issue with EnergyPlusToFMU or EnergyPlus <= 9.40 thread safety.

Should line 42 in .gitignore, that is !notebooks/test_* instead (or also) be !notebooks/demo_* since the files currently in notebooks/ are all demo_*.ipynb?

in test_Simulator.py setting

min_sim_period="3D"

causes self.data_client.thermostat.get_categories_dict() to return empty dict.

I am having issues in the next step of the process in the container build, i.e. creating the network from the docker image. I get the same non-zero code error 127 when it tried to find the jupyter_lab.sh file. ( image attached)

Need some adjustments in IDFPreprocesor for changed objects, e.g. for .err output

Severe  ** <root>[RunPeriod][simulation_runperiod][day_of_week_for_start_day] - "USEWEATHERFILE" - Failed to match against any enum values.
Severe  ** <root>[Window][Window_ldb_1.unit1][multiplier] - "0.914634" - Expected number greater than or equal to 1.000000
Severe  ** <root>[ZoneHVAC:EquipmentList][ZONEEQUIPMENT_unit1][equipment][0][zone_equipment_cooling_sequence] - Value type "string" for input "SequentialLoad" not permitted by 'type' constraint.
Severe  ** <root>[ZoneHVAC:EquipmentList][ZONEEQUIPMENT_unit1][equipment][0][zone_equipment_heating_or_no_load_sequence] - Value type "string" for input "ZoneHVAC:AirDistributionUnit" not permitted by 'type' constraint.
Severe  ** <root>[ZoneHVAC:EquipmentList][ZONEEQUIPMENT_unit1][equipment][0][zone_equipment_object_type] - "SequentialLoad" - Failed to match against any enum values.

under the test section; the path for copying the example IDF file has been updated to idf/v8-9-0/xyz/abc.idf

runtime is integrated via sum, i.e. the values recorded are cumulative over the previous step period. This means that any non-continuous runtime in a step period may occur at the beginning or end of the step period. Given known minimum cycle times, and times between cycles, the correct placement of the runtime within the step period can be inferred and used to upsample the runtime data from 300s to, for example 60s.

Add generic FMI interface for controller models to be implemented as Functional Mock-up Units (FMUs), see https://fmi-standard.org/ for standard details. Support tooling in https://github.com/ghorwin/FMICodeGenerator to generate working FMUs.

To create building simulations representing a specific geography weather data, and eventually weather forecasts, must be made available to the simulation. The actual weather data must be converted to the Energy Plus Weather format (.epw), see https://bigladdersoftware.com/epx/docs/9-3/auxiliary-programs/energyplus-weather-file-epw-data-dictionary.html for format reference. Forecast data is used for control algorithm and does not need to be converted to this format. Additionally, a method to retrieve both historical measured and forecasted weather data is ideal to support the programmatic modelling process. This could be based on pvlib https://github.com/pvlib/pvlib-python/blob/master/pvlib/forecast.py.

add GBQDataSource.py and GBQFlatFilesSource.py to read data in FlatFiles spec.

Need to increase simulation resolution to minimum 1 minute time steps (limit in EnergyPlus).

Take input time step size in minutes and resample input data, run simulation with those time steps, then aggregate back to 5 minutes time step output to follow ISM.

Thanks for your work in putting this repo together.

I'm encountering an error running docker-compose. Any pointers? FYI @peteg240

$ docker-compose up
Building building-controls-simulator
[+] Building 117.0s (8/12)                                                                                   
 => [internal] load build definition from Dockerfile                                                    0.0s
 => => transferring dockerfile: 37B                                                                     0.0s
 => [internal] load .dockerignore                                                                       0.0s
 => => transferring context: 34B                                                                        0.0s
 => [internal] load metadata for docker.io/library/ubuntu:20.04                                         0.7s
 => [1/8] FROM docker.io/library/ubuntu:20.04@sha256:0e0402cd13f68137edb0266e1d2c682f217814420f2d43d30  0.0s
 => [internal] load build context                                                                       0.0s
 => => transferring context: 5.99kB                                                                     0.0s
 => CACHED [2/8] RUN apt-get update && apt-get install -y --no-install-recommends sudo     && adduser   0.0s
 => CACHED [3/8] RUN sudo apt-get update && sudo apt-get upgrade -y     && sudo apt-get install -y --n  0.0s
 => ERROR [4/8] RUN mkdir "/home/bcs/lib" && mkdir "/home/bcs/lib/external"     && cd "/home/bcs/lib  116.3
[...LOTS OF TRUNCATED OUTPUT...]
#7 115.9       Start 35: ctest_fmi_import_test_me_2
#7 115.9 35/36 Test #35: ctest_fmi_import_test_me_2 ...........................   Passed    0.00 sec
#7 115.9       Start 36: ctest_fmi_import_test_cs_2
#7 115.9 36/36 Test #36: ctest_fmi_import_test_cs_2 ...........................   Passed    0.00 sec
#7 115.9 
#7 115.9 97% tests passed, 1 tests failed out of 36
#7 115.9 
#7 115.9 Total Test time (real) =   0.92 sec
#7 115.9 
#7 115.9 The following tests FAILED:
#7 115.9 	  6 - ctest_fmi1_xml_parsing_test (Failed)
#7 115.9 Errors while running CTest
#7 115.9 make: *** [Makefile:118: test] Error 8
------
executor failed running [/bin/sh -c mkdir "${LIB_DIR}" && mkdir "${EXT_DIR}"     && cd "${EXT_DIR}"     && curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash     && pyenv update && pyenv install 3.8.12     && wget "https://github.com/modelon-community/fmi-library/archive/refs/tags/2.3.zip"     && unzip "2.3.zip" && mv "fmi-library-2.3" "FMIL"     && rm -rf "2.3.zip"     && cd "FMIL"     && mkdir build-fmil; cd build-fmil     && cmake -DFMILIB_INSTALL_PREFIX=./ ../     && make install test     && cd "${EXT_DIR}"     && wget "https://github.com/modelica-tools/FMUComplianceChecker/releases/download/2.0.4/FMUChecker-2.0.4-linux64.zip"     && unzip "FMUChecker-2.0.4-linux64.zip"     && rm "FMUChecker-2.0.4-linux64.zip"     && mv "FMUChecker-2.0.4-linux64" "FMUComplianceChecker"     && mkdir "fmu"     && cd "${EXT_DIR}"     && wget "https://github.com/lbl-srg/EnergyPlusToFMU/archive/refs/tags/v3.1.0.zip"     && unzip "v3.1.0.zip" && rm "v3.1.0.zip"     && cd "${EXT_DIR}"     && wget "https://github.com/LLNL/sundials/releases/download/v4.1.0/sundials-4.1.0.tar.gz"     && tar -xzf "sundials-4.1.0.tar.gz" && rm "sundials-4.1.0.tar.gz"     && cd "sundials-4.1.0"     && mkdir "build"     && cd "build"     && cmake -DCMAKE_INSTALL_PREFIX="${EXT_DIR}/sundials" ..     && make install     && cd "${EXT_DIR}"     && wget "https://github.com/Reference-LAPACK/lapack/archive/refs/tags/v3.9.1.tar.gz"     && tar -xzf "v3.9.1.tar.gz" && rm "v3.9.1.tar.gz"     && cd "lapack-3.9.1"     && mkdir build     && cd "build"     && cmake -DCMAKE_INSTALL_PREFIX="${EXT_DIR}/lapack" ..     && cmake --build . -j --target install     && cd "${EXT_DIR}"     && wget "https://github.com/modelon-community/Assimulo/archive/refs/tags/Assimulo-3.2.9.tar.gz"     && tar -xzf "Assimulo-3.2.9.tar.gz" && rm "Assimulo-3.2.9.tar.gz"     && mv "${EXT_DIR}/Assimulo-Assimulo-3.2.9" "${EXT_DIR}/Assimulo-3.2.9"     && cd "${EXT_DIR}"     && wget "https://github.com/modelon-community/PyFMI/archive/refs/tags/PyFMI-2.9.5.tar.gz"     && tar -xzf "PyFMI-2.9.5.tar.gz" && rm "PyFMI-2.9.5.tar.gz"    && mv "${EXT_DIR}/PyFMI-PyFMI-2.9.5" "${EXT_DIR}/PyFMI"     && cd "${LIB_DIR}"     && mkdir "${PACKAGE_DIR}"     && sudo rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*]: exit code: 2
ERROR: Service 'building-controls-simulator' failed to build : Build failed

Need to generate .epw files at 60s period data and use DATA PERIOD and SIMULATION CONTROL objects to coordinate simulation dynamically.

I am trying to set-up the docker image but it fails on step 24/25 with the following error message.

I have built the latest version of BCS from source using docker up on Windows. However, I'm getting an error when I try to run demo_LocalSource.ipynb

It seems the actually directory specified by LOCAL_CACHE_DIR (i.e., /home/bcs/lib/building-controls-simulator/data/ ) does not exist.

I haven't specified any of the cloud credentials, so it should be trying to do everything locally. But, do I need to copy local files to a specific directory? If so, what files do I need to copy to the local data directory?

I resolved the issue by copying 2756663bc57afe940c552ab1080f2ec09ef54e24.csv.zip to /home/bcs/lib/building-controls-simulator/data/input/local/ creating the necessary parent directories.

tldr; The need to copy the example .csv.zip to the data/input/local/ should be documented as an step when installing BCS. Alternatively, could this file be included in the repo? (Probably not given the NDA on the DYD data.)

Installed docker successfully and made changes to env and docker-compose.yml. After making the changes, failed to build the docker image with docker-compose run --service-ports building-controls-simulator bash. Error message attached.

need instruction to set up environment variables.

State estimation (aka observer) process required to replicate realistic feedback controls scenario (see https://en.wikipedia.org/wiki/State_observer). Implement low pass filter to start with (https://en.wikipedia.org/wiki/Low-pass_filter).

Will need to wait for https://github.com/lbl-srg/EnergyPlusToFMU to add 9.5.0 support, or the alternative being to refactor the EnergyPlusBuildingModel class to use https://github.com/NREL/Spawn instead.

This release (https://github.com/NREL/EnergyPlus/releases/tag/v9.5.0) makes EnergyPlus thread safe, which should allow for parallel simulations on the same host container.

After building the container when I try to set the Eplus version to 8.9.0 using the bash scripts/epvm.sh 8-9-0, I am getting the "directory not found" error. I am working in VS code that I opened from the container.

Let me know if I doing something wrong?