You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »


1         General description

1.1      Introduction

The urban water balance tool (Figure 1) has been developed in EXCEL for application in urban area. Recently it has been transformed into a set of Python scripts. The water balance tool describes all possible urban water flows and the associated water resources. Rainfall-runoff, shallow groundwater (saturated and unsaturated), surface water and sewage (both mixed and stormwater drainage) are included. Water exchanges are included with atmosphere, deep groundwater, outside water and waste water treatment plant.

Figure 1      Schematic overview of Urbanwb model

In this figure:

ElementsWater flows

A

= area

P_atm

= precipitation

atm

= atmosphere

E_atm

= evaporation

PR

= paved roof  

T_atm

= transpiration 

CP

= closed paved  

R_up

= decoupled runoff

OP

= open paved 

R_ow

= runoff to open water

UP

 = unpaved

I_uz

= infiltration

OW

= open water

P_gw

= percolation

UZ

= unsaturated zone 

D_ow

= drainage 

GW

= groundwater

S_out

= downward seepage

MSS

= mixed sewer system 

R_mss / R_swds

= runoff to sewer systems 

SWDS

= stormwater drainage system

SOF

= sewer overflow on street

SO

 = sewer overflow

Q_ow

= discharge to open water

WWTP

 = waste water   treatment plant

Q_out

= discharge to outside / WWTP

 

History

Originally the time step was 1 day. That way time series of more than 100-year rainfall and evaporation could be managed in EXCEL. A smaller time step could also be applied (1 hour, 15 minutes, 5 minutes). However, because of the limitations of EXCEL, a smaller time step implies much shorter time series. Transforming the water balance tool to a set of Python scripts solved this limitation. This set of Python scripts that has been combined in the Urbanwb model. This documentation describes the Urbanwb model.

Model purpose

This tool has been developed to determine the return periods of runoff events for relatively small urban areas in which the basic hydro(geo)logic conditions are assumed to be similar for the entire area. Determination of runoff return periods requires large time series of rainfall and evaporation, preferably at least 30 years.

The calculation results of the Urbanwb model are much less accurate and detailed as the calculation results of detailed hydraulic models, like SOBEK and MIKE-urban. It is commonly accepted to design urban water systems based on the calculation results of these hydraulic models for a single design rainstorm. However, the runoff caused by a design rainstorm, also depends on the initial conditions in all parts of the urban water system.

Main advantage of the Urbanwb model is that multiple different rainstorms with all kinds of actual antecedent weather conditions, resulting in all kinds of different initial conditions in all parts of the urban water system, are calculated. Other relevant advantages are that both model building and model calculations take much less time.

General model description

The Urbanwb model is a lumped conceptual model for urban water balance modelling. Urbanwb model simulates dominant dynamic hydrological processes of an urban water system. Rainfall-runoff processes, shallow groundwater (saturated and unsaturated zone), surface water and sewer systems (mixed and stormwater drainage) are all incorporated in Urbanwb model. Three external boundaries are included (atmosphere, deep groundwater and outside water / waste water treatment plant) to where water can be exchanged.

Figure 1 provides a schematic overview of Urbanwb model with its fundamental elements included. Under this conceptual framework, major hydrological dynamics in an urban water system can be quickly and indicatively modelled to provide users with a general idea of the water quantity distribution and how the water system behaves under certain conditions.

Below you find a brief introduction of the major components of the Urbanwb model. Chapter 2 describes these components into much more detail.

1.2      Major components

In the Urbanwb, the land use area is divided into:

Below floor level, the distinguished components are:

Boundaries, over which external water exchanges occur, are:

1.3      General assumptions

2       Model components 

This section explains in detail how each of the Urbanwb components is architected. Their underlying principles, simplifying assumptions, and calculation orders are explained in depth in this section. At the end of this chapter, in section 2.9 , the method of applying adaptation measures is described. The possibility of generating runoff to adaptation measures however, is provided in all components.

2.1      Paved Roof

Paved Roof (PR) refers to all kinds of buildings in an urban area ranging from low-rise buildings (e.g. single dwelling, apartment complex) to high-rise buildings (e.g. high-rise housing, skyscraper). On rooftop, a roof drainage system collects rainwater in gutters and drains it into a sewer through a downspout pipe. A small amount of rainwater ponded or intercepted on the roof surface is defined as interception storage. It can be emptied only through evaporation. Water exceeding the interception storage capacity becomes runoff on the Paved Roof. Basically, all runoff ends in the sewer system (SWDS and/or MSS). However, the Urbanwb offers the option of disconnecting (part of) the runoff. The disconnected part of the runoff is assumed to flow to the Unpaved area. Figure 4  provides a schematic overview.

 Figure   4        Schematic overview of Paved Roof (PR) in Urbanwb

2.1.1       Assumptions

2.1.2       Calculation order

2.1.3       Code and input arguments

 

class urbanwb.pavedroof.PavedRoof(intstor_pr_t0, pr_no_meas_area, pr_meas_area, pr_meas_inflow_area, intstorcap_pr=1.6, swds_frac=1.0, discfrac_pr=0.0, **kwargs)          [source]

Bases: object

Creates an instance of PavedRoof class with given initial states and properties, iterates sol() function to compute states and fluxes of Paved Roof at each time step.

 

Parameters:


inflowfac()                            [source]

Calculates measure inflow factor of Paved Roof.

 

Returns:                               Measure inflow factor of Paved Roof

Return type:                         (float)

 

sol(p_atm, e_pot_ow)       [source]

Calculates states and fluxes on Paved Roof during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of Paved Roof during current time step

Return type:                         (dictionary)

2.2    Closed Paved

Closed Paved areas are mainly areas with paved covers like roads, parking lots, driveways, etc. that are made of impermeable material like cement and bituminous concrete pavement. In terms of conceptual modelling mechanisms, Closed Paved is quite similar to Paved Roof. On the surface of a typical impermeable paved area, a small amount of rainwater is intercepted as surface ponding which can only be emptied through evaporation. Rainfall exceeding the interception storage capacity will generate runoff, which flows to the sewer system (SWDS and/or MSS). The disconnected fraction of runoff is assumed to flow to the Unpaved area (UP). Figure 5  provides a schematic overview.

 

Figure   5        Schematic overview of Closed Paved (CP) in Urbanwb

2.2.1       Assumptions

2.2.2       Calculation order

2.2.3       Code and input arguments

class urbanwb.closedpaved.ClosedPaved(intstor_cp_t0, cp_no_meas_area, cp_meas_area, cp_meas_inflow_area, intstorcap_cp=1.6, swds_frac=1.0, discfrac_cp=0.0, **kwargs)         [source]

Bases: object

Creates an instance of ClosedPaved class with given initial states and properties, iterates sol() function to compute states and fluxes of Closed Paved at each time step.

 

Parameters:

 

inflowfac()                            [source]

Calculates measure inflow factor of Closed Paved.

 

Returns:                               Measure inflow factor of Closed Paved

Return type:                         (float)

 

sol(p_atm, e_pot_ow)       [source]

Calculates states and fluxes on Closed Paved during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of Closed Paved during current time step

Return type:                         (dictionary)

2.3    Open Paved

Open Paved areas are paths, sidewalks, parking area and other less imperviously paved areas that have relatively limited infiltration capacity. These somewhat permeable pavements use porous material that allows water flowing through it (e.g. pervious concrete, porous asphalt) or spaced nonporous material (e.g. paving stones, permeable interlocking concrete pavement) that allows water infiltrate between the cracks (Figure 6 ). Consequently, compared to the Paved Roof (PR) and Closed Paved (CP) components, the Open Paved (OP) component has an extra infiltration flux from Open Paved surface to groundwater. This infiltration flux is limited by an infiltration capacity as well as by the available interception storage on the Open Paved area. Rainfall exceeding the interception storage capacity will generate runoff, which flows to the sewer system (SWDS and/or MSS). The disconnected fraction of runoff is assumed to flow to the Unpaved area (UP). Figure 7  provides a schematic overview.

Figure   6        Permeable pavement — porous asphalt and interlocking pavement, source: google images.

Figure 7      Schematic overview of Open Paved (OP) in Urbanwb 

2.3.1       Assumptions

2.3.2       Calculation order

2.3.3       Code and input arguments

class urbanwb.openpaved.OpenPaved(intstor_op_t0, op_no_meas_area, op_meas_area, op_meas_inflow_area, intstorcap_op=1.6, infilcap_op=1.0, swds_frac=1.0, discfrac_op=0.0, **kwargs)         [source]

Bases: object

Creates an instance of OpenPaved class with given initial states and properties, iterates sol() function to compute states and fluxes of Open Paved at each time step.

 

Parameters:

 

inflowfac()                            [source]

Calculates measure inflow factor of Open Paved.

 

Returns:                               measure inflow factor of Open Paved

Return type:                         (float)

 

sol(p_atm, e_pot_ow, delta_t)        [source]

Calculates states and fluxes on Open Paved during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of Open Paved during current time step

Return type:                         (dictionary)

2.4    Unpaved

Unpaved area is a land use type that has no paved surface cover, e.g. gardens and grassland, on which the water can much more easily infiltrate than on paved surface. Vegetation (crop) type on the Unpaved area needs to be predefined. The model assumes notable distinction between paved areas (PR, CP and OP) and unpaved areas (UP). From paved areas, excess water is mainly drained through the sewer system. From unpaved areas, excess water mainly infiltrates to the unsaturated zone underneath, percolates to the groundwater and is drained via groundwater flow to the drainage system (open water). Rainfall water stored in the interception layer at the surface simultaneously evaporates to the atmosphere and infiltrates to Unsaturated Zone. Water exceeding the interception storage capacity is assumed to runoff to Open Water (OW). Figure 8  provides a schematic overview.

 

 

Figure   8        Schematic overview of Unpaved (UP) in Urbanwb

2.4.1       Assumptions

2.4.2       Calculation order

2.4.3       Code and input arguments

class urbanwb.Unpaved.Unpaved(fin_intstor_up_t0, up_no_meas_area, up_meas_area, up_meas_inflow_area, intstorcap_up=20, infilcap_up=48, soiltype=2, croptype=1, **kwargs)            [source]

Bases: object

Creates an instance of Unpaved class with given initial states and properties, iterates sol() function to compute states and fluxes of Unpaved at each time step.

 

Parameters:

 

inflowfac()                            [source]

Calculates measure inflow factor of Unpaved.

 

Returns:                               measure inflow factor of Unpaved

Return type:                         (float)

 

sol(p_atm, e_pot_ow, r_pr_up, r_cp_up, r_op_up, theta_uz_prevt, pr_no_meas_area, cp_no_meas_area, op_no_meas_area, ow_no_meas_area, delta_t=0.041666666666666664)           [source]

Calculates states and fluxes on Unpaved during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of Unpaved during current time step

Return type:                         (dictionary)

2.5    Unsaturated Zone

Underneath Unpaved areas (UP) is an Unsaturated Zone (UZ). The Unsaturated Zone, often called the vadose zone, is the portion of the subsurface above the groundwater table. As mentioned before the Urbanwb does not apply an Unsaturated Zone in paved areas (PR, CP and OP), thus by assumption the Unsaturated Zone has the same area size as the Unpaved area. Infiltration from the Unpaved surface is an inflow to the Unsaturated Zone and percolation from the Unsaturated Zone to the groundwater (GW) is an outflow. In the Unsaturated Zone, we focus on the root zone from where the plant transpiration take place as the water uptake through plant roots. The root zone can be represented by means of a container in which the water content may fluctuate. Rainfall infiltration and capillary rise of groundwater towards the root zone add water to the root zone and decrease root zone depletion, while soil evaporation, crop transpiration and percolation removes water from root zone and increase depletion (Allen et al, 1998). Evapotranspiration the from root zone is modelled as the product of reference crop evapotranspiration (using Penman-Monteith evaporation or Makkink evaporation) and transpiration reduction coefficient (Panman, 1948; Montheith, 1965). Transpiration reduction coefficient is derived from the concept of Feddes plant water stress factor in the literature (Feddes et al, 1978).

Figure 9  shows the schematic overview of the Unsaturated Zone. Two important definitions are recapped here. Field capacity is the amount of water that a well-drained soil can hold against gravitational forces. In the absence of water supply, the water content in the root zone decreases as result of water uptake by the crop. As water uptake progresses, the remaining water is held to the soil particles with greater force, lowering its potential energy and making it more difficult for the plant to extract it. Eventually, the so called wilting point is reached where the crop can no longer extract the remaining water in the soil and the water uptake becomes zero. The wilting point is the soil water content at which plants will permanently wilt.

Figure   9        Schematic overview of Unsaturated Zone (UZ) in Urbanwb

Figure 10  shows how the transpiration reduction factor is related to soil water pressure head h (i.e. root zone water potential). In the range between h3 (transpiration reduction point) and h2 (field capacity), root water uptake is optimal (maximal), so the transpiration reduction factor α= 1.

When h < h3, there is drought stress, and α linearly reduces to zero at h4 (wilting point).

When h > h2, α linearly reduces to zero at h1 (fully saturated, i.e. anoxic moisture condition).

The threshold pressure h3 increases with potential transpiration rates, i.e. daily crop-evaporation. For low potential transpiration rate, the threshold pressure h3l is lower than the threshold pressure h3h at high potential transpiration rate. Computational simplifications are made here to calculate daily crop-evaporation value. Evaporation data are often provided on daily basis. When the Urbanwb model is applied for smaller time steps (Δt), we derive the hourly values of h3 based on the daily evaporation values by divided by 2Δt, where Δt is expressed in days (e.g. Δt = 1 hour = 1/24 day). The factor 2 is applied, based on the assumptions that evapotranspiration mainly occurs during day time and that day time lasts on average 12 hours.

Figure   10      Transpiration reduction coefficient in Urbanwb (i.e. plant water stress factor) in relation to root zone water potential. Source: Dejongvanlier et al, 2008.

Some applied concepts regarding evapotranspiration based on literature are:

2.5.1       Assumptions

2.5.2       Calculation order

2.5.3       Code and input arguments

class urbanwb.unsaturatedzone.UnsaturatedZone(theta_uz_t0, uz_no_meas_area, uz_meas_area, soiltype=2, croptype=1, **kwargs)             [source]

Bases: object

Creates an instance of UnsaturatedZone class with given initial states and properties, iterates sol() function to compute states and fluxes of Unsaturated Zone at each time step.

 

Parameters:

 

sol(i_up_uz, meas_uz, e_ref, tot_meas_area, gwl_prevt, delta_t=0.041666666666666664)      [source]

Calculates states and fluxes in Unsaturated Zone during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of Unsaturated Zone during current time step:

Return type:                         (dictionary)

2.6    Groundwater

In the Urbanwb Model, underneath the Unsaturated Zone is the saturated zone, i.e. the Groundwater reservoir (GW). The Groundwater reservoir is modelled as an unconfined aquifer which consists of a pervious layer underlain by a (semi-)impervious layer, below which lies the deep groundwater, one of the boundary components that exchanges water with the Urbanwb model. Percolation from Unsaturated Zone and Open Paved recharges the groundwater, while downward seepage to deep groundwater and drainage to Open Water deplete the Groundwater reservoir. The inflow (percolation from Unsaturated Zone) and outflow (seepage and drainage) are driven by the head difference, so the value of these fluxes can both be positive or negative. Figure 11  shows the schematic overview of the Groundwater reservoir. The area of the Groundwater reservoir is calculated as the area of the total model minus the area of Open Water fraction that is not above the groundwater level and minus the area of Paved Roof fraction of which the basement is below groundwater. The maximum capillary rise and the storage coefficient for the current time step are determined by interpolation based on the groundwater level at the end of the previous time step.

Figure   11      Schematic overview of groundwater reservoir (GW) in Urbanwb

The formula of groundwater level during current time step h(t) and its derivation are shown below (Figure 12 ). In this figure, P is percolation (assumed to be constant during a time step), qs is downward seepage to deep groundwater, qd is drainage to Open Water. All these water flows can get positive as well as negative values, negative meaning flow in the other direction. In Urbanwb all relevant levels are relative to the surface level, where the unit (m-SL) means meter below surface level.

Figure 12   Groundwater level h(t) calculation

Seepage:             Drainage:        Continuity:

Substitution results in:

Initial condition:    

2.6.1       Assumptions

2.6.2       Calculation order

2.6.3       Code and input arguments

class urbanwb.groundwater.Groundwater(gwl_t0, gw_no_meas_area, gw_meas_area, seepage_define=0, w=100, vc=20000, head_deep_gw=21.5, down_seepage_flux=1, soiltype=2, croptype=1, **kwargs)       [source]

Bases: object

creates an instance of Groundwater class with given initial states and properties, iterates sol() function to compute states and fluxes of groundwater at each time step.

 

Parameters:

 

sol(p_uz_gw, uz_no_meas_area, p_op_gw, op_no_meas_area, tot_meas_area, meas_gw, owl_prevt, delta_t=0.041666666666666664[source]

Calculates states and fluxes in groundwater during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of groundwater during current time step:

Return type:                         (dictionary)

2.7      Sewer system

The sewer system in Urbanwb model is the combination of a Storm Water Drainage System (SWDS) and a Combined or Mixed Sewer System (MSS). Mixed implies a combined discharge of urban drainage and urban waste water. In urban areas both systems can be applied in practice. Hence, in the Urbanwb model the total paved area (PR, CP and OP) is split proportionally in a SWDS applied area (0 – 100%) and a MSS applied area (the rest). The proportion and system capacity of these systems should be predefined by the user to match the local situation. In dry to normal flow conditions, all water in a combined sewer system is transferred to waste water treatment plant (WWTP) for further treatment. In wet flow conditions (e.g. heavy rainstorms), a relief structure, a so called CSO weir, allows a large part of the combined storm- and waste water to be discharged untreated to an adjacent water body (e.g. a city pond). Combined sewer systems have two phases in wet flow conditions. In phase one, a combined sewer system collects water from paved areas and discharges it together with the urban waste water to a waste water treatment plant and the storage in the sewer system gets filled before sewer overflow through a CSO weir to Open Water occurs (phase 2). Sewer overflow of a combined system may impose pollution problems to the receiving water body. If rainfall is so extreme that the overflow discharge capacity is exceeded, then the sewer overflow into the street will occur. Opposite to combined sewer systems, in separated systems only waste water flows to the waste water treatment plant and only rainfall runoff enters the storm water drainage system, which drains this water directly to the surface water. The storm water drainage system is limited by a predefined system discharge capacity above which the sewer overflow into the street will occur. Figure 1 , in the first section of this document, provides a clear schematic overview of the sewer systems in the Urbanwb model.

2.7.1       Assumptions

2.7.2       Calculation order

2.7.3       Code and input arguments

class urbanwb.sewersystem.SewerSystem(swds_no_meas_area, mss_no_meas_area, stor_swds_t0, so_swds_t0, stor_mss_t0, so_mss_t0, q_swds_ow_cap, q_mss_out_cap, q_mss_ow_cap, storcap_swds=2.0, storcap_mss=9.0, **kwargs)                [source]

Bases: object

Creates an instance of Sewer System class with given initial states and properties, iterates sol() function to compute states and fluxes of sewer system at each time step.

 

Parameters:

 

sol(pr_no_meas_area, cp_no_meas_area, op_no_meas_area, r_pr_swds, r_cp_swds, r_op_swds, r_pr_mss, r_cp_mss, r_op_mss, meas_swds, meas_mss, ow_no_meas_area, tot_meas_area)                                           [source]

Calculates states and fluxes of sewer system during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of sewer system during current time step:

Return type:                         (dictionary)

2.8      Open Water

Open Water in the Urbanwb model refers to all controlled Open Water bodies, e.g. ditches, canals and ponds. In the Urbanwb model the open water has a fixed target level. Above this level, water will be discharged to outside water, limited by a user defined discharge capacity. In the Urbanwb model, the minimum open water level is the defined target water level. If evaporation losses result in water level below the target level, water will be let in (with unlimited capacity) from outside water to maintain the target water level. Open Water can be deemed as an abstract term reflecting system storage capacity. By assumption, all runoff from Unpaved and all sewer overflow into the street flow directly to the Open Water. Also, sewer system outflow and groundwater drainage will recharge the Open Water. During simulation, under successive heavy rain events, Open Water level may exceed the target level due to insufficient storage capacity and discharge capacity, indicating there is excessive water that the urban water system cannot handle. This can represent all kinds of real urban flood phenomena. In the current version of the Urbanwb model water above surface elevation level cannot flow (directly) to the other surface areas and cause flooding in these areas. Hence the maximum water level in the Open Water is not limited. The storage height above the target Open Water level is calculated to understand the storage requirements of the water system. Maximum storage height on Open Water for a certain flood event multiplied with the Open Water area reflects the required storage capacity for the total study area for that event. To sum up, Open Water component is an abstract recipient water body that indicates the required storage capacity of the system. Figure 13 shows the schematic overview of the Open Water.

Figure   13      Schematic overview of Open Water (OW) in Urbanwb

2.8.1       Assumptions

2.8.2       Calculation order

2.8.3       Code and input arguments

class urbanwb.openwater.OpenWater(ow_no_meas_area, q_ow_out_cap, ow_level, **kwargs)                  [source]

Bases: object

Creates an instance of OpenWater class with given initial states and properties, iterates sol() function to compute states and fluxes of Open Water at each time step.

 

Parameters:

 

sol(p_atm, e_pot_ow, r_up_ow, d_gw_ow, q_swds_ow, q_mss_ow, so_swds_ow, so_mss_ow, meas_ow, up_no_meas_area, gw_no_meas_area, swds_no_meas_area, mss_no_meas_area, tot_meas_area, tot_area, delta_t=0.041666666666666664)                [source]

Calculates states and fluxes on Open Water during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of Open Water during current time step:

Return type:                         (dictionary)

2.9      Measure 

Urban flooding is usually attributed to three types: pluvial flooding, fluvial flooding and coastal flooding. Pluvial flooding occurs when an extremely heavy rainfall saturates the storage capacity of the water system and excess water cannot be absorbed. Fluvial flooding occurs when rivers burst their bank as a result of sustained or intense rainfall. Coastal flooding occurs in coastal area as a result of extreme tidal conditions like storm surges. Unlike other types of flooding, pluvial flooding is a direct, quick and localized consequence of rainfall, and it is a predominantly urban phenomenon as it is in urban area where the effects are most pronounced and damaging (Susana). The Urbanwb model simulates only the pluvial flooding in urban water systems through two indicators, sewer overflow into the street and storage height above the target open water level. Climate change is predicted to increase the intensity and frequency of extreme rainfall events. Together with further urbanization and rapid growing population, this may result in increased urban pluvial flood risks. To effectively adapt to increasing flood risks, a combination of intervention strategies is required, including structural infrastructure, nature-based solutions, early warning system, risk financing instrument, etc. The Urbanwb model is capable of modelling all kinds of physical adaptation measures. Physical measures can be categorized into artificial structural infrastructure and nature-based solutions. Structural infrastructure refers to grey infrastructure are considered to be engineering projects that use concrete and steel, while nature-based solutions refer to blue-green infrastructure that depend on water, plants and ecosystem services. Blue-green infrastructure is the strategic use of networks of natural lands, working landscapes, and other open spaces to conserve ecosystem values and functions and provide associated benefits to human populations (Benedict & McMahon, 2006). Blue-green infrastructure is generally decentralized. Water is captured and treated where it falls, rather than being transported to a treatment facility. Blue-green infrastructure terminology can also be used in the context of low impact development (LID). Grey infrastructure refers to the human-engineered infrastructure for water resources such as water and wastewater treatment plants, pipelines, and reservoirs. Grey infrastructure typically refers to components of a centralized approach to water management. Examples of grey infrastructure are canals, levees, ditches, raised curbs, underground off-line tanks, etc. Examples of blue-green infrastructure are rainwater harvesting, water squares, urban wetlands, green roofs, bioswales, etc. A module named Measure is creatively developed in the Urbanwb model to model the physical urban adaptation measures. With the ingenious setup of this module, underlying mechanisms of these physical measures are simulated and incorporated into the dynamics of the entire modelling of water system. The next sections provide detailed descriptions on the structure of the Measure module.

Measures mitigate urban flooding by means of creating extra storage, encouraging evapotranspiration, facilitating infiltration, increasing drainage and the combination of these interventions. Consequently, despite many types/terms of urban adaptation measures, they can be categorized and modelled under certain framework with specific settings. The underlying idea and fundamental principle of this Measure module is to provide a general adaptive framework that represents the measures’ physical dimensions and that mimics the measures’ predominant functionality.

Measures in the Urbanwb model can be defined in a 1-layer, 2-layer or 3-layer structure (Figure 14 ).

Figure   14      Layer principle of measures in Urbanwb

1-layer structures contain only an interception layer (layer no. 1), which can represent the type of measures that creates storage and allows evaporation. A typical example of a 1-layer measure is a blue roof.

2-layer structures consist of 2 layers, an interception layer (layer no. 1) and a bottom storage layer (layer no.3). The bottom storage layer is the most sophisticated part of the measure module. In the bottom storage layer, evapotranspiration, percolation to groundwater and controlled runoff (to anywhere) can be defined by the user. Controlled runoff means the runoff volume that is first stored in the measure is discharged in a controlled way. Basically, controlled runoff implies either “continuously delayed released” to the urban water system or “instantaneously released at a much later time”, when the urban water system is able to handle this runoff again, most likely by means of real time control systems. Urban water system is referring to the entire water system, hence incorporating all elements described in the sections above. In the current Urbanwb model real time control is not incorporated and is simulated by a small constant discharge over a large number of time steps to one of the subsystems SWDS, GW, OW. Continuous slow release is defined as a dynamically-computed flux that dependents on a head difference and a flow resistance. Examples of 2-layer measures are rain barrel, wet pond, infiltration box, etc.

3-layer structures consist of 3 layers, an interception layer (layer no. 1), a top storage layer (layer no. 2) and a bottom storage layer (layer no.3). Extra, compared to the 2-layer measures is the top storage layer. This layer is especially added to model measures like green roofs and bioswales. These measures have a growing medium that encourages evapotranspiration and a drainage layer beneath the growing medium that drains excessive water to the sewer system. Some examples are provided in next paragraph to inspire the user how to conceptualize a measure into this Measure module.

The setup of the measures involves expert judgement: “the model is only as good as the modeler”.

Below some examples of how to conceptualize measures are provided:

 

2.9.1       Assumptions

2.9.2       Calculation order

2.9.3       Code and input arguments

class urbanwb.measure.Measure(tot_meas_area, runoff_to_stor_layer, intstor_meas_t0, EV_evaporation, num_stor_lvl, infilcap_int_meas, storcap_top_meas, storcap_btm_meas, stor_top_meas_t0, stor_btm_meas_t0, storcap_int_meas, top_meas_area, ET_transpiration, evaporation_factor_meas, IN_infiltration, infilcap_top_meas, btm_meas_area, btm_meas_transpiration, connection_to_gw, limited_by_gwl, k_sat_uz, btm_level_meas, btm_discharge_type, runoffcap_btm_meas, dischlvl_btm_meas, c_btm_meas, surf_runoff_meas_OW, ctrl_runoff_meas_OW, overflow_meas_OW, surf_runoff_meas_UZ, ctrl_runoff_meas_UZ, overflow_meas_UZ, surf_runoff_meas_GW, ctrl_runoff_meas_GW, overflow_meas_GW, surf_runoff_meas_SWDS, ctrl_runoff_meas_SWDS, overflow_meas_SWDS, surf_runoff_meas_MSS, ctrl_runoff_meas_MSS, overflow_meas_MSS, surf_runoff_meas_Out, ctrl_runoff_meas_Out, overflow_meas_Out, greenroof_type_measure, **kwargs)          [source]

Bases: object

Creates an instance of Measure class with given initial states and properties, iterates sol() function to compute states and fluxes of measure at each time step.

 

Parameters:

 

sol(p_atm, e_pot_ow, r_pr_meas, r_cp_meas, r_op_meas, r_up_meas, pr_no_meas_area, cp_no_meas_area, op_no_meas_area, up_no_meas_area, gw_no_meas_area, gwl_prevt, delta_t)          [source]

Calculates states and fluxes in measure during current time step.

 

Parameters:

 

Returns:                               A dictionary of computed states and fluxes of measure during current time step:

Return type:                         (dictionary)

3         FAQ

  1. What are area with measure, area without measure and measure inflow area?

    Figure   17      Illustration of measure inflow area

4         References for parameter estimations

5      Running the model

5.1   Overview

The script model can be run from windows command prompt or with run.bat file. The latter choice is highly recommended.

For the time being, the most commonly used function is savecsv, batch-run-sdf and batch-run-measure

The running_sample folder in the Urbanwb package includes the sample of running the model for both basic model and model with measure.

Two sorts of input are necessary to start the Urbanwb model:

Dynamic input : The forcing — Hourly time series of Precipitation, potential Open Water evaporation and potential reference crop evapotranspiration. The user is responsible for data preprocessing — clean data, fill vacancy, remove unrealistic data and make sure the data is in float type. Make sure the column name is the same because the script uses the column name to index which data is precipitation and evaporation.

Static input : All the static input parameters are stored in the configuration file suffixed with .ini . Currently, two configuration files are indispensable for every function to use — one is neighbourhood configure file, the other is measure configuration file. If no measure is included in the modelling, please specify measure_applied=false in measure configuration file. Though the script will automatically do some checks after reading the configuration file to make it fool proof, for example it will update the measure-related area with zero if no measure is applied even if it is not zero due to the user’s carelessness, it is highly recommended that the user carefully deals with the configuration input. Besides, the user should modify the parameters according to the local context of his area of interest and expected setups. Be aware of not changing the parameter name, otherwise the model goes wrong. The descriptions of the parameters are in the configuration file, documentation and script docstrings for the user’s cross check.

5.2   Input time series and parameters

5.2.1    Time series (Dynamic input)

The forcing of Urbanwb model is the time series of:

Note:

If Penman evaporation is not directly available, since it is not straightly measured, but (class-A) pan evaporation data are available, Pan evaporation can be multiplied by a factor 0.77 to convert to Penman evaporation (Linacre, 1994). The model assumes potential Open Water evaporation from actual interception evaporation on paved surfaces. Evapotranspiration for the unpaved areas (and reference crop grass) is assumed to be 0.8982 * Penman evaporation (Droogers, 2009).

Often hourly potential Open Water evaporation data are not available, or even daily evaporation time series are not available. Then assumptions and simplifications will be made on evaporation interpolation. For instance, when only monthly potential evaporation data and daily sunrise and sunset data are available, you can transform to hourly data by:

Hourly time series of precipitation (actually only rainfall) [mm] and potential evaporation of Open Water [mm]. (for grass, it is approximately 0.8982 * Penman evaporation – Droogers, 2009) Length should better be most recent 30 years. Atmosphere is the most crucial exchange to the model. 1. Format:

First, divide the monthly values by the number of days of these months. Second, assume zero evaporation during night hours and determine the hourly evaporation by dividing the daily values by the number of daily hours between sunrise and sunset.

All conversion required to retrieve hourly evaporation have to be done before entering these input data in the model.

The length of the time series of rainfall and evaporation is advised to be 30 years or more, preferably ending as recent as possible.

Regarding formats, CSV file format is preferred with corresponding column names. Check the data on vacancies and unrealistic values. Make sure the data is in float type.

5.2.2    Parameters (Static input)

Land use at or above surface level are divided into 5 components, namely Paved Roofs (buildings), Closed Paved (roads, etc.), Open Paved (pavements, parkings, etc.), Unpaved (grass land, etc.) and Open Water (ditches, canals, ponds, etc.). The fractions of the five land use types should sum up to 100%. In addition, the total area [m2] of the study area is required input. Besides, for paved areas (PR, CP, OP), three additional types of fractions have to be defined:

  1. disconnected fraction of three paved areas: “Part disconnected from sewer”: This disconnect fraction represents the percentage of each paved area that is disconnected from the sewer system. For instance if this fraction is 5% for Paved Roofs, it implies that 5% of the Paved Roofs (PR) is disconnected to sewer system. Consequently, 5% of the runoff from the Paved Roofs (PR) will not end in the sewer system but is assumed to flow to the Unpaved area.
  2. part of building above groundwater (GW): “part of buildings above GW”: This fraction means, in terms of Paved Roofs only, how much percentage of Paved Roofs (PR) has its bottom of foundation above the phreatic water table. This fraction in the model defines the total area size of the (shallow) groundwater (GW).
  3. part of Open Water above groundwater (GW): “Part of OW above GW”: This fraction is more or less similar to part of building above groundwater (GW). It affects the calculation of the size of the groundwater area. Say we have 300m2 Open Water. If this fraction is zero, then groundwater area is limited by this 300m2. If this fraction is 100%, then groundwater will also contain this 300m2 as all Open Water is assumed to be above the groundwater table.

To sum up, type 2 and type 3 fractions influence the total area of (shallow) groundwater (GW). This area is important since all the storage and fluxes in the model are calculated in depth [mm], so the conversion from one component to another component is dependent on the area ratio of these two components. Therefore, these two additional fractions (type 2 and type 3) are defined to determine the actual groundwater area in the model.

Runoff from paved surface to sewer systems only occurs when the surface interception storage capacity can no longer handle excessive rainfall. This runoff can flow to either of the two available sewer systems. The division is defined by the fraction (X%) flowing to the “Storm Water Drainage System”, the part of paved area that has a storm water drainage system. The rest of the paved runoff (100% – X%) is automatically defined to flow to the “Mixed Sewer System”, the part of paved area that has a combined sewer system.

Design standard / Design rainfall of sewer system.
In the Netherlands, the sewer overflow on the street is designed to occur once every two years. Hence 2 year is chosen as the design rainfall return period. Its corresponding rainfall intensity (16.8 mm/hour) is determined by rainfall statistics.
Consequently, for SWDS, the predefined hourly discharge capacity from SWDS to OW is determined by subtracting the interception capacity of the paved areas (1.6 mm) and the storage capacity of the SWDS (2 mm) from the T=2year rainfall intensity (16.8 mm), resulting in 13.2 mm/hr. This 13.2 mm/hour is the discharge capacity of SWDS to Open Water above which sewer water will overflow onto the street.
For the MSS the discharge capacity to the waste water treatment plant (WWTP) is calculated in a similar way. In the Netherlands the combined sewer overflow onto the Open Water is designed to occur approx. six times a year (T=1/6year). The corresponding rainfall intensity is 6.7 mm/hour. This will only occur when the discharge capacity of to the WWTP is exceeded. Hence the discharge capacity from MSS to WWTP is 6.7 – 1.6 (paved area interception) = 5.2 mm/hour.
The storage capacity of the MSS in the Netherlands is assumed to be 9 mm, hence MSS overflow onto street will occur above 16.8 – 1.6 – 9 = 6.2 mm/hour.
Please note that these values can (and have to be) adapted by the user dependent on the actual climate and sewer design of the study area.

5.3   Functions

5.3.1    save_to_csv

This function performs single run of the model. It can save all results or selected results in to an output csv file.

# save all results

#    module name     func name     timeseries name neighbourhood measure     outputfile

python -m urbanwb.main_with_measure save_to_csv timeseries.csv config1.ini config2.ini output.csv


# save selected results

#     module name     func name     timeseries name neighbourhood measure     outputfile variable to save     save_all  is False -> save selected

python -m urbanwb.main_with_measure save_to_csv timeseries.csv config1.ini config2.ini output.csv  owl r_pr_swds  theta_uz --save_all=False 

5.3.2    batch_run_sdf

This function performs batch run on different pumping capacity to produce database which can be used to plot Storage-Discharge-Frequency (SDF) Curve

  Running the model — urbanwb 0.1.0 documentation 

# mean daily rainfall as baseline q, batch run [4,5]

#     module name     function     ts.csv     config1.ini     config2.ini     output.csv     random number     baseline q default

python -m urbanwb.main_with_measure batch_run_sdf ep_ts.csv  ep_neighbourhood.ini  ep_measure.ini  ep2_results.csv --q_list=[4,5]


 

# 4 as baseline q, batch run [10,20]

#     module name     function     ts.csv     config1.ini     config2.ini     output.csv     random number     baseline q predefined

python -m urbanwb.main_with_measure batch_run_sdf ep_ts.csv ep_neighbourhood.ini ep_measure.ini ep2_results1.csv --q_list=[10,20] --baseline_q=4


# 3 as baseline q, batch run [min,max,steps] --- [4,8,3]

#     module name     function     ts.csv     config1.ini     config2.ini     output.csv     [min,max,steps]     baseline q:predefined     AP: True to enable  [min,max,steps]. if False, then q_list random numbers

python -m urbanwb.main_with_measure batch_run_sdf ep_ts.csv ep_neighbourhood.ini ep_measure.ini ep2_results2.csv --q_list=[4,8,3] --baseline_q=3 --arithmetic_progression=True

5.3.3    batch_run_meas

This function performs batch run on measure. First do batch run with different (pairs of) values, then do baseline run (no measure). In the end, save the runoff time series into a csv file.

It can vary one parameter with a list of values or vary two parameters at the same time.

#     module     function     ts.csv     config1.ini     config2.ini     output.csv     var to change     value to update var     corresp var     value for corresp var     baseline runoff     measure runoff to save 

python -m urbanwb.main_with_measure batch_run_measure ep_ts.csv ep_neighbourhood.ini ep_measure.ini ep3_results.csv --varkey="storcap_btm_meas" --vararrlist1=[1050,1200] --correspvarkey=None -vararrlist2=None --baseline_variable="r_cp_swds" --variable_to_save="q_meas_swds"

python -m urbanwb.main_with_measure batch_run_measure ep_ts.csv ep_neighbourhood.ini ep_measure.ini ep3_results.csv --varkey="storcap_btm_meas" --vararrlist1=[1050,1200] --correspvarkey="runoffcap_btm_meas" --vararrlist2=[30,40] --baseline_variable="r_cp_swds" -riable_to_save="q_meas_swds"

python -m urbanwb.getconstants ep3_results.csv --num_year=30

5.4   References

 

  • No labels