Do not remove geometry with BLOCK_WIND=.TRUE. holes.

[bwklein]

The request is to use the BLOCK_WIND=.TRUE. parameter to ignore the WIND influence, but do not remove OBST that are inside of the HOLE volume. The partial workaround now is to go through the model and set all the OBST to not permit holes, but there are some obstructions inside the model that we do want holes in later. There is not a way to be specific about which hole to allow and which one to not permit.

Would it be better to use INIT, WIND, or some other namelist group/parameter to specify the volume to block wind instead of Holes?

[mcgratta]

BLOCK_WIND is going away. As you can see, it was awkward to apply. In the current source code, wind boundary conditions are applied at external boundaries, as opposed to being "forced" internally, so there is no more need for this parameter. That being said, the only work around would be to either use the "wall of wind" approach, or the FORCE_VECTOR approach.

[bwklein]

In the new code, for WIND would you run a simulation to let the flow field develop in the entire domain from the boundary sources and then use that velocity field as input to subsequent simulations with the CSVF input? It seems that it won't apply a wind field at time zero through the entire domain. I am curious more about the expected 'workflow' when building a model with the new code.

[mcgratta]

In the new code, one would specify

&WIND SPEED=5, DIRECTION=134 /

and the flow would initial to that flow field. At the inflow boundaries, the model would continuously drive the flow vector towards the desired speed and direction. This is similar to how things work now, but we no longer explicitly force towards the mean flow at internal cells. We only force things at incoming boundaries.

[bwklein]

"... and the flow would initial to that flow field."

So, how would you blank out cells in the initialization step to not put the wind flow inside of a building for example?

Best Regards, -Bryan Klein klein@thunderheadeng.com Product Manager, PyroSim/Pathfinder Thunderhead Engineering Consultants, Inc. Website - http://www.thunderheadeng.com

On Mon, Mar 1, 2021 at 1:44 PM Kevin McGrattan notifications@github.com wrote:

In the new code, one would specify

&WIND SPEED=5, DIRECTION=134 /

and the flow would initial to that flow field. At the inflow boundaries, the model would continuously drive the flow vector towards the desired speed and direction. This is similar to how things work now, but we no longer explicitly force towards the mean flow at internal cells. We only force things at incoming boundaries.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9285#issuecomment-788318926, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4LF7R24HMCVUODOF7VYSTTBQDETANCNFSM4YND4NLQ .

[mcgratta]

The normal velocity at solid boundaries would quickly go to zero within a few steps, but there would be some initial wind within the buildings. The only way to avoid that is to ramp the wind SPEED up from zero.

[bwklein]

Ok, so either we ramp up from zero over time and wait for the flow in the domain to be established. Or, we allow the initialization to set the velocity in all cells and have some wind inside of the structures.

What if we extended INIT, with a 'Velocity' vector to initialize that subsection of the domain with a flow field so that you can use WIND with a full speed at t=0 and INIT to zero out the velocity inside of the buildings. Then there is no additional blocking/forcing or anything that has to happen during the run, and we won't have wind in the structure at the beginning of the simulation.

Best Regards, -Bryan Klein klein@thunderheadeng.com Product Manager, PyroSim/Pathfinder Thunderhead Engineering Consultants, Inc. Website - http://www.thunderheadeng.com

On Mon, Mar 1, 2021 at 2:57 PM Kevin McGrattan notifications@github.com wrote:

The normal velocity at solid boundaries would quickly go to zero within a few steps, but there would be some initial wind within the buildings. The only way to avoid that is to ramp the wind SPEED up from zero.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9285#issuecomment-788370592, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4LF7SUPX7X6WHV6R6LEZ3TBQLVNANCNFSM4YND4NLQ .

[mcgratta]

One of the problems with BLOCK_WIND is that it is very tricky to just impose velocities here and there like you would temperature or species concentration. The reason is that velocity is tightly coupled with the pressure solver, and when you're dealing with wind, you're dealing with more or less incompressible gas at nearly ambient temperature with a vertical stratification of pressure and density. Just randomly imposing a velocity within a volume is going to inevitably give rise to a huge velocity gradient, pressure spike, divergences, and so on. That is why traditionally FDS has ramped things up from 0 to allow the laws of physics to handle things properly.

There is a way to create a velocity field from a previous calculation, save it, and then initialize a new calculation with it. I've never used it, and I don't think many others have either. You could take a look at that, but it seems that ramping up from zero is going to be far easier.

[bwklein]

Ok, we can close this case then, thank you for the replies. We teach how to use Wind and the Wind Block with Holes method in the SFPE class, I'll remove that part. I need to update the content already for the new PERIODIC FLOW ONLY surface type instead of using the WIND=TRUE parameter on the Vents. I will also add in a bit about capturing the velocity field in the CSV files and using it to initialize a new simulation. We already discussed this topic in the course, so it will be a good example of another way to use this feature.

On Tue, Mar 2, 2021, 06:31 Kevin McGrattan notifications@github.com wrote:

One of the problems with BLOCK_WIND is that it is very tricky to just impose velocities here and there like you would temperature or species concentration. The reason is that velocity is tightly coupled with the pressure solver, and when you're dealing with wind, you're dealing with more or less incompressible gas at nearly ambient temperature with a vertical stratification of pressure and density. Just randomly imposing a velocity within a volume is going to inevitably give rise to a huge velocity gradient, pressure spike, divergences, and so on. That is why traditionally FDS has ramped things up from 0 to allow the laws of physics to handle things properly.

There is a way to create a velocity field from a previous calculation, save it, and then initialize a new calculation with it. I've never used it, and I don't think many others have either. You could take a look at that, but it seems that ramping up from zero is going to be far easier.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9285#issuecomment-788949816, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4LF7WUYQUSTDM3BCTEL23TBTZDRANCNFSM4YND4NLQ .