New Pedestrian Wind Comfort component

[stgeorges]

I am opening this topic due to suggestion by Mostapha at the Buttefly github discussion about the incoming Butterfly components.

This is a quote from the upper link:

@stgeorges: I would like to share a small Ladybug component: "Pedestrian wind comfort". Based on the wind factors it will perform an analysis of the wind comfort and safety of pedestrians at the location:

https://www.dropbox.com/s/qze418bv0ae5j74/pedestrianWindComfort.zip?dl=0

Independently from the Butterfly components it can import wind factors from any other cfd application (Ansys, Tecplot 360, SolidWorks...), but it is convenient as well to release it into the public as Butterfly components are closing to its release. I must mention my gratitude towards Dr. Liam Harrington for the help and advises in developing it

Here is a quote from @mostaphaRoudsari :

@stgeorges this look very nice. thanks for sharing! How does this differs from the one that @chriswmackey and @TheodoreGalanos are developing.

The "Pedestrian wind comfort" component uses the results of the cfd simulation to perform an analysis of the mechanical (wind) comfort, not thermal comfort:

Each comfort category corresponds to certain activity and purpose of the location. For example, the upper comfort category 2 (yellow color) would not be suitable for building entrances nor exits as the wind threshold in that area would be exceeded. If an architect has proposed an entrance at that point, certain objects need to be placed around it to mitigate the effect of the wind. The cfd simulation would then be repeated. Component's "pedestrianComfortCategory" output explains in detail each of comfort categories, and the purpose to which it corresponds. Hope this makes it more clear.

[chriswmackey]

@stgeorges ,

This looks is very awesome! Thanks for putting this together and we definitely need something in Butterfly that informs us of when the wind intensity of wind is too strong. Along these lines, I was wondering why you opened this issue on the Ladybug github instead of the Butterfly github. Especially given the fact that you are building up the categories from a wind factor file, this component seems much better fit in Butterfly.

Also, I have one suggestion with the comfort categories. The component descriptions are very clear about what the categories mean and I wonder if there should be one more category for cases where you really need the wind intensity to be low. For example, I know that paper will usually start to blow around at 1 m/s and this is the general rule of thumb that I have used to asses when indoor wind intensity is too great.

Finally, I have one request based on your post: I see that you are starting to put together a plugin diagram for Butterfly. Is there any chance that you can put what you have started into the Google Slides document that I shared with you that has the updated plugin diagrams for Ladybug + Honeybee? It seems that we might need a butterfly diagram for this upcoming release and it would be great to start from what you have.

-Chris

[chriswmackey]

Also, @stgeorges , You should send a pull request to the Butterfly github with this component when you get the chance. -Chris

[mostaphaRoudsari]

Thanks @stgeorges!

@chriswmackey @stgeorges I suggest to wait before sending the PR to butterfly. We should make sure that we have a guideline for development for butterfly before accepting new components.

[stgeorges]

Hi @chriswmackey , @mostaphaRoudsari

Along these lines, I was wondering why you opened this issue on the Ladybug github instead of the Butterfly github. Especially given the fact that you are building up the categories from a wind factor file, this component seems much better fit in Butterfly.

Even though the component is released now when the Butterfly project is coming near to its release, the wind factors do not need to be calculated by the use of Butterfly components. One can use Ansys, NX, Pro Engineer, SU2 ... Just as we are using Ladybug and Honeybee components to analyse the Thermal comfort based on cfd results wind speeds, we will be using this component to analyse the Mechanical comfort. So in my view the "Pedestriann wind comfort" component should not be a Butterfly component.

I wonder if there should be one more category for cases where you really need the wind intensity to be low. For example, I know that paper will usually start to blow around at 1 m/s and this is the general rule of thumb that I have used to asses when indoor wind intensity is too great.

The component is related to outdoor environments and indoor environments with opened apertures (overground garage for example). It should not be used for closed air motion spaces. I have no doubts that the possible future component that you will create for indoor spaces will be great!

Is there any chance that you can put what you have started into the Google Slides document that I shared with you that has the updated plugin diagrams for Ladybug + Honeybee?

I am ashamed to admit this, but I have never been using Google docs. I duplicated your Ladybug slide and tried to edit it with Butterfly pictures. Not sure if I did everything correctly. I apologize for the ignorance. I sent you the link to your gmail account too.

[chriswmackey]

@stgeorges and @mostaphaRoudsari ,

To run down the list of discussion topics:

1) Should the wind comfort component be in Ladybug or in Butterfly? - I think many of us agree that the litmus test for whether something should be in Ladybug is whether you can use the component directly with EPW data. From what I have seen with the current wind comfort component, it is reliant on some type of CFD data to give a spatial map of wind factors (whether this is OpenFoam, Ansys, etc.). As such, I would say that this specific component is built for integration with a CFD plugin like Butterfly instead of an EPW plugin like Ladybug. This is not to say that we could have a mechanical wind comfort component for Ladybug but such a component should be optimized to accept EPW data or be flexible enough to accept both temporal or spatial data like the Ladybug thermal comfort components.

2) When should Butterfly be able to accept pull requests? - I agree, @mostaphaRoudsari , that we at least need to decide on categories of Butterfly components before accepting pull requests. Mostapha, you are presently the most qualified to do this and I defer to your judgement when you think the time is ready. Whatever we decide on, it should be sensitive to the applications of CFD that we have in mind (as per the Butterfly plugin diagram).

3) How should we go about building the plugin diagrams? - Thank you, @stgeorges , for sharing your work on the Butterfly diagram thus far. I had also not used Google slides before Mostapha opened my eyes to it. For the sake of our sanity, I think it's best if we focus on editing only one slides file. This is the original one I had started: https://docs.google.com/presentation/d/1e_XmZj31HTAKlYL0SCmzD8q2hmjLXSnKVHeBBrw8rpw/edit?usp=sharing I added in your work, @stgeorges , after adjusting it to follow the conventions of the other diagrams. I also added a slide that outlines the plan for Dragonfly (only half of the capabilities listed have been implemented so far). Please feel free to edit and comment on these slides (I see them evolving as the plugins become more defined) and let me know if you agree with this strategy for plugin diagram making.

-Chris

[stgeorges]

1) Should the wind comfort component be in Ladybug or in Butterfly?

Fair enough. I will change the header of the component once the rest of the Butterfly components start getting released.

I added in your work, @stgeorges , after adjusting it to follow the conventions of the other diagrams. I also added a slide that outlines the plan for Dragonfly (only half of the capabilities listed have been implemented so far). Please feel free to edit and comment on these slides (I see them evolving as the plugins become more defined) and let me know if you agree with this strategy for plugin diagram making.

New slide was opened as a means of not spoiling yours due to my inexperience with Google docs. I am not sure if ".epw" block should have been removed from the "Butterfly" slide. After all, we are relying on cfd simulation to correct the actual weather file wind speeds for particular directions.

Are you the author of the new Butterfly logo? I can see the similar concept in all four logos, where Butterfly logo resembles the wind rose.

[mostaphaRoudsari]

About the slides: I think we need to be crystal clear on which part is already developed, which part is under development, and which part will be developed in the near future. The current graph is a couple of years ahead of what we have right now on Dynamo/Revit side!

Butterfly components needs to be developed in a different way. It's not only about the header. Let's have them all in Ladybug for now and once we are ready we will discuss the details about moving the components around.

[stgeorges]

About the slides: I think we need to be crystal clear on which part is already developed, which part is under development, and which part will be developed in the near future. The current graph is a couple of years ahead of what we have right now on Dynamo/Revit side!

Maybe this can be done by putting the transparency onto the icons/text as a means of depicting the future development, and transparency with a star to inform the users that the development is currently ongoing. Then at the bottom corner, there can be a small legend with mentioned explanations?

Butterfly components needs to be developed in a different way. It's not only about the header.

I am curious to know more about this, even though they are still not released. Can you be a bit more precise, please?

Let's have them all in Ladybug for now and once we are ready we will discuss the details about moving the components around.

Got it.

[mostaphaRoudsari]

I am curious to know more about this, even though they are still not released. Can you be a bit more precise, please?

Check this file.

[stgeorges]

Thank you Mostapha. I am not sure I understand what the file does. It crashed my Rhino 5 even though I increased the gridSize inputs (it could be just an issue with my PC. Due to heat it's not working properly). Can you explain in words on what the development difference between the butterfly and ladybug components will be? I noticed that the analysis mesh generation and resultMesh will not be a part of the actual components any more, but separate ones. What else?

[mostaphaRoudsari]

@stgeorges, I will write a separate post for developers later. It's more than one or two paragraphs. I will do it after the next release when I have more examples to share.

[chriswmackey]

@mostaphaRoudsari and @stgeorges ,

I know that the slides were far ahead of the project and, as per your suggestion Mostapha, I have created both a "Present" and "Future" set of plugin diagrams in the presentation. I think that having two versions of the slides is necessary because it is not simply that new features are being added but that Daysim will be replaced with the 2-phase work of @mostaphaRoudsari and @sariths , the direct connection to EnergyPlus will be dropped to have everyone interact through OpenStuido, etc.

Also, I'm sorry that we haven't filled you in on the revision of the code that is starting to happen now, Djordje. Mostapha is essentially referring to the fact that all of the code across LB+HB+BF is going to be cleaned up into a new format over the next few months. Mostapha's developer post will be more informative than what I can say now but the biggest change is that the new version will require the installation of Python 2.7, which will enable us to keep the majority of the code in well-documented standalone .py files that are independent of any specific platform like Grasshopper or Dynamo. It will also free us from the limitations of GHPython and IronPython (being able to use all of the modules in Python 2.7). I know that Mostapha will post more at the next stable release in a few weeks. Stay tuned.

-Chris

[sariths]

@chriswmackey and @mostaphaRoudsari , I had a question. If the new Honeybee scripts are being invoked through Revit or Rhino aren't we still constrained by the limitations of IronPython? If we call these scripts through sys.path.append I think the scripts will run on whatever flavor of Python that called them instead of Python 2.7.

[stgeorges]

Also, I'm sorry that we haven't filled you in on the revision of the code that is starting to happen now, Djordje. Mostapha is essentially referring to the fact that all of the code across LB+HB+BF is going to be cleaned up into a new format over the next few months.

I feel a bit left over. In a sense of being informed, not contributing. I am aware of Mostapha's ladybug analysis tools project, but I did not know other developer(s) have already been acquainted about the future changes. I will wait for that Mostapha's future post.

[chriswmackey]

@sariths , Good point. I don't know what flavor of Python we are going to suggest that users run as I know it has been left flexible up to this point. Mostapha will probably make a decision of whether it's better to make users install an official version of python (like 2.7 or 3.-) or whether we should just have a hierarchy of installed Python versions. In this latter case, we could search for any Python versions through PATH and, if we can't find anything official, we just use the ironPython that installs with GH/Dynamo. This would require a check on any component that uses modules that are not in ironPython, though. I have been itching to use the XML parsing module in the non-iron Python versions so I can say that I would definitely need such check for some of the things I am planning to develop.

@stgeorges , To be clear, none of us have a complete picture of what the next version is going to look like. Not even Mostapha yet and that is why he said he would send us all a post when he's figured it out. I should have said that I was describing was an example of how the development might be different as I can't say that I know exactly what will happen.

-Chris

[mostaphaRoudsari]

I suggest not to continue this conversation here. This issue is for New Pedestrian Wind Comfort component and not where the development is going. As I promised I will write full notes about the new structure once we release the new versions. Until then we will follow the current structure for ladybug and honeybee development. Thanks!

[stgeorges]

Ok.

[TheodoreGalanos]

@stgeorges

Hello! I was testing this component on a case I'm preparing lately and I had a few issues that I wanted to share.

First it seems as that the component is a bit heavy as more inputs are connected to it. Since it's going to be used with files that have a few million numbers I was wondering if there is a way to optimize this. Unfortunately, I can't really help here.

Another thing I noticed is the mesh input for the analysis geometry. Now, I fully understand that this component is intended to be used with multiple CFD software and data but I was wondering if I can ask a kind of OpenFOAM favor here :) In OF, at least in the usual way of extracting information during post process, we extract point files from paraview with a bunch of information for each point of the calculation surface that was used. I was wondering if it is possible to allow a point input in the component as well.

At least for paraview, the process to extract data as .stl file (mesh file) would get tricky, with a small pipeline of extract surface and triangulate filters involved (haven't tried it just guessing). Allowing the point input simplifies the process a lot as "save data" as points takes literally 1 second.

Finally, in order to bypass this and use point data that I had for a case, I tried creating a mesh from my points and then culled the extra cells (it seems to be hard to get the same face number as points in the simple native definition I made). I then plugged that mesh in the component. The component accepted it (no error of faces/wind factors don't match came up) but after I run it I got a "object cannot be interpreted as an index" error. I wonder if you know what this error means. I mean I'm 99% sure I'm creating it due to the awkward way I'm using the component.

Thanks for the great work! Can't wait to use this component in my studies :)

Kind regards, Theodore.

[stgeorges]

Hi @TheodoreGalanos,

Since it's going to be used with files that have a few million numbers I was wondering if there is a way to optimize this. Unfortunately, I can't really help here.

The multithread function is actually simple: it takes a list and a function name. Then assigns each item from the list to a thread which then performs the task on the function. This can be very convenient when one has a couple of variables, and a list. The problem starts when there are a couple of lists, like in case of Pedestrian wind comfort component, where we use hourly wind speed, wind direction values and hours of year. In that case one workaround would be to supply the multithread function with a list of lists, and then unpack it inside. This can stultify the whole process and result with similar run times as with a regular function. I opened a new topic on this issue at Rhino forum. I tried just that last night, and got similar run times as with current component. Let me try in the next few days how much will list comprehensions or packing some of the code into additional functions, have an effect on its run time. In general I tend to avoid list comprehensions with nested loops due to future issues with debugging.

I was wondering if it is possible to allow a point input in the component as well.

It depends. Will those points be centroids of the mesh faces, or mesh vertices?

Finally, in order to bypass this and use point data that I had for a case, I tried creating a mesh from my points and then culled the extra cells (it seems to be hard to get the same face number as points in the simple native definition I made). I then plugged that mesh in the component. The component accepted it (no error of faces/wind factors don't match came up) but after I run it I got a "object cannot be interpreted as an index" error. I wonder if you know what this error means. I mean I'm 99% sure I'm creating it due to the awkward way I'm using the component.

Internalize the points from which you made that mesh and supplied it to the _analysisGeometry input. And attach the .gh file along with WindFactors.csv file. Thank you.

[chriswmackey]

@stgeorges ,

Given that we came to the realization that Butterfly won't be released with full public support for a while, please send a pull request of your component to Ladybug when you get the chance. Ideally, it would be great to have this for the next release in a day or two. Let's put the component under WIP for the time being but I imagine that we can move it out soon and eventually move it over to Butterfly when the time comes.

-Chris

[stgeorges]

I added the .py and .ghuser files in this pull request.

[chriswmackey]

I merged it in and all is looking great. I think you win the award for best component icon with this one :)

I am going to close out this issue now that things are settled for the present. In the future, I imagine that we can continue discussion on the Butterfly github when the time comes.

[stgeorges]

Ok. Thank you.

[stgeorges]

Hi @TheodoreGalanos , Pedestrian wind comfort component got slightly quicker today. I realized we never checked the message you reported. Is it possible that you attach your .gh example file, along with WindFactors.csv file, please?