Thunderhead Engineering Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Forum moved to https://forum.thunderheadeng.com

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - swenson

Pages: [1] 2
1
Pathfinder / Re: SFPE Mode V Steering Mode
« on: October 18, 2016, 08:14:37 am »
Would it be possible to send us the two models so that we could understand what is happening? If you do not want to share publicly, please send directly to support@thunderheadeng.com.

Thanks,
Dan Swenson
Thunderhead Engineering

2
Pathfinder / Re: validation of a simple case
« on: June 01, 2016, 08:06:37 am »
Let me try to help.

Our Pathfinder Verification and Validation manual is available at: http://www.thunderheadeng.com/pathfinder/resources/

First, we regard the SFPE flow calculations (Human Behavior in Fire, June 2003, Society of Fire Protection Engineers) as validation data. The equations used in these calculations (see attached image) are based on experimental data. You can download a spreadsheet at the link given above. The Equations tab of the spreadsheet provides the equations. Further details are discussed in the SFPE Handbook of Fire Protection Engineering, 5th edition, chapter 59.

For a 1 m wide door, the SFPE flow rate is calculated as 0.92 pers/s. Using the number of people in the room, you can compare this calculation with the simulators you are testing. We provide SFPE calculation results for most of the validation problems described in the Verification and Validation manual (in particular, see "Chapter 3: Flow Rate Tests").

The experiments of Jun Zhang and Armin Seyfried described in "Chapter 2: Fundamental Diagram Tests" of the Pathfinder Verification and Validation manual can also be used to calculate the flow rates through a door. Their experimental data (see attached) shows a maximum specific flow of 1.5 pers/m-s at a density of about 1.8 pers/m^2 and was obtained by measuring the speed and density in a 3 m wide corridor. Flow in the corridor was controlled by adjusting the corridor entry and exit widths. If you take the same approach as used by SFPE, the door flow rate for a 1 m wide door with a 0.15 boundary layer would be 1.05 pers/s.

Both the Zhang and Seyfried paper and the Pathfinder manual present the results using the fundamental diagram.  I went back and looked at our calculations. The highest specific flow through a door that we calculated was about 1.7 pers/s-m (assuming a zero boundary layer) for the case with a 3 m entrance and 2.2 m exit. The corridor specific flow for this case was 1.27 pers/m-s at a density of 2.22 pers/m^2, so this is a case in which the corridor specific flow is in the region of high density where the specific flow is dropping (a region of experimental uncertainty). Using our calculated specific flow with no boundary layer value, the maximum flow rate for a 1 m door based indirectly on Zhang and Seyfried results would be a flow rate of 1.7 pers/s. If we assume the same 0.15 m boundary layer as in the SFPE calculations, the adjusted specific flow for the 2.2 m exit becomes 1.97 pers/s-m and a 1 m wide door would have a flow rate of 1.37 pers/s. I have not seen any door flow rate data from Zhang and Seyfried, but you might want to ask if they could provide it.

In general, the Zhang and Seyfried data would be expected to give higher flow rates, since the persons represented a younger age group.

The bottom line is that the results obtained with Pathfinder in Steering mode will reflect the assumed maximum speed and speed density profile. If you use the values that correspond to the SFPE data, you approximately recover the corresponding SFPE exit times. If you use the faster Zhang and Seyfried input, then you recover faster exit times. If you select SFPE mode, then the door flow rates will match the SFPE equations.

I will post the Pathfinder input files to our web site.

Sincerely,

Daniel Swenson
Thunderhead Engineering

3
PyroSim / Re: Setting Radiative Loss Fraction in PyroSim 2015.4.1214
« on: January 05, 2016, 01:33:04 pm »
In FDS 6.3.0 the the RADIATIVE_FRACTION was moved to the REAC line.

In PyroSim, you can specify RADIATIVE_FRACTION on the Byproducts tab of the Edit Reactions dialog (see attached image). Here is the NIST description from the release (https://github.com/firemodels/fds-smv/wiki/FDS-Release-Notes):

"The default radiative fraction in FDS has been 0.35; that is, the fire is assumed to radiate 35% of its energy. Most users simply accept this value because the literature does not provide an extensive database of these values. Radiative fraction is not an intrinsic property of a fuel; it varies with the size and environment of the fire. However, some fuels, like methane (natural gas), are known to radiate approximately 20%; and some fuels, like heptane and heavier hydrocarbons, radiate approximately 40%. Starting with FDS 6.3.0, certain select fuels like METHANE and HEPTANE will have default values of RADIATIVE_FRACTION other than 35%. METHANE and the alcohols will be 20%; heavier hydrocarbons 40%. Fuels for which we have no traceable reference will remain at 35%. Also, RADIATIVE_FRACTION is now set on the REAC line, not the RADI line. Old input files will be stopped with an ERROR to emphasize the change."

4
The post Mahesh is talking about is "Modeling Jet Fans, Part 3: Applications". At the end of the post is a zip file with the model files.

The INIT region is used to fill the garage with smoke. The input file provided in the original post just defined the SOOT concentration and by default the background species AIR filled the rest of the volume. FDS has changed and no longer allows the user to specify an INIT region that includes a background species.

The attached file shows how to work around this. We define MY_AIR as a lumped species that has the same properties as AIR. Then we initialize the garage using using MY_AIR and SOOT. The Supply vent will still provide AIR, the background species. So the garage will be filled initially with soot and air, then the fans will pull in fresh air to clear out the smoke.

See attached images and model.

5
PyroSim / Re: Fire Design
« on: November 16, 2015, 10:29:42 am »
If the vent is on the mesh boundary, you do not need to use a obstacle. You can just use a vent.

Spreading fires usually have a Heat Release Rate (HRR) that increases with time to a constant value with an eventual decrease. The HRR is equal to the Area * Heat Release Rate Per Unit Area (HRRPUA).

To define a HRRPUA that increases with time:

1. In the PyroSim interface you can select a t-squared fire that will increase  in a specified number of seconds to the maximum value.

2. Alternately, you can specify a "ramp" function that is defined by a set of Time-Value points for HRRPUA. These points are defined in a table with Time in the X value and HRRPUA in the Y value.

6
PyroSim / Re: Characterization of Candle Flames
« on: October 27, 2015, 08:18:12 am »
On 2/6/14 Anthony Hamins responded to the same question from me. He sent the following attachment with the note "Please see attachment, which was written for an early version of FDS. Good luck with your work."

The file from Anthony Hamins is named candle_y504.txt. I have also attached the file I used to make the video at https://www.youtube.com/watch?v=p9pjR9QWqT0. I did not use the direct numerical simulation option (DNS), which Anthony did use.

Daniel Swenson
Thunderhead Engineering
 

7
Under the News page of PyroSim (http://www.thunderheadeng.com/category/pyrosim/) click Quick Tips and you will see a post on t-squared fires. Open that post and then click on the link to the calculator. This will help you make plots of a t-squared fire.

In your case, you wanted a t-squared fire that rises to 3.2 MW at 120 s, then stays constant. To do this take the 3.2 MW and divide by the vent surface area (4 m^2) to get a HRRPUA (HRR per unit area) of 800 kW. So that is the value we will input. We also select t-squared fire option and the time as 120 s.

The attached file illustrates this.

Some more comments:

1. When I calculated D* to estimate the required grid size, the recommended largest size is 0.3 m. The attached model uses 0.25 m.

2. Remember that all geometry is snapped to the grid, so used the "snapped" geometry when calculating the correct HRRPUA.

3. I removed the controls that were in the original model.

4. I simplified the geometry of the original model. You will likely want to use multiple meshes if you must model such a large space.

5. The original model had no air supply, so combustion would stop when available oxygen was depleted. I opened the model by making holes in the -X and +X walls of the model.

6. This example actually helped us find a bug in modeling fire with vents (a new release should go out tomorrow). The bug is that the current release writes out a zero value for Fire Spread Rate. We really don't want to write anything. The quick work-around is to go the the Fire Spread Properties tab of the vent model and delete the zero value in the textbox and then click OK to close the dialog. A better approach is to assign the Fire surface to the top surface of the obstruction on which the fire is placed. That is done in the attached model.

Hope this helps,
Dan Swenson, Thunderhead Engineering

[ed]: I made the link a link instead of text.

8
PyroSim / Re: Meshes Alignment
« on: April 23, 2015, 01:26:28 pm »
Wilson,

The mesh alignment check bug has been fixed and will be in the next PyroSim release. The problem was that at about the sixth decimal place, the meshes actually had a gap between them so the alignment test assumed the meshes were independent and did not test for alignment. I would suggest that you input the mesh coordinates by typing in exact numbers, not using the mouse.

As far as refinement studies, you can either vary both meshes or just the one with the fire. Use the D* calculator (spreadsheet on our web to find the mesh size requirement for the  fire).

Daniel Swenson

9
PyroSim / Re: Meshes Alignment
« on: April 20, 2015, 08:20:23 am »
Wilson,

These meshes are clearly not aligned and PyroSim should have given you a warning message. You can see the mesh alignment constraints discussed either in the PryoSim User Manual or the FDS User Manual. To open, on the PyroSim Help menu, click PyroSim Manual or More Help.

The quick fix is for you to align the meshes. Since your model does not have very many cells, my recommendation is to just keep the same cell size in both meshes. I have done that in the attached model.

I will submit this as a bug to be fixed in PryoSim.

Thanks,
Daniel Swenson
Thunderhead Engineering

10
PyroSim / Re: Numerical instability
« on: April 15, 2015, 09:28:02 am »
I started to run the simulation and the quick answer for why your problem is crashing is that the pressure is continually declining. See the attached image (this is just a contour plot, it would be better to add a device measuring pressure to get a time history plot).

Unfortunately, I do not have time right now to try to debug your model, but somehow you are withdrawing more air than is being added to the model. Usually a building should have at least one vent open to the atmosphere to act as a supply. If you have a closed system, you need to make sure your total flow in and out of the building is zero.

Daniel Swenson
Thunderhead Engineering

11
PyroSim / Re: Pyrosim, Smokeview file not found and HVAC problem
« on: March 26, 2015, 09:29:44 am »
Torbjørn,

First, there is no problem with complex models, it is just difficult to debug them.

The simple answer to the problem is that you are not allowed to specify the flow on all ducts connected to an internal node. If you specify the flow, you apply to many boundary conditions to the problem. See the attached image. So, remove the fan from the Duct_HVAC_exit (both 1 and 2). That removes the problem, but now there is another problem that causes FDS to crash without a message.

I can spend some time on Monday looking at this.

What I would do it take your current model and simplify so there is only one duct network. Make sure this works, then start to add the other networks back in. That will isolate the problem.

Best wishes,
Dan

12
PyroSim / Re: Pyrosim, Smokeview file not found and HVAC problem
« on: March 24, 2015, 04:59:01 pm »
First, an interesting model, so good work there. However, there were several problems with this model that needed to be fixed, but the errors are understandable.

1. Because the model is complex, I simplified it and deleted most of the geometry. I retained the ceiling.
2. To help understanding, I used Grouping to organize the model.
3. You might want to consider multiple meshes and parallel processing

Here are a list of changes to the model.

1. Deleted an extra Vent.
2. Changed all HVAC ducts to reference the HVAC fan
3. Added the inlet vent and connected the vent to an HVAC node, then made a new HVAC duct that connects the vent to the central distribution node. This is necessary because an end node can only have one duct attached. See the image.
4. Reversed flow direction.
5. Outlet vents were so small they were collapsing to a point (remember that FDS moves all geometry to the mesh coordinates. If the mesh is large, then very small objects collapse to a point.

See the attached images to understand what I did. You will need to go back to your original model and make the same changes.

13
PyroSim / Re: Resuming simulation
« on: October 16, 2014, 03:09:01 pm »
This bug has now been fixed and will be corrected in the next release of PyroSim, which should occur next week (Week of October 20). As previously noted, PyroSim was not enforcing the requirement that fds input file obstructions be written in the same order for the first run and restart run.

This is not as trivial as it first appears. We use hash maps and sets to store the data and were not using linked versions in some cases where it was needed. Since non-linked maps and sets do not guarantee the iteration order, the order was changing when we wrote the file two different times.

14
PyroSim / Re: Resuming simulation
« on: October 09, 2014, 08:52:50 am »
Here is a bit more information about the PyroSim bug (Charlie can provide more details). We found that the obstructions are being written in a different order in the *.fds files written in the first run and the restart run. We assume that FDS requires exactly the same order. The bug is likely caused by how we are iterating through the obstructions as we write them. This should not cause a problem with a normal run, just a restart.

My guess is that we will have a fix by early next week.

Dan
Thunderhead Engineering

15
PyroSim / Re: Resuming simulation
« on: October 09, 2014, 08:45:56 am »
We have identified the problem in PyroSim and are working on the bug fix.

A temporary work-around is to manually run the problem. I can send detailed instructions if you would like.

Dan
Thunderhead Engineering



Pages: [1] 2