FDS part.f90 - Total FRAC is greater than one

[GoogleCodeExporter]

Application Version: FDS 5.4.0
SVN Revision Number: 4059
Compile Date: 06-02-09
Operating System: Linux x64

The total FRAC or SOLID_ANGLE_TOTAL_FLOWRATE can be greater than 1.

I recoded part.f90 to screen print the SOLID_ANGLE_TOTAL_FLOWRATE. I
then created a case with three sprinkler table rows with fracs of 0.5,
0.4 and 0.1; and specified a DROPLETS_PER_SECOND of 500 so that 5
droplets would be inserted per DT_INSERT.
This resulted in a SOLID_ANGLE_TOTAL_FLOWRATE of greater than 1.

I believe the reason for this is that an adjustment must be made for
patches with more than one droplet. If not, the fraction of water
actually discharged from the patch will not consistent with the FRAC
for the patch.

I also noted that in more than 5 droplets were inserted from time step 5
(.16 seconds) to time step 6 (.17 seconds).  I do not have an explanation
for this.

The code snipet, test case and screen shot of results are attached.

Original issue reported on code.google.com by pfh...@comcast.net on 2 Jun 2009 at 8:12

Attachments:

• Frac.fds
• Screenshot-1.png
• partf90-solidangle

[GoogleCodeExporter]

I'll take a look at this.

Original comment by mcgra...@gmail.com on 3 Jun 2009 at 1:23

• Changed state: Accepted

[GoogleCodeExporter]

This is what's going on -- each droplet has a mass 

m_i = 4/3 pi r^3 rho_w

This droplet needs a weighting factor to indicate the number of real droplets 
that 
it represents. 

m_total = sum_i(wgt_i*m_i) / sum_i(wgt_i)

SOLID_ANGLE_FLOWRATE is the wgt_i
SOLID_ANGLE_TOTAL_FLOWRATE is the sum_i(wgt_i)

As for the droplets per insertion time, the fact that 10 are introduced is 
because 
the insertion increment DT_INSERT and the time step are slightly different, 
meaning 
that sometimes more than one batch may be introduced over the course of a time 
step.

Does this make sense? Hard to do the math with a text editor.

Original comment by mcgra...@gmail.com on 3 Jun 2009 at 9:55

• Changed state: MoreInfo

[GoogleCodeExporter]

Regarding the droplets per insertion time, I figured it was something like 
that. I
just wanted to bring it up and get an explanation. Thanks.

Regarding the weighting factor, I understand your point, but still believe 
there is
an issue. 

If no more than one drop is inserted per patch, the sum of weighting factors 
would be
less than or equal to 1. However, if more than one drop is inserted per patch 
the sum
of weighting factors can be greater could be greater than 1.

I feel the real issue is that if more than one drop is discharged in a patch, 
the
current method being used will discharge a higher fraction of water from the 
patch
than what is specified via the FRAC. The reason for this is a Patch Fraction is 
being
used as a Droplet Fraction.

Example: A three patch discharge, discharging 4 droplets.

Patch 1 FRAC = .5
Patch 2 FRAC = .4
Patch 3 FRAC = .1

Assume the following droplets are discharged from each Patch.

Patch 1: Two droplets; .01kg and .02kg
Patch 2: One droplet; .02 kg
Patch 3: One droplet; .01 kg

                                                                 Frac of Patch Flow
                                  (Mass*Frac)/                  (PatchFlow/Total
Patch  Frac Mass       Mass*Frac   TotalFrac)     PatchFlow      of Patch flow)
1      0.5  1.00E-002  5.00E-003   3.33E-003        
1      0.5  2.00E-002  1.00E-002   6.67E-003      1.00E-002      6.25E-001
2      0.4  2.00E-002  8.00E-003   5.33E-003      5.33E-003  3.33E-001
3      0.1  1.00E-002  1.00E-003   6.67E-004      6.67E-004  4.17E-002
Total                Sum   1.60E-002                     1.60E-002  
Frac   1.5

Therefore, by my calculation Patch 1 should have 50% of the flow but actually 
has
62.5% of flow and the other patch flows are less than what they should be.

Original comment by pfh...@comcast.net on 4 Jun 2009 at 2:10

[GoogleCodeExporter]

A real sprinkler inserts far more droplets in a time interval than we can 
afford to
track.  At any single insertion time the instantaneous distribution will be 
skewed on
the relatively small number of drops being inserted.  The goal of the sprinkler
routine is to over time result in the correct spray distribution.

Original comment by drjfloyd on 4 Jun 2009 at 2:19

[GoogleCodeExporter]

But, wouldn't we still want to make sure the fraction of water being discharged 
at a
given time step from each patch is consistent with what the user specified in 
the
sprinkler table?

Original comment by pfh...@comcast.net on 4 Jun 2009 at 2:32

[GoogleCodeExporter]

Paul, I think I understand your point. For a given droplet whose size is chosen 
from 
the assumed size distribution, we randomly seek a "patch" to launch it from. 
The "patch" is one of the TABL lines. The selection of the patch is weighted by 
the 
relative mass flux fraction listed on the TABL line. Thus, if TABL line 1 has 
75% 
and line 2 25%, I think we throw approximately 75% of the droplets from patch 1 
and 
25% from patch 2. The droplet sizes are randomly chosen, so I think that Jason 
is 
right that in the long run, the mass balance is achieved. It's just not exact 
for 
each individual batch. 

Jason, is that what you reckon?

Original comment by mcgra...@gmail.com on 4 Jun 2009 at 2:44

[GoogleCodeExporter]

Kevin, that is what I was aiming for when I added the TABL stuff.  Not to say 
that
there might not be an error in implementation.  Haven't had an opportunity yet 
to put
together a good test of the logic.

Original comment by drjfloyd on 4 Jun 2009 at 2:49

[GoogleCodeExporter]

Based on some recent work, I feel that maintaining the correct fraction of flow 
from
each patch is important. 

The attached files shows two sets of results from comparing FDS predictions to 
actual
ADD test results.

The ADD1 image shows the results using FDS5 at various DPS.

The second image shows the results where a droplet was forced into every patch 
per
DT_Insert (570,000 DPS). For this to occur I modified the code such that if the 
number of droplets inserted per time step is greater than or equal to the 
number of
patches a drop would be inserted into every patch. Once the droplet count 
exceeded
the  number of patches, the droplets would be randomly inserted into patches.

IF ((I<=TA%NUMBER_ROWS) .AND. (TA%NUMBER_ROWS<=PC%N_INSERT)) THEN

I feel the results are much better; variation is more consistent and the minimum
statistics greatly improved.

Using so many droplets does create HUGE part files. However, I plan to try this 
with
different DT_INSERTS. I think that I can get away with using a longer DT_INSERT 
than
the default.  

Original comment by pfh...@comcast.net on 4 Jun 2009 at 3:25

Attachments:

• add1.jpg
• ADD-dropinEveryPatch.jpg

[GoogleCodeExporter]

Two issues here -- first, are the stats being done right. Second, how well is 
the 
experimental ADD predicted. Let's tackle the first one. Can we verify that the 
mass 
fraction of water from each patch is as specified when time averaged over a 
suitable 
time increment?

Original comment by mcgra...@gmail.com on 4 Jun 2009 at 3:35

[GoogleCodeExporter]

I am attempting to dump this info out by adding code to the dump.f90 file. 

However, I am running into issues with the Solid_Angle_Flowrate and
Solid_Angle_Total_Flowrate. 

When compiling I get the error "the name does not have a type, and must have an
explicit type." 

I suspect that even though explicitly defined in the part.f90 file, this 
information
is not available in the dump.f90 file.  Any suggestions?

Original comment by pfh...@comcast.net on 8 Jun 2009 at 12:18

[GoogleCodeExporter]

These are locally defined variables. They only exist within the subroutine in 
part.f90. This is good practice to avoid carrying lots of variables in the 
global 
arrays. I was thinking a bit over the weekend about a good way to verify the 
accuracy of the TABL distributions. Haven't come up with anything other than 
just 
hacking into the routine itself. Would be better to have something permanent to 
add 
to the Verification Suite. One thought was to exploit what Simo et al. have 
done 
with PDPA. I'll cc him to see if there is some way we can account for the mass 
fraction of droplets from the various "patches" that one might create.

Original comment by mcgra...@gmail.com on 8 Jun 2009 at 12:37

[GoogleCodeExporter]

DEVCs of AWMPUA with SURFACE_INTEGRAL and a TABL that defines a small number of
narrow angles with greatly varying flow rates would create a verification case.

Original comment by drjfloyd on 8 Jun 2009 at 12:44

[GoogleCodeExporter]

Good idea -- I think there's a case like this in the suite. I'll take a look at 
it.

Original comment by mcgra...@gmail.com on 8 Jun 2009 at 1:24

[GoogleCodeExporter]

I spent some time analyzing the current method as it pertains to droplet 
insertion 
using the detailed sprinkler table information.  As part of the analysis, I 
modified 
the code to:
1) Output patch fraction flow information
2) Force a droplet in every patch
3) Use different weighting factor to account for patch fractional flow
4) Adjusted the method in which droplet diameters are randomly selected, 
essentially 
eliminating the 7 bin strata and randomly selecting a droplet from one of 1000 
bins 
from the CNF.

The informal results of this process are shown in the attachments. 

Original comment by pfh...@comcast.net on 29 Jun 2009 at 2:23

Attachments:

• PatchAnalysis.xls
• Droplets.ppt

[GoogleCodeExporter]

Done a little investigation in the flowrates.  Created a simple test case with 4
patches (each discharging into one quadrant) where the flowrates increased by a
factor of two from patch to patch.  Four DEVC summing AMPUA over each quadrant 
of the
floor were used.  For cases where the number of drops is very small (1 or 2) 
slowly
over time the DEVC values are converge to the correct flows in each quadrant.  
For
cases where the number of drops inserted per timestep is large enough to expect
multiple drops in the smallest flow patch, again DEVC values converge (fairly 
quickly
though).  In the intermediate cases, the errors in flow plateau.  So something 
is
amiss in the logic. 

I do not think the answer is to force drops to occur in each patch.  As a random
event, that sort of forcing is likely to lead to unanticipated problems if 
weighting
isn't done properly (which is likely the issue now that weighting is in error). 

Eliminating the strata is also not the answer as that is important for mist 
systems
(not so much for non-mist).

Further updates to come.

Original comment by drjfloyd on 29 Jun 2009 at 9:06

[GoogleCodeExporter]

More info and Comments.

1. Seven Bin Process:  By cycling through the 7 bins in order, and selecting 
droplets from those bins, we are not directly using the 
Rosin-Rammler/Log-Normal 
distribution. While it is used as a basis for selecting the droplets within the 
bins, we are in effect modifying the droplet distribution that was determined 
experimentally. If this 7 bin process will remain, the basis for it should 
noted in 
the technical guide.

2. Weighting Factor Modification: The weighting factor modification I used 
assured 
that the Solid_Angle_Total_Flowrate never exceeded 1, but also considered the 
case 
where it was less than 1.

3. Droplets per Insertion vs. Number of Patches
The current process biases droplets to the patches with higher fractional 
flows. I 
found that using the default DT_INSERT and DPS, could result in wide variation 
between theoretical and actual patch flows. In my test case I used 5,631 
patches 
with a default number of droplets per insertion of 50. Some patches would not 
get 
any droplets for a significant amount of time (25s) which resulted in the 
significant patch flow variation.  I believe this is consistent with the 
results you 
noted.

4. Forcing a Droplet in Every Patch
The idea behind forcing a drop in every patch is that the patch fractional flow 
would be balanced at every insertion since water is flowing through each patch. 
 If 
some patches do not flow water, all flowing patches will actual have a higher 
fractional flow than what was specified. 

As I incorporated it, if the droplets per insertion were at least equal to the 
number of patches, a droplet was inserted into every patch. If the droplets per 
insertion exceeded the number of patches, a droplet was inserted into every 
patch 
and then the remaining droplets were randomly inserted as is the current 
method. I 
do not see a problem with this approach.

If there are a large number of patches (this is the case with the sprinklers XL 
GAPS 
has characterized) it can result in very large part files.  As a result, I 
started 
doing sensitivity analysis with DT_INSERT.

5. Papers on Droplet Flow
FYI regarding somewhat recent paper on droplet modeling.
“Numerical modeling and experimental measurements of a high speed solid-cone 
water 
spray for use in fire suppression applications”, 2004, Yoon et.al.

6. ADD Results
Comparing the FDS prediction to actual ADD results shows there are some areas 
with 
good agreement and other areas with not so good agreement, regardless of the my 
modifications.  I believe there are other factors that might be causing this. I 
speculate it may be due, in part to modified drag due to droplet distortion and 
droplet breakup. Has any consideration been given to incorporating a model for 
either in FDS?

Original comment by pfh...@comcast.net on 30 Jun 2009 at 12:45

[GoogleCodeExporter]

I'm in a process of implementing a droplet break-up model. I have some problems
finding good papers about the implementations of the existing models. Usually 
the
papers show the main equations, but do not tell how it is actually done. 

But in this case, I don't think the breakup model would make any difference. At 
this
slow speeds (8.7 m/s), all the breakup processes should have taken place 
already. If
the speed was about 30 m/s or above, then the 'bag breakup' would be possible.

Original comment by shost...@gmail.com on 30 Jun 2009 at 1:34

[GoogleCodeExporter]

I am choking on papers regarding break up and modified drag. You need 
references?

Original comment by pfh...@comcast.net on 30 Jun 2009 at 1:49

[GoogleCodeExporter]

Please, it would be great!

Original comment by shost...@gmail.com on 30 Jun 2009 at 1:52

[GoogleCodeExporter]

1. With STRATA the distribution is as input.  The drops per bin are weighted to
preserve the distribution.  However, I agree we should be explaining this 
process.

2. The magnitude of SOLID_ANGLE_TOTAL_FLOWRATE is not really the issue.  It is 
being
used as a parameter to normalize the weighting of introduced droplets.  The 
question
is more is the weighting being done properly.  

3/4 How well a spray pattern can be reproduced based on the number of droplets 
being
inserted is in some sense a user decision.  If you have a sprinkler with 5,000
patches but provide model inputs that only add a handful of drops per timestep, 
there
shouldn't be much expectation that you will have a great simulation of the 
spray.  I
don't think we want to be forcing 1 drop per patch on the user, but rather let 
that
be an option addressed via the number of droplets inserted.  

5. thanks for the reference

6. Before we can draw any conclusions about what is and isn't working in terms 
of
droplet insertion, drag, breakup, etc. we really need good validation cases to
identify where exactly errors are.  Do we have a good feel for the uncertainty 
in the
simulations you are doing for ADD?  Good and bad agreement statement can only 
be made
in the context of model vs. experimental uncertainty.

Original comment by drjfloyd on 30 Jun 2009 at 1:57

[GoogleCodeExporter]

I was looking at the ETAB/TAB for droplet break up and the Modified Droplet 
Drag 
noted in reference 3.

1. The TAB Method for Numerical Calculation, 1987, O'Rourke (Provides nice 
description of numerical implementation) 
2. Liquid Jet Atomization and Droplet Breakup Modeling of Non-Evaporationg 
Diesel 
Fuel Sprays, 1997, Tanner (builds upon the TAB method, ETAB-Enhanced TAB)
3. Modeling the Effects of Drop Drag and Breakup on Fuel Sprays, 1993, Reitz
4. Modeling Drop Drag Effects on Fuel Spray on Fuel Spray Impingement in Direct 
Injection Diesel Engines, 1997, Reitz
5. Computational Study of Large Droplet Breakup in the Vicinity of an Airfoil, 
2005, 
DOT/FAA/AR-05/42
6. Numerical modeling and experimental measurements of a high speed solid-cone 
water 
spray for use in fire suppression applications, 2004, Yoon et.al.
7. A DROPLET IMPACT MODEL FOR AGENT TRANSPORT IN ENGINE NACELLES, 2003, 
DESJARDIN
8. A Dilute Spray Model for Fire Simulations, 2002, DesJardin
9. DROPLET-WALL COLLISIONS EXPERIMENTAL STUDIES, 1995, Mundo

Original comment by pfh...@comcast.net on 30 Jun 2009 at 2:27

[GoogleCodeExporter]

As a follow up, I did re-code FDS to incorporate a droplet rebound model 
(reference 
7) about 8 months ago.  I did get it to work but didn't pursue it much since I 
believe the drag and break up were more important.  

Original comment by pfh...@comcast.net on 30 Jun 2009 at 2:34

[GoogleCodeExporter]

Changed the PWT calc for a spray distribution table (made it as simple as 
possible)
plus changed the selection of STRATA to prevent having NSTRATA and number of
insertions or number of active heads such that the MOD results in not picking 
all bins.

Changes guarantee that the distribution of flux will eventually converge given 
enough
inserted drops.  User still has the onus of selecting a sufficient insertion 
rate for
their spray pattern definition (though in my opinion 5000 patches is probably 
not
meaningful given current methods for measuring spray distributions and delivered
density).

Original comment by drjfloyd on 30 Jun 2009 at 6:35

[GoogleCodeExporter]

Previous work on characterizing sprinkler discharge resulted in this number of 
patches for various sprinklers. XL GAPS is embarking on further review and 
characterization of sprinkler discharge at UL. If you would like to be involved 
to 
further the understanding of this and its incorporation into FDS please let me 
know.

Original comment by pfh...@comcast.net on 30 Jun 2009 at 6:56

[GoogleCodeExporter]

In terms of FDS validation, I think there is a lack of a well characterized 
sprinkler
coupled to a measurement of delivered density that captures most of the water 
from
the sprinkler (with an assessment of the overall uncertainty in both).  Various
people have measured sprinklers.  Various people have measured delivered 
density. 
But I am not aware of a published dataset where both were done (at least not 
datasets
where most of the discharge is captured in the delivered density tests).  

Before delving into breakup routines and complex drag expressions, we need an
understanding of how good are we doing now, what level of detail in a spray
distribution is needed (noting that we can now support non-equal area patches), 
and
what if any grid size around a sprinkler head or OFFSET is needed.

For example if we are measuring delivered density with a container 10s of cm in 
width
and the projected area of a patch from the sprinkler to the container a few cm, 
does
that level of patch detail really buy us anything?

Original comment by drjfloyd on 30 Jun 2009 at 9:13

[GoogleCodeExporter]

I am jumping midstream into a long discussion, but I hope to convey that we 
(Paul 
and I) are not able to follow completely the logic of the droplet subroutine.  
We 
have had to delve into the code as the Technical Guide provides a very brief 
discussion.  For now our focus has been on the droplet assignment and insertion 
aspects.  

1) Clearly FDS during droplet insertion stage at every time step (DT_INSERT) 
enforces mass balance based on flow rate of sprinkler.  
2) Reading the technical guide there appears to be a single parameter (weighing 
factor) to help ensure mass balance while sifting through the code there are 
several 
such factors.  Some explanation of each would be helpful.  
3) Current mass balance is global but maybe could also consider local (patch) 
balance.  In other words, when patches (or TABL) are defined, the flux fraction 
from 
FDS should match the input (given on the TABL) when conditions are right (at 
least 
one droplet per patch at every DT_INSERT).  
4) From our understanding of the logic in the code, the weighing factor 
SOLID_ANGLE_TOTAL_FLOWRATE <=1.
5) Even if the number of droplets inserted per each dt_insert time step were 
greater 
than the number of patches, there are likely to be patches that do not receive 
a 
droplet.  We think it would be helpful if the user could have an option for 
force a 
droplet through each patch.
6) We would like to understand better the implementation of the Rosin Rammler 
distribution and the weighing factor introduced by the grouping of the 1000 
diameters into 7 bins.

We appreciate everyone's effort to understand the workings of the code.  As you 
can 
see both Paul and I, mostly Paul, have tried to put in a lot of time 
understanding 
the workings of FDS by reviewing the code.  On this topic of droplets, I would 
like 
to suggest that maybe we arrange for a working meeting which might help us move 
through this much quicker.

Original comment by mtabad...@gmail.com on 13 Jul 2009 at 7:44

[GoogleCodeExporter]

There seem to be two major issues here, not 6. The first is the distribution of 
water mass among the patches; and the second is the distribution of water mass 
among 
the 7 bins. 

Simo -- do you have anything written that describes the 7 bins? In brief, each 
bin 
has a weighting factor to account for the fraction of water mass that should be 
found in that bin's size range. These are called W_CDF. Then there is DR%PWT -- 
for 
each droplet there is a weighting factor that ensures that the mass represented 
by 
all the droplets equals that which is desired. For example, if there are 100 
droplets to be inserted, each one randomly chooses a size range, or bin. There 
are 
seven bins, by default, and each bin is equally likely to be chosen. Then a 
droplet 
radius is assigned following the mass distribution for that particular bin. The 
initial weighting factor for the droplet is the fraction of water represented 
by 
that bin. In other words, if that bin's size range represents only a small 
fraction 
of total water mass, the droplet will be weighted low. Once all the masses on 
all 
the droplets is summed, a second weighting factor ensures global mass 
conservation.

As for the patches, insisting on at least one droplet per patch per insertion 
makes 
things very tricky. Suppose one patch gets 10x the water flow as another? 
Assigning 
one droplet for each over-compensates for one and under-compensates for the 
other 
unless you start re-weighting these droplets accordingly. Add to this the fact 
that 
each droplet carries a different amount of water, and it all becomes more 
complicated than it already is.

Original comment by mcgra...@gmail.com on 13 Jul 2009 at 9:23

[GoogleCodeExporter]

I'm going to move this to 'On Hold' until after the 5.4.0 release.

Original comment by mcgra...@gmail.com on 24 Jul 2009 at 5:25

• Changed state: OnHold
• Added labels: Milestone-FDS_5.5

[GoogleCodeExporter]

Paul, I've lost track of this thread. Are you still having problems with 
droplets?

Original comment by mcgra...@gmail.com on 28 Jan 2010 at 10:41

[GoogleCodeExporter]

I'm going to close this issue. It appears that this part of the code has 
changed significantly since the original posting, in which case it would be 
better to test the new code and post a new issue if there is one.

Original comment by mcgra...@gmail.com on 17 May 2012 at 8:28

• Changed state: WontFix