Hi LBT team,

We think a component to convert LB Object to JSON string as well as the other way around will be helpful, in addition to save to file component. Similar functionality are available for HB objects, where we have both options to save as string and save as files.

We have been creating custom LB objects in the same json format and it will be great if we can have this component to enable us using the great visualization functions of LBT.

Thanks.
Bing

This shouldn't be terribly difficult to add. It should be exposed an an option on the component inputs, though, since I think it doesn't feel like the desired default behavior.

To enable this, you'll have to first figure out the number of _view_points that are within a given distance of a particular grid point. Once you have that, it's pretty easy. You'll just have to edit this line of code inside the component:

https://github.com/ladybug-tools/ladybug-grasshopper/blob/master/ladybug_grasshopper/src/LB%20Visibility%20Percent.py#L147

Essentially, you'll want to divide by the number of points within the distance rather than the vec_count (aka. the total number of points). You'll also probably need something to catch the case that no points are within the max_dist_ since you'll otherwise get a ZeroDivisionError.

More information is here:
https://discourse.ladybug.tools/t/view-analysis-view-distance-and-direction-to-a-particular-building-facade/17778/2

Hello, today I installed ladybug-grasshopper with ladybug[+] on my Mac running Mojave. The process involved a little digging so I thought it might be helpful to list it here (or hopefully it may help in making a Mac installer at some point).

1. Download Honeybee[+] from Food4Rhino (it has Ladybug files too)
2. Install ghuser objects in user objects folder
3. In grasshopper run in a ghpython component

import sys
print sys.path

The component will output a folder path which is where the python libs in Grasshopper are stored on Mac. In the output folder, drag the ladybug and honeybee folder from the Honeybee[+] download.
4. Download ladybug-rhino from GitHub
5. Install the ladybug-rhino folder in the location from step 3

The install so far throws no errors from EPW files, however the LadybugPlus_EPWmap component throws the following error when toggled to true

close_fds is not supported on .NET platforms

This shouldn't be that hard to reimplement given that the legacy code is not too long.

We are following a new standard for how we version components in honeybee-grasshopper, which you can see an example of here. We should bring all of the components in this repo in line with this standard as part of the next release.

Hi,
As per this discussion i think it will be nice to let differentiate the different tabs:
https://discourse.ladybug.tools/t/compare-energy-legacy-vs-workflow/10339/13
Thanks,
-A.

In light of having the flexibility to use the Grasshopper component as the base for other platforms I think we should not call ghenv methods directly from inside the component.

I suggest to keep all of them in a single module that can be reused among different components.

For example this one can be translated to a turn_off_output_preview method similar to the functions that we use to check the component inputs.

Hello!

I found a bug when trying to input the "north_" parameter into the "HumanToSky" component.

This bug is fixed by importing the following:

import math
from ladybug_rhino.togeometry import to_vector2d

I attached a .gh file with both the broken component and the fixed component.

BugReportLadybug.zip

It would be great if there was a way to generate a colored shading mask with Ladybug. Where we could assign a group of colors to each building of the context, and those colors be used in the shadow mask. This would really help to differentiate the shadows from each building.

Like this example:

The fact that the EPWmap component does not work on Mac is not all that surprising since it's using a number of DotNet-specific commands. However, @lsh has tested this and knows exactly what the error is, meaning we might be able to fix it. According to @lsh :

The install so far throws no errors from EPW files, however the LadybugPlus_EPWmap component throws the following error when toggled to true

close_fds is not supported on .NET platforms

@lsh, could you elaborate on the error message a bit more, letting us know what line it is occurring on?

Hi, I did a quick search in the forum but did not find anyone reporting this after the recent release so putting here as I think this may be a small coding issue.

The LB versioner component is giving me a error on python path. As I don't think the latest release (0.0.6 installer.gh) is installing python into this location, this could be solved by giving a user input for python path.

I noticed the versioner will install HB, HB-Radiance, HB-Radiance, but the necessary libraries (scripts\honeybee, honeybee_energy, honerbee_radaince, honerbee_standard) are not installed at the same time. The Legacy updaters, HB+ installer are not installing those libraries either.

It seems like this was a well-loved component of legacy Ladybug that we should port over to the LBT plugin sooner than later.

More information is here:
https://discourse.ladybug.tools/t/comparison-between-reflected-sun-beam-and-potential-glare-from-mirrored-surface/18238/3?u=chris

It seems that using subprocess.PIPE can be dangerous on Windows machines:
https://stackoverflow.com/questions/5069224/handling-subprocess-crash-in-windows

.... and this is causing a crash of Rhino on some machines:
https://discourse.ladybug.tools/t/ladybug-cumulative-sky-matrix-crashes-gh-and-rhino-without-crash-report/15648

We should try to find a workaround for this in the "LB Cumulative Sky Matrix" first. If the solution works well, we can roll it out to the other places where we are currently using subprocess.PIPE on Windows.

This is a proposal for all the Ladybug Tools plugins but I think we should start with Ladybug. There are a number of components, I can remember sunpath for one, that take the hour of the year as an input which works fine for hourly workflow but is not the best option when it comes to sub-hourly set-up. We end up with strange float numbers that we have to translate back and forth to minutes or datetime.

My proposal is to use minute of the year or datetime instead. Minute of the year will be the most efficient and datetime will be the most readable option.

What are your thoughts on this @chriswmackey?

This will be a major breaking change that we should do at the next release. This will involve isolating the parts of this repo just related to Grasshopper (src and user_objects) and putting them into a folder entitled ladybug_grasshopper. We can also add a samples folder that contains a set of sample test files.

Take it easy on lack of [+] libraries for now which can be addressed in the next round.

Hi there,

As it is noted in the comments to "Import EPW" component, if Horizontal infrared radiation intensity data is missing in the climate file it will be written as 9999. Currently, the components using the Horizontal infrared radiation do not check for missing data (i.e. 9999) and reading it as 9999 W/m2. Obviously, this makes all the results, which take into account Horizontal infrared radiation incorrect.

I came across this problem while calculating Mean Radiant Temperature with LB Outdoor Solar MRT component (just got incorrect results) and I was not able to run the DF Run Urban Weather Generator at all.

Even though the problem can be fixed with generating the missing values with DF Horizontal Infrared component, it would be great to add automatic checks for the missing Horizontal infrared radiation data and generate reports indicating this issue.

Cheers,
Dmitry

I am not sure if this is a bug or I am expecting a different functionality, but in when filtering data through the TimeOp the a_period field of the _header does not change. As a consequence, when I try to do some numeric manipulation and then reconstruct the data I cannot.

In honeybee_grasshopper, we have been following a good practice of importing different libraries in different try/except loops, giving a different warning for each library. I can see that this will probably be very helpful to debugging issues in the future, especially when we end up adding new extensions, which people may be missing. We should do the same here and separate the importing of ladybug, ladybug_rhino, ladybug_dotnet and ladybug_comfort into different try/excepts.

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

The hourly plot component currently only support annual hourly data. Will be nice to add support for monthly data collections too.

The AdaptiveParameter property ashrae_or_en was recently renamed to that from ashrae55_or_en15251, but the Grasshopper Adaptive component was not updated to use the new name, leading to an error in Grasshopper:

It should include base geometry (point, line, curve, sphere), and also colors to get the first MVP out.

@mostaphaRoudsari has written a new exporter component that helps us enforce our new versioning system. Before the next release, we should give this component an icon and add it to the plugin here.

@chriswmackey

@kelsworth found what looks like a bug in the LB Unit Converter component, and also possibly in the way the ladybug.datatypes.UNITS dictionary is being defined.

As you can see in the image below, the all_u output doesn't list the ClothingInsulation data type at all, and the clo unit is listed as part of the units for RValue. And the LB PMV Comfort component fails to read clo values unless it is defined as a ClothingInsulation data type.