Transcript Issues in Converting mfire

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.
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.
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
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.
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
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
Expanding the mfire model
• Limitations
• Fundamental Problem
• Fortran Issues
•
Common Block
•
Data Block
•
Unformatted Files
• Model computational consistency – Highest Priority
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)
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
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 convoluted WRITEs
COMMON Blocks
COMMON /CTRL/
NAV,MAXJ,INFLOW,CRITSM,CRITGS,CRIT
HT,NBR
COMMON /NTWK/
NO(NMX),JS(NMX),JF(NMX),NWTYP(NM
X),R(NMX),Q(NMX),P(NMX),KF(NMX),LA(
NMX),A(NMX),O(NMX),RSTD(NMX),DZR
D(NMX),FRNVP(NMX),NREV(NMX),RDCH
4(NMX),RDPROP(NMX),TRD(NMX),TJS(N
MX),RDOP(NMX),RCH4(NMX),FFRNVP(N
MX),RA(NMX),NNREV(NMX)
COMMON /FAN/
NOF(IMX),NFREG(IMX),RGRAD(IMX),NFC
W(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
DATA Blocks
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,J
SB
.
/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
.
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
/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.
Unformatted files
OPEN (10,FILE='MFCTL1',STATUS='UNKNOWN',FORM='UNFORMATTED')
READ (10) NETWW
IF (NETWW.EQ.1) GO TO 350
OPTION='
FORTRAN has an unformatted
file format that is a great time
save for the FORTRAN
programmer and a nightmare for
any other language
'
MD1='
'
MD2='
'
OPEN (21,FILE='MFCTL2',STATUS='UNKNOWN',FORM='UNFORMATTED')
The format is a record and a
counter after the record written
to the file in binary
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
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
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
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
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
• 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 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.
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