Documentation discrepancy Twozone Apartment Hydronic

[Jaap-Neven]

Problem Description

There are several important differences in the documentation of the Twozone Apartment Hydronic use-case, and the implementation of the model in Modelica.

Differences

1. The material matFlo is not specified in the documentation, screenshot below of the model implementation (line 67 in thermalZone in msl4 branch). Also the first layer has a heat capacity and density of zero, so can't this be removed as well?

Also, I can't find where this matFlo is actually used, or isn't it used at all? If not, I propose to remove it to avoid confusion.

2. Wrong thickness of last ceiling layer (gypsum and sand plaster). The documentation reports a thickness of 0.2m while the model specifies 0.02m. Screenshots below of thermalZone model line 177.

The same issue holds for the floor slab construction, line 362.

3. Wrong thickness of layer 3 in radiantslab construction (slaCon, Expanded polystyrene). Line 337 in ThermalZone. Model uses 0.0281m while documentation specifies 0.026m. Not a large difference, but it should be identical.

4. thermalZone is used as a base for both dayZone and nightZone models (in this folder). nightZone extends from thermalZone without changing anything, so thermalZone should reflect all parameters from nightZone.

In thermalZone (line 94), some issues arise due to hardcoding dimensions. For example, the width of the exterior wall is taken to be 5.3m, but this is not correct for the night zone. I propose to replace the hardcoded dimensions by parameters that are given at the start of the model, as specified in the documentation by the apartment plan.

The boundary conditions datConBou also have wrong azimuths. The upper wall has both constructions 'Apartment separator' and 'Elevator separator', but this is not accounted for.

5. dayZone extends from thermalZone with a wrong window dimension. Again I propose to not hardcode the dimensions in this part of the code, but specify them up front.

The boundary conditions are also different than the nightZone. dayZone considers the internal partition as a construction boundary ( datConBou ) while nightZone considers it as surBou.

Summary

I propose to adopt a more rigorous way of defining the building dimensions and parameters up front, instead of hardcoding them in the components themselves. Regarding the thickness of several layers (points 1-3), what is correct? The model or the documentation?

I'd be happy to fix all this in the om_msl4 branch, or elsewhere if preferred.

[EttoreZ]

Thank you @Jaap-Neven for the in depth analysis of the test case. I added this issue to pr #799. I report below answers to each of your points and changes made to the model:

1. matFlo was indeed not used as material for the floor as the actual material is slaCon. matFlo was therefore removed from the model.
2. and 3. The layer thickness is indeed a discrepancy between documentation and model. The correct value after checking the drawings is in the model, therefore the documentation of the test case.
3. The area and azimuth values for walls in the NightZone were updated to reflect the drawing in the documentation. The new values are datConBou(layers={matRoof,matAptSep,matElevatorSep}, A={Afloor,20.42,6.26}, til={C_,Z_,Z_}, azi={S_,W_,N_}, each stateAtSurface_a=false). The window width wWin={2.5} in the DayZone was updated to 2.5 m to reflect the drawing in the documentaiton.
4. The fact that DayZone considers the internal partition as a construction boundary ( datConBou ) while NightZone considers it as surBou is the correct way to model thermal zones with a common wall. One thermal zone will have the wall modeled as actual wall with the construct datConBou, in this case DayZone, while the other thermal zone only has the surface construct for heat transfer calculation purposes.

As a more general answer to hardcoding geometric properties into the thermal zone models that can cause mismatch between model and documentation, I would say this is the case for most test cases. The only robust solution would be to couple documentation and model parameters, but unfortunately there are no efforts on this front at the moment.