The two ground heat transfer models in EnergyPlus

asked 2015-06-30 14:01:45 -0500

Adams Rackes

261 ●6 http://bseg.cae.drexel.edu/

updated 2015-07-11 18:51:39 -0500

__AmirRoth__

4436 ●5 ●17 http://bleedinggreenna...

This is a modified version of the same basic question posted on EnergyPlus Support Yahoo! Group

I'm wondering about the two methods for simulating ground coupling in EnergyPlus. The first is the Slab or Basement preprocessor, now available through the GroundHeatTransfer:Slab and GroundHeatTransfer:Basement objects. The other is by means of the Site:GroundDomain:Slaband Site:GroundDomain:Basement objects. The former ("preprocessor") has been available with EnergyPlus for a long time, while the latter ("groundDomain") was added recently in 8.2 and 8.3

From here the newer inclusion appears to be the work of a group from Oklahoma State. It was described in another post as "improved" and "great," but I can't find any real comparison of the two models. The reference for the groundDomain is half a century old (I have a copy, it has hand drawn integral symbols!). The I/O and Engineering References both treat each model independently, without reference to the other, as if there weren't a different model implemented elsewhere.

The groundDomain model is much more convenient (since it doesn't require an initial run to estimate monthly room air temperatures) and I would love to use it. But is there a recent peer-reviewed reference for it, or validation data? People I know who have used EnergyPlus for a long time tend to prefer the preprocessor and distrust the groundDomain approach (which is said to give much faster ground temperature swings), but it's hard to know if this is justified skepticism or just workflow habit. I am working with small, naturally ventilated buildings with uninsulated slabs in warm climates where ground temperature can be quite important.

I'm also wondering why, if the groundDomain model is better, the EnergyPlus development team has spent resources on the last two release cycles improving the workflow of the preprocessor method? Does anyone know what the thinking here is/was?

Thanks for any thoughts and insight people have.

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2015-07-07 20:09:06 -0500

Matt Mitchell
156 ●2 ●2

updated 2015-07-08 10:55:07 -0500

There are currently no published studies comparing the models, however, there is a masters thesis coming out this summer that compares the models. Once that is out, we will work on getting some other peer-reviewed studies published.

Here is some preliminary data from the unpublished masters thesis comparing the slab preprocessor method against the ground-coupled method for a Chicago location. Under ideal conditions with no variations in zone conditions (no windows, constant zone temp), the models perform similarly. But when windows are added, the slab method overestimates heating loads by 18% and underestimates cooling loads by 21% compared to the coupled model.

For a house with no windows but with a floating zone temperature, the floor heat flow predictions are 15% lower with the Slab preprocessor method.

As of right now we are seeing good comparisons between different tools. There are some differences in results between the preprocessor method and the groud-coupled groundDomain method, which we believe are expected due the differences in the methods.

I would have to look into whether we have seen larger temperature swings with the ground-coupled method. I'm not aware of it as of right now. Regarding the effort spend on improving the preprocessor method, I'm not sure I'm aware of that either, but maybe we're thinking of two separate things. In the original post you cite here there is reference to improving the preprocessors, but the ground-coupled method is separate from them so that reference is not correct. There may have been other workflow improvements but I don't think they relate specifically to the preprocessors.

I'm not expecting there to be any additional work on the preprocessors. Once these models start getting some use and people are comfortable with them, the preprocessors will likely go away. Or at least make them to be downloaded separately.

One disclaimer: from this testing work, there were a few recommended modifications to the code which will make their way into the next E+ release. They are currently sitting on a branch waiting to be merged in. Let me know if you want a version with those changes incorporated. (I think thats OK, unless someone on the EPDT tells me otherwise). Let me know if you have any other questions.

Edit: This version would only be appropriate testing purposes due to lack of transition support.

edit flag offensive delete link

Comments

Hi Matt,

Thanks for the response. Super helpful. As you were writing, I was also conducting some tests. Compared to the preprocessor, it seems that the groundDomain method leads to the ground temperatures following more closely those in the coupled zone. Generally this means the ground is warmer than the preprocessor predicts, which is consistent with what you said for the case in Chicago (slab overestimates heating loads and underestimates cooling loads).

Since there's not enough space here, I'm going to put some details into an answer that shows the comparisons.

Adams Rackes ( 2015-07-09 09:20:19 -0500 )edit

Thanks for offering the modified version. Were the modifications you mention significant?

Also, can I suggest you add an output object for the temperature at the interface between the bottom of the slab and the soil? Since the slab used by the groundDomain model doesn't appear as an EnergyPlus surface, one cannot extract surface temp info from it. (unless there's a way I'm missing...)

Adams Rackes ( 2015-07-09 10:19:54 -0500 )edit

@Matt Mitchell, is the thesis that you mention public? If so, where could I get it? Thanks.

Jeremy ( 2016-11-18 12:15:50 -0500 )edit

@Matt Mitchell, Can I have access to the thesis you are mentioning? Thanks.

sofiag ( 2019-08-28 13:07:21 -0500 )edit

add a comment

answered 2015-07-09 10:14:57 -0500

Adams Rackes

261 ●6 http://bseg.cae.drexel.edu/

I have conducted a test. It is a naturally ventilated building in Curitiba, Brazil, equivalent to climate zone 3 in the U.S. The winter day June 1 is shown. The soil parameters are those from the GHT slab defaults (model assumptions and parameters listed at bottom).

I went through three iterations of the preprocessor (recalculating average zone temps and then putting those in as inputs to the GHT slab model). I also tried the groundDomain model with:

(a) groundDomain default domain size, and surface temps in Site:GroundTemperature:Shallow
(b) GHT:slab default domain size, and surface temps in Site:GroundTemperature:Shallow
(c) groundDomain default domain size, and surface temps using Kusuda-Achenbach parameters calculated by CalcSoilSurfTemp routine

for (a) and (b) I took the site ground temperature from the 0.5 m deep monthly values in the weather STAT file.

There were only very small differences among the three groundDomain variations. However, the groundDomain and slab preprocessor results were quite different. The shapes were similar, but with much higher temperatures with groundDomain. Here are the floor surface temperatures:

image description

Again, consistent with the ground being warmer. (Multiple iterations of the preprocessor move towards a warmer floor surface temp, but it's clear they were converging well cooler than groundDomain.) The difference is reflected in a consistent 1.5 - 2 °C increase in zone air temp with the groundDomain model:

image description

The shape of the groundDomain curves in the middle of the day is because the building is naturally ventilated, and with less heat sunk to the ground the zone operative temperature gets warm enough that the windows are opened--expected behavior, not really relevant here. In terms of heat transfer in the slab itself, the models are quite different:

image description

Again, same shape, but a significant offset (plus, again, the expected and not-relevant-here difference due to the change in zone air temperature resulting from window opening being triggered). Here negative indicates heat is being conducted away from the top of the surface, i.e., heat is being sunk to the ground.

Is this behavior what you would expect based on your knowledge of the difference between the two models? For a conditioned building, the difference might be a change in load, but for a passive building trying to avoid the need for AC a change in temp of 2 °C can be very, very significant.

Secondary issue: FYI, from this test, I did not see any greater variability with the groundDomain method. I think what my colleague who told me that might have noticed was a lot of spiking if you look at the flow on the bottom of the zone floor construction (the thin piece of material, in this case 1 cm of concrete):

image description

Note this spiking is exactly every hour and not really reflected in the heat going into this thin construction, but only in the heat going out. Seems not correct--I might expect step behavior from using an hour calculation timestep, but not spikes like this. If I change the ... (more)

edit flag offensive delete link

Comments

Two other points of information: 1. The difference is not only on a colder day. An annual test in a uniformly warm climate had the same trends for the groundDomain model vis-a-vis the preprocessor: 1 - 2 °C warmer air temp (with largest difference at at night), 3 - 5 °C warmer floor surface temp, and 10-15 W/m2 less heat transfer to ground--all pretty consistent for the year. 2. Not a convergence or multiple solutions issue. I initialized the slab preprocessor with the zone air temps calculated by the groundDomain model, but this did not change results after performing a few iterations.

Adams Rackes ( 2015-07-10 08:26:50 -0500 )edit

@Adams Rackes Thank you for the all the details! You said that you kept the default domain size in your tests. Since then, have you try to increase it? I've been performing some test on my own and I am noticing an increase of the zone coupled surface temperature with an increase of the domain size. I'd expect the zone surface temperature profile to converge.

Jeremy ( 2016-11-18 18:02:35 -0500 )edit

add a comment