More solar-related attributes for SurfaceComponent?

[gioagu]

Hi!

As of now, there is only a boolean isSunExposed attribute to the SurfaceComponent class.

I think it would be useful to be able to store (for example):

direct_solar_irradiance: _Timeseries diffuse_solar_irradiance: _Timeseries global_solar_irradiance: _Timeseries insolation_time:_Timeseries (e.g. sun hours per day, per month, per year, etc.) shadowing_ratio: _Timeseries (for example due to adjacent buildings)

This could for example speed up simulations where these parameters are computed only once and then simply reused whenever necessary.

What do you think?

[RomainNouvel]

Hi Giorgio! Sounds useful. Some comments:

• for which purpose do you need to store separately direct and diffuse solar irradiance?
• can you detail the parameter shadowing_ratio? For which purpose do you need it? Does it add something to the parameter global_solar / insolation time?
• we could also add the Timeseries "daylightIlluminance"
• Wouldn't these parameters be useful even if a ThermalZone (and then SurfaceComponent) does not need to be modelled (for instance: a simple solar potential study)?

[gioagu]

Hi!

Global irradiance is made of direct, diffuse and reflected. If we store 3, we can obtain the fourth. Oh, I forgot to tell that this should be "clear sky" values, or we need to further thinker with atmospherical parameters, which I would not put in the building physics characteristics.

(To my understanding) some PV panels are better for direct, other for diffuse irradiance. Just to name an example.

The shadowing ratio tells us how much surface is shadowed (e.g. in %) by adjacent objects/buildings. E.g. when computing solar gains (energy balance method), you may want to use this value(s) in order to reduce the amount of solar energy effectively hitting/heating up your outer surfaces. It is a simple aggregated value for each surface.

Daylight Illuminance: ok. I think that, at a certain point, we will need to face the fact that all this information can actually be thought as texture containing a value for each pixel, instead of aggregated values for the whole surface...

About the usefullness in "simple solar potential study": hmm, yes indeed, but we would need to find out where to put these attributes. Essentially, they pertain to each distinct outer surface (so we need to exclude the shared walls portions). Good point, need some further reasoning!

[RomainNouvel]

Some propositions related to Giorgio's issue:

• the object solar irradiances and daylight illuminance should be attached to the object BoundarySurface (actually "ADEElement" _BoundarySurface), independantly from any thermal modelling. Through the relation between ThermalBoundarySurface and CityGML BoundarySurface, they can also be used in thermal building simulation.
• I wouldn't restrict to "clear sky" value. At the contrary, the more realistic are this data, the more useful they will be.
• Diffuse and direct solar irradiances does not seem necessary for solar/renewables potential study. We should first focus on the use: 1- Global short-wave radiation for solar/renewables potential study and thermal building simulation / 2- Daylight illuminance for Daylighting study / 3- Sunny Hours (or insulation time) for visual comfort requirements...

[jkaempf]

Hello guys, Just to complement the elements of your discussion, from the urban simulation tool CitySim we get as output hourly values of short-wave irradiance (W/m2) on all building and ground surfaces. These as Giorgio said are made up with direct (solar), diffuse (sky and ground) and reflected (from other surfaces) components of the light in the urban scene. We use these values as source terms for the thermal calculations within buildings, but also for the energy conversion on the solar panels (PV and ST). Furthermore, practitioners mostly use these results with viability thresholds to decide where to put the solar panels in the urban scene. So as a conclusion, I would say it would be interesting at least to save the:

• global_irradiance as timeseries on each surface of the scene within the CityGML EnergyADE.

Regarding the other metrics, those can be derived easily with CitySim but apart from the illuminance (lx) of facades for the shops, those were never asked to me by practitioners. Hoping this helps.

[RomainNouvel]

Ok Jerome, Based on your comments, here is a try of formalization for the new ADE Energy version:

• new Class GlobalSolarIrradiance, which inherits from _TimeSeries with the following variableProperties: interpolationType = Continuous / uom = W/m2 / variableLabel = "global solar irradiance". It is optional, related to ADE_BoundarySurface with a [1 , 0..1] relation (direction from _BoundarySurface to GlobalSolarIrradiance). Definition: global solar irradiance (in W/m2) incident on a outside tilted surface.
• new Class DaylightIlluminance, which inherits from _TimeSeries with the following variableProperties: interpolationType = Continuous / uom = Lux / variableLabel = "daylight illuminance". It is optional, related to ADE_BoundarySurface with a [1 , 0..1] relation (direction from _BoundarySurface to DaylightIlluminance). Definition: Daylight illuminance/intensity (in Lux) incident on a outside tilted surface.