Running HB example on Rhino.Compute

Hello All!
I have a Rhino.Compute server setup with the legacy Ladybug and Honeybee plugins installed. I can run the Honeybee Grid-based Daylight Simulation Example III found on hydra without any issues both locally on a Windows 10 machine and on the server machine.

I modified the definition to include an RH_IN decorated param for varying the _gridSize input as well as an RH_OUT decorated param for getting the resulting mesh.

When I run this on compute, I hit the server just fine and get a response, but the resulting data is empty. I have a feeling it might have to do with the consoles that might be popping up. I am not sure how these would be handled in a headless environment (we’re also checking on our side).

Has anyone run into this? Any tips? Thanks!

I see Honeybee uses sc.doc... all over the place, which will fail in a headless context. I’ll see if we can handle this in compute.

Hi Luis @fraguada,
You can set runRad to 2 instead of True to run the simulation headlessly. But I don’t know if this would help with your problem.

1 Like

In the process of debugging I am finding two related issues which are exposed due to how HB and LB definitions are expected to work in GH:

  • “Disjoint Graphs” - GH Definitons that make use of LB or HB depend on the Ladybug and Honeybee init component which set up a lot of important stuff and save some of this stuff in the sticky dictionary. Other components depend on this, but aren’t connected to them in the graph. So we have a “disjoint” graph (I am sure there is a more correct term). The issue here is that the LB and HB init components aren’t solved at all because Rhino.Compute only solves graphs which help solve a requested output. In order to solve this, we can ask for the result of the init (the text that says “flying…”) and this will cause the init components to solve.
  • Component solve order - In cases where components depend on data that is stored in the sticky dictionary, we need to solve the graph in a specific order. Disjoint graphs have several routes but Rhino.Compute solves them in the order that the outputs were defined. So if I drop a param for a result mesh before setting up a param for the text from the LB or HB init components, it will try to get the mesh before the components that generate it have the appropriate init data from LB and HB (I hope that makes some sense). The workaround here is to recreate the output params in the appropriate order.

Hi @fraguada, the “init” components has been removed in the new plugins, which just imports/checks whatever is needed in each component.

Do you want to test the new plugins? @mostapha can you add Luis to early access group?


Done! @fraguada let us know if you have any other questions.

1 Like

I am testing the newest version of LadyBug on Rhino Compute (available on Food4Rhino Ladybug Tools 1.0.9 updated on 2020-Oct-13).

It does look at it still requires the LadyBug_LadyBug component to run before everything else to run otherwise it will return the error “You should first let Ladybug fly…”
This error can be avoided by using forcing all other components to run after LadyBug_LadyBug does by:

@mostapha Can I apply to be part of the pre-release test group? I am from KPF UI team and we are looking into porting some of our building simulation scripts to rhino-compute, so be-able to run your tools on compute means a lot to us! thanks.

1 Like

@Demi ,
None of the components of the new LBT plugin (version 1.0) require Ladybug_Ladybug or Honeybee_Honeybee to be dropped onto the canvas to run. Furthermore, you won’t find any dependencies on RhinoCommon or Grasshopper SDK within any of the LBT plugin components and we did this intentionally so that we can automatically generate components for other CAD interfaces like Blender/Sverchok using the Grasshopper components. All of the Rhino and Grasshopper dependencies are wrapped into a single Python package that all of the components import from:

So all that you would have to do to make a version of the LBT plugin that runs without a Rhino doc is make a version of that ladybug_rhino package that returns things without a need for a Rhino doc. Of course, this means that you will have to make assumptions like all geometry is in meters or something like that in order to run without a doc. But overwriting all of this is a much lighter lift than trying to do this with the legacy plugin.

1 Like

Oh I know what’s wrong! I thought ladybug would update automatically (in my old scripts) once I install the newer version and forgot these were just python components! Sorry my bad!!!

will keep you posted!