FDS part.f90 - Total FRAC is greater than one

[gforney]

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 pfhart@comcast.net on 2009-06-02 20:12:26

---

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

[gforney]

I'll take a look at this.

Original issue reported on code.google.com by mcgratta on 2009-06-03 13:23:23

[gforney]

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 issue reported on code.google.com by mcgratta on 2009-06-03 21:55:27

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-04 14:10:44

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-04 14:19:25

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-04 14:32:02

[gforney]

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 issue reported on code.google.com by mcgratta on 2009-06-04 14:44:37

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-04 14:49:32

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-04 15:25:05

---

• Attachment: add1.jpg
• Attachment: ADD-dropinEveryPatch.jpg

[gforney]

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 issue reported on code.google.com by mcgratta on 2009-06-04 15:35:13

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-08 12:18:31

[gforney]

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 issue reported on code.google.com by mcgratta on 2009-06-08 12:37:06

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-08 12:44:47

[gforney]

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

Original issue reported on code.google.com by mcgratta on 2009-06-08 13:24:47

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-29 14:23:00

---

• Attachment: PatchAnalysis.xls
• Attachment: Droplets.ppt

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-29 21:06:34

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-30 12:45:27

[gforney]

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 issue reported on code.google.com by shostikk on 2009-06-30 13:34:01

[gforney]

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

Original issue reported on code.google.com by pfhart@comcast.net on 2009-06-30 13:49:58

[gforney]

Please, it would be great!

Original issue reported on code.google.com by shostikk on 2009-06-30 13:52:39

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-30 13:57:28

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-30 14:27:42

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-30 14:34:05

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-30 18:35:33

[gforney]

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 issue reported on code.google.com by pfhart@comcast.net on 2009-06-30 18:56:07

[gforney]

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 issue reported on code.google.com by drjfloyd on 2009-06-30 21:13:57

[gforney]

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 issue reported on code.google.com by mtabaddor on 2009-07-13 19:44:02

[gforney]

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 issue reported on code.google.com by mcgratta on 2009-07-13 21:23:11

[gforney]

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

Original issue reported on code.google.com by mcgratta on 2009-07-24 17:25:40

• Labels added: Milestone-FDS_5.5

[gforney]

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

Original issue reported on code.google.com by mcgratta on 2010-01-28 22:41:42

[gforney]

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 issue reported on code.google.com by mcgratta on 2012-05-17 20:28:53