mleach's profile - activity

The only other thing I can think of is exhaust. Do you have Unbalanced exhaust on this system? I believe EnergyPlus wi

I would expect this is being caused by economizing. You could try setting Economizer Control Type to NoEconomizer in th

EnergyPlus Displacement Ventilation Control Issue I'm trying to model displacement ventilation. I'm setting the RoomAir

You need to specify ventilation requirements for the space. In your case, it seems like the best option will be to spec

EnergyPlus Displacement Ventilation Control Issue I'm trying top model displacement ventilation. I'm setting the RoomAi

I should have been more specific. I understand the basics of how to control a plant loop. What I was asking is how wou

I should have been more specific. I understand the basics of how to control a plant loop. What I was asking is how wou

I see that you can hook it up this way, but how would you actually control the loop to provide heating and cooling as ne

You could try with the ZoneHVAC:OutdoorAir Unit as you mentioned but it looks a bit like a black box (heating, cooling,

What about a case where you have an actual transfer fan that transfers air from one space to another in response to a th

It depends on the system configuration but I have done this a few different ways, none of which are perfect. These are the steps I generally take:

1. Represent DOAS heating and cooling using components on the outdoor air path of each AHU. Say that the DOAS provides air at 70 F. You can put a heating coil and a cooling coil on the AHU outdoor air path (before the OA mixer) and apply scheduled setpoint managers to the outlet node of each coil, each set to 70 F. In this same way, you could apply ERV, evap cooling, etc.
2. The tricky part is correctly capturing the fan energy. I have tried a few ways to do it and can think of at least one other, but none of them are perfect. I have added the DOAS fan power as a process load but then you don't capture its fan heat at all, and this approach really only works well for a CAV DOAS. For a VAV DOAS I have represented the DOAS fan by applying a relief fan to each AHU (such that the flow through the fan is always equal to the OA intake, as long as you don't have exhaust fans affecting the flow balance, even if you have DCV applied). Again, however, fan heat is not captured. I haven't tried this, but you could also increase the W/cfm of the AHU supply fans to represent the fan heat added by the DOAS, but the exact amount of heat getting added will vary with a variable speed supply fan, and the heat is really getting added to the wrong place (after the OA mixer, as opposed to before). So, the bottom line is you probably can't capture the DOAS fan heat correctly no matter what you do, unless there's some other way I haven't thought of.

I'm trying to control a GroundHeatExchanger:Vertical object using SetpointManager:Scheduled:DualSetpoint so that it runs when the condenser loop drops below 50 F and when the condenser loop rises above 75 F. In between 50 F and 75 F, the condenser loop should float and the GroundHeatExchanger:Vertical should be off (no flow, no heat transfer). To do this, I took the following steps:

1. Created a SetpointManager:Scheduled:DualSetpoint object and applied it to the plant side outlet node of the condenser loop. The low temperature schedule is always 50 F and the high temperature schedule is always 75 F. Note that I tried an alternate version where I applied an identical version of the same setpoint manager to the outlet node of the GroundHeatExchanger:Vertical, but it didn't seem to make any difference.
2. Set the Plant Loop Demand Calculation Scheme in the condenser loop PlantLoop object to DualSetPointDeadband
3. Created a PlantEquipmentOperationSchemes object with PlantEquipmentOperation:HeatingLoad and PlantEquipmentOperation:CoolingLoad objects and assigned the PlantEquipmentOperationSchemes object to the Plant Equipment Operation Scheme Name field in the condenser loop PlantLoop object. The GroundHeatExchanger:Vertical is assigned as the equipment for both the HeatingLoad and CoolingLoad control schemes and both control schemes are set to Always On.

When I run the model, it works fine on the cooling side but the GroundHeatExchanger:Vertical never comes on for heating. The condenser loop cooling and heating demand output variables look correct based on the temperature schedules assigned to the DualSetpoint manager, and GroundHeatExchanger:Vertical operation in cooling seems to sync perfectly with condenser loop cooling demand. I just can't figure out why it doesn't work in heating.

Is there a way to generate G-functions for GroundHeatExchanger:Vertical without buying GLHEPRO? Is there any kind of library of standardized G-functions that can be used?

I tried two different configurations. In one, I had a SetpointManager:Scheduled on the fan outlet node and a SetpointManager:MixedAir on the heating coil outlet node (which you are suggesting I NOT do). In the other, I just put a SetpointManager:Scheduled on the heating coil. However, I saw the same problem for both cases, and I can't not have a setpoint manager on the heating coil, so those seem to be the only two options. Can someone state definitively that you cannot put conditioning equipment on the outlet branch? I couldn't find any such statement in the documentation.

I'm trying to create a modified version of the E+ example file (5ZoneSupRetPlenRAB.idf) that contains the SetpointManager:ReturnAirBypass object. In the example file, the cooling coil and heating coil are on the main HVAC branch. There is a separate bypass branch that routes return air to a point beyond the main HVAC branch. SetpointManager:ReturnAirBypass is assigned to the airloop and controls the flow of bypass air to hit a scheduled setpoint temperature. A mixer connects the two parallel branches and an outlet branch containing just a fan carries the mixture of bypass and conditioned air to the demand side of the airloop. Everything seems to work fine in this case, as would be expected since it is an example file.

However, if I move the heating coil to the outlet branch (after the mixer but before the supply fan) and add a SetpointManager:Scheduled to either the fan outlet node (and place a corresponding SetpointManager:MixedAir object on the outlet of the heating coil) or to the heating coil outlet node, the mixing behavior changes. Bypass flow is decreased compared to the base example file case, resulting in many hours in which the heating coil needs to run to hit the desired loop outlet temperature.

Is SetpointManager:ReturnAirBypass designed only to work in the configuration represented by the example file? Is there some reason why my configuration doesn't work? Am I missing something?

Hi Taylor. Did you ever figure out this problem? I'm having the same issue.

I have a model with three plant loops: one for space heating, one for space cooling, and one for domestic hot water. I'm getting large numbers of the following warnings:

* Warning * GetSpecificHeatGlycol: Temperature is out of range (too high) for fluid [WATER] specific heat *
* ~~~ * ..Called From:PlantLoopSolver::UpdateAnyLoopDemandAlterations,Temperature=[5024.90], supplied data range=[0.00,125.00]
* ~~~ * Environment=RUN PERIOD 1, at Simulation time=01/01 21:15 - 21:30
* Warning * GetSpecificHeatGlycol: Temperature is out of range (too low) for fluid [WATER] specific heat supplied values *
* ~~~ * ..Called From:PlantLoopSolver::UpdateAnyLoopDemandAlterations,Temperature=[-43.64], supplied data range=[0.00,125.00]
* ~~~ * Environment=RUN PERIOD 1, at Simulation time=01/02 14:00 - 14:15

I've seen similar warnings before and they usually indicate that plant loop temperatures are outside of intended range. I looked at detailed timestep data for each plant loop, however, and I don't see any indication that my loops are not controlling properly. If my plant loop supply side inlet and outlet temperatures look normal, what else could be causing these warnings?

If you have multistory spaces, is there a simple way to merge spaces created from floor plans? For example, I have a two story space that spans the second and third floor of a building. When I create spaces from floor plans, I end up with the lower half of the space on the second floor and the upper half of the space on the third floor. What’s the easiest way to combine those spaces into a single two-story space?

I have a built up PSZ air handler (I'm not using a Unitary system; I have a standard built up air handler with a chilled water coil, a max humidity setpoint manager on the cooling coil air outlet node, a humidistat in the zone, and the controller water coil is configured to meet both sensible and latent load) configured to provide max humidity control. In a proposed case model where the cooling coil is hardsized everything works fine. When I autosize for a baseline case, the cooling coil can't keep up with the dehumidification load. I tried to change the type of load field in Sizing:System to Latent or Total (instead of Sensible) but that didn't have any effect. Is there any way to get the autosizing routine to size the system to meet both the sensible and latent load?

UPDATE: After doing a bit more digging, it looks like the limiting factor is the fan flow rate, not (necessarily, at least; could be both...) the cooling coil. When I hard sized the cooling coil, the system performance didn't change. So I'm currently thinking that the issue has to do with Sizing:Zone, which I'm guessing does not account for the humidistat in the space when calculating cooling design flow. This is by no means a solution, just some extra info to consider.

After doing a bit more digging, I found some additional info, but still no answer to my question. Here is the additional info, for what it's worth: 1. Sizing:Zone does look at ventilation rates but (it appears) only to verify that zone equipment flow rates are enough for minimum ventilation. This doesn't affect the scenario described above. 2. Under Coil:Heating:Water Sizing (my coil type) in the Engineering Reference, it says that coils in terminals get sized according to the terminal flow rate, although what I'm seeing with autosizing does not seem to be consistent with this...

I'm running into a sizing problem with EnergyPlus. I have a multi-zone VAV system with AirTerminal:SingleDuct:VAV:Reheat terminals. When I autosize from design days, I am getting 0 heating load for a particular interior zone, so the reheat coils are getting no power. However, there IS an operational heating load created by the 55 F air getting delivered from the central air handler and the minimum flow rate for the zone terminal. As far as I can tell, this load is NOT accounted for when the coil is sized. I'm by no means an EnergyPlus sizing expert, but it looks to me that the reheat coil gets sized according to the results of Sizing:Zone, which seems to calculate design heating and cooling loads according to the loads in the space (interior, from equipment, people, lights, etc.; exterior, through the zone envelope), WITHOUT accounting for any minimum flow rate from the central system.

First of all, can somebody verify my assumptions about how these reheat coils get sized? Second, if I'm not missing anything, how can I properly account for the impact of the potential heating load generated by terminal minimum flow rates when autosizing (particularly for the case where zone loads are small)?

To clarify, I'm looking for a way to do this for all such surfaces automatically, to avoid having to do it manually for each surface

I’m trying to figure out a simple way to assign exterior wall boundary conditions and constructions for cases where building floors are either partially or totally below ground. I understand that it isn’t realistic to capture changing ground level, but assume a simplified case in which the ground plane occurs at a global z-coordinate of 0. Then, if I build my geometry such that anything below ground has a negative global z-coordinate, is there a simple way to divide an exterior wall surface that intersects the z=0 plane into an above ground surface, with an above ground construction, and a below ground surface, with a below ground construction (e.g., Construction:CfactorUndergroundWall)? It’s easy enough to find surfaces that are fully below ground. I think it’s just the intersection case that is tricky.

In OpenStudio, if you remove a space type you are still left with all of the resources for that space type (default schedule sets, schedules, load definitions, etc.) Is there some way to remove all of that when you remove the space type other than individually removing each type of resource (which can be a pretty long list)?

I'm trying to figure out how to calculate total annual schedule hours for a ScheduleRuleset using an OS measure. Consider the following application. Given a total annual hot water consumption value (gal/year), and a proposed fractional schedule for usage (with any number of Rules to specify different schedules for weekdays, weekends, seasonal closure periods, etc.), calculate the peak flow rate input you should specify for the WaterUseEquipment object.

Sorry for the late response on this. I actually wrote an answer previously but it looks like it didn't take. I found out that the issue corresponded to the HVAC solver hitting maximum iterations because of a separate control problem. When the solver was unable to solve, the flow rate would default to 100% flow rather than tracking the correct DCV flow. FYI, the solving problem was related to what appears to be a bug in ERV (HeatExchanger:AirToAir:SensibleAndLatent) frost control (MinimumExhaustTemperature method).

I'm using the dual duct terminals to model DOAS so that I can correctly do DCV (with other terminals, the OA rate will reduce but the total fan flow and power will not). It's mostly working except for some strange artifacts. On random dates, but always near hvac startup or shutdown, the OA rate spikes up to the maximum fan flow value. The return and relief air nodes, and the mixed air mass flow rate output variable, always show the correct flow (no spikes). The OA fraction reads larger than one (the ratio of the OA rate to the return air rate), and the supply outlet node flow has the spikes. Again, this happens RANDOMLY. There is no pattern that repeats weekly. Additionally, multiple air loops that share the same inputs show DIFFERENT behavior, reinforcing the indication that this behavior is random. I've tried all combinations of adding and removing the min OA schedules in the outdoor air controller and design specification outdoor air objects and nothing fixed the problem (in fact, adding the MinOA schedule to the design spec oa objects made it worse in some cases). Is this a bug or am I doing something wrong?