Announcement: Wind Pressure Coefficients-Integrated Building Energy Modeling Workflow Launched!

Kia ora @Naga. No worries for the delay. My hope was that, as this was part of your thesis, then some outside assistance with Quality Assurance might be of assistance in progressing the thesis as well. I recognise that the system cannot in reality be a part of the actual research, it is a means to an end. However, I was concerned as much for the accuracy of your calculations as for the benefit to my students.

Thanks for the rapid response. I felt the need to re-look because I was hoping that the odd result would not have invalidated work already done, or caused a deep dive that was indicative of a thesis issue.

Look forward to you finding the time.

@MichaelDonn

Thank you for your thoughtful message, and I truly appreciate your concern regarding the reliability of the results.

I’d like to reassure you that the issue is not from the simulation workflow itself, but rather from the specific model inputs currently being used.

1. Window Operation Inputs Missing
The model appears to lack details regarding window operation schedules and control parameters. This omission can significantly influence the simulation outcome.

2. Wind Pressure Profiles
For most orientations in your current setup, the wind pressure values are negative. This implies airflow directionality away from the zone, contrary to what is typically assumed in standard modeling methods.

3. Discharge Coefficient Representation
While conventional methods often apply a constant discharge coefficient, our parametric approach uses orientation-specific values derived from CFD-based data. This distinction plays a crucial role in accurate air movement predictions.
(Conventional)


(Parametric approach)
image

4. Window Operation Assumptions
In the conventional model, windows are always open, which naturally leads to higher energy use. This contrasts with our model, which implements dynamic window operation based on indoor and outdoor conditions.

While ladybug-tools offers an intuitive GUI, its true strength lies in its capacity for detailed spatio-temporal analysis. This enables us to trace and interpret unexpected simulation results with precision. This analytical layer is always employed by us to ensure that every model is rigorously validated. Hence, I hope this addresses any concern regarding the integrity of the results within the thesis.

If you’d like to explore our methodology further, I highly recommend reviewing our recent publication article along with E+ Engineering Reference and Input Output Reference.

Kia ora @Naga

Thank you for your careful outlining of the differences that appear between your two models built into your demonstration script.

Apart from changing the geometry, and updating the version of LadyBug Tools, I was assuming that the two examples you showed in your workflow were only different in the application of the CFD estimates of wind pressures.

However, it would seem that there is more happening inside the calculations that you are performing than merely applying ventilation wind pressures.

I am sorry to keep bothering yoou, but, in order to understand this further, so I could describe the situation to my Masters students, I have dug into the actual differences between these two runs, and I am more deeply puzzled than before.

As I understand it, the model for the “Standard Simulation” is the exact same model that has been fed into your CFD analysis to create the. The difference between the Standard and the WPC Simulations can be seen in this screen capture

.

The base model that was fed into the Pressure Coefficient calculations is connected at the Blue boxes. Thus, it can be seen that for the standard simulation a basic AFN Airflow Network Component is added in (upper red dotted box, with base model connection at blue box). For the Integrated Simulation, the model is connected directly because the AFN AirfFlow Network description is part of the text string generated by your CFD calculations and connected at the red arrow.

Thus, there are two differences between the simulations

  1. addition of a very basic Air Flow Network definition, with basic default values, to the Standard Simulation that is not in the WPC Integrated simulation.
  2. addition of the airflow network definition with calculated wind pressures to the Integrated Simulation (arrowed entry) via an additional “text string”

So, to understand the two calculations better, I tried rearranging the inputs.

I tried

  1. just connecting the additional WPC text string to the standard simulation - crash, object naming issues

  2. bypassing the AFN definition for the Standard Simulation and connecting the WPC text string - outputs identical, as hoped for

  3. running the standard simulation as first set up in the workflow

  4. stripping out the wind pressures from the WPC text string file but leaving in the rest of your AFN text strings and connecting these to the add string input of the Standard Simulation

  5. disconnecting the AFN definition but leaving your WPC added string attached also with the Wind Pressure Coefficient data excluded for the Standard Simulation

What is striking to me is that 4) is using all the setpoint settings that you described that should be different and the energy use index is still far bigger than for the version with your full wind pressure data accounted for. This still seems strange to me in that the HEATING energy is so different, and that this is not cured by the addition of your AirFlow Network definition without the associated Wind Pressures .

m

Kia ora @Naga

I am really sorry to bother you again, but I have two questions:

1 is a curious situation. A model built from a series of faces (so we have ultimate control of the construction of each face), like this

When processed by a standard AFN component works just fine.

When it is processed by your Wind Pressure Coefficient processes, then the Zone names created by the new model are the individual face names, even though the rooms/zones have their own names.

Room names from the Model fed into your WPC components look like this.

Label created here:

BUT: in the E+ .idf file, the zone name is somehow derived from the surface

Creating this issue with the simulation:

Is this an indication that the WPC components cannot at present handle zones (HB_Rooms) made up of individual HB_Faces?

  1. I have the same issue with another similar Honeybee model where the student, to enable careful control over each individual element, has individually modelled and named the apertures… We have the same issue, the named individual apertures become the “duplicate” names of the zones in the WPC calculation

What is suspect is that the data handling within this component / cluster, needs work?

I should add that the datatree has a lot of null values

but the idf string looks OK at first glance

Note: I have refrained from sharing the model itself as it seems to me that possessing it would leave you down a deep rabbit hole trying to understand it. And it is not my model to share.

M

Kia ora @Naga,

@MichaelDonn and I were trying to use your Naga original workflow_v1.1_updated.gh (483.6 KB) to run our apartment model and understand the application of wind pressures. However, we encountered an AFN error stating that 2. ** Severe ** AirflowNetwork::Solver::get_input: AirflowNetwork:MultiZone:Surface object, Invalid Surface Name given = 3842_W1

To troubleshoot the issue, we went back to the basics and tested the workflow using a simple box model as a single zone. We identified several issues and hope to get some clarification from you or @chris.

Based on my script Naga workflow_HLK_QA4.gh (569.8 KB), we tried several approaches to model the zone (Opt 1–4). All models were valid except for Opt 4. However, even with the validated models in Opt 1–3, we consistently ran into problems assigning window geometry, unless we used the Apertures by Ratio component. We also attempted to combine Apertures by Ratio (set to 0%) with manually assigned window geometry (HB or Rhino geometry) to see whether this would resolve the issue.

In the end, only Opt 2 (with simplified brep) using Apertures by Ratio worked fully.

I’d appreciate any comments you may have on these issues.

Thank you.

-Hirda

I will look into the source code and see if they are any updates that is causing the bug.

Thank you for your prompt reply, Naga. I’d appreciate it and look forward to it.

can you share GH file compliant to Rhino 7 version?

Hi @Naga,

Thank you for getting back to me so quickly.

Here it is. I’m not entirely sure whether I converted the GH file correctly to make it compatible with the older version of Rhino. I’ve also attached the simple geometry for Opt 1 and Opt 2.

Naga workflow_HLK_QA4.gh (569.8 KB)
Simple geometry3_Rhino7.3dm (119.9 KB)

Hi @hirda_khalid ,

I tried opening v1.1 of my workflow and found few of native GH components expired. Moreover, the framework of AFN in new version of LB tools 1.9 is different to 1.7. Now, I understand why @MichaelDonn was having issues while simulation.

Please find the revised version of GH workflow at GitHub - EPDL-Technion/WPCs-integrated_BEM at eba3b18e009947afaa3710911d46d187c312611e.

This version is compatible with Rhino version 7.38 + LB tools 1.9 + Eddy 0.3.8 with BlueCFD 2017.2.0.0.

By next week, I will try to create workflow compatible with Rhino 8.

Kindly, let me know incase you are having any issue with your geometry.

Kia ora @Naga

Thank you SO much. (@hirda_khalid Hirda is in-transit from the Architectural Science Association conference in Australia)

Hirda and I have tried updating via sync the components to v1.9, and this SEEMED to reduce issues with the output from the locked clusters. But, your careful updating of these would be greatly welcomed, thank you.

As we are in the midst of a project looking at window efficacy, combining your work with the other flow visualisation capabilities of Patrick Kastner’s Eddy3D are providing critical input that will allow Hirda to focus on the window not the software… She has spent the past year focusing on building a model case study baseline using real hourly data on Temperature, Humidity, CO2 from low income housing apartments.

Regards

M

Hi @Naga

Thank you so much for your work on this.

I am just back from international travel so have just been able to run your revised version.

Looking at the error message below, I suspect there are version issues, as I am using version 8 of Rhino as well as version 1.9 of LBT.

If this is not the problem, please advise if you can interpret this as @MichaelDonn and I cannot understand it

Hi @hirda_khalid

RH 7 native components do not work in RH 8 version.

I need sometime to generate workflow in RH8 version. Can you try in RH 7?

Hi @Naga

Unfortunately , we have no access to Rhino 7 at the School. And, 12 months of Hirda’s thesis work has been on R8.

OMG. Then I will try to create the workflow in RH8 this weekend.

O my goodness. That is so kind.

Thank you.

M

Thank you, Naga. We appreciate your time and support!

Hi @hirda_khalid,

I had added workflow in GitHub that works with Rhino 8.

Please let me know incase of any issues. I will try to resolve it ASAP.

Actually RH07 workflow also worked for me, except for EDDY3D components, as they were of 0.3.8 version that only work with RH07 not RH08.

@chris, I would like to bring to your notice that honeybee_energy API is not being recognised by IronPython2 or Python3 components of RH08. For now, I used Python native string generation method to overcome this issue. Please let us know if there is going to be any update to address this issue.

Hi @Naga

FYI, I believe that Chris has said in the past that:

“…the earliest that you will see us move the Ladybug Tools components over to the new Script Editor (IronPython2 / Python3) is Rhino 9.”

you can see more discussion about this item over at: Scritping in R8, ironpython2 and python 3? - #4 by chris

all the best,
@edpmay

Hi @Naga ,

Thank you for your hard work. We really appreciate your time on this. Sorry for the delay, I ran into some errors at the beginning but managed to sort them out with @MichaelDonn yesterday. Now it’s fully working!

We just have one question, why are the panels hidden? We copied the inputs from your original workflow to run the script. I assume they have the same values as in the original version?

Kind regards,
Hirda