NIST Technical Note 1889v4
 

CFAST – Consolidated Fire 

and Smoke Transport 

(Version 7) 

Volume 4: Configuration Management 

Richard D. Peacock 

This publication is available free of charge from: 

http://dx.doi.org/10.6028/NIST.TN.1889v4 

NIST Technical Note 1889v4 

CFAST – Consolidated Fire 

And Smoke Transport 

(Version 7) 

Volume 4: Configuration Management 

Richard D. Peacock 

This publication is available free of charge from: 

http://dx.doi.org/10.6028/NIST.TN.1889v4 

October 2015 

CFAST Version 7.0.0 

GIT Revision: Gitv7-0-g4eddb8a 

UNITED STATES OF AMERICA

DEPARTMENT OF COMMERCE

U.S. Department of Commerce 

Penny Pritzker, Secretary 

National Institute of Standards and Technology 

Willie May, Acting Under Secretary of Commerce for Standards and Technology and Acting Director 

Preface 

The purpose of this document is to describe the policies and procedures for developing and maintaining CFAST. Such a document is commonly referred to as a Configuration Management Plan. 

Description of the theoretical basis of the model [1] instructions for its are contained in a separate user’s guide [2], and model assessment information is contained in a separate verification and 

validation guide [3]. 

iii
 
iv
 
 

Disclaimer 

The US Department of Commerce makes no warranty, expressed or implied, to users of CFAST, 

and accepts no responsibility for its use. Users of CFAST assume sole responsibility under Federal 

law for determining the appropriateness of its use in any particular application; for any conclusions 

drawn from the results of its use; and for any actions taken or not taken as a result of analysis 

performed using these tools. 

Users are warned that CFAST is intended for use only by those competent in the fields of 

fluid dynamics, thermodynamics, heat transfer, combustion, and fire science, and is intended only 

to supplement the informed judgment of the qualified user. The software package is a computer 

model that may or may not have predictive capability when applied to a specific set of factual 

circumstances. Lack of accurate predictions by the model could lead to erroneous conclusions 

with regard to fire safety. All results should be evaluated by an informed user. 

Throughout this document, the mention of computer hardware or commercial software does 

not constitute endorsement by NIST, nor does it indicate that the products are necessarily those 

best suited for the intended purpose. 

National Institute of Standards and Technology Technical Note 1889v1 

Natl. Inst. Stand. Technol. Tech. Note 1889v4, 31 pages (October 2015)

CODEN: NTNOEF 

This publication is available free of charge from: 

http://dx.doi.org/10.6028/NIST.TN.1889v1 

v
 
vi
 
Acknowledgments 

CFAST was originally developed by Walter Jones, formerly of NIST. 

Continuing support for CFAST is via internal funding at NIST. In addition, support is provided 

by other agencies of the U.S. Federal Government, most notably the Nuclear Regulatory Commission (NRC) and the Department of Energy (DOE). The NRC Office of Nuclear Regulatory 

Research has funded key validation experiments, the preparation of the CFAST manuals, and the 

continuing development of sub-models that are of importance in the area of nuclear power plant 

safety. Special thanks to Mark Salley and David Stroup for their support. Support to refine the 

software development and quality assurance process for CFAST has been provided by the U.S. 

Department of Energy. The assistance of Subir Sen and Debra Sparkman is gratefully acknowledged. 

The idea for this Guide originated with Jason Floyd, a co-developer of FDS and practicing 

engineer at Jensen Hughes. He readily saw the need for a clear description of the process of developing and maintaining FDS and Smokeview. This guide adapts the FDS process for the CFAST 

model. Bryan Klein, currently with Thunderhead Engineering, Inc., and Kristopher Overholt, currently with Continuum Analytics instituted a number of the internet tools that are described in the 

Guide, including the source code repository, issue tracking system, and discussion group sites. 

vii
 
viii
 
Contents 

Preface iii
 

Disclaimer v
 

Acknowledgments vii
 

1 Overview 1
 

2 Relevant Publications 3
 

3 Model Identification and Control 5
 

3.1 Project Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
 

3.2 Version Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
 

4 SQA Documentation 9
 

4.1 Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
 

4.1.1 Creating a Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . 10
 

4.1.2 Committing Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
 

4.2 Standards, Practices, Conventions, and Metrics . . . . . . . . . . . . . . . . . . . 10
 

4.3 Software Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
 

4.4 Model Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
 

4.5 Problem Reporting and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 11
 

4.6 Tools, Techniques, and Methodologies . . . . . . . . . . . . . . . . . . . . . . . . 12
 

4.7 Media Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
 

4.8 Supplier Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
 

4.9 Records Collection, Maintenance, and Retention . . . . . . . . . . . . . . . . . . . 13
 

4.10 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
 

4.11 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
 

5 Summary 15
 

References 17
 

ix
 
x
 
List of Figures 

3.1 CFAST SQA Organization Structure. . . . . . . . . . . . . . . . . . . . . . . . . .
 

xi
 

6 
xii
 
Chapter 1 

Overview 

The Consolidate Model of Fire and Smoke Transport (CFAST) is a two-zone fire model that predicts the thermal environment caused by a fire within a compartmented structure. Each compartment is divided into an upper and lower gas layer. The fire drives combustion products from the 

lower to the upper layer via the plume. The temperature within each layer is uniform, and its evolution in time is described by a set of ordinary differential equations derived from the fundamental 

laws of mass and energy conservation. The transport of smoke and heat from zone to zone is 

dictated by empirical correlations. Because the governing equations are relatively simple, CFAST 

simulations typically require a few tens of seconds of CPU time on typical personal computers. 

The purpose of this document is to describe the policies and procedures for developing and 

maintaining CFAST. Such a document is commonly referred to as a Configuration Management 

Plan, known through the rest of this document as “the Plan.” This document will be updated as the 

necessity arises and will establish and provide the basis for a uniform and concise standard of practice for CFAST development. It is based in part on IEEE Standard 828 [4] and ASTM E1355 [5]. 

The volumes that make up the CFAST Technical Reference Guide are based in part on ASTM 

E 1355, Standard Guide for Evaluating the Predictive Capability of Deterministic Fire Models [5]. 

ASTM E 1355 outlines the process of assessing the accuracy of a fire model. Volumes 1 through 3 

are the result of this evaluation process. The main purpose of the present volume is to describe the 

process by which the model software is developed and maintained. A model such as CFAST cannot 

remain static. As progress is made in fire science, the model needs to be updated and improved, 

but still shown to reliably predict the kinds of phenomena for which it was originally designed. 

This document describes the processes used during the development and deployment of the 

Consolidated Fire and Smoke Transport model (CFAST). This software quality assurance (SQA) 

plan is intended to guide the planning for modifications to the model, provide required reviews for 

both software and associated documentation of the model, define testing to be conducted prior to 

the release of an updated model, describe problem reporting and resolution procedures, and ensure 

all records, source code, and released software is kept available for the life of the code. While this 

report and many of our practices follow the Institute of Electrical and Electronics Engineers (IEEE) 

standard for software quality assurance, IEEE 730-2002 [6], other standards have been followed as 

well. Most notably, ASTM 1355-05, “Standard Guide for Evaluating the Predictive Capability of 

Deterministic Fire Models” [5] has been used extensively to guide the documentation, verification, 

and validation of the model. 

CFAST is intended for use only by those competent in the field of fire safety and is intended 

1
 
only to supplement the informed judgment of the qualified user. The software package is a computer model which has limitations based on the way it is used, and the data used for calculations. 

All results should be evaluated by a qualified user. 

The SQA process and requirements outlined in this document apply specifically to the CFAST 

and is focused on ensuring the quality of the numerical predictions of the model. The user interface that may be used to develop input for the model is included in this process to insure that 

changes to the model are reflected in the user interface and in the data files created by the user 

interface for use by the model. Of course, users must ensure that the input files developed for 

the simulations accurately reflect the desired model inputs, whether developed using the supplied 

user interface, another third-party interface, or manually input with a spreadsheet or text editor 

program. Documentation of these inputs is included as part of the model documentation outlined 

below. 

Documentation and configuration management for its companion visualization program Smokeview, is included in the documentation for the Fire Dynamics Simulator (FDS) and Smokeview [7]. 

2
 
Chapter 2 

Relevant Publications 

To accompany the model and simplify its use, at the National Institute of Standards and Technology 

(NIST) has developed a Technical Reference Guide [1], a User’s Guide [2], a Validation Guide 

[3], and this Configuration Management Guide. The Technical Reference Guide describes the 

underlying physical principles and summarizes sensitivity analysis, model validation, and model 

limitations consistent with ASTM E 1355 [5]. The User’s Guide describes how to use the model. 

The Validation Guide documents sensitivity analyses, model verification, model validation, and 

model limitations consistent with ASTM E1355 [5]. 

The U.S. Nuclear Regulatory Commission has published a verification and validation study of 

five selected fire models commonly used in support of risk-informed and performance-based fire 

protection at nuclear power plants [8]. In addition to an extensive study of the CFAST model, the 

report compares the output of several other models ranging from simple hand calculations to more 

complex computational fluid dynamics codes such as FDS developed by NIST. 

While this document and many of our practices make extensive use of ASTM 1355, “Standard 

Guide for Evaluating the Predictive Capability of Deterministic Fire Models” [5] to guide the 

documentation, verification, and validation of the model, other standards have been followed as 

well. Most notably, our software quality assurance processes were guided by the IEEE standard 

for software quality assurance, IEEE 730-2002 [6]. 

In addition, numerous related documents available at http://cfast.nist.gov provide a wealth of 

information concerning earlier versions of the model and its user interface. This software quality 

assurance (SQA) plan is intended to guide the planning for modifications to the model, provide 

required reviews for both software and associated documentation of the model, define testing to 

be conducted prior to the release of an updated model, describe problem reporting and resolution 

procedures, and ensure all records, source code, and released software is kept available for the life 

of the code. 

3
 
4
 
Chapter 3 

Model Identification and Control 

CFAST is developed and maintained by the Engineering Laboratory (EL), NIST). Like all projects 

at NIST, a designated project leader is responsible for directing and prioritizing model development, error correction, and preparation of documentation for the model development. The organization chart in Figure 3.1 provides a graphical representation of the software quality organization 

structure for CFAST 

Review and approval of software and documentation is part of the standard review process for 

any report or other product developed by NIST. A minimum of five reviews are required prior to 

release of reports or software, including two independent technical peer reviews, two technical 

and management reviews at the technical workgroup and division level, and a policy review at the 

NIST-wide level. This review is documented and recorded on the NIST standard form NIST 114 

along with official approval notification provided to the primary author of the product. 

CFAST is distributed exclusively through a NIST website dedicated to the CFAST model 

(http://cfast.nist.gov). Content of the website is the responsibility of the CFAST project leader 

and the NIST webmaster. Additions and changes to the website are made only with the approval 

of the CFAST project leader after any required NIST reviews. 

Document identification and control consists of placing all project files in a central location and 

maintaining a record of changes to those files. The central location is known as the Repository. 

3.1 Project Repository 

CFAST and Smokeview make use of GitHub, a free service to support software development for 

open source applications. GitHub uses Git version control software. Under this system a centralized repository containing all project files resides on an external server. A record of version number 

when a specific file was last changed is maintained. As an open source program, any individual 

can obtain a copy of the repository or retrieve specific versions of the repository. 

Each member of the CFAST development team has an account and password access 1 to the 

CFAST repository. In addition, anonymous users can “fork,” or copy, the repository and receive 

the latest versions of the source code, manuals, and other items. These users may make changes to 

their own copy of the repository and can suggest these changes to the CFAST developers by means 

1Access to the CFAST repository is by means of two-factor identification. 

5
 
Fire Modeling

Staff

Fire Modeling

Group Leader

Engineered Fire Safety

Group Leader

Engineered Fire Safety

Staff

CFAST

Technical Lead

CFAST

Project Team

- Approves all research activities

- Review and approval of all

reports and software

- Review and approval of group

reports and software

- Approves all changes to activities

- Assists in development and 

oversees SQA activities

- Manage development, testing,

maintenance, and release

of CFAST

- Responsible for compliance with

SQA plans

- Develop software specifications

- Responsible for product quality

- Implements software quality activities

- Design and implementation of product

and documentation

Washington Editorial

Review Board

- Provides independent policy,

technical, and editorial review

of all reports and software

- Provide independent technical

review of CFAST reports and

software

- Assists in implementation of SQA

activities

- Assists in implementation of SQA activities

- Responsible for implementation and

maintenance of software repository

error reporting, and user feedback

Fire Research Division

Chief

Figure 3.1: CFAST SQA Organization Structure. 

of a “pull request.” If the changes are approved by one of the developers, these changes then merge 

into the main branch of the repository. 

The current location of the CFAST repository is https://github.com/firemodels/cfast. 

The repository contains the following files: 

1. Compiled CFAST and Smokeview executables 

2. CFAST source code files 

3. CFAST documentation 

4. Input files for software testing, verification testing, and validation testing 

5. Experimental data files used for validation testing 

6. Scripts and post-processing utilities used for software testing 

7. Web pages and wikis containing notes and other information 

In the event of an unexpected change to the GitHub service and/or the CFAST repository, each 

member of the development team, plus interested third parties, has a copy of the repository on their 

local computer. At NIST, the staff computers are regularly backed up as well. Thus, there is very 

little chance that the project repository will be lost. If need be, the files could be moved to another 

open source software development site. 

3.2 Version Identification 

At the start of a simulation, CFAST writes header information to the Smokeview output file, 

CFAST output file, and the CFAST log file. This header information contains the version of 

CFAST used to perform that simulation. While each release is tagged with a specific version 

6
 
number (e.g., 7.0.0), there may be many commits of source code, documentation, or other files to 

the git repository before a new version is released with an incremented version number. Thus, if 

a developer or a user who performs their own compilation between baseline releases discovers an 

error, the version number written to the output files may not be sufficient to identify the specific 

set of source code files used. Rather, one would need to know the git revision number of the most 

recently committed source file. This is accomplished as part of the automated build and testing 

process where the git revision number is inserted into a source file that is used to identify the specific revision number, revision data, and compilation date for the CFAST model and user interface 

program, CEdit. 

7
 
8
 
Chapter 4 

SQA Documentation 

The released version of CFAST is documented by four primary publications, the Technical Reference Guide[1], the User’s Guide [2], the Verification and Validation Guide [3], and this Configuration Management Guide. The documents apply to the newest version of the model available on 

the NIST website. The Technical Reference Guide describes the underlying physical principles, 

provides a review of model verification and validation efforts by NIST and others, and describes 

the limitations of the model. The User’s Guide describes how to use the model, includes a detailed 

description of the model inputs and outputs, and provides a process to ensure the correct installation of the model. There are also documents archived on the website that are applicable to older 

versions of both the model and user interface. 

4.1 Development Process 

Changes are made to the CFAST source code daily, and tracked via revision control software. However, these daily changes do not constitute a change to the version number. After the developers 

determine that enough changes have been made to the source, they release a new minor upgrade, 

7.0.0 to 7.0.1, for example. This happens every few weeks. A change from 7.0 to 7.1 might happen only once a year, when significant improvements have been made to the model physics or 

numerics. 

There is no formal process by which CFAST is updated. Each developer works on various 

routines, and makes changes as warranted. Minor bugs are fixed without any communication 

(the developers are in different locations), but more significant changes are discussed via email or 

telephone calls. A suite of simple verification calculations (included in this document) are run each 

night to ensure that the daily bug fixes have not altered any of the important algorithms. A suite of 

validation calculations (also included here) are run each night. Significant changes to CFAST are 

made based on the following criteria, in no particular order: 

Better Physics: The goal of any model is to be predictive, but it also must be reliable. CFAST is 

a blend of empirical and deterministic sub-models, chosen based on their robustness, consistency, and reliability. Any new sub-model must demonstrate that it is of comparable or 

superior accuracy to its empirical counterpart. 

Simpler Algorithm: If a new algorithm does what the old one did using fewer lines of code, it is 

9
 
almost always accepted, so long as it does not decrease functionality or accuracy. 

Increased or Comparable Accuracy: The validation experiments that are part of this guide serve 

as the metric for new routines. It is not enough for a new algorithm to perform well in a few 

cases. It must show clear improvement across the entire suite of experiments. If the accuracy 

is only comparable to the previous version, then some other criteria must be satisfied. 

Acceptance by the Fire Protection Community: Especially in regard to fire-specific devices, like 

sprinklers and smoke detectors, the algorithms in CFAST often are based on their acceptance 

among the practicing engineers. 

4.1.1 Creating a Change Request 

Change requests are submitted using the CFAST Issue Tracker. The Issue Tracker is an online 

service provided by GitHub. A change request is initiated by opening a new issue. The issue 

report contains the baseline identification (version number, compile date, and revision number), 

operating system, and a description of the defect or enhancement request. Input files or other 

supporting documentation can be attached. If the issue is opened by a user, it will be given a status 

of New until it is reviewed by a developer. This typically takes a few minutes to a few hours, 

depending on the time of day the issue is reported. If the issue is opened by a developer, the 

developer can immediately assign a status and an owner. 

4.1.2 Committing Changes 

Once a developer has addressed a change request, the modified files are committed to the CFAST 

repository. A description of the changes will be added to the change log. This description first 

identifies the primary component being changed (for example: CFAST Source or CFAST Documentation). This component identification will be followed by a brief summary of the changes 

made. 

Changes to the CFAST source code and supporting documentation are reviewed by other 

members of the team. There is no formal system with which changes are reviewed because the 

frequency of changes makes it impractical. As a general rule, all team members watch for unintentional commits of copyrighted material or algorithms, and also proprietary data or case studies 

collected from an end user. CFAST itself does not include copyrighted or proprietary data, but 

occasionally this kind of information is submitted by an end user who has submitted a bug report. 

4.2 Standards, Practices, Conventions, and Metrics 

Prior to final implementation of a new feature or change, a review of the proposed modification 

is conducted by a developer who is not involved in the modification. This review includes review 

and concurrence of the software requirements and design specification as well as more detailed 

review of code changes as the complexity of the modification requires. Review and acceptance of 

the software requirements and design specification by interested project sponsors or users may be 

included as appropriate. Name and date of approval and/or review is noted electronically in the 

document. 

10
 
Review of the testing and validation report is also conducted by a developer who is not involved 

in the modification prior to proposed model release. Any significant changes in model output 

(typically a change greater than 1 % of a given output) should be explained based on changes to the 

code as a result of a new feature. Name and date of approval and/or review is noted electronically 

in the document. 

4.3 Software Reviews 

Software reviews are outlined as part of the standard practices described above. The standard 

NIST review process includes review of software and documentation prior to any report or product 

release by NIST. 

4.4 Model Testing 

Individual testing of model algorithms are made by the developers during any revision of the 

model. Often, this testing forms the basis for any new standard test cases included with future 

model releases. System release testing of the model prior to release includes the following: 

• Examination of results of test cases specific to any model modifications made as appropriate. 

Comparison with analytic solutions to simplified problems is desirable when available. 

• Examination of results of standard test cases included with the release version of the model. 

Any changes in the output from prior versions is explained (and documented in the software 

testing and validation results report) by modifications made to the model. 

• For major new releases of the model, a complete suite of test cases should be compared to 

those from previous versions of the model. At a minimum this includes the set of validation 

exercises described in U.S. Nuclear Regulatory Commission publication NUREG 1824 [8], 

but may include additional example cases or validation exercises as appropriate. 

• For all changes to the model, an automated testing process is used that provides automatic 

error checking and collecting performance and accuracy statistics between CFAST revisions. 

Results of this process for release version of the model are included in the Verification and 

Validation Guide [3]. 

4.5 Problem Reporting and Resolution 

NIST maintains an e-mail address specifically for inquiries and problem reporting for the CFAST 

model (cfast@nist.gov). These e-mails are directed to the CFAST project leader for response and 

resolution as appropriate. Inquiries and responses are catalogued and retained by the project leader. 

NIST has developed an automated reporting and resolution tracking website for use with the 

CFAST model to facilitate tracking and cataloging of inquires, problems, and model enhancements 

/ revisions. This is included as part of the CFAST website at http://cfast.nist.gov 

11
 
4.6 Tools, Techniques, and Methodologies 

The CFAST and Smokeview source codes undergo an automated build, verification, validation, 

and regression testing process, which is similar to a continuous integration system that automates 

the build/testing cycle for a project. This automated process is referred to as CFASTbot. The 

CFASTbot build/test process helps the CFAST development team by performing automatic error 

checking and collecting performance and accuracy statistics between CFAST revisions. 

The automated built/test verification process runs on a regular schedule (nightly) to ensure that 

CFAST and Smokeview are free of compiler errors, verification errors, or any other errors that 

would result in a failure during the build/test cycle. The automated build/test validation process 

runs continuously through the validation suite set-by-set. For future reference, the results of a 

build/test process are archived and tagged with the git revision number that was used. 

Upon completion of the automated build/test process, the results of the build/test process are 

dispatched to the development team. In the event of a failure, the build/test process continues when 

possible, and the appropriate error logs are dispatched to the development team. 

4.7 Media Control 

Release versions of the CFAST model are available exclusively on the CFAST specific website 

maintained by EL at NIST. This website is included in NIST’s automated backup and recovery 

system for computer systems organization wide. 

Development versions of the model are maintained by the CFAST project leader. All software and documents are included in NIST’s automated backup and recovery system for computer 

systems organization wide. As part of its model development, NIST maintains a web-based system for version control and history of both the CFAST source code and of pre-release and release 

executables for the software. 

These computer systems are available only to specified personnel, including the CFAST project 

leader and project team members. 

4.8 Supplier Control 

CFAST is entirely a product of NIST and as such does not include any commercial software libraries. The differential equation solver used by CFAST, DASSL, is a publicly available software 

package. Full source code for the solver as used by CFAST is maintained under version control 

with the rest of the model code. 

BFRL currently uses Microsoft Visual Studio 2013 and Intel Fortran Professional 2016 for 

development1. Prior to any change to a different development system, a full test suite of test cases 

are compared to verify consistent operation of the model and model results. 

1Certain commercial entities, equipment, or materials may be identified in this document in order to describe 

an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or 

endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, 

materials, or equipment are necessarily the best available for the purpose. 

12
 
4.9 Records Collection, Maintenance, and Retention 

All software, documentation, and SQA documents are retained by the CFAST project leader, typically in electronic form. Software and documentation is also maintained and archived on the NIST 

CFAST website as part of the version control software for the model. 

NIST management approval is required prior to destruction of old or out-of-date records. 

Records are typically maintained for a minimum of 25 years. 

4.10 Training 

No specific training is identified for use of this SQAP. Details of training requirements for use of 

the model included in the CFAST user’s guide is applicable to developers of the model as well. 

4.11 Risk Management 

The primary risk management tool for software developed and released by NIST is the official 

NIST review process for software, documents, and other products of NIST. Official approval is 

required prior to release of the model for general use. 

13
 
14
 
Chapter 5 

Summary 

This document describes the processes used during the development and deployment of the Consolidated Fire and Smoke Transport model (CFAST). This includes 

• Relevant documentation for the model: a Technical Reference Guide [1], a User’s Guide [2], 

a Validation Guide [3], this Configuration Management Guide, and publications by others 

on the accuracy of the model. 

• Control and tracking of the source code using a centralized project repository on GitHub. 

• An automated build, verification, validation, and regression testing process then helps the 

CFAST development team by performing automatic error checking and collecting performance and accuracy statistics between CFAST revisions. 

• Details of the review process used by the developers and NIST to ensure the quality of the 

model and related publications. 

Besides formal internal and peer review, CFAST is subjected to continuous scrutiny because 

it is available free of charge to the general public and is used internationally by those involved in 

fire safety design and post-fire reconstruction. The quality of the CFAST and Smokeview User 

Guides is checked implicitly by the fact that the majority of model users do not require a formal 

CFAST-specific training course, but are able to read the supporting documents, perform a few 

sample simulations, and then systematically build up a level of expertise appropriate for their 

applications. The developers receive daily feedback from users on the clarity of the documentation 

and add clarifications when needed. Before new versions of the model are released, there is a “beta 

test” period in which users test the new version using the updated documentation. This process 

is similar, although less formal, to that which most computer software programs undergo. Also, 

the source code for CFAST is released publicly, and has been used at various universities worldwide, both in the classroom as a teaching tool as well as for research. As a result, flaws in the 

theoretical development and the computer program itself have been identified and corrected. As 

CFAST continues to evolve, the user base will continue to serve as a means to evaluate the model. 

We consider this process as important to the development of CFAST as the formal internal and 

external peer-review processes. 

15
 
16
 
References 

[1] R.D. Peacock, K.B. McGrattan, G.P. Forney, and P.A. Reneke.	 CFAST – Consolidated Fire 

And Smoke Transport (Version 7) Volume 1: Technical Reference Guide. Technical Note 

xxxx, National Institute of Standards and Technology, Gaithersburg, Maryland, July 2015. iii, 

3, 9, 15 

[2] R. D. Peacock, P. A. Reneke, and G. P. Forney.	 CFAST – Consolidated Fire And Smoke 

Transport (Version 7) Volume 2: User’s Guide. Technical Note xxxx, National Institute of 

Standards and Technology, Gaithersburg, Maryland, July 2015. iii, 3, 9, 15 

[3] R. D. Peacock and P. A. Reneke. CFAST – Consolidated Fire And Smoke Transport (Version 

7) Volume 3: Software Development and Model Evaluation Guide. Technical Note xxxx, 

National Institute of Standards and Technology, Gaithersburg, Maryland, July 2015. iii, 3, 9, 

11, 15 

[4] Institute of Electrical and Electronics Engineers.	 IEEE Std 828-2005, IEEE Standard for 

Software Configuration Management Plans, 2005. 1 

[5] American Society for Testing and Materials, West Conshohocken, Pennsylvania.	 ASTM E 

1355-04, Standard Guide for Evaluating the Predictive Capabilities of Deterministic Fire 

Models, 2004. 1, 3 

[6] The Institute of Electrical and Electronics Engineers.	 IEEE Standard for Software Quality 

Assurance Plans, IEEE Std 730-2002 edition, 2002. 1, 3 

[7] K. McGrattan, S. Hostikka, R. McDermott, J. Floyd, C. Weinschenk, and K. Overholt. Fire 

dynamics simulator technical reference guide volume 4: Configuration management. Special 

Publication 1018-4, National Institute of Standards and Technology, Gaithersburg, Maryland, 

April 2015. 2 

[8] M.H. Salley and A. Lindeman. Verification and Validation of Selected Fire Models for Nuclear 

Power Plant Applications, Supplement 1. NUREG 1824, U.S. Nuclear Regulatory Commission, Rockville, Maryland, 2015. 3, 11 

17