Hi @chris,
Lately i updated OS to 2.8. Seems to be it uses E+9.1.
Using the HB_EPWindowShades component it creates, among others in the IDF, a block WindowProperty:ShadingControl for each zone (it is supposed to do so). Unfortunately this block doesn’t include the zone name, which is a compulsory input. As a result you can imagine, the simulation crashes.
Tried to use the HB_runEnergySimulation instead but the error i get is:
This component does not support shading control in versions of E+ greater than 9.0.0. Use and older version of EnergyPlus or use the OpenStudio component.
See a snapshot of the definitions HB creates and the one missing. Now i see that other compulsory fields are missing (Fenestration surface names)
What version of the components are you using? I know that E+ changed the shading control objects in 9.0 but I have since updated honeybee to work with the new versions.
I have been able to run shading control without any issues:
Hi @chris and thanks for your answer.
I’m using the last version of the components (same as you).
I think i get to isolate the problematic case, which is the shadeType 0 (Blinds).
Do you mind checking the attached (is your same case but with the above option).
Thanks,
-A. shading_control_test_AY.gh (650.6 KB)
@AbrahamYezioro ,
Thanks for the sample file. The issue is not the use of blinds. It’s the use of a scheduled shading (shdCntrlType_ = 0), which it seems has been totally re-vamped in the newer E+. I will see if I can fix it but, in the meantime, just use any of the other shade control types and it should work.
Hmmm …,
I’m considering downgrading to OS2.5. I’m in the middle of a project where i can’t change the type of control (needs to be scheduled).
Just tried now to update a previous IDF version to 9.1 with the IDFVersionUpdater.exe. The IDF has a scheduled shading control. The update succeed (of course) and simulating it also runs fine. It means that this shading control should work well.
Thanks entirely to the fact that the OpenStudio SDK basically took care of this issue, I was able to fix it very easily within the OpenStudio component:
Unfortunately, it would be an absolute coding nightmare to fix this same issue in the component that goes directly to IDF so I am afraid to say that this might be the first instance of the IDF component’s deprecation. However, it may be just as well since the IDF format is completely changing to a JSON-based schema in E+ 10, which will definitely spell the end of times for that component.
You can find a version of your grasshopper file that works with OpenStudio 2.8 here: shading_control_test_AY_CWM.gh (659.9 KB)
And it goes without saying that you should let me know if you experience any issues with ShadingControl in the new OpenStudio component. I tested it with a CSV schedule so I believe it should work in your case but you have a good habit of always finding the bugs I miss
Thanks a lot @chris!!
Just checked and it works fine with my library defined schedule.
Glad we get it … and sorry this is the thread that announces the beginning of the end for the E+ component.
Somehow people need to be aware that for the shading control needs, and OS2.8 and above, this is a breaking point when deciding which component to use for performing the simulation itself. There is no choice now…
Later on i’ll try to check other control options. Who knows …
Thanks again,
-A.
As you can see there are two zones (z3, z3). Both of them with windows and blinds controlled by schedule. For some reason the WindowShadingControl is assigning some of the windows of one of the zones to the other’s object definitions.
Do you think it is an issue?
Attached also the file, so you can check. Look at the group at the bottom of the canvas.
BTW the shadeCntrlIDFStr output is not what is registered in the IDF file right now.
@AbrahamYezioro ,
Thanks for reporting. It is hard to tell if this is actually a bug since it seems like the issue isn’t large enough that it won’t run. I will check you file to see if there is anything about the z3 window that is being assigned to Zone 2 that would trigger this (it’s not an interior window, right?). I’ll also see if I can ask OpenStudio team about it the next time that I get to talk to them.
Hi @chris,
Just wondering if you have new insights for this.
I was thinking i can live with the previous comment (assigning windows from one zone to other).
Now i’m getting a situation where too many of such assignments are made and the IDF editor can’t open the file. I noticed that the Window ShadingControl has a limit of 10 Fenestration Surfaces. The OS is assigning, for my case, 22 of them. This crashes the editor, though the simulation is performed.
Now i’m not sure how reliable this simulation is.
I sliced the block of windowShadingControl, so you can have a look (if you like).
Worth to mention that the extra assignments happens in the first object, while the other have only 1 fenestration surface assigned.
If you have a wise recommendation i’ll appreciate.
Want to update.
In this discussion i’ve found a partial solution for the oppening issue in the idf editor.
Just edited the energy+.idd as noted there.
I’m considering to report a bug in the github or ask a question in bigladder. I’m not sure how the process is done from HB to OS. Can you make it clear if the WindowShadingControl is automatically created, or how it is decided to create the group(s) of windows according to the zones?
Thanks,
-A.
Hi @chris,
Wanted to know if you get some feedback from the OS side?
Want to report that the solution i’ve found is fine but is a pain to use it.
I’ve got a case of a building of certain height and that for the amount of windows it has, and since the shading control is written into the first object in the idf, the added lines in the Energy+.idd may be not enough. Then the simulation crashes.
At some point this can be critical for more than one … as it is for me now.
Sorry for the late response here but I knew that I was going to need some time to explain what I know and discuss solutions. There’s a long story to how we ended up with the current ShadingControl situation and the changes that are taking effect have required coordination between the EnergyPlus contributors, the IDFEdditor maintainers, the OpenStudio team, and us. Because of all the people involved in this change, this sequence is still playing itself out and so there are going to be some incomplete and unsatisfying situations for a while.
I know that much of the underlying reason for why people wanted this change is to allow better coordination between the blind-pulling/electrochromic behavior in daylight and energy models. Part of this involved moving the specification of ShadingControl object on the FenestrationSurface objects to the other way around (specifying the FenestrationSurfaces on the ShadingControl). This way, more complex sequences of blind-pulling across different windows could be modeled with one shading control object. However, this creates a non-backwards-compatible change, which is probably why they decided to make the change around the shift from E+ 8 to E+ 9.
Honeybee (trying to straddle both old and new versions of EnergyPlus) is still kinda set up to use the old way, which results in many FenestrationSurfaces being set to one ShadingControl and the situation you experience here. Realistically, this is the only way that we can ensure Honeybee is still fully compatible with OpenStudio 2.5 (the version where we know that everything is stable) but still work with the new EnergyPlus /OpenStudio. So I think that we are probably going to leave honeybee-legacy as it is for now and, if you really need to avoid the painful situation you describe with honeybee legacy, our answer is just to use OpenStudio 2.5 and you will not experience it.
However, now that we have the opportunity to fully revise Honeybee (the new honeybee-energy library is nearly at an MVP level now that it can produce simulate-able energy models), I think we will set up ShadingControl with more of a “new E+” philosophy. Namely, I think we will just write out individual ShadingControl objects for each and every FenestrationSurface. This is clearly going to increase the size of the resulting IDF file but it means that you will never experience this headache that you currently have. While it’s still going to be lacking some of the HVAC capabilities, ShadingControl is something I think we could put in the release of Honeybee[+] that is currently planned for Spring 2020.
Let me know if this set of solutions sounds like it will work for what you need or if you have an alternative suggestion.
Thanks @chris for the detailed explanation.
First of all i need to inform that i opened an issue at the github of OS. Link here. I was assuming you previous comment that the issue was caused on the SDK new version of the OS.
From your explanation now i understand that this is a work in progress that many parties are involved on.
I don’t have a problem rolling back to OS 2.5 but i believe the issue is more critical not only for me but for most users (that are applying blinds or other shading controls) now. My concern is regarding the results obtained when the interface assigns most of the controls to one window in a completely different window than it was assigned. If there is some influence so i think this is critical and OS 2.8 should not be supported for now. I understand from the responses i get in the link above that results are affected if you are asking for daylighting.
The meaning of that is that the last stable version for HB legacy is OS2.5 and E+8.9 and people need to know. If you agree with that i’ll roll back to those versions. I don’t believe it is “healthy” to allow/release versions that are not fully reliable. I understand the “need” to be compatible backwards but at this stage i think the limit is drawn. Unfortunately i don’t have alternatives to suggest. For me is not critical to be in the last version of OS i just update almost automatically as new versions appear.
Makes sense?
Thanks again,
-A.
I’m sorry that my last response didn’t really account for everything that you reported in your previous posts. I have realized that there are two issues here:
The fact that we often need to assign many Fenestration Surfaces to the same ShadingControl object to get it to work in both old and new versions of E+. This is what I described above and this will be addressed in Honeybee[+] by only having one shading control per window.
The fact that Fenestration Surfaces in honeybee-legacy were not being grouped with the correct zone in ShadingControls.
I didn’t realize that the second issue was not resolved yet and I just dug in and fixed it:
So, if it’s the second issue that was causing you say that we should refrain from saying OS 2.8 is supported by honeybee-legacy, hopefully this addresses the concern. With this said, Honeybee[+] will definitely be better integrated with the newer OpenStudio and E+ because it won’t be trying to straddle E+ versions in the same way. So there will be good reasons to make the jump once we release it. And we will eventually get to the point where we say “OpenStudio X.X is the last stable version of OpenStudio that is compatible with Honeybee-legacy” but I think, for now, the latest version of OpenStudio is still usable, albeit with some caveats like the fact that the IDFs might not display well in the IDFEditor. Let me know if my understanding is correct.
.
