Adjustment of internal gains calculation

[nhuelsenbeck]

What is the problem?

• The exported variables nrPeople and nrPeopleMachines need to be changed to specific variables (W/m^2).

This issue is related to https://github.com/RWTH-EBC/AixLib/issues/690

Why do we want to solve it?

• To increase the transparency of the interal gains calculation.

How do we want to solve it?

• Remove the 0.01 factor in every archetype

• Change name of nrPeople and nrPeopleMachines in ThermalZoneRecord file

[DaJansenGit]

This should also solve the problem explained in #523 for non archetype buildings.

[PRemmen]

@DaJansenGit sorry to be a little pedantic here :)

1. could you please check if the documentation and the names of paramters in TEASER classes are still correct?
2. have you compared simulation results? are they 100% the same?
3. aren't here any changes in UseConditions.xml necessary?

thanks!

[DaJansenGit]

All fine, thanks for being pedantic @PRemmen ;)

1. we just added a minor additional comment in the documentation, but now it should be fine
2. the results aren't 100% the same. But this was expected due to the former workaround that used a fixed multiply by *0.01 in TEASER (by expecting an heat transmission of 100 W/person) but a non fixed calculation in modelica, where the heat transmission of people is depending on the room temperature and activity type. Due to the fact that this activity type information and the temperature dependence does not exist in SIA 2024 or DIN V 18599-10 we implemented a new model in modelica that only multiplies only the specific heat transmissions with the room area. I hope this was clear, but in the end it should mean: we have slight differences in the results but the new results are the correct ones ;)
3. Nope the UseConditions.xml don't have to be touched because we still use the same data from DIN V 18599-10 as before.

@MartinRaetz I hope you agree? ;)

[PRemmen]

@DaJansenGit @MartinRaetz thanks for clarification 👍

can you give just one example what not 100 % the same means :) But then I'll really keep my mouth shut.

[DaJansenGit]

@PRemmen You can find an example here https://github.com/RWTH-EBC/AixLib/pull/691 ;)

[PRemmen]

do we have one example what this implies on the total energy demand and the dynamic behaviour of the thermal demand/indoor air? maybe @nhuelsenbeck has the results files still available. Don't get me wrong: I like the adjustment a lot, however I'm running some simulation for different projects so i need some estimation of the effects :)

and then: :no_mouth:

[MartinRaetz]

@PRemmen The only change is the intensity of "internal gains persons" (internal gains machines and lighting are still the same). Reason for this is the room temperature dependency of human heat production in the low order model, which is deleted in RWTH-EBC/AixLib#691.. We think this is correct since the values of the DIN are not temperature depending and already regard a typical room temperature including a typical activity type.

Analogous calculation for persons: NetLeasedArea = 4500 OfficeShare = 0,5 RatioConvective = 0,5 (boundarycondtitions.py) MaxOfProfile = 0,8 (from SIA) WattPer_m² = 5 (from DIN) 4500 0,5 0,5 0,8 5 = 4500 watt

Analogous calculation for machines: NetLeasedArea = 4500 OfficeShare = 0,5 RatioConvective = 0,75 (boundaryconditions.py) MaxOfProfile = 0,8 (from SIA) WattPer_m² = 7 (from DIN) 4500 0,5 0,75 0,8 7 = 9450 watt

[MartinRaetz]

@PRemmen The plots of room temperature and thermal demand of the office archetype for zone office:

I´ll send you the Teaser Exports and the respective Modelica simulation results via email, so that you can check for effects.

Maybe @nhuelsenbeck can add the results obtained before merging the branch to development

[DaJansenGit]

niklas no longer works at the institute, so he won't be able to do this ;)

[DaJansenGit]

@PRemmen @MartinRaetz I had a closer look and the difference between both models. I did some comparison simulations and put screenshots, resultfiles and a total model (which is not working for any reason, but you can have a look at the setup) on sciebo. Hope you are fine with this ;) @PRemmen You can find the data here

Just for a fast comparison: I found that the total energy consumption differs only by 0.4 %, so i think this is ok! Find the screenshot for this attached. New: Old:

[DaJansenGit]

Peter agreed, I will close this now.

[MichaMans]

I reopened the issue because of the ongoing discussion in RWTH-EBC/AixLib#690

We can think about several implementations. My suggestion would be a reference oriented integration. Meaning that the main reference of the internal gains are the SIA, providing the following information:

• Person schedule in percentage of maximum
• Person area in m²/Person
• Aktivity type in met
• mean sensible heat emission at 24°C --> 70 W/Person
• mean moisture production at 24°C --> 80 g/(h * P)

I would suggest to take these informations into the "database" and integrate them in to the useconditions. These will then get exported without scaling, because its not necessary here. In the Modelica models, these boundary conditions will be used as input for the new formula based calculation of the internal gains of vdi2078.

Would that be in your favour too? @MartinRaetz @KremerMartin @DaJansenGit @PRemmen @AnaConstantin

[MartinRaetz]

I appreciate it, but I think we should precisely determine what certain parameters in the SIA actually represent:

The definition of the activity type is: 1 met = 58 W/m² (Body surface) The mean sensible heat emission and the mean moisture production is calculated via the activity type, a body surface of 1,8 m² and a room temperature of 24°C.

I also think that calculations, except those regarding the resistances and capacities of the walls, should be in the AixLib instead of Teaser. To me, it appears that the user can change values easier and understand the calculations better in Dymola. That is why my suggestion would be to only implement the following information in Teaser and take the calculations to the AixLib: -Person schedule in percentage of maximum -Person area in m²/Person -Activity type in met

Since the development of a humidity and a CO2 model is already in progress, we should think about how to serve the needs of their implementation as well. In my opinion it is not recommendable to mix different calculations like the one in the SIA and the one in the DIN. The activity type in the SIA is not quite comparable to the one used in the DIN. See https://github.com/RWTH-EBC/AixLib/issues/690#issuecomment-492647897.

[KremerMartin]

I appreciate it, too. In my opinion we should also do the calculations in the AixLib. We won't need a heat or moisture output per person. This could be misleading for the user.

@MartinRaetz The VDI references the DIN 13779, where the activity type is defined just the same way you have posted above. The VDI classifies activity levels out of the activity types.

[MichaMans]

@MartinRaetz I fully agree. So we'll let the W/Person output out and we will calculate that on formula basis in the aixlib model. I'm fine with that. Nevertheless i slightly disagree with your opinion on

To me, it appears that the user can change values easier and understand the calculations better in Dymola.

I think the understanding of the calculation is easier to understand in modelica, yes, but the change of the input should be easier with TEASER as long you are following a TEASER based workflow. Otherwise it will be very confusion where to change data / boundary conditions.

@KremerMartin With @MartinRaetz suggestion of the implementation, your needs for the formula based calculations are fully met or?

[MartinRaetz]

@MichaMans I agree with you! I would as well carry any adjustable input via Teaser to Modelica.

[KremerMartin]

@MichaMans Yes. With his suggestion the implementation in Modelica can be done.

[AnaConstantin]

Hi everyone, in my opinion the input parameters we need (TEASER / Modelica should be the same) for internal gains through occupants for different type of zones

• occupant presence as a schedule : percent normed (0 to 1) over a period of time (days, week)
• occupant density in persons / m2
• heat / humidity output: as a function from temperature, given as a set of polynomial coefficients. A constant would be a polynomial of order 0, the formula that @KremerMartin presented in the other issue would be a polynom of order 1. I do not think it is difficult to implement or to grasp for a user. And it is pretty general.

[MichaMans]

@AnaConstantin I am not sure if i can fully agree on:

occupant density in persons / m2

As SIA bases on m²/Persons, i would take this value And do i understand it right that you want to integrate the full formula of the heat output in TEASER? I think in the end the key is that we of course have all input parameters for the modelica model in TEASER, but for example the formula is not an input more the actual model, we don't need that.

[KremerMartin]

@AnaConstantin I agree to @MichaMans . We should not use a formula as output from teaser. If the ROM will be used stand alone (without Teaser), which is possible, it won't be understandable how the internal gain model works. If we implement the formula in the AixLib it will work fine and reduce the calculation steps in Teaser.

[AnaConstantin]

@MichaMans and @KremerMartin thank you for your comments. Regarding persons / m2 - SIA might use m2/persons, but ASHRAE 90.1 and DIN 18599 use persons / m2. Also other types of internal gains (lights and appliances) are also expressed per surface (W/m2). I like it better to have every type of internal gain expressed in the same manner. Regarding the calculation of heat load, the input for Teaser and Modelica would be an array [a0, a1, a2,..,an] to generate a formula heatOutput = a0 + a1T + a2T^2 + ... + an*T^n. The array would just be passed from TEASER to the Modelica Model. The model in AixLib would have to be changed to accommodate the usage of a formula but this is easy, the parameter is an array instead of just one value and one extra equation. I like this solution because it allows the user to use the reference of their choice for the internal gains: a constant value (just [a0]) or a formula ([a0, a1] like in VDI 2078).

[KremerMartin]

@AnaConstantin @MichaMans So, if I take it right, in Teaser we implement an option to calculate the internal gains of the humans by constant value or by a formula like in VDI 2078. The question is, is it reasonable to let the user set the coefficients of the formula. In my opinion we should stick to the norms. The user can decide, whether he wants to calculate with the standard value for heat output as found in DIN and SIA or calculate with a temperature dependent heat output as defined in VDI. If the user is able to set the parameters on his own, this could lead to errors in calculation. If someone finds another way of calculation normed (not considered), he/she can write an isssue to report that and we can add the corresponding formula.

[AnaConstantin]

@KremerMartin I would argue that SIA also uses a formula, as stated in the standard. This is why I think it is important to have a flexibility in setting this parameter. I think however that we can give the user some choices, like a drop down menu of different functions (as in Modelica Functions) and in this way the user can build a new function if desired. The transfer from TEASER to Modelica is still possible. It's important however how much degree of flexibility is desired in TEASER.

[DaJansenGit]

@KremerMartin and @AnaConstantin Regarding the temperature sensitivity I like the idea that Ana brought up, because the user can export everything from TEASER directly and directly knowns how the internal gains will be calculated. By setting a default parameter set the usability will be given as well. To prevent wrong calculations we can implement a test function in python to make sure, the given parameters make sense and lead to a valid formular. Regarding m2/person or person/m2 I think it's more important to show clearly where the values come from than having the same export format for all internal gains... so imho m2/person (directly taken from SIA) would be the better way...

[MartinRaetz]

Thank you all! @DaJansenGit @MichaMans @AnaConstantin @MichaMans I just want to add my opinion:

I agree with Ana on keeping all internal gains in a similar format, i.e. have Teaser recalculating its input "m2/person" to output "person/m2". People who just use the AixLib would be less confused.

On the other hand, I think we should not make this internal gains model more complex than it has to be. Simplicity is actually one of the key factors to use Teaser. These parameters (1,8m² per person, 58W/m²) in the formula - in my opinion - are quite fixed and should not be modified. If someone wants to do it, he/she is expert enough to simply edit the teaser output or the Aixlib in a fork. Having a "polynomial" model instead of an internal gains model would complexify more than we might win with the flexibility. As Teaser is basically based on assumptions and rough estimations this might be to much detail. I think it would make the internal gains model and Teaser less comprehensible.

[KremerMartin]

@MartinRaetz @AnaConstantin @DaJansenGit @MichaMans Thanks for your comment. I agree also to Martin and Ana to keep the inputs for modelica in a similar format.

@MartinRaetz I think you misunderstood @AnaConstantin . She does not want to replace the internal gain model. There are different norms that provide formulas for calculating the temperature dependency of the heat/ moisture output. To fit all this norms, the user who has acces to a certain norm, will be able to set the parameters for the polynomial form of the temperature dependency. We should implement some default parameters (in my opinion based on VDI and a constant one taken from SIA or DIN). In this way a user with no acces to any norm can use a temperature dependent or not temperature dependent heat output. For example this could be done by a case discrimination in the Teaser code (temperature dependent, constant, user defined).

[AnaConstantin]

@KremerMartin I like your suggestions.

[DaJansenGit]

The final implementation will be: TEASER Changes

• Persons/m2 will be implemented in TEASER (@MartinRaetz and @DaJansenGit)
• Schedule will not be touched
• TEASER gets three new options: (@MartinRaetz and @DaJansenGit )
  • Boolean internalGainsTemperatureIndependent
  • Boolean internalGainsTemperatureDependent (default value)
  • Boolean internalGainsWithMoisture
• For case internalGainsTemperatureIndependent the constant specific heatflow rate (W/person) will be included as a parameter
• The mako templates will be changed to export dynamically depending on the above three options and activity type will be included in export (@DaJansenGit )

Modelica Changes (@KremerMartin )

• One base model without heatport and calculation of heatflow output, maybe we will go by conditional model for the heatport to prevent problems with the outer connections
• Extending model with constant heat output (prescribed by TEASER output)
• Extending model with temperature and MET depending heat output
• Extending model with temperature and MET depending heat output and moisture
• There will be no custom model to implement own polynomial calculations of heatflow output, if somebody wants this feature he/she can implement it by his/her own

[DaJansenGit]

due to the changes ongoing with https://github.com/RWTH-EBC/TEASER/pull/584 I would suggest we finalize everything but don't touch the UseConditions.xml anymore, because those will be replaced by the json files in the near future. We wait for the PR to be done and change the .json files then. Is this ok for you @MartinRaetz @KremerMartin @MichaMans ?

[KremerMartin]

@DaJansenGit I think this will be ok.

[MartinRaetz]

@DaJansenGit I also agree!

[DaJansenGit]

We also need to adjust the export for the annex/ibpsa library. This uses a W/m2 approach at the moment.

[DaJansenGit]

Changes to the ibpsa export: Before: persons is w/m2 but as the prior version likes it to be persons/m2 it multiplies by 0.01 which is 1/(watt/person), multiplying this with some (w/person)which is (activitytype * 50w). Now multiplying correctly with the area and the ratio_conv. Now: persons is persons/m2 multiplying this with heatflowperperson (w/person) which is depending on the respective zone used and will be part of the new json boundary conditions. The same procedure applies to machines. The boundary conditions are used from the SIA which is itself calculating the HeatFlowPerPerson by the respective ActivityType, hence is no functionality lost.

The necessary changes in TEASER and AixLib are done. We are waiting now for the release of the json update by #584 @PRemmen :)

[DaJansenGit]

with #594 the json changes are integrated into our branch. But we still need to:

fill the new *.json files with the correct values for the internal

• [x] Implement activity type
• [x] Implement fixed heat flow rate
• [x] Persons per m2
• [x] add moisture gains by plants to json

  general

• [x] add moisture gains by plants to useconditions.

[PRemmen]

@DaJansenGit do you need any help, I think this is also a feature to be integrated into the next release #604

[KremerMartin]

Christoph (my Hiwi) has implemented the parameters and I have pushed the change in commit ee317b9 . As the SIA 2024 does not contain some declared zone types, Christoph made some assumptions for the missing parameters (person/m², moisture gain from other than people, activity type, fixed heat flow rate). Here the list:

• Kitchen - preparation, storage: Same as kitchen with reduced moisture gains
• Further common room: School room
• Auxiliary areas: adjoining room
• stage: same as theatre
• sauna area: swimming hall

@MichaMans @PRemmen Do you think this assumptions are ok? Or is there need for reworking these zone types?

[DaJansenGit]

closed by 5bf2fd2