Generalized initial velocity field

[GoogleCodeExporter]

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_500x5
00m.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.mor...@gmail.com on 6 May 2009 at 1:35

Attachments:

• STRIP_3.fds

[GoogleCodeExporter]

Thanks. We'll take a look at this.

Original comment by mcgra...@gmail.com on 6 May 2009 at 8:56

[GoogleCodeExporter]

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/8dc
b39fc2a00b8c7?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 comment by randy.mc...@gmail.com on 9 Jun 2009 at 1:04

• Changed state: OnHold

[GoogleCodeExporter]

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 comment by randy.mc...@gmail.com on 9 Jun 2009 at 5:52

• Changed title: Generalized initial velocity field
• Added labels: Milestone-FDS_6.0, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

Original comment by williams...@gmail.com on 10 Jun 2009 at 1:17

[GoogleCodeExporter]

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 comment by randy.mc...@gmail.com on 10 Jun 2009 at 1:22

[GoogleCodeExporter]

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 comment by mcgra...@gmail.com on 10 Jun 2009 at 1:44

[GoogleCodeExporter]

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 comment by williams...@gmail.com on 10 Jun 2009 at 2:56

[GoogleCodeExporter]

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 comment by randy.mc...@gmail.com on 10 Jun 2009 at 3:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by gfor...@gmail.com on 10 Jun 2009 at 6:17

[GoogleCodeExporter]

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 comment by williams...@gmail.com on 11 Jun 2009 at 1:55

[GoogleCodeExporter]

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 comment by randy.mc...@gmail.com on 11 Jun 2009 at 2:02

[GoogleCodeExporter]

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 comment by randy.mc...@gmail.com on 11 Jun 2009 at 2:04

[GoogleCodeExporter]

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 comment by williams...@gmail.com on 11 Jun 2009 at 3:11

[GoogleCodeExporter]

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

Original comment by randy.mc...@gmail.com on 11 Jun 2009 at 4:02

[GoogleCodeExporter]

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 comment by david.sh...@atf.gov on 15 Sep 2010 at 7:06

Attachments:

• ATF_MBR06.dat

[GoogleCodeExporter]

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

Original comment by randy.mc...@gmail.com on 21 Mar 2012 at 12:40

• Changed state: Fixed

[GoogleCodeExporter]

Have heard no reported problems.

Original comment by randy.mc...@gmail.com on 13 Jun 2012 at 1:49

• Changed state: Verified

[GoogleCodeExporter]

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

Original comment by dpark...@gmail.com on 17 Oct 2014 at 12:22

[GoogleCodeExporter]

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

Original comment by randy.mc...@gmail.com on 17 Oct 2014 at 12:50

[GoogleCodeExporter]

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 comment by dpark...@gmail.com on 17 Oct 2014 at 1:48

[GoogleCodeExporter]

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 comment by randy.mc...@gmail.com on 17 Oct 2014 at 2:14