Hi @chris, I have tested DES.gh and GHE.gh. I understand that the second one is the one you mentioned that still doesn’t work. I managed to launch the FMU, but I had to create both the system_params.json and the Modelica folder from the URBANopt CLI. However, I encountered an error when running uo_des run-model (I believe it’s now a problem with the Docker image or with GTM or MBL).
With the system_params.json that is created with Run_URBANopt, I encountered issues where the weather path is missing, and when I manually include it, I get errors about unexpected properties like “max_electrucal_load.” When I remove that property manually, it tells me that the path to the Modelica loads doesn’t exist.
I understand that this system_params should be created after running the simulation with Run URBANOpt using the Run DES component (but in my case, this component doesn’t work because when it starts downloading the GMT libraries, I encounter issues with the Python version installed within Ladybug Tools, which is version 3.7, and the required version is 3.8.
I understand that you are in the midst of development, but if it can be of any help, I have captured the errors that I encountered, and I can share them with you. Regarding the Docker part, I suppose I should contact NREL, but I’m not sure if they have a dedicated forum or how to reach them.
Sorry that I was unresponsive for a couple of weeks. I have a long response drafted for you that answers all of the questions but I’m just waiting on us to post an updated release with everything you’ll need to run things correctly.
For now, I’ll say I have been able to get to the point where you can write out a full set of Modelica files for both a standard 4th generation system (with a heating and cooling plant) and a 5th generation system (with an ambient loop and at least one ground heat exchanger). I was not able to get the docker-based workflow to run from Grasshopper, which is meant to simulate the Modelica files using OpenModlica in the background. It seems that this workflow is currently not set up to run on Windows and I’ll need some more changes from NREL to fully expose it (perhaps within a few months). However, I am confident that, if you have a Dymola license, the Modelica files we are currently writing should simulate and, if you know enough about OpenModelica, you should be able to simulate the files in the OpenModelica UI. Granted, I personally don’t know enough about OpenModelica but I only get one error when I run the “Check All” functionality on the current models and it just says “Too many open files”, which makes me think it’s a setting that I need to change in the UI.
Give me until the end of today and I’ll post the full instructions for you to test.
Below you can find the full set of instructions for the basic DES workflow from Dragonfly, along with some files for you to test.
But, first, just so you know where we have gotten to, you can see what the heating/cooling plants of the 4th generation system look like here in OpenModelica:
In order replicate the test on your end, you have to do the following:
Uninstall your current version of Ladybug Tools / Pollination and download the latest single-click installer from the Pollination website. You need to do this because, like you said, the Python libraries that NREL has written to produce the Modelica files are intended to work best in Python 3.10 and we just updated our Pollination installers to use Python 3.10 today.
I would start by running the samples that I have already put together for DES simulation before trying to run your own. It sounds like you’ve been trying to use these already but I would re-download the latest ones since I have been updating them over the last few days. Here is a sample Grasshopper file for a 4th Gen DES and Here is a sample Grasshopper file for a 5th Gen DES. You’ll see in the latest version of Dragonfly that, when you plug in a des_loop to the GeoJSON export component, the weather_filename is automatically included in the GeoJSON, we automatically translate the EPW to an .mos file so that it can be used with Modelica simulation, and we also write out a basic system_params.json with any properties of the DES that you set in Grasshopper.
When you get to the “Run DES” component in the samples, note that the first time you run the component, it will download 3 different dependencies to your machine - the geojson-modelica-translator, the ThermalNetwork package for sizing ground heat exchangers, and the correct version of the Modelica Buildings Library. Each of the dependencies will ask you for admin privileges to install. So it will take a while the first time but, once you get these dependencies installed, this won’t happen the next time the component runs.
Also note that, if you are running the 5th generation system, there is a whole long routine that runs prior to writing the Modelica files, which will size the ground heat exchanger. This process can eat up a lot of memory when you start getting to district-size exchangers with thousands of boreholes. So I recommend running on a machine with at least 32 GBs of RAM.
If the “Run DES” component executes successfully, it will output a folder where all of the Modelica files are written. You can open this in OpenModelica with the caveat that these files Only work with MBL version 9.1.0 right now. I know that they did the later releases of the MBL for better compatibility with 5th Gen systems but the geojson-modelica-translator is not yet updated to work with the new conventions. So you will have to use MBL 9.1.0 in the OpenModelica UI if you want to be able to open the files without serious errors. If the 9.1.0 package is being used correctly, you should see this in the OpenModelica UI:
I hope that’s enough to get you started testing and let us know how it goes. I can answer any questions related to the NREL packages or Dragonfly but, as I said, OpenModelica is a bit beyond my expertise at the moment.
Hi @chris , I was already finishing my workday, and your message makes it unlikely that I’ll sleep tonight. I need to try out this move. Thank you very much, I’ll keep you updated with the results.
Thanks, @Batiste . I realize our time zones are a bit mismatched since I just woke up here on the west coast of the US. Take your time with it if you can as there’s no rush and the workflow is only going to get better from here.
Hi @chris, I have tried the 4th Gen DES and I see the Scripting Notification Message that you have put it in the previous message. When I “Check All” the model I have no errors. But when I Run the simulation ( with a > 32 GB ram computer) the simulation stops at second 600s with this error:
I’m not sure what that error code means but let me know if you end up finding out more. I remember Nate from NREL told me that the OpenModelica simulation requires a really large amount of resources in order to run. So it may be worth running a test with a district that has just 1-3 buildings to see if it can complete.
Those images from OMEdit come from navigating through the tree menu and double-clicking on specific parts of the DES. For example, you can see the cooling plant under Plants > Central Cooling Plant:
I have tried what you said, but now I am facing this problem when I run the DF Run URBANopt:
Error running command: ‘C:/URBANopt-cli-0.10.0/OpenStudio/bin/openstudio.exe --bundle ‘C:/Users/Batiste/simulation/Buffalo_Development_DES_2/Gemfile’ --bundle_path ‘C:/Users/Batiste/simulation/Buffalo_Development_DES_2/.bundle/install/’ run -w ‘C:/Users/Batiste/simulation/Buffalo_Development_DES_2/run/honeybee_scenario/Residential4/in.osw’ 2>&1 > “C:/Users/Batiste/simulation/Buffalo_Development_DES_2/run/honeybee_scenario/Residential4/in.osw.log”’
stdout:
stderr: El proceso no tiene acceso al archivo porque est� siendo utilizado por otro proceso.
DONE, result = false
The translation to english: stderr: The process does not have access to the file because it is being used by another process.
The only thing that I modify is to syncronize the Grasshopper file with LB Sync Grasshopper File.
The error message seems pretty clear that it’s having trouble overwriting the older results because they’re open in another program. I would try either manually deleting the project folder before you rerun the simulation, which will give you an indication of which files are open, or you could just run the simulation in a different project folder altogether by changing either the Dragonfly Model _name_ or _folder_ into which the GeoJSON is written.
We are currently working on the basic DES (5G) workflow for Dragonfly using the “ghe_example” sample file. Everything is progressing well until we reach the “Generate DES Modelica Files” step, at which point the process appears to freeze.
I’ve conducted a test using only one floor per building in order to reduce simulation time, but the issue persists during the “Generate DES Modelica Files” step (the simulation appears to halt).
Just to provide additional context, we are using Rhino 7 and Pollination 1.40.5.
If you have any insights or suggestions on how to resolve this issue, it would be greatly appreciated. And thank you very much for all your work!
What is it that convinces you the process is “frozen” vs. it’s just taking a while to run? The component generally takes a long time to run, especially the first time that you run it and it has to download a bunch of extra dependencies. How long are you waiting and do any of the batch windows pop up?
I noticed that the simulation was running for quite a while (approximately 1.5 to 2 hours), so I decided to force-stop it. What’s puzzling to me is that I haven’t seen any pop-up window to download and install the geojson-modelica-translator and ThermalNetwork packages.
Maybe it’s something related to the Python version I’m using (3.12.1)? *
(*) Edited: I have used the “HB Check Versions” component and the Python version is 3.10.10.
How much RAM does you machine have? It’s possible that the routines that size the ground heat exchanger loop are eating all of your memory and taking a long time to complete as a result.
As I don’t get any pop-up terminal window when I run the GH script, I have also tried to manually download and install (via CMD prompt) the Python dependencies needed by the component (geojson-modelica-translator, ThermalNetwork and MBL 9.1.1 through Dragonnfly CLI), which successfully got installed. However, this approach doesn’t work either.
I found the cause of the freezing issue during the ‘Generate DES Modelica Files’ step. Initially, I ran Rhino as an administrator and encountered this error. However, when I executed Rhino in normal user mode, it worked perfectly.
It appears that pop-up windows are requesting administrator privileges, which may have caused a conflict depending on the initial Rhino execution mode.
Sorry for the late response, but yes, that makes sense. The first time that the DES component runs, it needs to install 3 different dependencies, each of which requires you to click "OK for 3 separate “Admin Privilege” popup windows.
After you do this the first time, you should not have to do it again until you upgrade. FYI, the latest development version of Dragonfly is now able to perform the whole Modelica simulation of the GHE DES if you have Docker installed. If you get the chance to test it, please let me know.
There’s a sample file here that shows the whole workflow.
Thanks for testing it so quickly, @Batiste . Glad that it all worked.
If you have any feedback about which Modelica simulation outputs you want to see usable in Grasshopper, I’ll take this into account. You can probably see that we don’t have anything at the moment to parse or visualize the results but we’ll be implementing some things once our subcontract with NREL gets renewed (hopefully in a few months). So the next few months are probably the best time to test and give feedback if you want to help shape the direction that we move in.
Yes, you need to have Docker Desktop installed on your machine in order to run any of the Modelica simulations. And you also need to have Docker Desktop open for the simulation to run.
I should also warn that the Modelica simulation can eat a lot of memory. I usually blow through almost all of my 32GBs of RAM when I run the simple sample file of a 5th gen system. So just be prepared that this is very much a “bleeding edge” capability.
