Generalized initial velocity field

[gforney]

We wish to apply a PROFILE='ATMOSPHERIC' boundary condition when OBSTacles
abutt the domain boundary. This image
http://www2.bfrl.nist.gov/userpages/wmell/PUBLIC/WUI/CATRIBE_GIS/WFDSofCDA_500x500m.png
from WFDS shows a typical situation. If the wind was coming from the East,
then we may want GROUND_LEVEL to follow the terrain.

This relates to "Issue 218:Error with ATMOSPHERIC wind input", following
which, in version 5.0.2, GROUND_LEVEL was introduced as a global starting
point for the atmospheric velocity profile. One potential solution is to
have an optional regression to pre 5.0.2 behaviour and apply a velocity
profile beginning from the bottom of the VENT.

STRIP_3.fds has a single OBSTacle, with the inlet divided into three
vertical 'strip' VENTs. The central VENT, which begins from the top of the
obstacle rather than from Z=0, presents a truncated atmospheric velocity
profile rather than starting with velocity = 0 at the bottom of the VENT.

Alternatively GROUND_LEVEL could be applied on a per vent basis, or
(ideally!) an option for ground level to be automatically calculated from
the highest abutting OBSTacle.

Currently issue 728 stops us from applying atmospheric boundary conditions
using many SURFs.

Original issue reported on code.google.com by rick.morgans on 2009-05-06 01:35:11

---

• _Attachment: STRIP_3.fds_

[gforney]

Thanks. We'll take a look at this.

Original issue reported on code.google.com by mcgratta on 2009-05-06 20:56:50

[gforney]

Rick,

I am putting this issue OnHold until I am convinced that FDS can correctly generate
and maintain an atmospheric profile on its own.  If it cannot, then I think putting
effort into developing these boundary conditions is not a good idea.  Below is a copy
of a correspondence I had with Tony Bova who had been working on a similar issue.

Please understand, I am not dismissing the idea.  I just think there needs to be an
order to how we handle this, and step one is making sure FDS has the requisite
physics to model the ABL (e.g. surface roughness).

Best,
Randy

Correspondence with Tony Bova:
Hi Tony,

Did you happen to see my post?

http://groups.google.com/group/fds-smv/browse_thread/thread/c464ecdfc07dcb03/8dcb39fc2a00b8c7?hl=en#8dcb39fc2a00b8c7

My take on this at the moment is that: if FDS cannot produce the
atmospheric profile on its own via a case like the one I posted, then
there is no advantage to having an initial field that matches the
atmospheric profile.  That is, FDS would just destroy whatever you
gave it.

With that said, if FDS does reproduce the profile correctly (and I
think it can for a flat surface given the correct upper bc and rough
wall model), then it is only a time savings to have the initial
profile.  But this profile can be generated once by FDS and, with the
FDS restart capabilities, used for any future simulation.
Additionally, this would allow for the inclusion of turbulence in the
initial field.  By only specifying the mean, you force yourself to
either 'reconstruct' the turbulence, which is difficult, or to run for
a longer time to generate the fluctuations, possibly negating the
advantage of initializing the mean.

Regarding your boundary conditions on the top of the domain, as you
can see from my input file, I think specifying the tangential bc
produces a more well-behaved calculation.  I might venture to say that
this case is actually "well-posed" whereas using an OPEN bc on the top
is not, but this may not be completely accurate.  My experience with
the case I posted is that it is robust and I think that makes it a
good candidate for how to set up these atmospheric cases.  Of course,
we should pay much closer attention to the requirements of where to
put the upper boundary.  But in principle, I think if you know a mean
wind speed and direction at the height of the neutral stratification
of the BL, then that is the correct bc for FDS.

Best,
Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-06-09 13:04:29

[gforney]

After some off-line discussion, I'd like to use this issue as motivation for a more
general fix to the problem.  The issue of initializing the velocity field shows up
in
several areas, e.g. the periodic verification studies, and I think it makes sense to
handle all these cases by reading an initial field from an optional input text file
which the user may generate however they choose.

Original issue reported on code.google.com by randy.mcdermott on 2009-06-09 17:52:58

• Labels added: Type-Enhancement, Milestone-FDS_6.0
• Labels removed: Type-Defect

[gforney]

Why not add velocity to the &INIT group? That way you don't need a separate text file.

Original issue reported on code.google.com by williamson.justin.wade on 2009-06-10 13:17:52

[gforney]

Justin,

The thought is that we may want to specify u(x,y,z,t0), etc. to vary spatially within
the domain.  I think the only practical way to do this in general is to read from a
file.  No?

Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-06-10 13:22:27

[gforney]

Keep in mind that all INIT features in FDS, as well as the U0, V0, W0, are fragile 
and often misinterpreted and misused. Proceed with caution.

Original issue reported on code.google.com by mcgratta on 2009-06-10 13:44:48

[gforney]

The INIT group is defined by XB, so you could theoretically specify any spatial
function within your domain with several INIT lines. I do not see any difference
between a separate text file and INIT lines contained within the input file (other
than the fact that your input file could become huge).

I understand that the initial conditions can be a major source of numerical
instability. I do not see an easy way of avoiding that other than applying a
preliminary "filtering" function that smears out the initial step gradients. 

Actually, I just had a thought that you could use a PL3D file as an initialization
format. There could be a pre-processor that generates the necessary text for domain
initialization from a previous simulation result. 

Original issue reported on code.google.com by williamson.justin.wade on 2009-06-10 14:56:09

[gforney]

Justin,

I am trying to avoid exactly the case where we need several INIT lines to specify the
initial field.  Take the test case of decaying isotropic turbulence, for example. 
Suppose I want to perform a 256^3 simulation.  Every point has a different velocity.

I like your idea of settling on an input format like PL3D, that would seem fine with
me.

Cheers,
R

Original issue reported on code.google.com by randy.mcdermott on 2009-06-10 15:05:11

[gforney]

It (PLOT3D format) would also have the advantage of being easily visualized and
therefore checked/verified with Smokeview

Original issue reported on code.google.com by gforney on 2009-06-10 18:17:42

[gforney]

There may be an issue here with the number of variables needed to initialize the
domain. PL3D only allows 5 because it is a standardized format. This would capture
the major parameters U,V,W,T, and one additional species or pressure. How important
is it to initialize the pressure field or other parameters? You may need to produce
2
different PL3D files to capture all of the necessary parameters. That would be a nice
feature to have anyway for standard output.

Also, this could be used to develop the incoming turbulent boundary condition from
a
periodic simulation result. For example, the boundary condition could be prescribed
as equivalent to the time dependent outflow of a periodic domain. There could be a
general way to apply this to WUI domains that are reasonably flat at the upwind side
by including a small portion of the domain to gradually transition from flat to
whatever you want.

Original issue reported on code.google.com by williamson.justin.wade on 2009-06-11 13:55:38

[gforney]

Justin,

The hydrodynamic pressure is not needed, but I could see that in an ABL sim you might
want to specify P_0 and T as a function of height differently from the default laps
rate that is allowed by FDS currently.

I agree with you that the we can use this method to generate turbulent initial
conditions.  I had a recent post suggesting this

http://groups.google.com/group/fds-smv/browse_thread/thread/c464ecdfc07dcb03#

This suggest that we may want to stick with the format of the restart file (which I
don't use generally, so I'm not familiar with it) as our standard input format.

R

Original issue reported on code.google.com by randy.mcdermott on 2009-06-11 14:02:40

[gforney]

Justin,

The hydrodynamic pressure is not needed, but I could see that in an ABL sim you might
want to specify P_0 and T as a function of height differently from the default laps
rate that is allowed by FDS currently.

I agree with you that the we can use this method to generate turbulent initial
conditions.  I had a recent post suggesting this

http://groups.google.com/group/fds-smv/browse_thread/thread/c464ecdfc07dcb03#

This suggest that we may want to stick with the format of the restart file (which I
don't use generally, so I'm not familiar with it) as our standard input format.

R

Original issue reported on code.google.com by randy.mcdermott on 2009-06-11 14:04:05

[gforney]

I'm not sure that the restart format can help you produce a time dependent turbulent
boundary condition. Multiple slice files are likely more appropriate.

Original issue reported on code.google.com by williamson.justin.wade on 2009-06-11 15:11:54

[gforney]

Yeah, I was thinking about the initial condition, not the bc.  That is a different
issue, but one we need to address.

Original issue reported on code.google.com by randy.mcdermott on 2009-06-11 16:02:29

[gforney]

In spaces that have non-insignificant inlet and exhaust flows the ambient flow field
takes time to develop.  In these cases the model often has to run for days just to
set up the initial velocity conditions prior to starting the fires.   It would be very
helpful to be able to define the initial velocity at all cells at an initial condition
for the run.   Perhaps a solutions could be to save a file similar to a restart file
but only containing the velocity info.

The attached file has an only exhaust and inlet flows, no heat

Original issue reported on code.google.com by david.sheppard@atf.gov on 2010-09-15 19:06:33

---

• _Attachment: ATF_MBR06.dat_

[gforney]

Added UVWFILE and UVW_TIMER functionality in SVN 10271.  Tony Bova has been working
on verification.

Original issue reported on code.google.com by randy.mcdermott on 2012-03-21 12:40:13

[gforney]

Have heard no reported problems.

Original issue reported on code.google.com by randy.mcdermott on 2012-06-13 13:49:45

[gforney]

Is there a method for achieving the same thing, but with an initial temperature profile?

Original issue reported on code.google.com by dparkin7 on 2014-10-17 12:22:05

[gforney]

It could be done.  But how complicated is your TMP profile?  Can you just use a few
INIT lines to get close?

Original issue reported on code.google.com by randy.mcdermott on 2014-10-17 12:50:07

[gforney]

Not very complicated.  It's a linear profile in Z direction...yes I use some INIT lines
but I'm just being a perfectionist - it requires a fair few INIT lines if you want
to avoid little step changes along the way.  Of course, being a perfectionist in CFD
land is not the best idea...lol my bad.

Original issue reported on code.google.com by dparkin7 on 2014-10-17 13:48:24

[gforney]

You could probably do this with a RESTART.

Set up the case with a hot and cold wall, top and bottom and FREEZE_VELOCITY=T on MISC.
 Once the temperature stratifies, save the RESTART file.  Then try removing the FREEZE_VELOCITY.

Original issue reported on code.google.com by randy.mcdermott on 2014-10-17 14:14:38