Hello all. What is the best way to get the unmet hours output for HVAC simulation in LBT honeybee energy? In the legacy version, a dedicated HVAC result component exists.
Good question. If you just need the total number of hours that the setpoint is not met, the fastest way to get it is by parsing the “Comfort and Setpoint Not Met Summary” table from the Summary Report like so:
There is a way to get the hour-by-hour results (just like legacy) but I discovered a bug while putting together a sample. Give me an hour to fix the bug and then I’ll post a sample that shows the hourly results.
1 Like
Thanks for the qyick reply @chris. Now i am getting the idea of using tabular data. If i am not wrong it is reading the sql generated data . So in HTML report that is generated , the tables present inside this can be visualised in grashopper directly. This is quite useful.
To add on to the above discussion two main component i miss while working with Lbt energy model with detail hvac that was actually helpfull. One being the adding cooling heating detail and secondly the read hvac ouyput detials. Will it be added in near future? Sorry if i am being over ambitious.
Th bug fix has been fully merged and has made it through the automated release. So, if you run the Versioner now and restart Rhino, you should be able to open this sample file that shows you how to request and import all of the HVAC-related results that you could get with the Legacy components:
UnmetHours.gh (108.1 KB)
I hope you don’t mind that I now recommend doing this by requesting the outputs using the same workflow that you would use to request whatever other custom outputs you would want from the simulation. It’s just that, particularly for the Node-level outputs for the HVAC, it can be a tremendous amount of data and so I think it usually makes more sense to just request the one output that you are interested in rather than always requesting node flow rate, temperature, and humidity all at once.
And, yes, that’s exactly how the “Read Tabular Data” component works. Just look up a table you want in the HTML file and then you can import that data to Grasshopper.
For heating and cooling details, it would be tough to implement some of them in a way that is relevant to the many templates that can be assigned with a given HVAC component. This is actually the main reason why we have 3 different components to assign the HVAC templates right now (eg. certain customization inputs like heat recovery are just not relevant to some types of HVAC that don’t have ventilation). Most of the really meaningful inputs like heatRejectionType_ on cooling details are essentially supported now by the fact that there are so many variations on the plant side of things with the many new HVAC templates. And the centralPlant_ is built into the way that the HVAC templates are assigned, which is almost always the preferred option.
I should ask what input parameters on these heating/cooling components do you miss? If it’s just one or two like the heating/cooling COP, maybe we can find a way to support it for most of the HVAC templates, though I don’t know what the COP would mean for a system like evaporative coolers, for example. It’s also that these new HVAC templates are purposefully set up so that it’s hard to mess up the assumptions and make a wrong design decision based on them. This is great for people who only know what their HVAC is called but don’t know the details of the individual pieces of HVAC equipment. But it’s not really intended for major customization and this is intentional.
At a certain point, our answer is just “use ironbug if you need full customization” since that’s really the tool that is set up in a manner that you need to understand the equipment of the HVAC template in order to make changes to it. I should also mention that you can use IronBug now with the LBT plugin using the workflow that Mingbo posted here. I know the end of the release notes say that “Ironbug Integration” is a currently unsupported feature but this just means that you can’t assign an Ironbug HVAC to a honeybee Model or write it into a JSON file or use Ironbug on Mac. You can still apply an Ironbug HVAC to an OSM as long as you’re in Grasshopper on Windows.
Hey @chris. Thanks a lot for the update.
I agree that to avoid overload of data in gh it is always bettter to request data that is required.
For the Customization of HVAC, I export the osm file to OSapp. After modification i re run the OSM in Grasshoper as we used to do with legacy version. The point I made to have a cooling detail and heating detail component was only to avoid opening OS app for quick twiking of Hvac parameters. You rightly said Iron bug way is the best way for customised HVAC. It is very nice to see the deafult templates and assumptions for HVAC are quite robust for initial comparison of designs.
Thank you again for your time and leading us in the world of simulations.
Sounds good , @Asisnath , and thanks for the kind words. If there is a particular customization input of the Legacy HVAC templates that you miss, please feel free to open a “wish” issue on the honeybee-energy github. You can see from issues like this that I still have plans to add certain customization options that are straightforward to implement across all of the templates. In particular, it’s relatively easy/straightforward to include customizations like the addition of a certain piece of HVAC equipment in air loops or the editing of HVAC equipment that all templates share. The only place where it gets a little messy/harder is a case where we want to change a property on a piece of HVAC equipment that not all of the templates share so this might be a situation where Ironbug is recommended.
2 Likes
@chris I totaly understand the way the components are categorised & designed. A lot of thought have been given on each component and parameters. The more simulation workflow we run more questions will arise. Will definitely share my side of experience. Thanks 