Steven Schafrik, Research Associate, Virginia Center for Coal and Energy Research, Virginia Tech

Rebecca Ruckman, Mine Ventilation Services, Inc.

EXPANDING THE LIMITATIONS OF THE MFIRE SIMULATION MODEL

Engineers need a tool that can:

• Design, locate, and model components of the mine system, such as fire doors and fuel bays. Model fires in shops or fuel bays, or test gas dispersion (stench) for possible scenarios.

• Train, teach, and show mine personnel how a fire affects the mine. Indicate changes to the ventilation, time available for escape, and how fast the fume front moves.

• Investigate or estimate fires or possible fire scenarios. Predict what potentially could happen or analyze what has happened.

Introduction

•In 2001, MVS obtained a copy of mfire from the former US Bureau of Mines

•mfire was modified to combine the utility of the mfire code with the ability to run on Pentium computer processors, done using Compaq Visual Fortran• Modification including removal of prompts

• No computational code was modified

• Various “housekeeping” and structural modifications were made

•The results from this work became the kernel for the MVS MineFire program• A bridge program between VnetPC and mfire

• Simplified input and output also added schematics and graphing capabilities

MVS Abbreviated History with mfire

• Ability to import an existing ventilation network from VnetPC, or start a new model from MineFire. Import DXF files from AutoCAD or other CAD programs similar to VnetPC.

• Fully interactive schematic that allows editing and data entry of ventilation parameters, rock property data and temperatures without using table views. Table views allow the user to cut and paste data to and from Excel or other spreadsheet programs, useful for performing calculations and returning the answers to the program.

• Dynamic results view in the schematic that shows the progression of fume fronts and changes to the ventilation parameters over adjustable time increments. See the progression of the fire and the potential problems it may be causing.

• Ability to vary and control calculation parameters through the use of Control Card functions, including time increments, calculation precisions, use of the fan curve and more.

• Ability to change the properties of a branch between an ordinary airway, fire branch or fan branch during the course of an event through the use of a time table. Increased control of the simulation to approximate complex situations.

• Ability to display in Imperial or SI units and offers a conversion utility.

MineFire Features

• Research using the mfire model have been ongoing

• It is an extremely useful and interesting tool that is difficult for the average user to interact with

• Noted research (not exhaustive list):• University of Kentucky, Dr. Andrej Wala, several and very interesting

useful projects that involve mine fires and a model verification

• University of Nevada Reno, Dr. Frederick Harris, Jr., graduate students in early 2000s converted Fortran to C++

• West Virginia University, Lihong Zhou, 2009, Converted Fortran to C++, added a fire model (t-square), smoke model and database connection

• NIOSH funded, 2010, “Mfire 3.0” which allows for a connection to Excel and discrete event simulation

Other Research

• Recent research and studies have concentrated on re-writing mfire from FORTRAN

• A study was done by MVS in 2002 to look at re-writing and re-engineering the mfire model for a commercial product

• Both ANSI C and Visual Basic were investigated

• Development costs were prohibitively high

• By integrating the mfire model with accepted ventilation prediction software, development costs are minimized while keeping the same calculation engine in the original designs

• It does not matter which computer language is used to calculate a value, it is the calculation action itself which is important

Converting mfire

• Limitations

• Fundamental Problem

• Fortran Issues• Common Block

• Data Block

• Unformatted Files

• Model computational consistency – Highest Priority

Expanding the mfire model

•“Mfire allows networks of up to 500 branches and 10 fans.”

MFIRE1.F:PARAMETER (NMX=3500*2, NMY=2450*2, NMZ=105*2, IMX=70*2,

IMY=70*2,IMZ=70*2, LMX=105000*2, NXX=NMX*3)

…

BLOCK DATA

INCLUDE 'CMMN1.DAT'

PARAMETER ( K1=NMX*4, K2=NMX*3, K3=NMX*6, K4=NMX*8, K5=NMY*3,

. K6=IMX*2, K7=IMX*IMY*2, K8=LMX+NMY+1, K9=NMY+NMX,

. K10=NMY*2, K11=NMX*2+IMX*11, K16=NMZ*10*5, K22=NMX*2,

. K17=NMZ*10*5+NMX*2, K19=NMZ*22, K21=IMX*3, K23=NMY*4,

. K24=IMY*5+IMX*IMY*4, K25=NXX*3)

C

CMMN1.DAT:PARAMETER (NMX=1000, NMY=700, NMZ=700, IMX=30, IMY=20,

IMZ=20,LMX=30000, NXX=NMX*3)

Limitations

Where does the “500 Branches” come from? CMMN1.DAT?

Lines in the box are from memory debug statements

THIS IS A FUNDAMENTAL PROBLEMVariables and Arrays are accessed using these constants, the constants are inconsistent within the same program

A Fundamental Problemmfire1:NMX=7000, NMY=4900, NMZ=210, IMX=140, IMY=140,IMZ=140, LMX=210000, NXX=210000

Inside Sub INPUT: NMX=1000, NMY=700, NMZ=700, IMX=30, IMY=20,IMZ=20, LMX=30000, NXX=3000

• Variables are not defined• Leads to fundamental problem described

• Special compiler flags are needed

• INCLUDES, COMMON and DATA blocks are the source of the issues

• Many WRITE statements are inconsistent in style and FORTRAN is known for convoluted WRITEs

FORTRAN Issues

A way to pass information to functions while minimizing declarations

A complication for translating code to any other language

COMMON /CTRL/ NAV,MAXJ,INFLOW,CRITSM,CRITGS,CRITHT,NBR

COMMON /NTWK/ NO(NMX),JS(NMX),JF(NMX),NWTYP(NMX),R(NMX),Q(NMX),P(NMX),KF(NMX),LA(NMX),A(NMX),O(NMX),RSTD(NMX),DZRD(NMX),FRNVP(NMX),NREV(NMX),RDCH4(NMX),RDPROP(NMX),TRD(NMX),TJS(NMX),RDOP(NMX),RCH4(NMX),FFRNVP(NMX),RA(NMX),NNREV(NMX)

COMMON /FAN/ NOF(IMX),NFREG(IMX),RGRAD(IMX),NFCW(IMX),MPTS(IMX),QF(IMX,IMY),PF(IMX,IMY),NSKP(IMX),NEGQ(IMX),JSB(NMX)

COMMON Blocks

DATA blocks are ways to initialize variables, especially in BLOCKS

What is difficult to discern from the code snippet to the left and the full code is which variables are arrays and which are single values

This is a result of the lack of variable declaration in mfire source

New version has all variables defined and typed properly

DATA NO,JS,JF,NWTYP,R,Q,P,KF,LA,A,O,RSTD,DZRD,FRNVP,NREV,RDCH4,

. RDPROP,TRD,TJS,RDOP,RCH4,FFRNVP,RA,NNREV

. /K1*0,K2*0.0,NMX*0,K3*0.0,NMX*0,K4*0.0,NMX*0/

DATA NOF,NFREG,RGRAD,NFCW,MPTS,QF,PF,NSKP,NEGQ,JSB

. /K6*0,IMX*0.0,K6*0,K7*0.0,IMX*0,IMX*0,NMX*0/

DATA FC1,FC2,FC3,DK,FK,FKQ

. /K24*0.0/

DATA MNO,MEND,MSL,FNVP,RQ,INU,KNO,KJS,KJF

. /K8*0,K9*0.0,NMX*0,K25*0/

DATA JNO,T,Z,CH4C,JNOL,PROP,PRCH4,JLR

. /NMY*0,K5*0.0,NMY*0,K10*0.0,NMY*0/

DATA Blocks

Compiler complaints:

Warning: In this DATA statement, there are more variables than values assigned to the variables.

FORTRAN has an unformatted file format that is a great time save for the FORTRAN programmer and a nightmare for any other language

The format is a record and a counter after the record written to the file in binary

In order to do a valid comparison of all mfire calculations, the entire file in FORTRAN code must be changed to regular text files

This has potential to introduce rounding and other errors that will be difficult to track

OPEN (10,FILE='MFCTL1',STATUS='UNKNOWN',FORM='UNFORMATTED')

READ (10) NETWW

IF (NETWW.EQ.1) GO TO 350

OPTION=' '

MD1=' '

MD2=' '

OPEN (21,FILE='MFCTL2',STATUS='UNKNOWN',FORM='UNFORMATTED')

READ (21) OPTION

READ (21) MD1,TACC

IF (OPTION.EQ.'DONE') GO TO 350

NSTOP=0

MARKX=0

349 IF (NSTOP.GE.1) THEN

OPEN (25,FILE='JUMP',STATUS='UNKNOWN',FORM='UNFORMATTED')

WRITE (25) OPTION

ENDIF

Unformatted files

• The highest priority for this work was to not change the fundamental calculations of mfire

• Model results can be validated by looking at the output files, same inputs should yield the same outputs

• Problem: modification of the WRITE statements was done

• Problem: calculations are based on internal calculations, a final result does not indicate the source of the problem

• Model results can be validated by looking at the internal memory of the project at points in the calculation

• Equal memory means equal results

• Level of specificity can be determined and point of change without running in debug mode

• A memory dump tool was used exhaustively to validate the model results

Tools for Change

• Different compilers, different issues• Compaq Visual Fortran

• Worked fine with proper switches

• Original product used, no longer available

• PGI Visual Fortran

• Excellent compiler, with great cross-platform support

• Determines variables to be of a different type (single or double) than Intel

• Most tolerant to FORTRAN Structures

• Tested in x64 and Linux

• Intel Visual Fortran

• Results in very fast and efficient executable

• Computational results most comparable to Compaq Fortran

• Products in x64 and Linux

• All compilations have different memory profiles that are significant to mfire, the convergence tolerance is 5x105

• Integer divide

• 5 / 2.0 can yield 2, 3 or 2.5

Miscellaneous Considerations

• A simulation was conducted for a model with 3015 branches, 2347 junctions, and 102 fans.

• The ventilation system is designed with a central ramp system used for personnel and material transportation to the mine and working areas

• A light vehicle fire was simulated in the central ramp system

• The analyses illustrated a rapid spread of contaminates through the system to where personnel may be present, if no mitigation or fire suppressant equipment is utilized

• For mitigation analyses, the fire doors located in the access ramps, where contaminates spread from the central ramp system to the levels, were simulated as closed after ten minutes

• With mitigation implemented, the fumes spread to the levels prior to the doors closing but were restricted after closure, allowing fumes to start exhausting the system where personnel may be present

A Case Study

A Case Study cont.• This simulation

illustrates the source of the fire in the ramp system and the fume spread through working sections after 10 minutes.

• MineFire enables users with the ability to track fume fronts and propagation through color codes.

• The color codes are user defined based on various ranges in fume concentrations.

• Using the memory dump tool, it was possible to systematically change the mfire source code to expand the limitations

• The driving limitations were the number of branches (500 to 4,000), number of junctions (1,000 to 4,000), and number of fans (10 to 400) capable to be simulated.

• In progressing to that goal several other limits were expanded, such as the maximum number of iterations and the maximum allowed node number.

• The output file was modified in a way to output more data but not to disturb the post-processing capabilities of MineFire

• The current mfire kernel used by MVS is capable of taking the maximum allowable ventilation model from VnetPC and perform simulations without modification

• This approach varies from other approaches taken because it results in a commercial software application and was not a re-engineering of accepted simulation code and methodology

Conclusion