Difference between revisions of "1D Pumps"

From Tuflow
Jump to navigation Jump to search
 
(105 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<font size = 18>Page Under Construction</font>
 
<br>
 
<br>
 
<br>
 
 
=Introduction=
 
=Introduction=
This post provides a modelling example for a 1D pump using a fixed flow rate and pump curve. For this example we will model a pump in two common situations (2D-2D & 1D-2D).
+
This post provides a modelling example for a 1D pump using a pump curve. For this example we will set up a pump in two common situations (2D-2D & 1D-2D).
 +
 
 
=Pump Attributes=
 
=Pump Attributes=
The 2D and 1D check files can be controlled separately by having the <font color="blue"><tt>Write Check Files </tt></font> <font color="red"><tt>==</tt></font> in both the .tcf and .ecf files. However,
+
A pump needs to first be digitised in a 1d_nwke layer. The direction of the polyline must go from inlet to outlet as a pump is unidirectional (see Section 5.9.2.1 Pumps). The attributes required for a pump in your 1d_nwk layer can be found within the 2018 TUFLOW manual.<br>
<font color="blue"><tt>Write Check Files </tt></font> <font color="red"><tt>==</tt></font> in the .tcf file will automatically also write the 1D check files.  There is no need to specify <font color="blue"><tt>Write Check Files </tt></font> <font color="red"><tt>==</tt></font> in the .ecf file unless a different folder path for the files is desired.<br>
+
In the 1d_nwk layer, the following attributes are required:<br>
The check files for big models can get very large and consume quite a lot of hard drive space. It is possible to exclude or include certain check file types.  This is done by specifying either "Include" or "Exclude" to the left of the equals sign:<br>
+
#ID = ID of the pump channel. <br>
<font color="blue"><tt>Write Check Files Exclude </tt></font> <font color="red"><tt>==</tt></font><tt> <file list></tt><br>
+
#Type = "P" or "PO". <br>
<font color="blue"><tt>Write Check Files Include </tt></font> <font color="red"><tt>==</tt></font><tt> <file list></tt><br>
+
#US_Invert = Intake elevation of the pump. <br>
The file list is a space separated list of files. To exclude the large grd, uvpt and zpt files specify:<br>
+
#DS_Invert = Outlet elevation of the receptor. <br>
<font color="blue"><tt>Write Check Files Exclude </tt></font> <font color="red"><tt>==</tt></font><tt> zpt uvpt grd</tt><br>
+
#Inlet_Type = Used to specify the pump curve in the Depth Discharge database. <br>
To output only the gridded elevations (DEM_Z) the command would be :<br>
+
#Width_or_D = Diameter of the pump’s outlet pipe/hose. <br>
<font color="blue"><tt>Write Check Files Include </tt></font> <font color="red"><tt>==</tt></font><tt> DEM_Z</tt><br>
+
#Number_of = Number of (identical) pumps. 
 +
<br>  
 +
[[File:1d_nwk_pump_pipe.PNG|border|300px]] <br>
 +
 
 
=2D-2D Configuration=
 
=2D-2D Configuration=
Depending on the size of the model, the check files may contain a large amount of data, for example the _grd_check file may contain thousands or millions of cells. As a modeller you probably won't inspect each cell to ensure that the data is value, however you may want to view this for the entire model. Thematic mapping or styling the input layers can be used in your GIS software to do this.
+
Because pumps are zero length channels they do not create automatic nodes at the upstream and downstream end. If you ran the model with just a pump polyline and SX connection you will get [[TUFLOW_Message_1353| <font color="red"><tt>ERROR 1353 - No NA data for Node</tt></font><tt>.</tt>]]To remove this error, the most efficient schematisation is to digitise a 1d_nwk 'NODE' at the upstream and downstream end of the pump (no need for a separate 2d_bc SX layer). The 'NODE' requires a nominal storage amount in the “Len_or_NA” attribute, in addition infill 'SX' into the "Conn_1D_2D" attribute to connect the 1d pump to the 2D domain. SX connections are required at connections to 2D domains to transfer water from the 1D node to the 2D. Without the SX connection, water will build up within the node and cause an instability. See the example below.<br>
Some tips are given below for a range of GIS platforms, however, the functionality is likely to be available in almost all GIS platforms:<br>
+
 
* [[QGIS_Style_Check_Files | QGIS style check files]]
+
[[File:1d_nwk_pump_SX_node.PNG|border|300px]] <br>
* [[MapInfo_Style_Check_Files | MapInfo style check files]]
+
 
* [[ArcMap_Style_Check_Files | ArcMap style check files]]
+
A simple 2D-2D pump configuration will look like the below schematisation. <br> 
 +
 
 +
[[File:Pump_schematic.PNG|border|600px]] <br>
 +
 
 
=1D-2D Configuration=
 
=1D-2D Configuration=
Connecting a pump from a 1d network to the 2d domain or vice versa is similar to the configuration above, the only difference is that the connection with a 1d structure does not require a 2d SX connection or 1d nwke ‘Node’. A storage chamber in the 1d network can also be modelled using a 1d_na node with an elevation vs area .csv assigned to the node. <br>
+
Connecting a pump from a 1d network to the 2d domain or vice versa is similar to the configuration above, the only difference is that the connection with a 1d structure does not require a 1d nwk ‘Node’. A storage chamber in the 1d network can also be modelled using a 1d_na node with an elevation vs area .csv assigned to the node. <br>
[[File:1D-2D_configuration_v1.png|border|600px]] <br>
+
[[File:1D-2D_pump_schematisation.PNG|border|600px]] <br>
  
 
=Estry Control File Setup=
 
=Estry Control File Setup=
Within the *.ecf the following commands and files are at a minimum required to run a pump with no logically control:<br>
+
Within the *.ecf the following commands and files are required to run a pump with no logical controls:<br>
<br>
 
 
<font color="blue"><tt>Read GIS Network</tt></font> <font color="red"><tt>==</tt></font><tt>..\model\mi\1d_nwke_xxxxx.MIF</tt><br>
 
<font color="blue"><tt>Read GIS Network</tt></font> <font color="red"><tt>==</tt></font><tt>..\model\mi\1d_nwke_xxxxx.MIF</tt><br>
 
<font color="blue"><tt>Depth Discharge Database</tt></font> <font color="red"><tt>==</tt></font><tt>..\bc_dbase\xxxxx.csv</tt><br>
 
<font color="blue"><tt>Depth Discharge Database</tt></font> <font color="red"><tt>==</tt></font><tt>..\bc_dbase\xxxxx.csv</tt><br>
<br>
+
If you do not specify a Depth-Discharge database then you will be faced with <font color="red"><tt>ERROR 1118 – Could not find a y-Q curve</tt></font><tt>.</tt><br>
If you do not specify a Depth-Discharge database then you will be faced with <font color="blue"><tt>ERROR 1118 – Could not find a y-Q curve</tt></font><tt>.</tt><br>
+
 
+
=TUFLOW Operating Control File (.TOC)=
The table below contains a complete list of the 2D check files. Note that for linked 2D/1D or 2D/2D models these check files are outlined in the sections below.
+
For guidance on setting up the operating controls for pumps, see section 5.9. in the latest TUFLOW Manual. <br>
{| align="center" class="wikitable" width="75%"
+
 
 +
.ecf command required: <br>
  
! style="background-color:#005581; font-weight:bold; color:white;"| Filename prefix / suffix
+
<font color="blue"><tt>Read Operating Controls File</tt></font> <font color="red"><tt>==</tt></font><tt> xxxxx.toc</tt><br>
! style="background-color:#005581; font-weight:bold; color:white;" width=75%| Brief Description
 
|-
 
| [[Check_Files_2d_bc_tables | _2d_bc_tables_check.csv]]|| Tabular data as read from the boundary condition database via any 2d_bc layers and after any adjustments (eg. time shift).  Provides traceability to original data source.  '''Note: the boundary values do not include the effects of any 2d_bc attributes such as f.'''
 
|-
 
| [[Check_Files_2d_bcc_check | _bcc_check.mif<br>_bcc_check_R.shp<br>]]|| GIS files providing trace back information and uses cells, rather than point/line objects to show 2D BCs.
 
|-
 
| [[Check_Files_2d_DEM_M | _DEM_M.flt<br>_DEM_M.asc]]|| A DEM of the final material ID values, similar to the DEM_Z check grid described below.  The .tcf command Grid Format can be used output this check file in ASCII format rather than the default FLT format.
 
|-
 
| [[Check_Files_2d_DEM_Z | _DEM_Z.flt<br>_DEM_Z.asc]]|| A DEM of the final ground/bathymetry elevations, including those from any 1D WLL mesh.  The file is given a DEM_Z extension, and can be readily opened by most GIS and other GUIs.  The default size of the grid cells is half the smallest 2D cell size.  This can be changed using the <tt>Grid Output Cell Size == </tt>command.  To exclude writing this file, include “DEM_Z” in the Write Check Files EXCLUDE list.  The <tt>Grid Format == </tt> command can be used to control the format of the file. <br>
 
The DEM_M and DEM_Z check grids are written if the model start up is forced to only process the .tgc file.  To do this, don’t specify or comment out, the BC Control File command.
 
|-
 
| [[Check_Files_2d_dom | _dom_check.mif<br>_dom_check_R.shp]]|| Contains a rectangle for each 2D domain showing the location, orientation and size of the domain.  Within this domain, cells can be turned on or off, outside this domain no 2D calculations can be performed.
 
|-
 
| [[Check_Files_2d_fc | _fc_check.mif<br>_fc_check_R.shp]]|| GIS layer of the final arrangement of flow constrictions (FC).  The flow constrictions are written as individual square cells of the same shape as the grid cells, even if the FC was specified using points or lines/polylines.
 
|-
 
| [[Check_Files_2d_fcsh_uvpt | _fcsh_uvpt_check.mif<br>_fcsh_uvpt_check_P.shp]]|| Contains information on adjustments to the ZU/ZV cell sides as modified by <tt>Read GIS FC Shape == </tt> commands.
 
|-
 
| [[Check_Files_2d_glo | _glo_check.mif<br>_glo_check_P.shp]]|| GIS layer of any gauge level output (GLO) locations.
 
|-
 
| [[Check_Files_2d_grd | _grd_check.mif<br>_grd_check_R.shp]]|| GIS layer of the final 2D grid.  Represents the final grid including modifications from the .tgc file, boundary specifications and flow constrictions.  Note that the Material and bed resistance (eg. Mannings_n) attributes do not include any modifications due to flow constrictions as these are applied directly to the cell mid-sides (rather than the cell centre).  To view these use the _uvpt_check.mif/.shp file.<br>
 
Can also be written at different stages within a .tgc file (see <tt>Write GIS Grid == </tt> command).  The file contains all modifications to the 2D grid at the point in the .tgc file that it is written. <br>
 
Note that a number of additional attributes are appended to the_grd_check layer when some features of TUFLOW have been used.
 
|-
 
| [[Check_Files_2d_input_layers | _input_layers.mif]]|| GIS layer contain full filepaths to all input layers used to compile the model.
 
|-
 
| [[Check_Files_2d_lfcsh_uvpt | _lfcsh_uvpt_check.mif<br>_lfcsh_uvpt_check_P.shp]]|| Contains information on adjustments to the ZU/ZV cell sides as modified by <tt>Read GIS Layered FC Shape == </tt> commands.
 
|-
 
| [[Check_Files_2d_LP | _lp_check.mif<br>_lp_check_L.shp]]|| GIS layer of any 2D longitudinal profile(s).
 
|-
 
| [[Check_Files_2d_PO | _po_check.mif<br>_PO_check_P.shp<br>_PO_check_L.shp]]|| GIS layer of any 2D plot output location(s).  The layer shows points and lines occurring from the cell centres, rather than their exact locations in the original file(s).  For the shapefile the points and lines are output in separate files, see also [[TUFLOW_FAQ#Shapefile_Geometry_Types | FAQ Shapefiles]].
 
|-
 
| [[Check_Files_2d_sac | _sac_check.mif<br>_sac_check_R.shp]]|| GIS layer of the lowest cell selected for <tt>Read GIS SA </tt> inputs, and cells selected if using <tt>Read GIS SA PITS </tt>.
 
|-
 
| [[Check_Files_2d_sh_obj | _sh_obj_check.mif<br>_sh_obj_check_R.shp]]|| Contains objects such as buffer polygons used for wide lines, triangles generated for TINs within polygons, and regions and polylines for thick and thin lines to illustrate areas that have been modified by Create TIN Zpts (if the WRITE TIN option is specified), Read GIS Z Shape, Read GIS Variable Z Shape, Read GIS FC Shape and Read GIS Layered FC Shape commands.
 
|-
 
| [[Check_Files_2d_uvpt | _uvpt_check.mif<br>_uvpt_check_P.shp]]|| GIS layer containing the initial velocities, roughness value, FLC, WrF, FC lid depth and FC BD factor at the U and V points.  For materials that vary Manning’s n with depth, the Manning_n attribute contains the Manning’s n value at the higher depth.
 
|-
 
| [[Check_Files_2d_vzsh | _vzsh_check.mif<br>_vzsh_check_P.shp<br>_vzsh_check_L.shp]]|| Contains information on Zpts that have been modified by <tt>Read GIS Variable Z Shape == </tt> commands.
 
|-
 
| [[Check_Files_2d_zln_zpt | _zln_zpt_check.mif<br>_zln_zpt_check_P.shp]]|| GIS layer containing Zpts that have been modified by <tt>Read GIS Z Line == </tt>commands, the type of Z Line and the Z Line filename.  This feature is very useful for checking which Zpts that the Z Lines have modified.  '''Note:  It does not include any GULLY lines.'''<br>
 
When written in .mif/.mid format, the points are given different symbology according to whether they have been raised or lowered (up or down triangles) or remain unchanged (a cross). 
 
|-
 
| [[Check_Files_2d_zpt | _zpt_check.mif<br>_zpt_check_P.shp]]|| GIS layer of the final 2D Zpts.  Represents the final Zpts including all modifications from the .tgc file, and any flow constrictions in the .tcf file.<br>
 
Can also be written at different stages within a .tgc file (see the <tt>Write GIS Zpts</tt> command).  The file contains all modifications to the 2D Zpts at the point in the .tgc file that it is written.  This allows checking of the elevations at different stages of building the topography.
 
|-
 
| [[Check_Files_2d_zsh_zpt | _zsh_zpt_check.mif<br>_zsh_zpt_check_P.shp]]|| Contains Zpts that have been modified by Read GIS Z Shape commands.  When written in .mif/.mid format, the points are given different symbology according to whether they have been raised or lowered (up or down triangles) or remain unchanged (a cross).
 
|}
 
  
 
=Depth Discharge Database=
 
=Depth Discharge Database=
==Constant Flow Rate==
+
The depth discharge database is set up in the same way as a pit inlet database, see 5.12.4 in the TUFLOW manual. Each pump ‘Inlet_type’ must reference a name within the depth discharge database, otherwise [[TUFLOW_Message_1118 | <font color="red"><tt>ERROR 1118  - Could not find pit inlet type ",a," in the pit inlet database</tt></font><tt></tt>]]. The ‘Area (m2)’ column is the area of the pump offtake and ‘Width (m)’ column is the width of the pump offtake. Without information in the Area(m2) or Width(m) columns in the depth discharge database <font color="red"><tt>Error 1092</tt></font><tt></tt> and <font color="red"><tt>Error 1093</tt></font><tt></tt> will appear. <br>
The table below contains a complete list of 1D check files.<br>
+
{| align="center" class="wikitable" width="75%"
+
==Pump Curve==
 +
The performance of pumps is a function of suction head at the inlet and the level of the discharge location. The resultant total head between the water level at the inlet and outlet is what determines the flow rate through the pump. If the suction level is low the pump will need to provide more energy in the form of pressure to maintain the water elevation at the outlet, the opposite is also true if the water depth at the pump inlet is high. <br>
 +
 
 +
[[File:pump_fundamentals_total_head.jpg|thumb|none|500px|www.pumpfundamentals.com]]
  
! style="background-color:#005581; font-weight:bold; color:white;"| Filename prefix / suffix
+
That being the case it is important to consider what total head is required to achieve the modelling objectives and what flow rates you may require. Once you have an idea on any limits in total head you can start to research an appropriate pump and then extract the performance curve that is often incorporated as part of the technical specifications. An example is shown below. <br>
! style="background-color:#005581; font-weight:bold; color:white;" width=75%| Brief Description
 
|-
 
| [[Check_Files_1d_bc_tables | _1d_bc_tables_check.csv]]|| Contains the inverts of the 1D nodes and at the ends of the 1D channels. Very useful for checking for smooth transitions from one channel to another and with the nodes. 
 
|-
 
| [[ Check_Files_1d_pit_inlet_tables |_pit_inlet_tables_check.csv]]|| Similar to the _1d_bc_tables_check.csv.  It contains tabular data as read from the pit inlet database.
 
|-
 
| [[Check_Files_1d_ta_tables | _ta_tables_check.csv]]|| Tabular data as read from tables via the 1d_tab layers for cross-section, storage and other data.   Provides full traceability to original data source and additional information such as hydraulic properties determined from a cross-section profile.  Flood Modeller XZ processed, and MIKE 11 processed cross-section data included.  Refer also to the _xsl_check layer.
 
|-
 
| [[Check_Files_1d_bc_check | _bc_check.mif<br>_bc_check_P.shp]]|| GIS .mif/.mid or .shp files of the final 1D boundary conditions (BC).  If no boundary conditions were specified, empty .mif/.mid or .shp files are written that can be used to set up a new layer.
 
|-
 
| [[Check_Files_1d_hydroprop | _hydroprop_check.mif<br>_hydroprop_check_L.shp]]|| Contains the hydraulic properties at the top of the hydraulic properties tables as attributes of the 1D channels.  Other information such as the primary Manning’s n is also provided.  Very useful for carrying out quality control checks on the 1D channels.
 
|-
 
| [[Check_Files_1d_inverts | _inverts_check.mif<br>_inverts_check_P.shp]]|| Contains the inverts of the 1D nodes and at the ends of the 1D channels. Very useful for checking for smooth transitions from one channel to another and with the nodes. 
 
|-
 
| [[Check_Files_1d_IWL | _iwl_check.mif<br>_iwl_check_P.shp]]|| GIS .mif/.mid or .shp files of the initial water levels at the 1D model nodes.
 
|-
 
| [[Check_Files_1d_mhc | _mhc_check.mif<br>_mhc_check_P.shp]]|| GIS layer of manholes including any automatically created manholes.
 
|-
 
| [[Check_Files_1d_nwk_C | _nwk_C_check.mif<br>_nwk_C_check_L.shp]]|| GIS .mif/.mid or .shp files of the final 1D model network.  This check layer contains the channels of the 1D domain only. The _nwk_N_check layer contains the nodes.<br>
 
The layers lines are coloured based on the channel type (available for the .mid/.mif format only).<br>
 
Any generated pit channels are shown as a small channel flowing from north to south into the pit node.  The upstream pit channel node that is generated is also shown.  The length of the pit channel is controlled by <tt>Pit Channel Offset == </tt> command.
 
|-
 
| [[Check_Files_1d_nwk_N | _nwk_N_check.mif<br>_nwk_N_check_P.shp]]|| GIS .mif/.mid or .shp files of the final 1D model network.  This check layer contains the nodes of the 1D domain only.  The _nwk_C_check layer contains the channels.<br>
 
The node symbology is displayed as a red circle for nodes connected to two or more channels, a larger magenta circle for nodes connected to one channel and a large yellow square for nodes not connected to a channel (available for the .mid/.mif format only).  '''This is very useful for checking for channel ends or nodes that are not snapped.'''<br>
 
The top and bottom elevations of the NA table at nodes is now shown using the Upstream_Invert and Downstream_Invert attributes.
 
|-
 
| [[Check_Files_1d_WLLo | _WLLo_check.mif<br>_WLLo_check_L.shp<br>_xWLLo_check.mif<br>_xWLLo_check_L.shp]]|| GIS layer of all the WLL objects read.  The attributes provide information on which nodes that area associated with, etc. <br>
 
The _WLLo_check layers are written for ESTRY 1D domains, whereas the _xWLLo_check layers are written for external 1D domains, such as Flood Modeller or XP-SWMM.
 
|-
 
| [[Check_Files_1d_WLLp | _WLLp_check.mif<br>_WLLp_check_P.shp<br>_xWLLp_check.mif<br>_xWLLp_check_P.shp]]|| GIS layer of where the points were generated along the WLLs.  These points can then be used for <tt>Read GIS WLL Points == </tt> command.<br>
 
The _WLLp_check layers are written for ESTRY 1D domains, whereas the _xWLLp_check layers are written for external 1D domains, such as Flood Modeller or XP-SWMM.
 
|-
 
| [[Check_Files_1d_xsl | _xsl_check.mif<br>_xsl_check_L.shp]]|| GIS layer containing tabular data as read from 1d_xs input layers.  Contains the XS ID and other useful information on the cross-section properties, etc.  Refer also to [[Check_Files_1d_ta_tables | _ta_tables_check.csv]].
 
|-
 
| [[Check_Files_1d_x1d_chans | _x1d_chans_check.mif<br>_x1d_chans_check_L.shp]]|| GIS layer containing the location of 1D channels from an external 1D domain.
 
|-
 
| [[Check_Files_1d_x1d_nodes | _x1d_nodes_check.mif<br>_x1d_nodes_check_P.shp]]|| GIS layer containing the location of 1D nodes from an external 1D domain.
 
|}
 
  
==Pump Curve==
+
[[File:Manufacturer pump curve.JPG|border|600px]]
The following check files will only be produced if a linked 1D / 2D model is created.
 
{| align="center" class="wikitable" width="75%"
 
  
! style="background-color:#005581; font-weight:bold; color:white;"| Filename prefix / suffix
 
! style="background-color:#005581; font-weight:bold; color:white;" width=75%| Brief Description
 
|-
 
| [[Check_Files_1d_to_2d_bc | _1d_to_2d_check.mif<br>_1d_to_2d_check_R.shp]]|| Displays the 2D cells connected to 1D nodes via 2D HX and 2D SX 2d_bc objects.  For the .mif/.mid format cells connected to the same node are given the same colour to allow for easy visualisation of whether the right connections have been made.  Additional information is supplied through the attributes.<br>
 
In the .mif layer, all SX cells connected to the same 1D node are grouped together as one object, and the Lowest_ZC_2D value is the lowest 2D cell ZC value of all the cells connected to the 1D node.  For the .shp layer, it’s not possible to group the cells as one object, so each cell is separate, and therefore, when clicking on the SX cells, note that the value is still the lowest ZC of all 2D cells, not of the individual cell.  For 2D HX links, the value is the ZC value of the individual cell.
 
|}
 
 
==Creating a TUFLOW pump curve==
 
==Creating a TUFLOW pump curve==
The following check files will only be produced if a multiple 2D Domain (linked 2D / 2D model) is created.
+
The setup of the Depth Discharge database for a pump curve is similar to reading in inflow hydrographs, hyetographs etc, that is; a source .csv, and the two corresponding headings within the 3rd and 4th column. <br>
 +
 
 +
[[File:depth-discharge_pump.PNG |border|500px]] <br>
 +
 
 +
Once you have your manufacturer curve for your given pump it is now necessary to create the curve .csv for TUFLOW to read in. The manufacturer specifications will need to be translated into a total head vs pump rate chart. Although reading in the depth discharge database is the same process as other boundary conditions within TUFLOW, the curve itself is fundamentally different as you no longer need to start the csv file with 0,0. If the curve did start at 0,0 this would not make sense because at a total head difference of 0m the pump should effectively be operating at peak performance so the flow rate would be greater than 0 m3. The image below shows a csv file for the pump performance curve given in the previous section. <br>
 +
<br>
 +
[[File:Pump_curve_csv_example.png|border|600px]] <br>
 +
 
 +
==Using a Pump Curve in a TUFLOW Operating Control (TOC) File==
 +
 
 +
With the pump curve defined in the depth-discharge database it can either be specified within the pump 1d_nwk fields in the inlet_type field, for non-operational pumps, or it can be defined with the TOC file, for operational pumps.  When defining with a TOC file, the pump curve is defined at the top of the structure control definition block and then the subsequent rules can turn the pump on/off.  See the below TOC structure control definition for an example.  In this case, the pump curve is used when the pump switches on once upstream water levels reach 2.75m AD.  The pump curve is then used until the upstream water levels are reduced to 2.25m AD at which point the pump is switched off.
 +
 
 +
<font color="blue"><tt>Define Pump Control</tt></font><font color="red"><tt> ==</tt></font> Pump_1
 +
<font color="blue"><tt>Pump Capacity</tt></font><font color="red"><tt> ==</tt></font> pump_1
 +
HU <font color="red"><tt>==</tt></font> H1D Pump1.1
 +
            <font color="blue"><tt>If </tt></font>HU <= 2.25
 +
                      <font color="blue"><tt>Pump Operation</tt></font><font color="red"><tt> ==</tt></font> Off
 +
            <font color="blue"><tt>Else if</tt></font>  HU > 2.25  <font color="blue"><tt>AND</tt></font> HU < 2.75
 +
                      <font color="blue"><tt>Pump operation</tt></font><font color="red"><tt> ==</tt></font> <font color="blue"><tt> No Change </tt></font>
 +
            <font color="blue"><tt>Else if</tt></font> HU <font color="red"><tt>>=</tt></font> 2.75
 +
                      <font color="blue"><tt>Pump Operation</tt></font><font color="red"><tt> ==</tt></font> On
 +
            <font color="blue"><tt>End if</tt></font>
 +
<font color="blue"><tt>End define</tt></font>
 +
 
 +
=1D Result File=
 +
Although strictly not a check file, the operation of the pump can be confirmed by opening the *_1d_O.csv which is found within the csv folder where the results are written. The *_1d_O.csv monitors the operation of structures, this file can be quite useful in checking how the structure is performing with the given .toc file and GIS inputs. <br>
 
{| align="center" class="wikitable" width="75%"
 
{| align="center" class="wikitable" width="75%"
 
 
! style="background-color:#005581; font-weight:bold; color:white;"| Filename prefix / suffix
 
! style="background-color:#005581; font-weight:bold; color:white;"| Filename prefix / suffix
 
! style="background-color:#005581; font-weight:bold; color:white;" width=75%| Brief Description
 
! style="background-color:#005581; font-weight:bold; color:white;" width=75%| Brief Description
 
|-
 
|-
| [[Check_Files_2d_to_2d_bc | _2d_to_2d_check.mif<br>_2d_to_2d_check_R.shp]]|| Displays the 2D cells used to link two 2D domains together via a 2d_bc type “2D” boundary.  Similar to the _1d_to_2d_check layer, the cells connected to the same hidden 1D node are given the same colour when using the .mif/.mid format.  Use the command <tt>Reveal 1D Nodes == ON</tt> command in the .tcf to view the locations of the hidden 1D nodes.  
+
| [[Pump_Results_1d_O | _1d_O.csv]]|| This csv displays the status of the pump, whether that is closed or fully open, results for any logic parameter specified in the TOC file and the flow through the pump if it is in operation.
 
|}
 
|}
 
+
<br>
Any further questions please email TUFLOW support: [mailto:support@tuflow.com support@tuflow.com]
+
Any further questions please email TUFLOW support: [mailto:support@tuflow.com?Subject=TUFLOW%201D%20pumps%20help support@tuflow.com]
 +
<br><br>
 +
{{Tips Navigation
 +
|uplink=[[ TUFLOW 1D Channels and Hydraulic Structures | Back to 1D Channels and Hydraulic Structures]]
 +
}}

Latest revision as of 18:07, 27 November 2023

Introduction

This post provides a modelling example for a 1D pump using a pump curve. For this example we will set up a pump in two common situations (2D-2D & 1D-2D).

Pump Attributes

A pump needs to first be digitised in a 1d_nwke layer. The direction of the polyline must go from inlet to outlet as a pump is unidirectional (see Section 5.9.2.1 Pumps). The attributes required for a pump in your 1d_nwk layer can be found within the 2018 TUFLOW manual.
In the 1d_nwk layer, the following attributes are required:

  1. ID = ID of the pump channel.
  2. Type = "P" or "PO".
  3. US_Invert = Intake elevation of the pump.
  4. DS_Invert = Outlet elevation of the receptor.
  5. Inlet_Type = Used to specify the pump curve in the Depth Discharge database.
  6. Width_or_D = Diameter of the pump’s outlet pipe/hose.
  7. Number_of = Number of (identical) pumps.


1d nwk pump pipe.PNG

2D-2D Configuration

Because pumps are zero length channels they do not create automatic nodes at the upstream and downstream end. If you ran the model with just a pump polyline and SX connection you will get ERROR 1353 - No NA data for Node.To remove this error, the most efficient schematisation is to digitise a 1d_nwk 'NODE' at the upstream and downstream end of the pump (no need for a separate 2d_bc SX layer). The 'NODE' requires a nominal storage amount in the “Len_or_NA” attribute, in addition infill 'SX' into the "Conn_1D_2D" attribute to connect the 1d pump to the 2D domain. SX connections are required at connections to 2D domains to transfer water from the 1D node to the 2D. Without the SX connection, water will build up within the node and cause an instability. See the example below.

1d nwk pump SX node.PNG

A simple 2D-2D pump configuration will look like the below schematisation.

Pump schematic.PNG

1D-2D Configuration

Connecting a pump from a 1d network to the 2d domain or vice versa is similar to the configuration above, the only difference is that the connection with a 1d structure does not require a 1d nwk ‘Node’. A storage chamber in the 1d network can also be modelled using a 1d_na node with an elevation vs area .csv assigned to the node.
1D-2D pump schematisation.PNG

Estry Control File Setup

Within the *.ecf the following commands and files are required to run a pump with no logical controls:
Read GIS Network ==..\model\mi\1d_nwke_xxxxx.MIF
Depth Discharge Database ==..\bc_dbase\xxxxx.csv
If you do not specify a Depth-Discharge database then you will be faced with ERROR 1118 – Could not find a y-Q curve.

TUFLOW Operating Control File (.TOC)

For guidance on setting up the operating controls for pumps, see section 5.9. in the latest TUFLOW Manual.

.ecf command required:

Read Operating Controls File == xxxxx.toc

Depth Discharge Database

The depth discharge database is set up in the same way as a pit inlet database, see 5.12.4 in the TUFLOW manual. Each pump ‘Inlet_type’ must reference a name within the depth discharge database, otherwise ERROR 1118 - Could not find pit inlet type ",a," in the pit inlet database. The ‘Area (m2)’ column is the area of the pump offtake and ‘Width (m)’ column is the width of the pump offtake. Without information in the Area(m2) or Width(m) columns in the depth discharge database Error 1092 and Error 1093 will appear.

Pump Curve

The performance of pumps is a function of suction head at the inlet and the level of the discharge location. The resultant total head between the water level at the inlet and outlet is what determines the flow rate through the pump. If the suction level is low the pump will need to provide more energy in the form of pressure to maintain the water elevation at the outlet, the opposite is also true if the water depth at the pump inlet is high.

www.pumpfundamentals.com

That being the case it is important to consider what total head is required to achieve the modelling objectives and what flow rates you may require. Once you have an idea on any limits in total head you can start to research an appropriate pump and then extract the performance curve that is often incorporated as part of the technical specifications. An example is shown below.

Manufacturer pump curve.JPG

Creating a TUFLOW pump curve

The setup of the Depth Discharge database for a pump curve is similar to reading in inflow hydrographs, hyetographs etc, that is; a source .csv, and the two corresponding headings within the 3rd and 4th column.

Depth-discharge pump.PNG

Once you have your manufacturer curve for your given pump it is now necessary to create the curve .csv for TUFLOW to read in. The manufacturer specifications will need to be translated into a total head vs pump rate chart. Although reading in the depth discharge database is the same process as other boundary conditions within TUFLOW, the curve itself is fundamentally different as you no longer need to start the csv file with 0,0. If the curve did start at 0,0 this would not make sense because at a total head difference of 0m the pump should effectively be operating at peak performance so the flow rate would be greater than 0 m3. The image below shows a csv file for the pump performance curve given in the previous section.

Pump curve csv example.png

Using a Pump Curve in a TUFLOW Operating Control (TOC) File

With the pump curve defined in the depth-discharge database it can either be specified within the pump 1d_nwk fields in the inlet_type field, for non-operational pumps, or it can be defined with the TOC file, for operational pumps. When defining with a TOC file, the pump curve is defined at the top of the structure control definition block and then the subsequent rules can turn the pump on/off. See the below TOC structure control definition for an example. In this case, the pump curve is used when the pump switches on once upstream water levels reach 2.75m AD. The pump curve is then used until the upstream water levels are reduced to 2.25m AD at which point the pump is switched off.

Define Pump Control == Pump_1
Pump Capacity == pump_1
HU == H1D Pump1.1
           If HU <= 2.25
                     Pump Operation == Off
           Else if  HU > 2.25  AND HU < 2.75
                     Pump operation ==  No Change		
           Else if HU >= 2.75
                     Pump Operation == On
           End if
End define

1D Result File

Although strictly not a check file, the operation of the pump can be confirmed by opening the *_1d_O.csv which is found within the csv folder where the results are written. The *_1d_O.csv monitors the operation of structures, this file can be quite useful in checking how the structure is performing with the given .toc file and GIS inputs.

Filename prefix / suffix Brief Description
_1d_O.csv This csv displays the status of the pump, whether that is closed or fully open, results for any logic parameter specified in the TOC file and the flow through the pump if it is in operation.


Any further questions please email TUFLOW support: support@tuflow.com

Up
Go-up.png Back to 1D Channels and Hydraulic Structures