Hi everyone. I’m sorry for such a large post. I modelled a mixed-mode residence in Honeybee such that AC is required for 3months (summer: March to June) and rest as naturally ventilated space. I created a custom schedule and program to meet the requirements.
After simulation i could see that AC schedule and window opening timings are similar but the indoor air temp is too high - 48c. The setpoint being 24c.
I am trying to understand why the indoor temp is too high when the AC is on. If we are providing a schedule to the ventilation control does it override the temp setting set above in the component? @chris can you please have a look at my script if the workflow is correct for a mixed-mode simulation. base.gh (111.3 KB) honeybee_standards.rar (53.9 KB)
You were supposed to get a warning in the case of applying a ventilation schedule with the AirflowNetwork. The EMS program that’s currently being used to open the windows with the AFN doesn’t yet include the schedule value and it only opens the windows based on the temperature setpoint controls (I will be adding in the schedule value soon when I resolve this issue). So I might recommend just using the simple ventilation objects for the time being. But, even with a fully-working schedule, the schedule only gets applied on top of the temperature controls so you need to make sure that these temperature setpoints align with your intentions. I see that you set up the controls to shut the windows whenever the zone temperature gets beyond 32 C and, given that you are doing this at a time when the cooling system isn’t running, you are going to end up with a case of the temperature running out of control. So I recommend removing this from your controls and you should see the temperature hopefully not getting that much higher than 32 C.
Thanks @chris for the information . Though i didnt get any warning message as you have mentioned with afn, I will do as you have mentioned and revert back.
The main issue what I can observe is the max operative temperature occurs when AC is on (HVAC being autosized). When the building has natural ventilation the temp. are justifiable. We can infer that as windows are closed during conditioning the temp rises indoor but as HVAC is kept Autosized it should bring down the temp. to setpoint values.
In the Legacy version, this script was working as it should be. Still trying to understand the OSW when it runs. I am attaching the modified defination.base_REV1.gh (122.5 KB)
Your file just has too many external dependencies for me to be able to make use of it. At the least, replacing the EPW file path on your machine with the “Download Weather” Component will help. Internalizing the schedule definition or Program JSON inside the document as text would also be helpful.
But it’s definitely an issue with your controls and just not setting them up in a way that they play nicely with one another.
Hey @chris, I apologies for those external dependencies. I have changed the file with everything internalized through the string to hb object. Now I assure you the file has everything for you that you need to check.
Here is the revised file.modified2.gh (128.7 KB)
Thank you for internalizing the dependencies. The issue is definitely with the schedules you created and not with anything specific to natural ventilation. You will see that, as you were saying earlier, your cooling system is being sized to 0 because of the 100C setpoint:
You want to make sure that, when you create the weekly schedules for your setpoints, you use the summer_des inputs to ensure that the cooling system on the design day is cooling the space to a 24C setpoint and not a 100C one:
FYI, @Asisnath , I just added support for the schedule value in the AFN controls:
The only reason why this wasn’t implemented originally is that I didn’t expect people to create such sophisticated control strategies with the AFN so soon after the release. But this issue clearly showed me that it was a priority. Now that the schedule value is implemented, the controls between the simple ventilation and the AFN ventilation will always be identical.
You can get the fix on your end with the LB Versioner component.
Hi @chris. Superb!!! . Yes it was indeed a very important add-on to the AFN component. Thank you so much. I will update the above workflow and revert back with the output.
Hi @chris. I indeed updated through versioniser and modified my script. Just to be sure, i want to ask a question regading the update.I was thinking there will be an input option to schedule in air flow network component and we have to plug the schedule both to ventilation and afn component. So is it like the schedule automatically assigns to the AfN components if we apply schedule in ventilation component?
Yes, @Asisnath . The fix is all under the hood and there’s no change on the interface end. Essentially, the fix ensures that the schedule you assign to individual Rooms with the “HB Ventilation Control” makes it into the EMS program that you see is used to control the AFN window openings in the resulting IDF. I verified in a test case that the schedule has the desired impact on the hourly air flow and room temperature.
