Plant operating experience over the years has led clients to
be more demanding with regard to equipment design. This
experience is expressed in client specifications, codes and
standards. Heat exchanger design must meet requirements
Design basis and client specifications applicable for the
Use of specialty expertise available with the designer
(best practices, etc.)
Requirements from the process licensor.
These requirements exist in addition to the basic
requirements of heat transfer area and pressure drop. They are
maintained by heat exchanger designers in the form of a
checklist, and applied during design development. The checklist
can become quite extensive to cover various parameters that
influence thermal design. It is used with every exchanger on
the project, with the number of exchangers rising to 100-plus
for large projects like refineries and
In many designers experience, the use of this
checklist, although essential, can be monotonous and
time-consuming. Furthermore, the checklist cannot be
incorporated into general-purpose thermal design software. To
assist the designer, an Excel Visual Basic for Applications
(VBA)-based tool has been developed.
The checklist is established in an Excel format at the start
of the project. These requirements can be easily modified for
each service, client or project. The user must apply it to a
commercially available software programs design
output,1 and the program will display warning
messages for violations of requirements. This helps the thermal
designer quickly check the acceptability of each exchanger
design, improving productivity.
However, this automation process does not replace the manual
check that is required before finalizing the exchanger
configuration. The methodology for automating a checklist for a
shell-and-tube heat exchanger design in commercially available
software is discussed here.
Software output checking tool
The software allows the facility to export output reports in
an Excel format. The exported report is a fixed format. It
contains most of the parameters required for reviewing software
output. The tool makes use of the exported Excel file to read
the parameters required for checking. The flowchart for the
programming section is shown in Figs. 1 and
1. Algorithm used for checking
| Fig. 2.
Algorithm used for verification.
The checking tool consists of a requirements spreadsheet and
a mapping spreadsheet. The requirements spreadsheet is used to
define various checks required for software output.
Any checklist point can be split into two parts; one is
applicability, and the other is verification. An example is a
checklist point indicating, Cooling water velocity in the
tube side should be greater than 6 ft/s. This checkpoint
is applicable only for the exchangers that have cooling water
on the tube side, and the program verifies velocity only for
these exchangers. The verification conditions are defined
similarly to the applicability conditions.
A mapping spreadsheet contains the mapping of all the
software output parameters with their corresponding cell
locations in the exported software output files. The worksheet
tab name, the cell row number and the cell column number for
each parameter of the software output are specified in this
worksheet. The file needs to be set only once.
Background VBA code will read the location of each parameter
from this mapping sheet. Therefore, when a user wants to check
the tube-side velocity, the program will read the location of
the cell that contains tube-side velocity from the mapping
Some parameters are not reported in a single cell, but
rather spread out over many cells. These parameters are
shell-side monitor and tube-side
monitor. These parameters are reported in a particular
row, although they are spread across many cells over different
worksheet tabs. For this parameter, the value is written as
multiple in the mapping file. When the program
reads the location as multiple, it knows that the
parameter should be checked for multiple columns from the
To define applicability and verification, the software
output parameters listed in the mapping spreadsheet are used as
a dropdown list. The selection process is split into two
selections, for user convenience. Users must select the output
report name as it appears in the software output. Accordingly,
the options are displayed to the user for the next selection.
Each software parameter can be uniquely specified through these
The comparison rules are also listed in a separate worksheet
and are used as a dropdown menu. The various comparison
conditions hardcoded in the program are equal to, greater
than, less than, list, between and contain. These
comparison conditions are self-explanatory.
Tables 13 show the methods of
translating typical checklist points in an automated
1. Tube-side cooling water velocity should be between 6
ft/s and 9 ft/s (Table 1).
2. Inlet-nozzle dynamic pressure (measured as Rho
v2) should be greater than shell entrance Rho
v2. This checklist condition is applicable to all
exchangers. For such checkpoints, a dummy applicability
condition is defined that is evaluated to be true for all
exchangers (Table 2).
3. Tube length should be 8 ft, 10 ft, 12 ft, 16 ft or 20
ft (Table 3).
User calculation spreadsheet
A worksheet is created to read the software output values
for additional user-defined calculations. This worksheet also
makes use of software parameters listed in the mapping
spreadsheet. Each software parameter is accessed in a similar
way, as a means of defining applicability and verification.
The values of the software parameter will appear in a
specific cell in the corresponding row of the worksheet. This
cell can be linked to any other user-defined calculation. The
final result should then be linked in the requirements
spreadsheet to define the verification condition.
When the program executes, it initially updates the
parameters from software output to the requirements
spreadsheet. As a result, all user-defined calculations are
automatically updated. The updated values are then used for
A file-browse dialogue box is added as a user interface to
enable easy browsing and selection of the software output file
to be checked.
The automated checklist tool is useful in the thermal design
of heat exchangers. It can be used to quickly check the
acceptability of the design configuration based on various
project, client and services requirements. The use of this tool
helps increase the productivity of the thermal designer.
Furthermore, it is easy to customize the tool for various projects, clients and services. A
customized tool reduces checking time to 50% for exchangers,
which normally have 6070 checklist points. This concept
may be extended for the use of a checklist with commercial
The author thanks Mr. Mohan Chitale for initiating this
effort and taking it to finalization. The author also thanks
Technip management for supporting this work.
1 Heat Transfer Research Inc. (HTRI) is a
for-profit research consortium focused on studying heat
transfer and related thermal phenomena.
Shende is a senior heat transfer engineer at
Technip in Mumbai, India. He has over 10 years
of experience in the design of heat transfer equipment,
especially shell-and-tube heat exchangers. Mr. Shende
holds a bachelors degree in mechanical
engineering from Nagpur University in India, and a masters
degree in mechanical engineering from the Indian
Institute of Technology Kharagpur in India.