ladybug-tools / butterfly

:butterfly: A light python API for creating and running OpenFoam cases for CFD simulation.
http://ladybug-tools.github.io/butterfly.html
GNU General Public License v3.0
249 stars 71 forks source link

Tailor Wind Tunnel to Landscape #105

Open MaxMarschall opened 7 years ago

MaxMarschall commented 7 years ago

Hello,

I would like my wind tunnel to be of the same (or smaller) length and width of the terrain that I modeled. I would expect this to be the case if I inputted the landscape as BF Geometry and set the wind tunnel parameters as follows: par

However it comes out like this: wt

It is slightly bigger, which would be problematic in the simulation, right? How exactly are the parameters calculated? It seems that I would have to enter 0 as parameters, however that throws an error.

Regards, Max

TheodoreGalanos commented 7 years ago

Hi @MaxMarschall

There are a number of ways you can do this. The easiest way to do this is to have almost like two BF definitions.

The first definition is the one you already have. You only use this definition to allow BF to export one .stl file containing both the buildings and the terrain, along with the case folder. You should keep everything apart from the blockMeshDict file from this folder.

The second definition should only have the buildings connected as BF Geometries to the wind tunnel component. In this way the wind tunnel extensions would now be multiples of the building max height which is much smaller than the terrain and extend from the edge of the building's bounding box and not the landscape's. Playing with the sliders would give you the tunnel you wish. This definition would give you another case folder, from which you only take the blockMeshDict.

Note: Remeber to have different case names in the two parts of the definition so that they won't override themselves!

If you then paste the blockMeshDict to your first case folder everything should run correctly. Unfortunately I'm not in the computer to test and I'm pretty sure this would require you running the case manually after this point so that BF won't override your files. I will check tomorrow to see if the new workflow of running everything at the solution component allows us to do this through BF.

Just to add a small note here. If your plan is to have the wind tunnel encapsulate the terrain right at its boundaries then you can instead transform this case into an 'internal' case. Your 'room' would then be the bounding box of the terrain (easily generated through Rhino or GH) with its top side extended as high as you wish.

Sorry a bit too late for a really intelligent answer. I'm sure there is a better way and I can find it tomorrow. If you want you can share the geometries with me and I can send over the OF case if you have problems creating it.

Good luck!

Kind regards, Theodore.

MaxMarschall commented 7 years ago

Dear @TheodoreGalanos,

Thanks for your help. That does sound like an option although of course it would be great if there were another way.

Also, do you think there could be the opportunity for a more direct definition of the wind tunnel generally? Specifying the multiplying factor of the height (or largest dimension?) of the geometries' bounding box as the gaps between bounding box and wind tunnel seems a bit cumbersome, as opposed to for instance specifying it in meters. Like I said I'm new to CFD and maybe there is a particular reason for this?

Please find attached my model, of course it would be incredibly helpful if you could try to run that for me! 161110_Test.zip

The latest problem I'm having is that the mesh completely regular...no refinement. Would be good to know your explanation for this. mesh

Best, Max

mostaphaRoudsari commented 7 years ago

You will be able to change the ground for the wind tunnel once we address #77.

The size of the wind tunnel is set based on the maximum heights of your model which is a common practice for setting up the wind tunnel size. I can add the functionality to overwrite the vertices using the API. Currently they are read-only.

mostaphaRoudsari commented 7 years ago

Now that I read this again this is a different issue! We can add a new component to set-up the size based on X, Y, Z size and origin.

TheodoreGalanos commented 7 years ago

@mostaphaRoudsari yes I think that would solve this. It would actually be the 'default' openfoam way to do things in OpenFOAM.

Another way to deal with this is to get the bounding box of the convex landscape and use its bounding box for the X and Y extensions. The user can then set the Z extensions him/her self. I say this because due to the way SHM deals with meshing convex landscape surfaces, most if not all the times I have done this I have sized my domain around the surface and vice versa.

But ofc this is something the user can do easily in GH and we still retain the full manual description of the domain the way you describe it.

Kind regards, Theodore.

Zarisu commented 7 years ago

Hey guys,

I have an additional question about tailoring wind tunnel to terrain. I have successfully done so in GH, by taking the section of the terrain which corresponds to domain size chosen. When the inlet profile is determined by the ABL inlet profile (atmBoundaryLayerInletVelocity), the difference in terrain height lead to wrong inlet velocities.

The attached Figures show that the velocity is simulated correctly at the lowest point of the terrain (red), which is not the case for the left side (green).

Does anyone have knowledge of how to solve this problem?

Best Regards Zarisu terrain_error

TheodoreGalanos commented 7 years ago

Hi @Zarisu

It's hard to tell from the picture and the scale of the graphs but I feel there isn't anything wrong going on here.

The ABL profile in OF depends on three parameters only: the z minimum (which in your case should be at the bottom of the red line), the reference height, and the velocity at that reference height. With this information OF assigns velocities to the inlet according to the height of each cell.

Now in your inlet, the lowest point of the green side should exhibit higher wind velocities than the lowest point of the red side, since it is higher (the 0 in both graphs is misleading in this case). Unless you calculated the wind velocity with a common origin (the black arrows), then this should be okay or at least looks sensible.

Kind regards, Theodore.

mostaphaRoudsari commented 7 years ago

I'm not sure how your case is set but in case you're using Butterfly make sure the z minimum is not set to 0 by default: https://github.com/ladybug-tools/butterfly/blob/master/butterfly/conditions.py#L39

Zarisu commented 7 years ago

Thanks for the answer @TheodoreGalanos, I am sorry that the picture isn't that explaining. However, you fully understood my question,

Is there a way to calculated the wind velocity with a common origin? Such that velocity at 10 meters height relative to the ground is the same.

And thnks @mostaphaRoudsari, the z_ground is set to the lowest point :)

Senserily yours Zarisu

TheodoreGalanos commented 7 years ago

Hi @Zarisu I think OF does that by default. This means that it calculates wind velocity, at all heights, based on the z minimum value you input in the ABL conditions, your reference height+velocity, and the specific height at each point of the mesh. So the common origin is the z minimum in a way.

Now for your mesh, 10 meters above the ground on the right is actually z=10m, whereas 10m above the ground on the left is probably somewhere around 40-50m. There is no way, afaik, to set the same wind velocity at these two different heights using an ABL profile. But in all honestly you wouldn't want to, it's physically correct to get higher wind velocities on the green line.

Kind regards, Theodore.