Preprocessing doesn't work well for multi-use buildings

[martin-mosteiro]

calc_mainuse only works if a building has up to two uses: it takes the buildings' uses and generates an array of uses with the largest area (array_max) and with the smallest area (array_min). If the main use is 'PARKING', the building would have no heated area even if the building was 51% parking and 49%, say, offices. So calc_comparison corrects this by defining the building's main use as array_max if the use is not 'PARKING', and as array_min otherwise. Now what happens if a building is 50% 'PARKING', 49% 'OFFICE' and 1% 'COOLROOM', for example? The building gets defined as 'COOLROOM', even though that use only accounts for 1% of the area (yes, this actually happens for one building in the Hochschulquartier)

Fixing calc_mainuse to take the second most important use (instead of the least important) would be an easy fix, but more importantly: does it make sense to apply the archetypes based on a single use?

For some properties (say, construction properties), it might arguably be okay. However, for all properties that depend on the square meters of each type of use (e.g. Occ, Es, Hs, Ve, all internal loads) it certainly doesn't. Why should a building with say for example 34% office, 33% residential and 33% gym require only 10 L/p/d of hot water?

[martin-mosteiro]

@daren-thomas You said this needed discussion?

[martin-mosteiro]

So here are the effects of this preprocessing on the calculations done on CEA:

1. demand/electrical_loads.py

calc_Eint calculates the following:

tsd['Eaf'] = schedule_applicances_lighting * bpr.internal_loads['Ea_Wm2'] * bpr.rc_model['Aef']
tsd['Elf'] = schedule_applicances_lighting * bpr.internal_loads['El_Wm2'] * bpr.rc_model['Aef']

However, Ea, El and Aef are only defined for the main use type, so if the building is, say, 51% RESTAURANT and 49% percent LIBRARY, the electricity demand will be overestimated.

Furthermore, if the occupancy types include COOLROOM, SERVERROOM or INDUSTRY, the script calculates the following, respectively:

tsd['Eref'] = calc_Eref(schedule_Eref, bpr.internal_loads['Ere_Wm2'], bpr.rc_model['Aef'])  # in W
tsd['Edataf'] = calc_Edataf(schedule_Edata, bpr.internal_loads['Ed_Wm2'], bpr.rc_model['Aef'])  # in W
tsd['Eprof'] = calc_Eprof(schedule_pro, bpr.internal_loads['Epro_Wm2'], bpr.rc_model['Aef'])  # in W

However, if these are not the main uses, Ere_Wm2, Ed_Wm2 and Epro_Wm2 will all be 0, so that the corresponding electricity demands will also be 0 - even if part of the building is indeed COOLROOM, SERVERROOM or INDUSTRY.

2. demand/refrigeration_loads.py and demand/datacenter_loads.py Since the electricity demands were miscalulated in electrical_loads.py, the demand in these scripts is also calculated as 0 even if the building does have partial COOLROOM or SERVERROOM uses.

3. demand/ventilation_airflows_simple.py calc_m_ve_required calculates the following:

   tsd['m_ve_required'] = tsd['people'] * bpr.comfort['Ve_lps'] * physics.calc_rho_air(tsd['T_ext'][:]) * 0.001  # kg/s

   Ve_lps is however (you guessed it) taken from the main archetype. So if the building is, again, 51% RESTAURANT and 49% percent LIBRARY, the ventilation demand will be overestimated.

4. technologies/controllers.py simple_temp_control gets the heating and cooling setpoints and setback temperatures as well as the ventilation demand, which, as mentioned above, are taken from the main archetype only.

5. demand/sensible_loads.py If the heating or cooling system is T3, then calc_Qgain_lat does the following:

   w_int = people * X_ghp / (1000 * 3600)  # kg/s

   Again, X_ghp is defined for the main archetype only. So the humidity gains from people can be way overestimated if the main use is RESTAURANT or INDUSTRIAL.

6. demand/hot_water_loads.py calc_Qwwf does the following:

   mww = schedule * Vww_lpd/ 1000
   Vww = mww * gv.Pwater /3600 # kg/s
   mw = schedule * Vww_lpd / 1000
   Vw = mw * gv.Pwater /3600 # kg/s

   I have three issues with this. First, mw is calculated based on Vww_lpd instead of Vw_lpd - so mww and mw are the same! Second, the mass and volumetric flow rates are inverted! (even the labels say Vww and Vw are in kg/s!) Third: as you might have guessed Vww_lpd and **Vw_lpd) are taken from the main archetype. So going back to the RESTAURANT+LIBRARY example above, the water demand will be overestimated for the library part (which requires 1/4 as much water as the restaurant part).

Conclusions All points relating to the internal loads could be easily fixed. Since these values are used as "schedule*value', schedules could be created the same way the issue with the occupancy was solved in PR #597. This would solve issues 1, 2, 5 and 6 above. Messing with the set points is a bit trickier, since that would require multi thermal zone calculations - but point 3 could potentially also be solved by creating a schedule for Ve.

[martin-mosteiro]

I solved this issue the same way as was done for occupancy, as discussed in the "Conclusions" above (i.e., creating yearly schedules for each of these services based on the archetype schedules for each occupancy type in the building).

I also fixed the preprocessing step so that each building's internal_loads.dbf file depends not only on its main use, but also on the other uses in the building. However, internal_loads.dbf is no longer used since the schedule maker creates the schedules and corresponding demands for each occupancy type based on the archetypes. This might be impractical for calibration, though.

@JIMENOFONSECA, @gabriel-happle: do you have an opinion on this?

[gabriel-happle]

Interesting issue @martin-mosteiro I will take a look at this tomorrow. I will assign myself to the issue as well, in order to stay in the loop. I also plan to start looking into actual multi-zone mixed-use representation soon.

[jimenofonseca]

@martin-mosteiro is there a branch with these changes right?

[martin-mosteiro]

Yes, i612.

Cheers Martín

Am 08.05.2017 um 23:25 schrieb JIMENOFONSECA notifications@github.com<mailto:notifications@github.com>:

@martin-mosteirohttps://github.com/martin-mosteiro is there a branch with these changes right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/architecture-building-systems/CEAforArcGIS/issues/612#issuecomment-299881765, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ARsFYQqTew5XwuTYCy72xy0DsxVsRiLMks5r3yXugaJpZM4NDQFE.

[martin-mosteiro]

As discussed during the meeting, here is a summary and update of this issue.

The issue actually aims at a few different problems I found in the schedule makers, namely:

1. If the main use was 'PARKING', the smallest use (rather than the next main use) was assigned as main use instead.
2. During preprocessing, the main use defines the internal loads and ventilation properties of the building (rather than being defined by the mix of uses in the building).
3. The average schedules for multi-use buildings were defined by the square meters of each use, which doesn't make sense for variables that depend on the number of people in a room (e.g. humidity gains).
4. The internal loads and ventilation were calculated as follows (for humidity gains, for example): X = schedule(people) * X_ghp. However, it isn't the same to have 10 people working in an office as 10 people in a gym.

So here is what I did to solve each of these points:

1. Change the definition of mainuse so that if the main use is 'PARKING', the second main use is used instead.
2. Preprocessing defines an average value based on the value for each archetype
3. The schedules (and the average values in point 2) were redefined so that variables that depend on the number of people are averaged by the area of each use and the occupant density for each use (it's not the same to have 50% of the building occupied by an occupancy type with low occupant density than one with high occupant density).
4. Schedules for each internal load and ventilation were created. These are weighted so that if for example there are 10 people in the gym at 9 am the humidity gains will be larger than if there are 10 people in an office at 9 am.

This schedule maker is compatible with #664 (instead of one schedule per building, you would just need one schedule per floor). The above points all assume, however, that an average needs to be calculated for a single thermal zone with multiple uses (as opposed to having one occupancy type and one thermal zone per floor as proposed in #664 ).

This will be further discussed on Friday.