Butterfly: outletBoundary component modification to model a case study

Hello to everyone.

I want to show you how I have modified the indoor airflow example to cover my need.

The experimental case study is an office with an area of about 42 m2 normally occupied by four users. The air exchange system used consists of 2 fans: one introduces fresh air into the office, the other discharges the exhaust air. Both units have no filter or heat recovery system. The average inlet/outlet air speed is equal to 2.0 m/s.

The model in Rhino is here below:

I have modified the Outlet boundary component considering a Velocity vector:

and changing the standard code of the outletBoundary component with that reported in the attached file.

Here below the results:

The pressure value [Pa] are the increment in relation to a base value (0 Pa = 0 atm) because I have not assigned a value of pressure in the outletBoundary Componet and the default value is 0, it’s correct?

Comments and suggestion are welcome

PS:

maybe in the samplefiles folder of the downloaded Butterly zip there is an error: a fixed value (273.15), that I think is related to the conversion of temperature from Kelvin to Celsius, is subtracted to the pressure values of the “p” field

script_out_bound_butterfly_mod.txt (2.05 KB)

Hi Fransesco!

Thanks for sharing the example with us! Great job! And thanks for catching our mistake in the example file, it will be rectified shortly! The pressure is calculated based on the reference condition I believe, which yes usually this is 0. Bare in mind that OF divides pressure by density, so if you want the ‘real’ pressure you would need to multiply the results by 1.205 (perhaps we add this in BF at some point but it’s easy in native GH).

Vector based velocity is a very good idea, and a nice and easy way to model these kind of flows!

If you wish to experiment even further with the custom boundary condition components you can try implementing a flowRateInletVelocity boundary condition (see https://github.com/OpenFOAM/OpenFOAM-3.0.x/blob/master/src/finiteVo…)

It will allow you set the flows in m3/s, which is handy for usual HVAC specs. The direction of the patch follows the normal of the surface. Setting a minus in the volumetric flow rate assigns an opposite direction.

Thanks for using and sharing! Keep them coming!

Kind regards,

Theodore.

P.S.: Try this as an expirement. Increase the refinement of your mesh, factor of 4 should be nice. You can simply reduce the the blockMesh cell size by 4 to accomplish that. Try running the case and see the impact on the residual graph.

P.S.: Try this as an expirement. Increase the refinement of your mesh, factor of 4 should be nice. You can simply reduce the the blockMesh cell size by 4 to accomplish that. Try running the case and see the impact on the residual graph.

  1. how have you defined 4 as a “nice” factor?

  2. here below (sorry for the quality…) the residual graph with the blockMesh cell sized reduced by this factor:

Hi Fransesco,

I assumed you are working in meters and noticed that there were 2 cells per meter in your screenshots which is around 0.5m. For indoors, 0.1-0.2 is a good value so 4 times would get you there.

The pressure plot you shared above, it seems like your cell size varies, are you using any gradient options in the blockMesh step? In this example there’d be no need, as all areas are equally important.

If I can see correctly (colors are missing :slight_smile: ), the impact of mesh quality is already evident. If you compare the two residual plots, the first shows a case that is not converged and seems to be ‘stuck in a bad place’ where the residuals pulse around a min and max range without decreasing. The second shows the typical pattern of a converging case where residuals steadily decrease.

Kind regards,

Theodore.

Hi Theodore,

sorry for the delay in responding.

I assumed you are working in meters and noticed that there were 2 cells per meter in your screenshots which is around 0.5m. For indoors, 0.1-0.2 is a good value so 4 times would get you there.

Ok. I understood. You have to consider that the mesh displayed is generated by genTestPoints component where the grid size is effectively 0.5m:

The pressure plot you shared above, it seems like your cell size varies, are you using any gradient options in the blockMesh step? In this example there’d be no need, as all areas are equally important.

The pressure plot varies because I have modified the cell grid size of the meshParams component in (0.25, 0.25, 0.25):

Now, I have re-uploaded the basic values of (1,1,1) and modified the cell size in the blockmesh component as you suggested in the previous post:

As cell size by default, this component considers the length/5. So, in this case, there would be a cell size of about (1.5, 1.1, 0.6). It’s correct? But If I display the mesh with load mesh component connected to the case output of the snappyhexmesh component, I find this:

With a cell size of (0.25, 0.25, 0.25) as modified in the screenshot of the blockmesh component reported above, the mesh is extremely dense:

The residuals decrease:

with a more clear image.

Regards,

Francesco

@Francesco661

I am trying to replicate your work on version 0.0.05.
I am trying to have a small building with an inlet that moves a vol_flow_rate of air and 2 outlets that divide the airflow. This outlets are exhaustion-vents one sucks 20% of the air flow and the other 80%.
I’ve copied your component into the my project, but the wind speeds don’t look accurate.
Have you manage to upgrade you component to the current version?

I am kinda new to Butterfly.
Any help is welcome.