It is common to have many plugins in grasshopper env.
I prefer text in plugin tabs over icons, so I would also prefer shorter names without LBT.
I mostly spend time in energyplus and openstudio related tabs but I would prefer to stay with a single honeybee tab.
I prefer Option 1 without subcategories.
What about ironbug? Will ironbug stay only in C#?
When downloading through pip it is great to have that lbt-ladybug, lbt-honeybee as it downloads all packages. Additionally, it is easy to check all modules with simple “pip search lbt”
We don’t know yet. We need to do some work on the new HBJSON schema before being able to fully support Ironbug. @MingboPeng, can probably provide a more comprehensive answer.
All Ironbug components don’t care if your are using the legacy honeybee, or the new Honeybee. It only interacts with OpenStudio. So nothing will be changed from Grasshopper component perspective. Everything works today will work tomorrow with the new Honeybee.
As for C# question: there are a lot of features that relies on C# Reflection which has been used to dynamically generate grasshopper components. I don’t see any use case that makes me want to rewrite Ironbug with Python. So yes, only C#.
In terms of taking HVAC systems built with Ironbug and run it on Pollination Clould, there are some more works that need to be done:
Ensure Ironbug runs cross platforms: the core library of Ironbug has been designed from day one to be able to run cross platforms (most of it), only a few adjustments are needed to make it ready.
Ensure OpenStudio’s C# SDK runs cross platforms: I have built and tested it on Linux, everything works as expected. Up until this point, all critical pieces of entire workflow are there and just need some time to assemble them together.
The last part is ensure that Ironbug can export user’s HVAC configurations to Honeybee Schema format: the most part of Ironbug side has been done since it was designed to be flexible and reusable. But still need some time to make adjustments on Ironbug to make it work with Honeybee Schema.
I don’t see it is hard/impossible to do, but just need some time to work on it.
I do know a bit of python, but I know nothing about C#
I really like playing with HVAC systems and ironbug is great for that.
I am thinking about defining HVAC systems as graphs in a way that could be both understood by OpenStudio (C#, ruby) and Modelica (accessed through OMPython and other python modules).
Ad3. It would be great to have HVAC systems defined in HBJSON.
I think its time to learn C#, huh.
Ok, now I understand why you are asking. I think this is totally possible. When we add HVAC system configuration (you called it as graphs) to HBJson, you should be able to access it from Python since we are also generating the Python SDK for Honeybee Schema. Ironbug can take this HVAC system configuration from HBJson and translate it to OpenStudio file for simulation.
So for you, you don’t need to deal with Ironbug directly, and you just need to create the HVAC system configuration via Honeybee Schema Python SDK for HBJson.
That’s my plan to do.
How can we ad the Ironbug_HVACsystem to the new HB Model to OSM component?
If you are not concerned about running hbJson file on the cloud, and you do everything within Grasshopper, here is how Ironbug can work with HBModel.
Thank you for the exemple.
But at the same time you are making me curious.
Is it possible to run simulations on the cloud?
Where can I get information on this subject?
Adding HVAC system after creating OSM model hmm…
What about measures for HVAC?
I think what Mingbo means to say is that you can’t currently run Ironbug in a cross-platform way yet because it uses OpenStudio’s C# bindings, which are presently specific to Windows. We are developing a cloud service that’s not ready for testing yet but it uses Linux-based machines and IronBug can’t currently run on them. However, the cloud service issue is in the future and probably the more immediate issue is that the OpenStudio installer for Mac doesn’t include OpenStudio’s C# bindings so, as of now, you won’t be able to run your IronBug Grasshopper definitions out of the box on Mac. We should have solutions for all of these issues in the future but, for now, just be aware that you are limiting yourself to Windows if you use IronBug.
OpenStudio measures are written in Ruby and are cross-platform and so there’s no issue running them on any operating system. You can assign them using the
measures_ input to the “Model To OSM” component. You’ll be hard-pressed to find existing measures with as many inputs exposed as the IronBug components but, if you are writing your own measure, this is another way to get a high level of control over detailed HAVC.
I’m using Ironbug after running a calculation with the new HB-Energy plugin.
How can I separate the conditioned zones? I have used the “Import OSM” to obtain the OSzones and then specify the equipment for zones but I can only do it for all zones.
How can I manage the conditioned zones with their equipment and the unconditioned zones without equipment to create the new OSM file?
When using Ironbug with the new LBT 1.0, how can assign different systems to different zones in the model (i.e. different air loops supplied by different AHUs)? I saw that connecting the new Room item to the Thermal Zone item from Ironbug it is not read as previously HBzone were.
How can I assign the systems with the exemple you shared?
You can use zone’s display name for creating thermalZone with Ironbug:
Let me know if this works for you.
Your specific case there is fine because the Room’s autogenerated name is the same as the ID but, for other cases, you should use the
identifier property instead of the
display_name since the identifier is ultimately what is used to uniquely identify the object in all simulation engines. Also you can get the
identifier all without the need for a custom Python component like so:
Hi @chris and @MingboPeng,
Is there a way to run the the Ironbug HVAC_template: “sys13_RadiantPanel + DOAS”
together with the new Ladybug Tools in the workflow discribed above?
Hi @Erikbeeren, I personally haven’t tried to run radiant system with new Ladybug Tools. What’s the problem that you are facing?
I got the folowing error:
Program Version,EnergyPlus, Version 9.4.0-998c4b761e, YMD=2021.02.08 09:06,
** Severe ** [Branch][Compensated Chilled water loop Demand Branch 1][components] - Missing required property ‘component_name’.
** Severe ** [Branch][Compensated Chilled water loop Demand Branch 1][components] - Missing required property ‘component_object_type’.
** Fatal ** Errors occurred on processing input file. Preceding condition(s) cause termination.
…Summary of Errors that led to program termination:
… Reference severe error count=2
… Last severe error=[Branch][Compensated Chilled water loop Demand Branch 1][components] - Missing required property ‘component_object_type’.
************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).
************* Fatal error – final processing. Program exited before simulations began. See previous error messages.
************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
************* EnergyPlus Sizing Error Summary. During Sizing: 0 Warning; 0 Severe Errors.
************* EnergyPlus Terminated–Fatal Error Detected. 0 Warning; 2 Severe Errors; Elapsed Time=00hr 00min 0.22sec
Runtime error (AggregateException): One or more errors occurred.
line 125, in script
I do not know if it has to do something with not being able to assign the internal source material to a construction.
LBT_ironbug.gh (172.2 KB)
I think we need to check with @chris first.
@chris, is the internal source material enabled in the new LBT?
Hey @MingboPeng and @Erikbeeren ,
There’s no official InternalSource material in in the LBT plugin right now but, if you set up IronBug to work with the hack that I used in Legacy to represent internal source materials, @MingboPeng , then you can use the same hack in LBT. If you ever took a look at it, you’ll see that the Legacy INTERNAL SOURCE material is just a dummy opaque material that I end up swapping out with a real internal source in the “Export to OpenStudio” component:
So, if Ironbug is also set up to use this hack, all that you should have to do is create an Opaque Material called INTERNAL SOURCE and use it in a construction like so:
I am working on an energy simulation of a 1-zone model.
I am using the workflow outlined by @MingboPeng above to write the OSM file, add the HVAC generated by Ironbug by overriding the OSM file, and re-run the OSM model:
I am also using the HB Label Rooms component to get the simulation name to pass to the HBZones input for the Ironbug_ThermalZone component:
When I try to run the energy simulation, I get an error that the “Zone has no surfaces”:
Any thoughts as to why this is happening? I have also attached my grasshopper script.
energysimulation_ironbug.gh (95.5 KB)