Error with wind simulation when adding awning window panes

Hello everyone

I am having trouble when simulating corner windflow of an office space in a third floor. It has awning windows and louvered shading devices on top and bottom parts of the EAST windows as it can be seen in the snapshot.

When I simulate the case it gives odd results

If I remove the awning window panes then the results seem normal. Is it just not possible to simulate obstructions like this?

I am attaching my grasshopper definition in case you could take a look.
Thank you!
AirflowRUN.gh (485.1 KB)

1 Like

Hi,
LUISARTUROREYESVALEN
It works for me when I added a test srf for probes.

find attached : Error with wind simulation when adding awning window panes_OMD.gh (480.4 KB)

best,
Omid.

2 Likes

Than you very much for your response OmidmRashidi. I´ll check your file at the office. One more thing. Do you know how I can convert this results to Air Changes per Hour ACH?

Thanks again.
Arturo

1 Like

Hi @LUISARTUROREYESVALEN

There is an OF function object that you can use to calculate average values of fields over patches. Assuming the windows are your inlet patch, you can write the following in the OF terminal (make sure to change inlet to the name of your inlet):

postProcess -func “patchAverage(U,name=inlet)”

To navigate to your case through the terminal you should do the following command:

cd workingDir/butterfly/YourCaseNameHere

The result of the function object will be the average velocity over the windows. You can then multiply that to their area to find your m3/s. That, along with the total volume of the room, should allow you to calculate your ACH.

Bare in mind this might not be the most accurate way but it certainly is the fastest. Other ways include function objects that calculate fields taking into account normal direction (so no outflow), weighted averages, etc.

Hope this helps!

P.S.: There is a chance this gives you a vector (can’t recall), transform it to scalar to continue your calculations.

Kind regards,
Theodore.

2 Likes

@TheodorosGalanos @mostapha,
Calculating ACH will be something that a lot of people would be interested in. I would suggest having this part of a BF workflow in the future please.

3 Likes

Thank you very much @TheodorosGalanos

I managed to do the calculation as you kindly described. I am just trying to find a way to properly justify it for LEED documentation. As @devang says it would be really helpful having it as part of the BF workflow.

Thanks again. Best.
Arturo

hi @LUISARTUROREYESVALEN

I believe the way people are usually doing it is by calculating the pressure coefficients on the windows of each zone that you are simulating. Of course, that assumes closed windows while modelling for CFD simulations. Additionally, you would need a number of wind directions to be run in order to get a better image about the yearly wind conditions, coefficients, and ultimately potential of each opening.

Within openfoam there is a pressure function object that can be used to calculate Cp. If your setup includes closed windows as wall boundaries, you can experiment with it by supplying the following to the function object BF component and run your case for 1 more iteration (if already run):

pressure1
{
type pressure;
result test; //this should give you a reference name to call later
executeControl timeStep;
executeInterval 1;
writeControl writeTime;
libs (“libfieldFunctionObjects.so”);
calcTotal yes;
calcCoeff yes;
p p;
U U;
rho rhoInf;
pInf 100000;
UInf Uinf; //maybe try your input velocity @10m here. If unsure take this line out and see if it works
rhoInf 100000; // this is due to our incompressible set up
}

The above is something I have not tried myself, so let us know what happens if you do! After calculation the function object creates new volumetric data which you could access with other function objects like for example the patchAverage one described earlier:

postProcess -func “patchAverage(test_coeff,name=window)” //window can be the actual name of the window patches

All that said, I don’t see a reason why all the above cannot be calculated without pressure coefficients by using an internal/external model simulation set up that assumes, and indeed models, window openings as fully open. The same number of simulations can be run, and volumetric flow for each window (now an opening) can be calculated. That could be extrapolated, by running an adequate number of simulations, to yearly data in the same way pressure coefficients would or in the way we do it for outdoor thermal comfort. That would give us a sort of volumetric inflow schedule that could then be used to understand and calculate at which times NVP is adequate.

I imagine the reasons that this is not so popular are (1) most prescriptive calculations (e.g. ASHRAE) work with pressure coefficients and (2) it is more complicated as it requires detailed modelling of the interior of the zones. Unless there is something I’m missing, and would love to find out, this method is perfectly viable.

Hope some of this helps.

P.S.: I am hoping for some BF time in the near future so we can incorporate more of these things or develop models/definitions that work. Stay tuned.

Kind regards,
Theodore.

1 Like

Dear all,

Thanks for your solutions. I have read the suggestions, however I have been facing such problem at the moment. I tried simple vertical louvers on the facade., and I’d like to simulate the both indoor and outdoor CFD to see the potential of the airflow. However, the CFD vectors stay the same even I have been constantly changing the positions of the louvers.

Any help is appreciated.
Thanks!
Gunsu