Option for non-constant TGround in equivalent air temperature (VDI 6007)

[PGorzalka]

Hi,

Issue 1080 of AixLib intends to add non-constant soil temperatures to the reduced-order model. Regarding the RC model itself, this does not affect IBPSA. However, the equivalent air temperature calculation models currently only allow a constant ground temperature parameter.

I would like to suggest adding a variable TGroundUsed in ThermalZones.ReducedOrder.EquivalentAirTemperature.BaseClasses.PartialVDI6007 that is used for the calculations in VDI6007 and VDI6007WithWindow and gets the value from one of the options

• TGro (current constant parameter)
• TGround (input connector to be added)

depending on another Boolean parameter to be added which is by default pointing to TGro.

Looking forward to hearing your thoughts about this.

[mwetter]

That would be a good addition. However for consistency with ReaderTMY3, please call the input connector TGro_in.
I assume TGroundUsed will be a protected variable.

[PGorzalka]

Thank you for the feedback. I implemented this in pull request 1749. As this is my first contribution here, I hope I did it as intended by the guidelines.

[PGorzalka]

Being basically finished with this issue (just missing a Dymola update to run the unit tests), I would like to bring up a related topic.

Currently, the model calculates the equivalent temperature lumping surfaces in contact to air and to the soil (where TGro that I just inserted as non-constant is only used as contribution by the surfaces in contact to soil):

TEqAir = TEqWall*wfWall + TGro*wfGro;
TEqAirWin = TEqWin*wfWin;

where
TEqWin=TDryBul.+delTEqLWWin*(ones(n)-sunblind);
TEqWall=TDryBul.+delTEqLW.+delTEqSW;

where
delTEqLW=(TBlaSky - TDryBul)*hRad/(hRad + hConWallOut);
delTEqLWWin=(TBlaSky - TDryBul)*hRad/(hRad + hConWinOut);
delTEqSW=HSol*aExt/(hRad + hConWallOut);

In these equations, TEqWin, wfWin, TEqWall, wfWall, delTEqSW, and HSol are arrays with one value per orientation and HSol needs to be calculated accounting for the orientation of the surface outside of the model. That means, they lump walls and roofs of different orientations. This follows exactly the equations presented in VDI 6007.

However, delTEqLW and delTEqLWWin are no arrays and heavily simplified. VDI6007's equation (33) says
delTEqLW = ((TTer - TDryBul) * (1-phi) + (TBlaSky - TDryBul) * phi)) * hRad / (hRad + hConWinOut) * eps_lw/0.93
where TTer is the radiation temperature of the ground surface, phi is the sky view factor (usually taken from the surface tilt), and eps_lw is the longwave emissivity of the surface.

While I am sure that eps_lw/0.93 = 1 is a valid assumption, I do not like TTer = TBlaSky, i.e. the assumption that all surfaces exchange longwave radiation with the sky as if they were horizontal. In a past discussion for AixLib, @mlauster mentioned as reasons for the simplification

1. epw files do not contain TTer (this is also mentioned in Clean up equivalent air temperature calculations #500)
2. in typical (German) TRY files (which contain terrestrial longwave radiation), the difference between ground and sky irradiation is neglectable, so the typical error due to this simplification is small
3. the nonlinearity and complexity added by the calculation

Regarding point 2, I checked this with the district I am currently working on.
The weather file shows lower sky radiation for basically the whole year with a mean difference of 68.4 Wh/m², causing a mean change in equivalent air temperature of about 1.1 K. I plotted the distribution of both in the figures below. The integral of heating power for the whole year is reduced by about 7% due to this, which is, in my opinion, not neglectable.

Point 3 is not that important I think. Yes, some cosines need to be calculated, but only during initalization, so the added calculation complexity is very small (there was no change in calculation time for my example).

Point 1 is certainly valid, but equally valid for the soil temperature, and TTer might be calculated by some external model (or, in Germany, taken from the weather files).

So, as a consequence, I would like to introduce the more complex equation from VDI 6007, of course keeping the default behaviour as it is. In my opinion, the naming of the model referencing the guideline directly is a little misleading if it does not completely follow the equations presented there. Of course, I would keep the default behaviour. @mwetter What do you think about this, would this be a valuable contribution here? And if yes, would it make sense to add it to the existing pull request or should I open a new issue?

@DaJansenGit FYI

[mwetter]

@PGorzalka : Having as an option the more detailed equation seems fine to me; however I don't quite understand how a user would use it as TTer is not available. Would you also implement a model to compute TTer? Just telling the user to use "some external model" is not good as it complicates the use of a library. Generally, for all the options, the library can support them.

If you move forward with it, I suggest you make a new branch based on your PR. This way, the two contributions can be reviewed separately once you finished #1749 (which I believe still has pending issues to be resolved).

[PGorzalka]

@mwetter : It depends... from the German TRY datasets, it is available. I do not know if other institutions also publish similar data - with search terms in English, I could not find any. However, historical data is available e.g. for global hourly land surface temperatures ranging from July 2021 to today. A model to calculate typical TTer is far beyond the scope of my knowledge and research. Therefore, I would recommend the user to use the available data.

Regarding the separate branch, I already did so. I will create a new pull request if I'm finished with everything. Pending issue is just that the tests require a Dymola update on my PC, which requires an update of our license server, which requires our IT admin to return from holidays :)