Occupancy model

[Mathadon]

It could be useful to allow a replaceable occupancy model in the zone model that adds sensible and latent heat to the zone air volume. The model could contain a replaceable occupancy comfort model that allows evaluating several norms in terms of occupant comfort.

Is this a good idea? Do we need to consider Strobe for making this implementation?

[rubenbaetens]

Note that you aim to introduce two models to the zone: an occupancy model introducing boundary conditions and a comfort model for evaluation. I'd separate both:

(1) I'm unaware on how many occupancy models exist in effective standards, i personally only know a few allthough ASHRAE may have more than i know. From a user-perspective, it could be indeed interesting that you can define this at the zone-level. On the other hand, i don't know if it's handy if as such this zone also has the information on occupancy and set-point temperature, and this then need to be transfered to the thermal system models. Additionally, it could become complex if this implementation might depend on the chosen media for e.g. moisture production and carbon emissions. Even more: note that this could mean a severe duplication of code with time-events and possible overhead, i.e. many timetables could be read double if many zones have the same occupant boundary.

I wouldn't consider StROBe to bring a direct solution here. Allthough we should have in mind that occupancy behaviour should be able to be defined outside the zone.

(2) For evaluating comfort, Fanger is of course thé standard. I once implemented Fanger (and i think it's also in the Buildings library), but it's so complicated and so complex non-linear that i observed a severe overhead on the code for little added value regarding PMV and PPD. Could it be interesting to keep it outside Modelica and include it with a C-code function ?

[Mathadon]

I agree that they are two models. 1) I may have been misleading: with 'occupancy model', I mean a model that generates sensible and latent heat gains and optionally CO2 gains based on an input: the number of zone occupants. So the complexity is quite low. We could include an option that varies the sensible/latent heat gain based on the zone air temperature. Or even based on the zone humidity, if there are references for this. 2) Can't be that complicated..? Either way it should be optional and disabled by default so I think it should be fine :)

[rubenbaetens]

Note that: 1) all loads are time dependent and thus not just based on the number of occupants: is it an office, a living, a bedroom, a class in school, a room in an elderly home, ... ? or do you want to have a RealInput defining nOcc and define the presency elsewhere ? Even then the metabolic rates between a sleeping person and an active person are not quite alike ... 2) You might be suprised ;)

[Mathadon]

1) You make a good point about the type of building/occupants. I propose to make the occupant model replaceable, such that you can change these characteristics of the model. It should be fairly simple for users to make their own models. I do also want to have a RealInput as you describe. Thanks for the feedback! 2) I'll check it out :)

[Mathadon]

Buildings has an implementation for Fanger, so I propose to copy that one.

[rubenbaetens]

Addressed in #518.

[rubenbaetens]

In the occupancy model you fix the clo-value toa single-value (0.7), while standards usually give 2 values - i.e. a winter (1.0) and summer value (0.5). Maybe it's better to reformulate this based on 2 parameters and make it a function of the exterior temperature ?

[Mathadon]

Beter to make it a continuous function then?

[rubenbaetens]

Something like that, yes. The clo-value is too important to simplify it to a single value all through the year. But there is no real good theory on how to do this, though this might be a good reference : http://www.sciencedirect.com.kuleuven.ezproxy.kuleuven.be/science/article/pii/S0360132312002260

[rubenbaetens]

It would be nice if we add some sources for the numbers now used. I'll need and make a residential occupant (i.e. active and asleep), but struggle on finding goot data.

[rubenbaetens]

Additionally, you could state PMV / PPD should not be calculated if nOcc = 0.

[Mathadon]

But what should then the output be? 0? I'll check this again later!

[rubenbaetens]

I suggest to replace QlatPp and QSenPp by the metabolic rate M (between 0.6 and 1.6) which defines all other parameters.

[Mathadon]

Why is this a more logical way to describe it?

[rubenbaetens]

Now you have two parameters which are in reality always directly correlated, so it seems better to me to define one single parameter.

[Mathadon]

I disagree, the fraction of the heat that is sensible/latent depends on the ambient temperature?

[rubenbaetens]

So why put that fraction in two parameters if it depends on something ?

[Mathadon]

Because otherwise that relation/function should be defined in the record, which I thought would be a bit too complex.

[rubenbaetens]

The difficulty is QLatPp is in many standards not given. The give e.g. metabolism M, and m_flow_h2o_pp and m_flow_co2_pp*s_co2 directly.

[Mathadon]

Just for me to understand correctly, do you have an example that I can check?

[rubenbaetens]

Current IDEAS.Buildings.Components.InternalGains only allows nOcc as an input and ths doesn't allow to add other moisture sources. I'll propose an extension.

[Mathadon]

closed in #518