Louvered vent blows at the wrong angle (cont'd)

[bwklein]

I was looking at case #13213 and couldn't reopen it to comment, so I created this issue to continue the report.

I do think there is something happening in the velocity imposed at the edges of a vent that isn't helping the flow angle be as accurate as it could be. See the attached zip file for PyroSim and FDS test case files. In the image below, you can see that the flow in the field of the vent is at the desired 45deg (green arrows), but at the vent edges, the flow is shearing across and back toward the vent surface (red arrows). This shear flow angle seems to be pushing the flow from the vent further in that direction than it should be. I would have expected the 2 vectors at the edges to be in a similar direction as the 3 in the middle of the vent face, even if the magnitude was lower from the surrounding cells influencing them.

Should HVAC surf types have NO_SLIP=T by default to help minimize edge effects?

jet_fan_test.zip

[mcgratta]

Against my better judgment, I'll take a look. This kind of thing has always been tricky, and I hesitate to change the code and create unintended consequences. I'll see if there are settings on SURF or HVAC that would solve the problem without need for a code change. Then the AI powered PyroSim can choose the proper settings.

[bwklein]

Then the AI powered PyroSim can choose the proper settings.

No AI in our tools, only human intelligence at work here. 😄

[drjfloyd]

In a real life jet fan, the opening for the air flow is surrounded by some kind of shroud. There is an edge of finite thickness present between the outflow and the gas to the side of the fan. Your inputs do not have this edge. At coarse grid resolution there is only so much we can do in terms of trying to impose tangential flow for an input that isn't entirely physical. If you add a one cell shroud around the exit this essentially goes away.

[mcgratta]

A thought occurred to me last night on this. It has to do with how FDS deals with the sides and edges of solids. The velocity boundary routine returns two quantities at solid surfaces -- the vorticity and the strain rate. These two quantities are passed to the routine that computes the finite differences of the terms in the momentum questions. When we first implemented thin solids, we had to change the arrays holding these two quantities because now one could have a single point on the boundary at which we compute the vorticity and strain rate for both sides of the obstruction. These values would be different. So for each boundary point, we have the two opposite side sets of values. I'm not sure that we ever considered holding two sets of values for the edges of the solids. That is, I believe that we compute a vorticity and strain rate at the edge that applies to the momentum equations in the two coordinate directions. To do what you want; I think we would have to compute unique sets of vorticity and strain rate for the two flow directions, normal and tangent to the fan face.

Long story short, this may not be possible, or might have adverse effects, typical whenever we muck around with this stuff. I'll dig in a little more, but for now Jason's advice is probably best. If we made a change like this, it might entail having to run all the validation cases to find that one needle in a haystack case that begins to act wonky.

[bwklein]

I messed around a bit with @drjfloyd suggestion about adding a 1-cell wide perimeter boundary (green arrows) for handling the edge effects better. That does seem to help the edge vectors as expected.

If I set the UVW values to 45° (-0.707107, -0.707107, 0.0 in my case), the primary flow centerline is somewhere closer to 55°.

If I set the UVW values to 35° (-0.819152, -0.573576, 0.0 in my case), the primary flow centerline is somewhere closer to 45°.

I then ran the same case with 2x the resolution to see if there is a difference in the results, and the same pattern emerges.

45° UVW values @ 3 sec:

35° UVW values @ 3 sec:

[mcgratta]

Here is another thing to try

&HEAD CHID='JETFAN_test2'/

&TIME T_END=100.0/

&MESH IJK=16,14,12, XB=187.0,190.2,144.6,147.4,1.8,4.2/

&SURF ID='fan housing', NO_SLIP=T, COLOR='GRAY 20' /

&OBST ID='JetFan 1', XB=188.0,189.2,145.6,146.4,2.8,3.2, SURF_ID='fan housing' /

&SURF ID='BLOW',     VEL=-1., NO_SLIP=T, VEL_T= 1,0 /
&SURF ID='BLOW IN',  VEL= 1., NO_SLIP=T, VEL_T=-1,0 /
&SURF ID='BLOW OUT', VEL=-1., NO_SLIP=T, VEL_T=-1,0 /

&VENT SURF_ID='BLOW'    , XB=188.0,188.0,145.6,146.4,2.8,3.2, COLOR='SLATE BLUE' /
&VENT SURF_ID='BLOW OUT', XB=188.0,188.2,146.4,146.4,2.8,3.2, COLOR='SLATE BLUE' /
&VENT SURF_ID='BLOW IN' , XB=188.0,188.2,145.6,145.6,2.8,3.2, COLOR='SLATE BLUE' /

&VENT MB='XMIN', SURF_ID='OPEN' /
&VENT MB='XMAX', SURF_ID='OPEN' /
&VENT MB='YMIN', SURF_ID='OPEN' /
&VENT MB='YMAX', SURF_ID='OPEN' /

&SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., PBZ=3.033979/

&TAIL /

[bwklein]

@mcgratta the use case here is for Jet Fans, where the atmosphere is recirculated by the HVAC vents. I don't think I can change the SURF params of HVAC, since it is a built in surface type.