@chris, @MingboPeng
Could you please advise on the recommended workflow for using the ElectricLoadCenter components of IronBug within the Dragonfly/URBANopt engine to enable urban-scale simulations of PV panels and electrical storage?
You basically just need to translate the Dragonfly Model to Honeybee and then you can use it with the rest of the components @MingboPeng made.
As far as I understand at the moment, there isn’t an easy way to run the simulation with the Ironbug PVs with the URBANopt component because we would have to JSON-ify the Ironbug PV system and then add native support in our HB > OSM translators for applying the PV system to the OSM as part of the translation process (much like what we did with Ironbug HVAC). And, even if we were to do this, it’s also unclear how the PV gets distributed between multiple buildings that might exist in a dragonfly Model whereas you can manually manage this in grasshopper if you just translate the dragonfly models to honeybee like in my sample above.
Does the sample I provided give you want you need, @behnammmohseni ?
I need to simulate a large-scale urban community equipped with PV panels using the URBANopt engine.
The building envelopes and HVAC systems can be developed in either Dragonfly or Honeybee; however, the main challenge lies in integrating the PV systems (or solar collectors).
I attempted to use the HB Load gbXML OSM IDF component to aggregate all generated OSM files. It appears that the shades are recognized only as shading surfaces rather than PV shades, as the electricity generation output remains empty when using HB Read Generation Results.
The model output from HB Load gbXML OSM IDF can be connected to DF Model to geoJSON, but it still lacks interpretation of PV shading surfaces. (I also noticed a slight discrepancy between the EUI results from URBANopt via Dragonfly and those from OpenStudio via Honeybee.) The internalized model is attached for your reference.
