Annual Results to Data culling results - Bug?

Testing the daylight_into_energy example file i’ve found an issue.
For this particular example there are two rooms, each with 6 grid points.
When i plug the results from the AnnualDaylight component and he points from the SensorGridFromRooms to the AnnualResultsToData, the data output plots only the first room with the HourlyPlot component.

I’ve found that commenting line 182 solves the issue and plots all point of all rooms, like so:

    data_dicts = json.loads(stdout)
    data = [[HourlyContinuousCollection.from_dict(d) for d in data]
            for data in data_dicts]
    #data = data[0]
    data = list_to_data_tree(data)

Am i right or there is other way to plot all the data?


1 Like

Hi @AbrahamYezioro

I experienced the same issue. Was able to resolve it using this fix.


Thanks for reporting the issue, @AbrahamYezioro , and for confirming it, @Tarang_105d .

This was, indeed, a bug. I just pushed your fix to the latest development version of the plugin and you should be able to get it with the LB Versioner shortly:

1 Like

Thanks @chris,
I think this component should have a warning regarding the amount of data that can be created and plotted. Just can imagine a project with many rooms and many grid points on each room. There picking the grid room and maybe specific grid point inputs can become very handy.
At least i know I’ll keep this always in mind.
Thanks again,

Hey @AbrahamYezioro ,

I understand it’s very easy to accidentally make the Grasshopper definition run for a very long time when there isn’t an input of selected points. If you have a suggestion for how you would want this warning to display or at what point we consider the data to be “a lot,” I can try to add something for this case.

Hi @chris,
I can think about some options, from less complicated, to more:

  1. Just add in the description a warning asking to pay attention that if not providing a specific grid point the calculation can take long time to complete.
  2. The component turn orange until the grid names/points inputs are provided, giving a warning like the previous point.
  3. Adding a Run input + point 1 and/or 2 before.

I think that option 2 can be the one that can be helpful enough.

makes sense?

1 Like

Hey @AbrahamYezioro ,

They all actually sound like improvements over the current setup and I think you’re right that the second option is the best. The case of someone wanting to import all of the data from all of the sensors is rare enough that it’s fine to make people plug in all of the points to sel_pts.

I just made the change such that _sel_pts and _all_pts are required inputs: