I am also in complete agreement with Aurelien Keller about his comment on descriptions. This is necessary, and I am too working towards improving tool tip descriptions and component descriptions as and when I spot the ones that I think could be improved.
What I really like is adding what decision the component can help you take in addition what it can help you simulate. Obviously, I draw inspiration from components written by Chris and Sarith. Technical notes, suggested practices, and warnings provided by Sarith are much appreciated.
One thing, I donāt know if its possible or how difficult would it be, so just asking.
Would it be possible to make more clear the additional results from Energy plus?
Iāll try to explain my self.
Iāve been spending a lot of time developing a way to use Air flow network directly in grasshopper instead of running the simulation, editing the .idf and reloading it. I plug it in the additional strings of the run energy simulation and then I get the air flow volume (ach) from the āOther zone dataā in āRead resultā and the opening factors and multiplier of the windows from the āother surf dataā in āRead EPS Srf resultsā all of them quite mixed, but its easy to separate them, so not a real problem with that.
However, some other outputs that Iām also including, such as the wind pressure on the windows surfaces donāt appear (or I havenāt found), I need to get into the excel .
Hi Bijit & Mostapha, I agree that coloring the text will be better.
Bijit, I propose that we color the text outside of this component. To do that, added two more outputs to the windRose component.
Ladybug is coloring the meshes as black, and rightly so. Otherwise, the meshes will have default Grasshopper mesh color which most people donāt like and I believe that it is a deliberate decision by the developers of Grasshopper so that the users change the color.
So since Ladybug is coloring the meshes, the native Custom Preview component can not help you color already colored meshes. Therefore, I wrote a small component that lets you do that.
Hi Devang! Thanks. Since itās already a mesh you can easily color them inside the component. If weāre going to color the text then letās do it inside the component.
What about using OpenStudio API? That basically does what you say and you can see an example in OpenStudio component in Honeybee.
Do you want to have a report while writing the idf file for all the assumptions? That should be similar to what Olivier is asking for. Iāll discuss it under his comment.
I love the idea of having an input summary form but is it only include what the user inputs from GH interface? Or all the inputs? In a sense idf is the list of all the inputs. How do you think we should abstract that data to make it useful?
Hi Devang, Thank you for the detailed reply. Great suggestions.
Can you share an example of the checklist? I would say the better idea is to create quality-check components based on these checklists/best practice approaches. We can definitely implement this in [+] components. For CFD Ilker had a similar idea but for post processing the results and give feedback based on the accuracy of the results.
Totally! The new development is well documented and thatās how weāre generating this API documentation. It might be too much work for the legacy version, and also if everything goes as planned we should retire the legacy version at some point soon.
I know this is not your request but we should fully implement airflow network to honeybee.
2.Yes. We have been talking about this. The most straight forward approach is to generate the sql file. We even get it started but then we closed it as I thought no one will be really use it. I will go ahead and re-open the issue so we implement this to Honeybee[+] now that we know weāre not going to be the only users!
Yes. Itās easy to color the meshes inside the component. The thing is, we want to leave the choice of colors in the hands of the users. And to do that, the way I see it, we will have to add two more inputs to the component for colors. Will you be ok with that?
About developing AFN, Iām not sure yet about how worthy is to use it. The main advantage Iām seeing right now is that it gives data of the air flow between different zones, what can be extremely useful. But I donāt completely trust yet my results. So, if you develop it one day, Iāll really love to test it and see what Iāve been doing right and wrong.
Thanks, I guess I really have to learn about OpenStudio.
I have some questions regarding HB+.
Is it intended to replace the old HB at some point?
If it is, then a lot of the code has to be rewritten right? Maybe we could help at some point? I think this would be a good opportunity for developers to learn the inner workings of LB/HB. Iām particularly interested in participating.
Iāve been browsing through the code of HB+ (Iām assuming itās this: https://github.com/ladybug-analysis-tools/honeybee-plus), and I have to say that it looks really great with all the docstrings, PEP8 and even its own API documentation.
I was wondering if this is meant to work with a later version of GhPython/GH/Rhino (Rhino 6 maybe?). I remember from your video tutorials for developersā¦ youāve mentioned that at the moment, sc.sticky was used instead of import libraries due to some reasons.
For some reason, weāre going the normal way of development. Maybe itās related to the upcoming Rhino 6? (I remember something like GH would already be part of Rhino with a better Python implementation or something like that).
I have attached the checklist that gave me the idea. It is too old. Now that you have mentioned, I like the idea of creating components more. Do we have any such component already in LB+HB? If yes, I would be interested.
Thank you for the recognition! It is always good to feel appreciated
Julia,
Thank you for the comment and I should have put up an example sooner about how you can get custom outputs for anything you want with Honeybee. The SQL is one method that we have not fully implemented yet but will usually take SOOOOO long to write because E+ will write all of this crud into the SQL that you are usually not interested in. A better approach in my view is to run the model once and parse the Result Data Dictionary (.rdd) file using the āHoneybee_Read Result Dictionaryā component. This allows you to see all of the outputs that you can request and you can even search through it to find a particular output. Once you find what you are looking for, you simply copy the text into a panel and and plug this into simulationOutputs. Then you can use the āHoneybee_Read EP Custom Resultā component to bring the results that you are interested into GH. I updated the example of the evaportaive cooling tower on Hydra (which already shows how to use additionalStrings) in order to show how to get out a custom output of the energy removed by the tower:
I am going to close the SQL github issue now unless someone has a specific reason why the SQL method is better than the method that I posted here. If you donāt mind, Mostapha, will you direct people who ask questions about custom results to this example file for the time being? If we implement SQL, I donāt see it happening until on the legacy version of HB.
This is good to know. The Ladybug[+] function that generates Rhino text should definitely include an option for color. Itās actually pretty easy to implement now on the Legacy plugin, Devang, if you wanted to give it a shot. You just have to add an extra output to the text2Srf function for color and set the default to black (if no input is provided).
Yes, HB+ will replace the legacy version (the ācurrentā one) at some point, although it will be at least several months before all of the features of the legacy version are in the plus version. Stay tuned to that github to find way to get involved.
HB[+] is intended to work with many different versions of python, including ironPython (that which is used by Rhino 5 and Rhino 6), Python 2.7, and all of the way to Python 3.6. There will be no need to let HB_HB fly or to use sticky as most code will be in external .py files. As such, it will be cross-platform. See here for the list of reasons why the code is being re-written:
Yes. I could easily implement that inside the component. But I am concerned about adding good two inputs for colors. One for frequencies and the other for average velocities. The advantage of doing this outside the component is that one can also color the Title Text (The text Below WindRose) if one wants to. If you and Mostapha are good with adding two more inputs then I will implement it.
To echo Mostaphaās sentiment here, the world of HVAC (and especially very innovative HVAC) is so vast that we cannot possibly write all the scripts to enable this within the Honeybee community alone. However, OpenStudio team has set up infrastructure for people to write custom ruby scripts with the OpenStudio API (called Measures) and simply run these scripts to apply highly custom, innovated HVAC systems to OpenStudio models. What is even better is that they have set up the Building Components Library (BCL) so that people can share these scripts and the innovation of our community can grow! Here is the list of scripts tat have been shared so far:
After the (very soon) release of OpenStudio 2.0, the format for measures will be standardized and we will be able to finish a couple of components that allow you to apply measures to your model with Grasshopper (without the current bugs). The biggest advantage of this workflow is that you can have custom inputs for each type of HVAC (ie. the number of boreholes on a Ground Source Heat Pump system).
Once OpenStudio team finishes this standardization, I have the working implementation of the āRun Measuresā component as the last thing I will add to the legacy Honeybee before going full force on Honeybee[+]. Any future HVAC templates that I make for my office or other work (ie. GSHP system templates) will be implemented as Measures and shared through the OpenStudio BCL.
