Create Modelica Loads from Dragonfly output?

grasshopper dragonfly
1

Hi All,

I am hoping to use Dragonfly to build a district of buildings and then pull those outputs to use in the District Energy System Workflow in UrbanOpt (described here: District Energy Systems (DES) - URBANopt Docs)

I tried running the dragonfly model and then using those results to run uo_des as provided by the geojson-modelica-translator (GMT).

I run into an issue because the GMT wants to see “modelica loads” inside the run files for each of the feature folders. These modelica loads are automatically generated when you use the regular baseline mapper class but don’t appear to be generated when using the honeybee mapper class.

Is there a way people have accomplished this? I was thinking maybe I should just edit the honeybee mapper class and try to stitch in the modelica loads stuff. But I am hoping someone else has already tried to do this…

Thanks!
Graham

2

I think I figured it out… you can add the following lines to the honeybee osw:

 { "measure_dir_name":"export_time_series_modelica",
  "arguments":{
    "__SKIP__":false
  }
},{
  "measure_dir_name":"export_modelica_loads",
  "arguments":{
    "__SKIP__":false
  }

Then run urbanopt with the honeybee_scenario.csv mapper and the resulting run folders will populate the modelica data. The GMT seems to accept this data

3

Hello Graham, I’m performing the same workflow as you to obtain modelica_loads from a URBANopt simulation done with Dragonfly. However, I have a different problem than yours; it’s not detecting the weather file, and I’m getting the following error: KeyError: ‘weather_filename’. Any suggestions are welcome. Regards.

4

Hi Batiste - I would guess this is an error in the geojson, I think I had to sort this out too.

In the geojson file theres a section for just the “project” where you can add a field called “weather_filename:” and then enter your EPW filename

Also look around in any of the UrbanOpt files for places where filenames are referenced… whenever Dragonfly makes file paths it does it in a very Windows centric way (at least on my Windows computer) and I had to change the file paths to a Linux appropriate structure since the GMT is basically a linux tool

1 Like
5

Wow, you both are quite advanced URBANopt users. I know the workflow for this currently involves a lot of text file editing and CLI commands.

I’m really glad that you were able to figure it out, @grahamjlinn . Out of curiosity, are you using Dymola to visualize and compile the Modelica files?

FYI, the team at NREL just finished updating all of the DES workflows to use OpenModelica. They just pushed an updated docker image a week ago.
… and they released an updated version of the Python package that generates the Modelica files:

All of this means that I’ll hopefully finally be exposing this in Dragonfly over the next month or two.

As for the issue you are facing, @Batiste , I see that weather_filename is an optional key in the GeoJSON schema that URBANopt uses:

image
image887×727 27.5 KB

If you could try out the test that @grahamjlinn mentioned, I’ll push an update to Dragonfly so that you can get this to work for all of your URBANopt simulations. Just to reiterate, you’d open up the GeoJSON file in a text editor and then add an extra property for weather_filename under the site properties, with the value being the path to the weather file. Then try running the URBANopt command that generates the Modelica files. If that succeeds, then let me know and I’ll change Dragonfly such that it always includes the weather file. Alternatively, @grahamjlinn , if you confirm that this is what’s needed for this workflow, I can likely add it sooner.

6

Hi @chris , that’s correct. By manually adding “weather_filename” in the geojson, it works when entering @grahamjlinn 's code in the “.osw” file, and when running Urbanopt again from the CLI, the loads for Modelica are created. However, it’s important to note that the weather_filename must correspond to a file that can be converted (IWEC) to “.mos” format . Since I’m working with areas in Catalonia (Spain), I created the .mos files using the following code.


Then I followed the Urbanopt workflow with “uo_des build-sys-param,” and it worked but with the following information.

imagen
imagen1097×268 7.99 KB

Finally, running “uo_des create-model” works and provides the following information:

imagen
imagen1087×272 9.02 KB

1 Like
7

Hi @Batiste ,

Thanks for confirming this and I will push an update soon that includes the “weather_filename” in the GeoJSON whenever there is a system_param.json file found in the project folder (indicating that there’s a DES to be simulated).

I have been working on automated routines in Dragonfly that write the system_param.json for 5th generation district systems (using ground heat exchangers) but it looks like these will still be under heavy development for a bit so I’ll likely be exposing the 4th generation district system parameters first. In any event, your use of the URBANotp CLI right now to make these system parameter JSONs looks like it’s working well.

As for the .mos file issue, I’m aware of this limitation and I have plans to build the translator from EPW > MOS into Ladybug Tools so that you don’t have to worry about this extra step on your end. I’ll try to post back here as all of this gets integrated and thanks for pushing the frontier of the software!

1 Like
8

Gosh thanks for the nice words Chris!!

I absolutely want to try out that OpenModelica update. I tried to use OM last fall when I was doing a bunch of work and it wasn’t ready, there were tons of issues and I had to buy a 3 month Dymola license.

But I have more work to do in Modelica so I am stoked to try out this new solution!

2 Likes
9

FYI, @grahamjlinn and @Batiste ,

I have added a method on Ladybug EPW to convert the EPW into a MOS file:

I’m planning to make use of it to add the weather_filename tomorrow and, from there, I’ll start adding the rest of what is needed for the DES capabilities into Dragonfly.

2 Likes