U-Value - construction list in Grashoper for PHPP

Hello everyone!

I am working on automating calculations from Grasshopper to PHPP.

I want to create a scheme that I can input from Rhino, creating a model with separated constructions. Some models have few constructions separated, while others have many, up to 40 types. For each separated construction, the material thicknesses, the materials themselves, and ultimately the U-value change.

I want to create a scheme where I can input these separated constructions from the Rhino model’s layer section into Grasshopper, as well as describe the materials, material thickness and thermal conductivity for these constructions, so that the U-values are automatically entered into the PHPP U-value sheet section and calculated.

Maybe someone has already created something like this and can help?

Thank you!

@Ervins there is a whole suite of passive house tools both PHI and PHIUS found here with the accompanying tutorials here these tools can take a hb model and data and put in in the PHPP or WUFI.
But you can get the U-value of constructions with the HB Deconstruct Construction component


Hopefully something of that was helpful
-trevor

Hi @Ervins

I have never set up a Rhino scene that way, but sounds interesting. So are you saying that you wish to model the assembly layers as Rhino objects somehow so that you can get thickness from them? Not sure I fully understand? Perhaps you can explain a bit more about your desired behavior in this case?


As far as the HBPH package, it includes a few things relevant to Constructions to consider:

  1. The HBPH package will take any Honeybee-Energy Construction and convert it to PHPP layers. Each Material in the Construction will become one layer in the PHPP U-Value.

  2. The HBPH package also includes a new component for building ‘mixed’ layers (ie: timber stud + insulation) in the PHPP manner as well. This component is used to create a new ‘mixed’ HB-Energy Layer which can then be used as part of an assembly. This should output the details ‘sections’ to PHPP in the end.

  3. HBPH also has a new component for the specific purpose of creating ‘stud-wall’ assemblies, which allows you to also input top and bottom plate values, and has some built-in defaults for wood materials.

Note that both of the above will also create a preview geometry view in the Rhino scene (Top-View, at world 0,0,0) so you can see what the construction build-up looks like.


Hopefully those are helpful.

all the best,
@edpmay

Hi @edpmay,

My idea is to create a model where the types of constructions are separated in the model. The structure differs due to different types of materials, thickness, whether they come into contact with the ground, whether the facade has an air gap or not; all of these factors ultimately affect the U-value calculation in PHPP.
These constructions are differentiated in the Rhino layer section. Next, I want to put them in grasshoper so that they are automatically assembled on the PHPP U-value, areas, page.

Here’s a look at how we do it using Sketchup.
We create a model, then we manually manage these structures in the PHPP U-value section and calculate them, then on the areas page we manually enter the square meter from sketchup.

I want to automate all this with the help of Rhino and grasshoper

image

Oh - I see, yes that makes sense. So you want to assign constructions based on a ‘type’ or tag applied to the surface in Rhino?

This probably best done using the Pollination Rhino Tool which allows you to manage and assign these types of attributes within Rhino.

Another solution would be to use something like ‘Materials’ in Rhino to assign or ‘tag’ the surfaces, and then lookup these values in Grasshopper from some library of constructions. Rhino does not yet support full ‘tagging’, though it looks like maybe they are getting closer. So for now we often use Rhino-Materials as a proxy ‘tag’ since they can work on both surfaces and Brep subfaces. (We use the material name to lookup in a library/search)

We added a component to HBPH+ which automatically reads in the Brep subface material names for just this purpose:

which might help do what you need? I prefer to work with closed-breps for room geometry rather than single faces, but certainly single faces with materials assigned is a simpler solution that would also do the same thing. You could use the new Rhino-8 Model-Object tools to read in that information and lookup your construction in a library.

2 Likes

Thank you very much for the suggestion. It looks like a good way to solve this.

Hello @edpmay and everyone!

Another day, another question.

Is there a way to organize the types of constructions in Grasshopper for PHPP? The problem is that Grasshopper reads each plane individually and enters it into the PHPP area sheet, further dividing it by orientation. In the end, this creates many sections (see the image below). Is it possible to write a script in Grasshopper so that these identical planes are combined, and then divided only by orientation? For example, in the model, there are two types of floors that are divided into four planes, but I want the PHPP area sheet to understand that the square meters of these identical planes can be combined and left as two types.



The second question would be why the program places windows on the same plane, facing the same direction, even when they are positioned in different directions? It recognizes the walls!


Hi @Ervins

That is a good question: in principle yes it is possible to add the ability to ‘merge’ surfaces together in the way you describe. We have implemented this already for WUFI-Passive and something similar could be done for PHPP I would think.

It is certainly possible to filter and collect surfaces that have the same orientation (normal direction), are co-planar, and have the same construction-type and then get their area information as a single value.

I think the core issue is that if we ‘merge’ multiple surfaces in that manner, it becomes impossible to track the surfaces or align them between PHPP and Grasshopper after the write operation is complete. So especially for ‘Certified’ projects this is a problem as the names of the surfaces in PHPP and the names of the surfaces in Grasshopper would no longer align after this ‘merge’. We generate ‘key’ elevations from Rhino (PDFs) which have all the surface names and info which are provided along with the PHPP for Certification review - so it is important that they match exactly for this review to be executed.

There would be no way to name the new ‘merged’ surface in an automated manner either, so I think the naming/id would end up being a challenge?


For your question about windows - this is related to the above: note that all surfaces in the Areas worksheet must have a unique name for HBPH to work properly. The error you are seeing is because in the example all the surfaces have the same name; and so there is no way to then determine which surface is the proper host for the window. Unfortunately PHPP does not have any mechanism to track or manage which surface is which aside from it’s display-name - so the display-name is an important ‘key’ which is used in several places to sort and id surfaces. You should ensure that your surface names are unique to avoid this window hosting issue.

By default Honeybee will assign a unique name to all surfaces, and so if you let these names stay assigned it should work properly for the window hosting. If you don’t want those random-string names then just be sure your manually-assigned names are unique.

all the best,
@edpmay