VEL_T

[gforney]

The parameter VEL_T seems not to work right.

The line
&SURF ID='LOUVER',VEL=-2.0,VEL_T=2.0,0.0 /
causes nothing but the VEL=-2.0

&SURF ID='LOUVER',VEL=-2.0,VEL_T=0.0,2.0 /
causes a flow I thought to appear with VEL_T=2.0,2.0 +/- 

Boris Stock
BFT Cognos

Original issue reported on code.google.com by Boris.Stock@GMX.de on 2007-05-07 16:14:13

---

• Attachment: VEL1.data

[gforney]

OK. I have not used this feature in years, and I can well imagine that we have 
broken it. I'll fix it.

K

Original issue reported on code.google.com by mcgratta on 2007-05-08 19:32:42

• Labels added: Priority-High
• Labels removed: Priority-Medium

[gforney]

I fixed the bug, and posted new source code and a new Verification Case called 
tangential_velocity.fds

We will compile RC4 at the end of the week.

I will close the case, but if your problem is not solved, open up a new one.

K

Original issue reported on code.google.com by mcgratta on 2007-05-08 21:05:35

[gforney]

(No text was entered with this change)

Original issue reported on code.google.com by bryanwklein on 2007-06-26 17:31:25

[gforney]

I may be misinterpreting your last comment: Are you saying FDS could never model a constant
mass flux or constant volume flux boundary condition where the vent is louvered? 

Original issue reported on code.google.com by drjfloyd on 2011-10-19 18:45:49

[gforney]

Louvered vent is fine.  But the normal component at the boundary is the only component
of velocity that adds or subtracts mass from the system.  Once the stuff gets in (via
normal component), the tangential velocity can throw it one way or the other.

Original issue reported on code.google.com by randy.mcdermott on 2011-10-19 18:51:26

[gforney]

Right now VEL_T is a constant value.  This is fine for a VEL input, but not for a VOLUME_FLUX
or MASS_FLUX input (especially if temperature/density changes occur at the VENT). 
 I think it would be useful to be able to do tangential flows for the other boundary
types, especially since VEL is often not the best choice for the boundary condition
(doesn't scale with grid and more often than not for typical real world engineering
problems one really wants constant volume or mass rather than constant velocity). 

I propose a change in the VEL_T computation so that

&SURF VEL_T = normed component (e.g. the fraction of the normal that is in the given
tangential direction) rather than absolute velocities.  So right now for a 2 m/s inlet
with a 45 degree down angle we would input:

&SURF VEL=-2,VEL_T(2)=-1.414

instead we would input:

&SURF VEL=-2,VEL_T(2)=-0.707 (e.g. sin(45 degrees))

and the line in VEL_BC rather than being of the form RAMP_T*VEL_T is of the form UN*VEL_T.

This way we could have tangential flows with VOLUME_FLUX and MASS_FLUX inputs rather
than only with VEL inputs. 

Original issue reported on code.google.com by drjfloyd on 2011-10-19 19:05:05

[gforney]

Except that it is totally permissible to have VEL=0 and VEL_T=1 m/s.  Think lid-driven
cavity flow.

I'm still not sure I understand the issue.  The mass flux or volume flux is only defined
for the normal direction to the surface.  The UN for that surface must be UN = MASS_FLUX_TOTAL/RHO_F.
 The tangential velocity can be whatever you want.

Original issue reported on code.google.com by randy.mcdermott on 2011-10-19 19:15:10

[gforney]

Right now there is no way to get a mass flux BC with a fixed tangential angle. I can
specify only one VEL_T, fixed for all time regardless of changes in the density or
mass flux at the vent that change the magnitude of the normal velocity.  

Say I want a 1 m^2 vent with a inlet velocity of 2 m/s and a 45 degree down angle.
 This is simple, I just input:

&SURF VEL=-2,VEL_T=0,-1.4/

Now lets make it a 1 m^2 vent with inlet mass flux of 1 kg / s. and a 45 degree down
angle with a constant wall temperature.  I can input:

&VENT MASS_FLUX=0.1,0.1,....,xxx, VEL_T= 0,??

This means I must 1) compute the average MW for incoming gas, 2) compute the local
pressure at the vent to account for stratification, 3) compute the density, 4) compute
inlet velocity, 5) compute the 45 degree downward component.  This becomes a chore.
 Be much easier to just be able to specify that I want the vent to be 45 degrees downward.

Now lets make it a 1 m^2 inlet from a complicated HVAC system.  How can I input this?
I can't as I cannot precompute VEL_T as the inlet velocity is unknown.  Temperature,
mass flux, and species at that inlet will all potentially be changing based on the
HVAC solution.

Original issue reported on code.google.com by drjfloyd on 2011-10-19 19:30:45

[gforney]

Oh and I see your point about the cavity flow.  Maybe it is a different keyword to indicate
angle vs. indicate absolute velocity.

Original issue reported on code.google.com by drjfloyd on 2011-10-19 19:31:55

[gforney]

OK, I see now.  I think what you said before is close to what you want.  You basically
want to specify a unit vector in the flow direction.  So, instead of using a fraction
of UN (itself a component), you want the normalized components of the velocity vector.

Just remember that regardless of the vent direction, the mass flux is RHO_F*UN and
the volume flux is AREA*UN.

Original issue reported on code.google.com by randy.mcdermott on 2011-10-19 19:47:59

[gforney]

Yes, exactly being able to specify the flow unit vector.  What do you think would be
a good name for that input?  VEL_ANGLE(3) or ANGLE_T(3), .. something else?

Original issue reported on code.google.com by drjfloyd on 2011-10-19 20:00:04

[gforney]

How about just VELOCITY_VECTOR(3)?  You can then normalize internally.  I think the
"tangential" business is extremely confusing and makes for complex code.

Original issue reported on code.google.com by randy.mcdermott on 2011-10-19 22:25:20

[gforney]

Feel free to change. That feature is old and used seldomly.

Original issue reported on code.google.com by mcgratta on 2011-10-19 22:27:48

[gforney]

Actually, come to think of it, what I have been using for particle insertion is UVW(3),
similar to XYZ(3).  Again, normalize as needed.

Original issue reported on code.google.com by randy.mcdermott on 2011-10-19 22:33:10