Expanding The Limitations Of The Mfire Simulation Model

1. Expanding The Limitations Of The Mfire Simulation Model Steven Schafrik, Research Associate, Virginia Center for Coal and Energy Research, Virginia Tech Rebecca Ruckman, Mine Ventilation Services, Inc.

2. Introduction • 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.

3. MVS Abbreviated History with mfire • 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

4. MineFire Features • 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.

5. Other Research • 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

6. Converting mfire • 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

7. Expanding the mfire model • Limitations • Fundamental Problem • Fortran Issues • Common Block • Data Block • Unformatted Files • Model computational consistency – Highest Priority

8. Limitations • “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)

9. A Fundamental Problem mfire1: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 • Where does the “500 Branches” come from? CMMN1.DAT? • Lines in the box are from memory debug statements • THIS IS A FUNDAMENTAL PROBLEM Variables and Arrays are accessed using these constants, the constants are inconsistent within the same program

10. FORTRAN Issues • 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 convolutedWRITEs

11. COMMON Blocks 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) • A way to pass information to functions while minimizing declarations • A complication for translating code to any other language

12. DATA 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/ Compiler complaints: Warning: In this DATA statement, there are more variables than values assigned to the variables.

13. Unformatted files 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 • 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

14. Tools for Change • 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

15. Miscellaneous Considerations • 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

16. A Case Study • 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 • Alight 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

17. A Case Study cont. • Thissimulation 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.

18. Conclusion • 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