Adams Rackes's profile - activity

I cross posted recently for this reason. I posted on EnergyPlus Yahoo, then someone posted there (on an unrelated thread) that it was better to post here, so I posted here too. So that's the causal direction. If you encourage migration, there's bound to be some duplication for the transition.

Even easier. From IORef: "The on-grade slab option can be used to simulate situations when the lower slab surface is near the ground surface level. In this situation, the entire floor must be included within the floor construction object." Just make your whole floor assembly the construction of your zone's floor surface, and apply the OSCM to the outer surface of it. Don't include any insulation in the Site:GroundDomain:Slab, since the insulation will already be in your floor construction.

Ha, just curious, I wasn't trying to hold your feet to the fire or anything! Thanks for the response. Is there any public roadmap for future EnergyPlus development and changes?

This is a question about EnergyPlus. I'm wondering about a potential change in idf file format in the future to JSON. I first saw this suggested in a brief note on the OS planned features roadmap ("Support for the new EnergyPlus 9.x JSON input format" is listed as a "Beyond" feature).

The only other information I can find from a little Internet searching is in the BEST directory page, where it says "EnergyPlus building descriptions use a custom object-oriented format. DOE is currently developing a complementary format that uses the standard object-oriented JSON language. This new format is expected to be available in either Fall 2015 or Spring 2016" and "DOE is also currently developing a JSON-based output format that references the JSON-based input. This output option will be available in either the Fall 2015 or Spring 2016 releases."

Can anyone familiar with this move comment on it? Is this happening? Is JSON expected to become the standard input format, or will two formats exist?

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.

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...)

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.

From de Dear and Brager's 2002 E&B article: "The outdoor climatic environment for each building was characterized in terms of mean outdoor dry bulb temperature Ta,out, instead of the ET* index that was originally proposed in the first publication of the ACS [5]. The reason for the downgrade to a simpler outdoor temperature expression is that the theoretically more adequate thermal indices such as ET* require both specialized software and expertise that most practicing HVAC engineers are unlikely to possess."

The second one is in the Standard.

It is not the transient outdoor temperature that is the independent variable, though. It is the "prevailing mean outdoor air temperature," which is a moving average with a window of at least 7 days and at most 30 days (or more if you use a more complex weighting scheme).

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.

Define a single layer with the properties of the bottom two layers combined and enter it as a Material. Reference this as the Slab Material Name in the Site:GroundDomain:Slab, where you would also select no insulation. Put the remaining materials, polystyrene and up, in a Construction object for the floor assembly. In your BuildingSurface:Detailed object for the floor of the zone, select the floor assembly object for the Construction Name and select your OCSM object as the Outside Boundary Condition Object. I believe that should do what you want.