QA Piping Systems FluidFlow

8/20/2019 QA Piping Systems FluidFlow

1/15

© Piping Systems FluidFlow Quality Assurance


2/15

Piping Systems FluidFlow Quality Assurance2

©

Table of Contents

Part I Introduction 3

Part II The life cyle of Piping SystemsFluidFlow 3

................................................................................................................................... 41 Software Requirements and Specification

................................................................................................................................... 52 Overall Design and Architecture

................................................................................................................................... 53 Model Development

................................................................................................................................... 64 Algorithm Development

................................................................................................................................... 75 Coding

................................................................................................................................... 76 Integration

................................................................................................................................... 77 Integration Testing

................................................................................................................................... 88 Data

................................................................................................................................... 89 Installation

................................................................................................................................... 810 User Operation

................................................................................................................................... 911 Maintenance

Part III Calculation Methods andStandards Used 9

................................................................................................................................... 91 Standards Used

................................................................................................................................... 102 Liquid Pressure Loss Calculations

................................................................................................................................... 113 Gas Pressure Loss Calculations

................................................................................................................................... 114 Non Newtonian Fluid Pressure Loss Calculations

................................................................................................................................... 125 Settling Slurry Pressure Loss Calculations

................................................................................................................................... 126 Two Phase Pressure Loss Calculations

................................................................................................................................... 137 Physical Property Estimation Methods


3/15

3Introduction

©

1 Introduction

This document is an attempt to explain the procedures, processes and efforts madeby Flite Software NI Ltd, the developers of "Piping Systems FluidFlow", to minimisethe occurrence and impact of errors in the end user operation and functionality of oursoftware.

To be effective, a Software Quality Assurance policy needs to be an integral part of the entire life cycle of our software application. In addition, our Quality Assurancepolicy is continually evolving as we find more effective ways of developing andvalidating our software. This document provides an overview of where we are todayand how the "Quality Assurance focus" is integrated into our business and life cycleprocesses.

The life cycle of our product "Piping Systems FluidFlow" has many steps. Each stephas its own distinct validation requirements.

In this context validation is defined as establishing, by objective evidence, that all

software requirements have been implemented correctly and fully.

In addition to validating each process step the integrated product needs also to bevalidated.

The remainder of this document is therefore split into 2 logical chapters:

1. A description of the individual steps in our product life cycle.

2. An overview of the main standards and methods used in our calculationprocedures.

2 The life cyle of Piping Systems FluidFlow

The life cycle steps that occur in the development and post-development of ourproduct are itemised below. The validation involved in each step is then described ina separate sub section.

Development Steps:

Software Requirements and SpecificationOverall Design and ArchitectureModel DevelopmentAlgorithm DevelopmentCodingIntegration

Post Development Steps:


4/15

4 Piping Systems FluidFlow Quality Assurance

©

Integration TestingDataInstallationUser OperationMaintenance

2.1 Software Requirements and Specification

The main purpose of this software is to enable engineers to make designs of flowsystems that are:

· Practical· Safe· Efficient· Reliable

To achieve the above end user design goals, the software must be easy to use,comprehensive, robust, and of validated high quality using the latest, appropriate,calculation techniques and prediction methods.

Our product does not stop there, it is also important that the engineer cancommunicate their designs for peer review and directly to customers.

This document does not discuss further, design and specification of the user interface,or other functional input/output specifications but focuses on the main engineeringspecifications.

The product is designed to calculate phase state, pressures, pressure losses,temperatures and flows for any fluid(s) flowing in a piping system. The system mustbe at steady state conditions.

Phase states handled by the software can be liquid, gas, non-Newtonian, solid-liquidtwo phase slurries or liquid-gas two phase. There are many calculation methods,available in the literature that can be used for the prediction of energy losses inflowing systems and for the prediction of physical and transport properties that areneeded to support these calculations.

Unfortunately there are no agreed universal standards for the method to be used ineach specific case. Where internationally recognised design and calculation standardsor methods exist FluidFlow uses the appropriate standard. Standards and calculationmethods used are detailed in Standards chapter.

Where standards do not exist regarding a calculation method or physical propertyprediction FluidFlow always offers alternative methods to the end user.

It is the responsibility of the engineer/end user to exercise due care and diligence byselecting an appropriate method and to interpret the results with knowledge of thesimulation limitations.


5/15

5The life cyle of Piping Systems FluidFlow

©

It is recommended that all results should be subject to a proper engineering reviewand judgement by the end user.

Our validation procedures are designed to ensure each calculation method does notfail under extreme conditions.

2.2 Overall Design and Architecture

One of the main goals of our software architecture is to encapsulate each of the manyhundreds of "building blocks" used by the application.

In this context encapsulation means the ability to group code together to provide aservice or functionality accessible through a well designed interface. Encapsulationhides the internal workings of each building block and streamlines code testing.

By designing and validating in this way it allows us to define quality as a systemrequirement. It provides a higher degree of reliability and provides opportunities for

code reuse.

Take for example the request for a thermo physical property, say density, which iscommonly used by all of the calculation methods. The density of a fluid is a functionof phase state, pressure and temperature. At the most abstract level (i.e., the actualimplementation of the encapsulated building blocks/objects is more detailed thandescribed here.) all we need do is to make a call to a building block passing to theinterface the phase state, pressure and temperature and the object passes back thedensity, and maybe an status/error condition. Once the building block has beenwritten and validated it can be used without worry.

Of course, the detail is more complex and we must also consider data flows,

efficiency, what to do if an error is generated etc.

Designing in this way also makes the code more adaptable to changing technologyand business needs.

Encapsulation is critical to building large complex software that can be maintainedand extended. Many studies have shown that as new features and functionality areadded the risk of "breaking existing parts of the software" is minimised by having awell designed encapsulated product.

2.3 Model DevelopmentOur software uses many mathematical models to simulate physical phenomena.These models rely on established laws of physics or on empirical relationships. Oftenthe models are only approximate in nature or have a limited validity range.

Validation of these models includes dynamic, static and formal techniques.

Dynamic techniques demonstrate the software's behaviour in response to selectedinputs and conditions. We use prototyping to verify the hardware response to


6/15


©

software events and commands. Dynamic and static testing demonstrates compliancewith the engineering and functional specifications. Each test case has apredetermined, expected, explicit and measurable output result.

As an example, consider the pressure loss through a pipe bend. The total pressureloss across a bend is a function of bend geometry, the empirical relationship used, the

volumetric flowrate of the fluid, the constructional material of the bend (roughness of the inside wall), the fluid physical properties of density, viscosity and phase state.

Testing just one of these variables, say bend geometry, means comparing calculatedresults with research papers, textbook examples and hand calculated values for bendsof different angles, R/D ratios, circular, annular and rectangular cross sections andestablishing that the pressure loss calculation returns expected results in each case.Testing in this way also enables us to define limitations to accuracy which are thenused as warnings within the software. Without this detailed validation it is impossibleto specify the limits of accuracy, because they are often unavailable from literaturesources.

Sometimes textbook examples are incorrect and an element of engineering judgement is necessary to be able to identify this.

2.4 Algorithm Development

An algorithm is a logical procedure for solving a models mathematical equations. Ittakes input data and transforms it into output predicted by the model. We use logicand data flow diagrams to illustrate and define the logical sequence of events.

Algorithms serve as a bridge between the model and the code, where the programcode follows the sequence of activities required by the algorithm. Over the last 20years we have established well tested, efficient and tried algorithms for commonly

needed tasks.

Where possible these algorithms have been encapsulated. An example of a commontask when solving mathematical models is the need for a solution to an explicitequation.

Explicit equations cannot be solved directly but require an iterative solution.

Specifically, we might consider the calculation of friction factor via the Colebrook-White equation. By using an encapsulated, validated, generic algorithm such asNewton-Raphson, Successive Approximation or Secant we eliminate the need to writespecific code for the solution of the Colebrook-White equation.

Algorithm analysis is carried out to ensure that the criteria of accuracy, timing,stability and size requirements are met.

Consistency checks are made where appropriate. For example, consider the adiabaticflow of a compressible fluid in a pipe. To be consistent we should be able to take anyof the Fanno flow property relationships and ensure that these conditions areconsistent from low flows right up to the speed of sound.


7/15


©

2.5 Coding

Coding is the language used to communicate the algorithm to the computer. Acompiler converts this code to an executable file. Our application produces oneexecutable file without the need for associated DLL's. This streamlines ourmaintenance and updates procedure.

Where possible we purchase "best of breed" toolkits, this avoids wasting time "re-inventing the wheel" and ensures an up to date look and feel to the software.

The compiler and integrated development environment we use provides excellentdebugging features which helps to validate new code and also speeds up the bugfinding and elimination process.

We operate a coding style using strict internal guidelines. This means that codewritten by one programmer is always consistent in its layout, structure and wellcommented. This allows for easier cross checking, helps cross-fertilise ideas and canbe quickly understood by all team members.

2.6 Integration

Our software is developed by a closely knit, experienced team of engineers andcomputer scientists. This means that the many building blocks in our software areoften written by different team members. Integration is the meshing of the individualcontributions into one coherent system. The use of a consistent coding style,documentation and our software architecture reduces potential problems in this area.

To facilitate easier development and integration all team members have access todesign documents, model descriptions, algorithm descriptions, engineeringspecifications and requirements, functional specifications, control flow diagrams, data

flow diagrams, source code and database files.

2.7 Integration Testing

Once the application is integrated/assembled into a complete product, there is a needfor a formal Quality Assurance testing procedure.

Before each release we undertake a formal testing procedure. Currently this testingprocedure takes about 20 man days of effort. As well as testing all aspects of the userinterface we have over 300 validation calculations.

The validation calculations are issued with each release of the software and can be

found at the following locations:

[The folder where FluidFlow is Installed]\QA Incompressible Flow[The folder where FluidFlow is Installed]\QA Compressible Flow[The folder where FluidFlow is Installed]\QA Non Newtonian Flow[The folder where FluidFlow is Installed]\QA Two Phase Flow[The folder where FluidFlow is Installed]\QA Scripting

Each time a user reports a bug, we add a validation example to our QA testing files sothat the likelihood of a re-occurrence is drastically reduced.


8/15


©

Validation examples are designed to test each calculation method used forconsistency, accuracy, repeatability. The Quality Assurance examples are also auseful source of explaining the capabilities of the software for a new user.

2.8 DataThe calculation methods used within the application often rely on some type of supporting data.

Typically this data may be used to describe physical properties, transport properties,to describe pressure loss against flow relationships or to support heat transfer andenergy balance methods.

The results delivered by Piping Systems FluidFlow are dependant upon the accuracyand relevance of input data.

Data contained in the support databases that are delivered with the application is not

all sourced, entered and validated by Flite Software NI Ltd. This is because thedatabases contain data entered by our end users. In this regard we act as a clearinghouse to merge data from a wide variety of users.

End users are recommended to validate all input and database data used in theircalculations.

2.9 Installation

Flite Software has made a special effort to simplify the installation process. We have

thousands of installations worldwide on a variety of operating systems.

We have code embedded in the application that checks that an installation has beensuccessful.

The application code is compiled into one executable file and we do not make anychanges or additions to the windows registry. For users operating in locked downenvironments we supply an installation 'footprint' as an alternative.

The software has also been fully tested for use within Terminal Services, Citrix, andNovell environments.

2.10 User Operation

All users are actively encouraged to feedback their experiences with our software.

Users can provide feedback via our website www.fluidflowinfo.com or directly via theapplication.

All code within the application is routed through exception handling constructs. Thismeans that if the software fails in any way, it writes to a log file providing the date,time, reason and type of each failure together with resource and status information

http://www.fluidflowinfo.com/


9/15


©

about the hardware where the failure occurred. This log file is called psff.elf and iswritten to the same folder that holds the single application executable file psff.exe.

2.11 Maintenance

Software maintenance is the main mechanism for making improvements, correctionsand adaptations to the application.

Corrective maintenance resolves errors found during the operation of the software.Each time a bug is reported to Flite Software NI Ltd, we verify that the bug exists andthen enter the details into our "tracking and resolution" system. We issue regularmaintenance releases.

The release numbering convention used by this product has the format [Major

Version].[Minor Version].[Build Number]. So for example if the current release is3.11.5 the next release will be either 3.11.6 or 3.12.0. The deciding factor on thenumber of the next release depends on the severity of any bugs found also on theenhancements and improvements made.

Perfective maintenance is carried out to improve the application performance or toadd or improve other program attributes. Only enhancements or new features causethe minor version number to change.

It is the users' responsibility to keep the software current via our website. We have aSoftware Assurance Policy that enables continued access to the downloads area of ourwebsite:

http://www.fluidflowinfo.com/Downloads/Downloads.asp

3 Calculation Methods and Standards Used

FluidFlow uses hundreds of engineering models and it is not the intention to list allpossible models here.

The models highlighted in this chapter represent the main models used by theapplication together with the references where appropriate.

3.1 Standards UsedThere are very few standards available for use when making fluid flow calculations.Piping Systems FluidFlow makes use of the latest standards and guides wherepossible.

For calculating pressure losses across control valves for liquid and gas flow thesoftware uses the following guide: ANSI/ISA-75,01.01-2002 - Flow Equations forSizing Control Valves.

For predicting all physical properties of water we use the IFC-97 formulations

http://www.fluidflowinfo.com/Downloads/Downloads.asp


10/15


©

developed by the International Association for the Properties of Water and Steam.

For calculation of liquid or gas flow pressure losses across orifice plates we use thepublication from the International Organisation for Standardisation - ISO5167-1:2003 Part 1. Measurement of fluid flow by means of pressure differentialdevices inserted in circular cross-section conduits running full.

For calculation of liquid or gas pressure losses through nozzles we use ISO5167-1:2003 Part 3.

3.2 Liquid Pressure Loss Calculations

For calculating liquid friction losses in a physical pipe of any material, we use theDarcy Weisbach equation and the Haaland formula for calculating friction factor. (

Haaland, SE (1983). "Simple and Explicit Formulas for the Friction Factor in TurbulentFlow". Trans. ASIVIE, J. of Fluids Engineering 103: 89–90.)

It is possible to configure the software to use the Hazen-Williams method forpredicting friction loss, this may be useful for designing fire protection and irrigationsystems. It is not recommended that users use this method for substances other thanwater. Overall fire sprinkler system design guidelines, are provided by the NationalFire Protection Association (NFPA) 13, (NFPA) 13D, and (NFPA) 13R.

Pressure losses through sprinklers can use the K method or the user can enter datadirectly from a specific manufacturer.

For the calculation of pressure losses through bends, tee and cross junction the usercan select from one of 4 available relationships:· Using relationships and data found in the Handbook of Hydraulic Resistance - 3rd

Ed - I.E. Idelchik.· Using relationships and data found in Internal Flow Systems - 2nd Ed - D.S. Miller· Using relationships and data found in Flow of Fluids through Valves Fittings and

Pipe - Crane Technical Paper 410· Using relationships and data found in AIR1168/1 - Thermodynamics of

Incompressible and Compressible Fluid Flow

Performance data for centrifugal pumps, positive displacement pumps are usuallytaken from manufacturers data. We have developed utility software that can read andconvert data directly from manufacturers catalogues.

Pressure Losses through valves can be calculated from generic relationships found inthe Miller and Idelchik references above. Additionally the software can userelationships based on Cv or Kv values which the user can enter.

Pressure losses through check valves use the K method.


11/15

11Calculation Methods and Standards Used

©

3.3 Gas Pressure Loss Calculations

For accurately calculating pressure losses in gas pipes there is no simple formula, asis the case for liquids. This is because the specific fluid physical properties of density,temperature and enthalpy do not remain constant over the pipe length.

The FluidFlow gas calculation routines are rigorous calculations which allow for theincrease in kinetic energy and changing physical properties that occur as gasaccelerates with pressure loss. The calculations allow for the changing non-idealbehaviour of the gas as it flows by using an equation of state to describe the changesin gas physical properties.

There are three equations of state (EOS) available within the software (BenedictWebb Rubin with Hans Starling modifications; Lee Kesler and Peng Robinson), it ispossible to select the most appropriate EOS for each physical property. Using the EOSthe gas thermophysical properties such as enthalpy and density are calculated as the

gas accelerates. An analytical solution to the EOS, energy and momentum equationsis not possible and FluidFlow solves these equations numerically. FluidFlow make noassumptions of gas ideality or adiabatic flowing conditions.

Our algorithm dynamically splits the pipe into segments based on an incrementaldensity change. For each segment, upstream conditions of flow, static pressure, staticdensity and static enthalpy are known and these are used to calculate downstreamstatic temperature and density. From these values it is possible to backsolve the EOSto obtain downstream static pressure. The energy equation and momentum equationscan now be solved for each segment. The method is a development of a paperoriginally published in The Chemical Engineer - Relief Line Sizing for Gases Part1 and2. Dec 1979 - HA Duxbury.

For pressure loss calculations across other fluid equipment items refer to the liquidssection.

3.4 Non Newtonian Fluid Pressure Loss Calculations

Piping Systems FluidFlow provides the user with the option of selecting one of 4possible calculation methods for determining pressure loss for Non-Newtonian fluidsflowing within a pipe system.

The available calculation methods are based on the relationships used to describe the

fluid rheology data. It is recommended that the user obtains fluid rheology data priorto making a Non-Newtonian calculation. The available rheology models are:

· Power Law with the friction factors calculated according to the relationshipsprovided by Ron Darby - Chemical Engineering Fluid Mechanics

· Bingham Plastic with friction factors calculated according to the relationshipsprovided in Darby together with the solution of Buckingham Reiner equation

· Hershel-Bulkley with friction factors calculated according to the method of Dodgeand Metzner

· Casson with friction factors calculated according to the method of Wilson Thomas


12/15


©

For calculation of pressure losses across other fluid equipment items the K factormethod is used. K factors are adjusted at low Reynolds numbers as recommended bySteffe - Non-Newtonian Flows in the Food Industry

3.5 Settling Slurry Pressure Loss Calculations

Piping Systems FluidFlow provides the user with the option of selecting one of 3possible calculation methods for determining pressure loss for the flow of settlingslurries through a piping system. For settling slurries, i.e., a “carrier fluid” conveyingsolid particles, the calculation is considerably more complicated than a liquidcalculation, due to the wide range of variables involved, viz particle size and sizedistribution, solids density and shape, percent solids, mixture velocity etc.

The accepted approach is to determine the ‘solids effect’, the extra friction losscaused by the solids content over that for an equivalent flow of the carrier fluid alone.The carrier fluid may be clean water if the solids are relatively coarse with no fraction

below about 0.4mm but solids smaller than 0.4mm can be held in suspension andcreate a ‘homogeneous’ carrier fluid, the friction characteristics of which needs to bedetermined.

A number of inter-related factors influence the excess pressure drop in a pipeline overthe pressure loss for water alone (or the carrier fluid if a fine particle fraction exists).The two main factors are the solids characteristics and the velocity of flow of themixture but pipe inclination is also important.

The design method is highly empirical. “Slurry Transport Using Centrifugal Pumps”,by KC Wilson, GR Addie, A Sellgren and R Clift provides the best reference with asynthesis of the authors’ many papers together with “Introduction to Practical Fluid

Flow” by R.P. King providing some useful additions.

These two references, and a considerable amount of literature research, provided thebasis for the development of the FluidFlow3 Slurry simulator.

FluidFlow simulates heterogeneous settling slurries according to three correlations:

· Durand-Condolios-Worster· Wilson-Addie-Sellgren-Clift· WASP

3.6 Two Phase Pressure Loss Calculations

When two-phase liquid gas flow occurs in pipes, many different flow patterns arecreated, depending on fluid properties, the relative rates of each fluid and the pipeinclination. There are large differences in flow behavior between horizontal, inclinedand vertical pipe flow. The pressure gradient (pressure loss per unit length) is flowpattern dependant. For a rigorous estimation of two-phase pressure drop we alsoneed to split the pipe into segmental lengths, similar to the approach used in gas pipecalculations.


13/15

13Calculation Methods and Standards Used

©

Our pressure loss algorithm dynamically splits the pipe into segments based on anincremental pressure change. The user can select from any one of 7 available models:

· Whalley Criteria (uses Friedel, Chisholm or Lockhart Martinelli, selection of methodis made by FluidFlow according to the criteria of Whalley)

· Drift Flux Model (2007 correlations)· Beggs and Brill (Extended Regions)· Friedel· Muller Steinhagen Heck· Chisolm Baroczy· Lockhart Martinelli

3.7 Physical Property Estimation Methods

Piping Systems FluidFlow can use any of the following thermophysical properties

during flow calculations. Density, Specific Heat, Thermal Conductivity, Viscosity, Heatof Vaporisation, Enthalpy, Melting Point, Vapour Pressure and Surface Tension.

The physical properties are often complex functions of pressure, temperature andphase state. Data needed to evaluate these properties at phase states, pressures andtemperatures in the physical world are stored in a physical property database thatcontains over 900 fluids.

The user can select any one of the following estimation methods:

For Liquid Density Prediction:· A single fixed Value

· Yamada Gunn method with a reference density· Spencer Danner method· Yamada Gunn method without a reference density· Interpolation from a table of values· Peng Robinson Equation of State· Benedict Webb Rubin Equation of State· Lee Kesler law of Corresponding States

For Liquid Specific Heat Capacity Prediction:· A single fixed Value· A polynomial approximation· Bondi estimation method·

Lee Kesler· Interpolation from a table of values

For Liquid Specific Heat Capacity Prediction:· A single fixed Value· A polynomial approximation· Latini estimation method· Sato Riedel estimation method· A log power law approximation method· Interpolation from a table of values


14/15


©

For Liquid Viscosity Prediction:· A single fixed Value· A log polynomial approximation· A natural log series· Interpolation from a table of values· Andrade method· Przezdziecki estimation method

For Vapour Pressure Prediction:· A log polynomial approximation· Interpolation from a table of values· Wagner estimation· Antoine estimation

For Gas Density Prediction:· Peng Robinson Equation of State· Benedict Webb Rubin Equation of State

· Lee Kesler law of Corresponding States

For Gas Specific Heat Capacity Prediction:· a polynomial based on ideal gas constants· Lee Kesler law of Corresponding States

For Gas Thermal Conductivity Prediction:· A polynomial approximation· Chung estimation method· Interpolation from a table of values

For Gas Viscosity Prediction:· A polynomial approximation· Chung estimation method· Interpolation from a table of values· Lucas corresponding states estimation

For Heat of Vaporisation Prediction:· A single fixed Value which is adjusted by the software as a function of temperature· An estimation method based on critical properties

For Liquid Surface Tension Prediction:· A linear approximation· An estimation method based on critical properties


15/15

Documents

QA Piping Systems FluidFlow