egillmor's profile - activity

There are many potential causes for this, so it's impossible to guess just from your post, but you may find this post he

I believe you need Sketchup 2017, at least that is what we use for our OS v2.9 projects. Email me and I can send you th

It is likely due to the newer version of EnergyPlus in newer versions of OS. Since you asked for resources for troublesh

What does your eplusout.err file say?

Yes the part load curve is likely the culprit. To get that more accurate to your selected chiller, there are some handy

Also, the walls in the model you posted have a U-value of about 0.007 (in IP units), or R-142. Not sure if that was int

Well at least it is changing now, so you know it's working. Whether the model is right or not is a complicated question

I took a look and the spaces 101 and 1 may be interfering with your other spaces as they are overlapping the other space

I took a look and the spaces 101 and 1 may be interfering with your other spaces as they are overlapping. I suggest del

I don't have the software to open a .rar file on this machine, but yes that is a problem. This is an old tutorial but I

I don't have the software to open a .rar file on this machine, but yes that is a problem. Every space needs exactly one

Yes -- Check the BCL under Lighting Controls. https://bcl.nrel.gov/node/37859

It's possible that either constructions are not assigned correctly, or HVAC is not set up correctly so that it is not be

First thing is that you have a Water Heater object on your heating Hot Water loop, which is why all of your District Hea

Not enough info here to diagnose what is going on with HVAC, but clearly something is not right. Now that you have it r

I am going to bet that since your DHW is also on district heating, that this is 99% DHW usage. This is somewhat reflect

Water Heater, not boiler. Not the same thing.

Be sure that your radiant construction is built of appropriate materials (I use insulation, concrete, and a floor coveri

Also, for your district DHW system: Rather than using a district heating object, I prefer to use a regular Water Heater

Are you trying to model radiant FLOORS or radiant BASEBOARDS? Those are two different things. Radiant FLOORS will requ

Glad it was an easy fix! On my machine the long-filename culprits that push me above the character limit are usually th

Are you running on a windows-based machine? If so, it may be that the file names of your measure files end up too long.

Duly noted and agree. I will move to a comment instead (sorry I'm not very well versed in posting protocol here)

Are you running on a windows-based machine? If so, it may be that the file names of your measure files end up too long.

The mid floors make sense; less ground reflectance going up. It's consistently your top floor that is the anomaly.

In that case, you may have some different construction materials happening that are changing how much daylight is bounced around the room. Since the top level is the driving factor, check to see if you have a different internal reflectance going on with the underside of your roof surface as compared to an internal ceiling surface.

I had something similar happen once when modeling radiant surfaces vs non-radiant surfaces. It took me HOURS to figure out what was going on, but the floor construction was the culprit.

What an interesting question! Short answer -- it doesn't really matter what we think, it only matters what your code reviewers think, and how they interpret it.

I think it is probably more correct to model it identically in the baseline and proposed (because of the "include all loads" language), but my local jurisdiction seems to prefer it broken out with baseline vs proposed since that is what they are used to under IECC Total Building Performance Method (where it is explicitly included and traded). They want to see that the design of the exterior lighting is in compliance.

Since compliance is the name of the game, I always show a baseline and proposed load generated using 9.4. I haven't had a project that is close enough to the edge that a bit of exterior lighting tradeoff makes a difference, and code officials are happy.

My understanding is that it was a change in policy. You can find this setting in the OS interface, Zone tab, where you can apply heating and cooling thermostat schedules to each zone. So, think in terms of heating/cooling schedules rather than single thermostats. With this new methodology, each zone now has its own individual thermostat, so that you can apply different heating/cooling schedules to each zone at the zone tab without inadvertently affecting other zones.

Thanks Julien, sorry that was my attempt to differentiate from Xcel's policies on fuel switching in the baseline, which I suspect Brian may also be dealing with. Xcel's modeling protocols often lead us to a different interpretation of Appendix G baselines when there is a mix of fuels.

If you are delivering outside air to your VRF spaces with a gas-fired DOAS, then you have a gas baseline in the eyes of LEED, period.

If you have no gas heating serving those spaces, then you might be able to use the electric baseline:

• If you have no gas heating anywhere in the building, easy peasy, use the electric baseline. (system 6 instead of 5)
• If you have no gas in your VRF spaces, but you do have gas heating in other spaces, work very hard to see if those other spaces would qualify for a separate baseline system under G3.1.1 exceptions. Then you can make a case to have multiple baseline systems. If you do use multiple baseline systems, be sure to write a short narrative explaining which exception you are applying and why.

Good luck!

A mistake I once made with this system type is that I left the outside air items on the VRF systems to "autosize", thinking that it would just autosize it to come from the DOAS. This inadvertently doubled the outside air to the zones, so that I got double the required OA through the VRF fan coils AND the DOAS. If by chance you did the same, you will need to set this to zero.

Hi All, I have a project with several 90.1-2007 App G Baseline System 8 - VAV systems with CHW cooling and electric heating. The model is meeting loads and the simulation completes successfully, but I get a severe error for each CHW coil controller that looks like this:

** Severe  ** FindRootSimpleController: Controller error for controller = "CONTROLLER WATER COIL 2"
**   ~~~   **  Environment=DENVER INTL AP ANN CLG .4% CONDNS DP=>MDB, at Simulation time=07/21 20:00 - 20:15
**   ~~~   **   Controller function is inconsistent with user specified controller action = Reverse action
**   ~~~   **   Actuator will be set to maximum action
**   ~~~   ** Controller control type=Temperature
**   ~~~   ** Controller temperature setpoint = 11.39 [C]
**   ~~~   ** Controller sensed temperature = 12.16 [C]
**   ~~~   ** Controller actuator mass flow rate set to 0.60 [kg/s]
**   ~~~   ** Controller actuator temperature = 12.22 [C]
**   ~~~   **   Note: Chilled water coils should be reverse action and the entering chilled
**   ~~~   **         water temperature (controller actuator temperature) should be below the setpoint temperature
**   ~~~   **   Note: Hot water coils should be normal action and the entering hot
**   ~~~   **         water temperature (controller actuator temperature) should be above the setpoint temperature

I have triple checked the model and the coil controllers have the correct action. I have heard that this error may show up because of something else going on with airloops, but I can't find anything amiss. The model seems ok otherwise, though I suspect that heating use might be a bit low (multifamily building), which might be triggering this issue: https://github.com/NREL/EnergyPlus/is...

Should I be concerned? Any resolution? I am using OpenStudio v1.8.0. Thanks in advance!

Hallelujah, I think I solved this. I changed the zone Cooling Design Air Flow Method from Design Day to Flow/Zone, and finally the airflow popped up to where I wanted it, and loads are met.

Hi All, I am running an OpenStudio model (v1.8.0) where I seem to have one rogue zone on an airloop where it is the only zone (constant volume PSZ heat pump airloop, operating 24/7 with no setback).

I am attempting to increase the cooling minimum airflow in an effort to meet loads, but I cannot seem to adjust the cooling airflow at the zone level. I am trying to change it at the OS:Sizing:Zone level. Everything at the system level is set to autosize. The outside air is correct, but I can't get the zone airflow to go higher than the minimum outside air flow. The OA is around 200 cfm, and the design air flow should be around 600 cfm, but the minimum cooling airflow stubbornly stays no higher than the OA no matter what I try. I have lots of unmet cooling hours for just this zone.

Changing the cooling design air flow rate worked just fine for all other zones in the model, even an identical one on the floor below that is set up exactly the same, but for some reason nothing I do seems to impact this particular zone. I have played with the cooling design flow, cooling minimum air flow per zone area, cooling minimum air flow, nothing seems to impact it. If I hard-size the fan I can reduce (not eliminate) the unmet hours, but I still can't change the cooling minimum flow.

What am I missing that could be preventing this one single zone from increasing its minimum cooling airflow?

Thanks in advance for your advice!

It reads the html. But I think I am making it more complicated than it needs to be; I'll just change my spreadsheet to read both ways. Thanks again!!!

When I remove the Postprocess measure the other error goes away too. Thank you!! I don't necessarily need that one in PAT so that's not a big deal, but I can talk with Peter about updating it. Thanks again!

Yes sorry I had stripped out the EDAPT measure in the one I sent you trying to isolate the error. Both of those measures (IP Units and PostprocessLEED) are from Big Ladder.
You are right about the IP Units messing up the EDAPT measure -- stripping that out fixed that first error. Hooray!! Is there any way to make those two measures play nicely together? I have all my spreadsheets written to read in IP units.

I just double checked, there are no spaces not assigned to thermal zones.

In another version I did have other OS files as design alternatives, but have since stripped them out in an effort to isolate the issue. In this one I now just have the Baseline plus one design alternative with one measure running on the baseline, plus several "Always Run" measures, and both DAs failing. The baseline does not fail if I remove the Xcel EDA QAQC measure. (I do have the most current version from the BCL.) The other design alternative still fails even with that measure removed. The DA uses a simple "change LPD" measure that works just fine everywhere else.