You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Default workflow does PV modeling through REopt which uses PVWatts. PV watts API doesn't take in context geometry
Describe the solution you'd like
We currently use urban context to impact EnergyPlus simulations related sun exposure to surfaces. It makes sense that we do the same multi-building interaction for PV generation (this is true for both building and ground mounted PV)
It runs PVWatts methods directly without an API call. If the optional surface field for the panel is filed out, then at each time step interaction with other model geometry will be used. This would make uses of the context shading surfaces we already creating as well as self shading within the building currently being modeled.
In the past I created and used Rooftop PV measure that uses Simple PV. It adds a shading surface 12 inches above each roof and turns that into PV with some fraction of surface covered. I think the best approach may be to enhance this measure with a "method" option that lets someone continue to use simple PV or use PVWatts. We could also just upgrade the measure and force this new approach, or make a separate measure. https://github.com/NREL/openstudio-common-measures-gem/tree/develop/lib/measures/add_rooftop_pv
Additional context
I have run the HPXML to OSM workflow with custom hpXML that used this object (without surface assigned) and the UO reporting seemed to pick it up. Key is to make sure we don't double count PV by also doing it in REopt.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Default workflow does PV modeling through REopt which uses PVWatts. PV watts API doesn't take in context geometry
Describe the solution you'd like
We currently use urban context to impact EnergyPlus simulations related sun exposure to surfaces. It makes sense that we do the same multi-building interaction for PV generation (this is true for both building and ground mounted PV)
Describe alternatives you've considered
EnergyPlus has a PVwatts object (this is used for some hpXML to OSM workflows).
https://bigladdersoftware.com/epx/docs/22-1/input-output-reference/group-electric-load-center-generator.html#generatorpvwatts
It runs PVWatts methods directly without an API call. If the optional surface field for the panel is filed out, then at each time step interaction with other model geometry will be used. This would make uses of the context shading surfaces we already creating as well as self shading within the building currently being modeled.
In the past I created and used Rooftop PV measure that uses Simple PV. It adds a shading surface 12 inches above each roof and turns that into PV with some fraction of surface covered. I think the best approach may be to enhance this measure with a "method" option that lets someone continue to use simple PV or use PVWatts. We could also just upgrade the measure and force this new approach, or make a separate measure.
https://github.com/NREL/openstudio-common-measures-gem/tree/develop/lib/measures/add_rooftop_pv
Additional context
I have run the HPXML to OSM workflow with custom hpXML that used this object (without surface assigned) and the UO reporting seemed to pick it up. Key is to make sure we don't double count PV by also doing it in REopt.
The text was updated successfully, but these errors were encountered: