When I select HVAC systems from OpenStudio library, I see a checkbox of Demand Control Ventilation.
What is this for? I checked the box, but DCV was not modelled.
Hi @keigonomura.
I’m also not sure how DCV is modeled behind the scenes through HVAC Manager. However, I also did run a quick simulation with DCV on and off. After I check the output file-> Outdoor Air Details section, I was able to see that DCV is integrated in the model. I think it would be worthwhile to understand how DCV is limiting outdoor air flow rates.
Thanks,
Levent
Hi @hlkocalioglu.
How to model DCV in EnergyPlus is not a single setting. It spans over various classes/fields.
It seems that Pollination only models the classes Controller:OutdoorAir and Controller:MechanicalVentilation. Besides, for DOAS, Pollination always models Fan:ConstantVolume even if users check the checkbox of DCV.
For DCV, the outdoor air flow rate is controlled based on the indoor CO2 concentration in most cases. CO2 is a good representative of the outdoor air demand. Counting the number of occupants by image processing is not so practical as the activity level of each occupant may be different.
Therefore, we also need to model the classes ZoneAirContaminantBalance and ZoneControl:ContaminantController to set the indoor CO2 concentration setpoint the outdoor air CO2 concentration. (People has a default CO2 generation rate of 0.0000000382m3/sW, editable if necessary.)
We should also take care of the Minimum Air Flow Fraction of Fans and AirTerminals. For DOAS, the minimum outdoor air flow rate is the same as the fan minimum air flow rate which is normally 40% to 50% of the fan maximum air flow rate, depending on fan manufacturers. For VAV, the outdoor air flow rate is normally controlled by a VAV box or motorised damper, and the minimum outdoor air flow rate is 0% to 30%, depending on the products.
Hi @keigonomura.
Yes and that is why I wasn’t sure that solely checking the button will model DCV. There has to be more inputs required for that.
Yes, I can also confirm that DOAS modeled by Fan:ConstantVolume even if DCV button is checked.
Let’s wait and hear from Chris to throw light on this.
Thanks,
Levent
Good questions, @keigonomura . I can answer a lot of what you brought up here, though I’ll admit that you’re approaching a level of E+ otaku that is starting to be a little more appropriate for the unmethours forum. Still, let me explain as best I can what happens when you check this box for DCV.
First, I’ll note that this is definitely correct:
EnergyPlus has at least 5 different ways to model DCV that I know of, almost all of which involve changes to several objects. In fact, I’d say that there are two ways to do it in Pollination (one of which is the DCV check box and the other is applying a ventilation schedule to the Room in question). These two pollination methods could produce the same energy use result but some of the different ways of modeling it in E+ will give you different energy usage.
To make things a little simpler for all of us, OpenStudio provides a single method on the ControllerMechanicalVentilation object that can be used to automatically set up DCV. The method is called setDemandControlledVentilationNoFail and you can see that it is called as part of the translation process from Pollination/Honeybee to OSM here in our source code:
So that’s describes all that is happening in the process of OpenStudio translation when you check the “Demand Controlled Ventilation” box in Pollination. I believe that changing this one attribute in OpenStudio causes it to make a few different changes in the IDF that it exports but it does not change the type of fan being used in the air loop. So, to explain what is happening here:
The DCV is effectively being modeled by adjusting dampers that change the amount of new fresh outdoor air that is introduced into the DOAS air stream (making up the rest of the air with recirculation). So this type of DCV reduces the overall heating and cooling energy that you need to expend conditioning outdoor air but it’s not going to change the fan energy since this is still at a constant volume for the default DOAS. Clearly, there’s some fan energy to be saved if you want to swap out the constant fan with a variable volume one, though not all projects will spend the extra money on this type of fan and you’re getting to a level of customization that’s a bit beyond the HVAC templates that ship with Pollination. So, if you want to model a DCV system that uses a variable fan, I recommend setting this up in IronBug so that you can also specify the controls on this variable fan to align with the controls dictating the outdoor air dampers.
To explain why the DCV you’re assigning with this pollination HVAC template does not need need these objects:
This is because the EnergyPlus occupancy schedule is being used to adjust the amount of outdoor air that is introduced into the DOAS air stream. In principle, this can get you a very similar energy use result to what you would achieve with the ZoneControl:ContaminantController but with a lot less calculation needed. Obviously, in the real world, you don’t know what the occupancy will be in the next hour and so you need something like a CO2 sensor to give you information about the occupancy. But, in an energy model, you know what the occupancy will be in the following hour because you have a schedule so you can simplify the whole calculation. So that’s why I would argue that the result you get with the DCV checkbox is still a decent representation of reality but I also recognize that there are nuances like CO2 dispersion, for which you would need the ZoneAirContaminantBalance IDF object. So, if you want to set up your DCV this way, I would again recommend IronBug, which I think supports these objects (@mingbo will correct me if I’m wrong). If I am wrong, then you can always assign these objects to your models produced from Pollination/Honeybee by using the add_str_ input on the HB Model To OSM component to add these additional IDF objects to your exported models. Or you can write an OpenStudio Measure to apply in the translation process (connecting them to the measures_ input of the “Model To OSM” component). Or you can write a Grasshopper component that post-processes the OSM using the .NET bindings of the OpenStudio SDK similar to what I did here for some people who needed very specific sets of window opening controls for the CIBSE TM59 standard.
I hope that all helps and let me know if I missed anything important.
@chriswmackey Thank you for your reply.
That’s incorrect. For DOAS, Outdoor air flow rate = Fan air flow rate. Fan must be variable volume to achieve DCV. DOAS with Fan:ConstantVolume and DCV is impossible.
Pollination sets Design Return Air Flow Fraction of Supply Air Flow in AirLoopHVAC to 1 in EnrgyPlus when modelling DOAS with DCV, which is incorrect because this setting allows Resturn Air. That’s not DOAS because DOAS does not have RA.
If you set Design Return Air Flow Fraction of Supply Air Flow to 0, you can see that DCV does not work and the outdoor air flow is constant because the fan is Fan:ConstantVolume and there is no RA.
Fan with Variable Speed Drive or Fan without VSD can be modelled by customising the fan power curve (fan power coefficients), but in any case the fan must be variable volume to achieve DCV.
I understand your view, but I don’t think DCV based on the occupancy is very similar to DCV based on CO2 concentration (DCV in reality).
MEP enginners determine the design outdoor air rates based on ASHRAE 62.1. It specifies People outdoor air rate and Area outdoor air rate for various Occupancy categories, but once the the design outdoor air rates are determined, DCV in reality does not distinguish People outdoor air rate and Area outdoor air rate. DCV in reality controls the total ourdoor air rate based on CO2 concentration. On the other hand, DCV based on the occupancy distinguishes People outdoor air rate and Area outdoor air rate, and it changes People outdoor air rate only.
Thanks, @keigonomura ,
I understand your frustration that people don’t all agree on what controls and layout a DOAS is supposed to have in order to be called a DOAS and I personally wish that I could change a few of the terms used in mechanical engineering to make them clearer (eg. why do we still call them “Chilled Beams” when they do space heating). But I am not the one who called this system that can have recirculation dictated by DCV a DOAS. As I showed in the sample code above, all of these names and methods are coming from OpenStudio SDK and OpenStudio-Standards. Knowing how passionate you are about this, you could try asking the OpenStudio developers about this particular issue on UnmetHours. Maybe they have an internal debate about it themselves. I can also plan to eventually add some extra code to correct for what OpenStudio team considers a DOAS and try to swap out the constant fan with a variable one. But that will take me some time.
Maybe the more immediately practical thing right now is to work in getting you an Ironbug script that performs the way you want it since it is very straightforward to swap out a constant fan with a variable one in IB. Have you tried using the FCU + DOAS template that is built into Ironbug and tweaking it with the fan you want? @mingbo might be able to point you to the best documentation there.
And, if accounting for CO2 concentration just means that you want to have the Area outdoor air rate decreased using the fraction of occupancy along with the People outdoor air rate, this is pretty straightforward to do with a ventilation schedule, which we could include in the IB script without the need to use the extra CO2 objects that might take some more work to support.
@chriswmackey Noted. We will need to use IronBug if our organization decides to subscribe Pollination. For now, I’m just trying to identify any concerns/problems as much as possible in the free trial period.
Thanks, @keigonomura ,
If you’re thinking about this long term, know that I’ll also try to implement your recommendation of the VAV fan in the DOAS HVAC templates. I opened an issue for it here, which will involve me swapping out the fan type that OpenStudio SDK uses by default:
I agree that it’s better practice to use variable fans whenever there is DCV involved.
You’ll likely still need Ironbug for other reasons but the constant fan in the DOAS won’t be one of them in the long term.