You may have noticed, that in some instances, the Pipe full capacity value on a pipe in InfoWorks ICM is less than the flow in a surcharged pipe. How can there be more flow in a pipe than its full capacity?
The Pipe full capacity (pfc) field is populated when the model network is validated. It is calculated from the Colebrook White or Manning equations. These equations are much more simplistic than the full solution St Venant equations used by the InfoWorks ICM simulation engine used to generate the model results. Therefore, there can sometimes be differences between the pipe full capacity field and the actual flow that can discharge. The value in the pfc field is only intended to be an approximation/reference for the user. It is not used by the engine to determine when a pipe goes into surcharge.
The Colebrook White or Manning equations assume that the pipe is infinitely long and therefore there is often more flow through a pipe than the quoted capacity, without it going into surcharge. To prove this is the case you can make the pipe a longer length or apply a constant max flow and you should see the pipe surcharging. The length of the pipe has a significant effect. You may find that a pipe of say 10 feet can carry much more flow than one of 300 feet, given the same gradient, roughness etc.
This pfc value has been in the software ever since we can remember, certainly since the early days of HydroWorks. It can be a useful reference, but sometimes creates confusion. We hope that this blog post provides some clarity on how the pfc field was intended to be used.
Figure 1: Area Take Off Dialogue Box
The Area Take Off option allows automatic calculation of runoff surface areas and the contributing areas of subcatchments using data imported from a Geographic Information System. It is designed to extract the areas surfaces form a catchment according to their types (Roads, Buildings and Permeable surfaces) and to the systems where they are connected (Storm, Sanitary/Foul etc.).
The Area Take-off tool in InfoWorks ICM provides a number of user definable operations. Some operations are complex and can lead to accidental misuse if they are not fully understood. One such case is the “Proportional system type split” option (shown in Figure 1), which is responsible for dividing up any areas that are left over after the primary areas have been extracted from the subcatchment by the Area Take-off operation. The complexity arises when there is no area of a specific type to be taken off from a subcatchment. According to the Area Take Off technical note within the InfoWorks ICM help section (3.4 & 4), in such cases, no residual area will be contributing to the runoff generation process. Therefore, it is recommended that you don’t select the “Proportional system type split” option when you are not simultaneously extracting the different types of contributing areas (Roads, Buildings and Permeable surfaces) for the various system types (Storm, Sanitary/Foul etc.) in your model network.
A common engineering practice is to take off a defined layer (say, buildings) and to divide the rest of the catchment areas across the other surface types (i.e. Roads and Permeable surfaces). In such circumstances, if a subcatchment does not present any building surfaces, but does include roads and permeable surfaces, then performing area take-off on the building layer, while leaving the “Proportional system type split” option active, will generate a null total contributing area. This in turn will lead to erroneous simulation results. Therefore, deactivating the “Proportional system type split” option is preferable in such situations, leaving the user to manually define the system type and the surface number to obtain the right overall contributing area count and distribution.
Fireflows are an integral part of the Hydraulic modeling process and provide a means to calibrate your model. Fireflow represents the amount of water available in a network for fire protection purposes apart from the amount of water used in the network demand. You may use the InfoWater Fireflow module to analyze your existing hydrants or provide recommendations for future build-outs.
In InfoWater, there are three inputs that can be applied while conducting a standard Fireflow. Continue reading
Float valves are one valve type available to use within the InfoWater, H2ONET or H2OMAP Water software that may not be as widely used as more common valve types such as a Pressure Reducing Valves (PRVs) or a Flow Control Valves (FCVs). Because Float Valves are not used as much, users may not be aware of the full functionality of this type of valve or how this type of valve works. This blog post will explain the functionality of the valve and provide a few suggestions on how users can make use of this valve within their models .
First let’s start with a description of the Float Valve from the software help file as this gives a good explanation of what these valves represent:
Float Valves: – Many storage tanks and reservoirs are fitted with float valves (e.g., ball float valves) on the inlet pipe to control rate of flow and prevent overflow. These valves gradually close (increase the resistance of the inlet pipe) as the water level in the controlling tank rises. The headloss across the valve is modeled (via a curve) based on any user specified pairs of headloss vs. flow points. The valve is active if the water level in the controlling tank is below the lower control level or the water level is between the lower and upper levels after the valve opening. Likewise, the valve is closed if the water level in the controlling tank is at or above the upper control level or the water level is between the lower and upper after the valve closes.
ICM RiskMaster allows 2D hydraulic results from InfoWorks ICM to be combined with economic data to allow damages to be quantified.
Traditionally flood management policies have been based upon the design standard philosophy, where policy makers decide on an appropriate protection level to be achieved within the flood system which is used to design and manage hydraulic infrastructure. In contrast with this approach and following the guidelines specified in the EU Floods Directive 2007/60/EC on the assessment and management of flood risks, flood management policies based on risk rather than system performance have been developed in recent years. Flood risk management policies are based on the evaluation of the consequences generated by flooding events and the alleviation measures on the expected flood impacts over a given time period.
Risk-based analysis methods can be used in order to assess and manage hydraulic infrastructure which protects assets from flood events. A flood-risk methodology analyses a hydraulic system based on the evaluation of the consequences derived from the service of the hydraulic infrastructure rather than system performance. Thus, in contrast with traditional performance methods, in which the hydraulic system is expected to service a specific loading level, a flood risk approach should take into account all type of events based on their probability of occurrence. The results of the analysis provide a comprehensive view of the performance of the hydraulic system and the consequences derived from flood events.
The calculation of risk involves multiplying the damage result for each receptor in a simulation with the probability of occurrence of the event simulated. The total damages are calculated at each damage receptor by taking the 2D flow depth and using the depth-damage curve to associate this with a damage value. This is then summed for all damage receptors to provide a total damage value for each return period. This in turn is multiplied by the event probability, to provide the annual damage. Continue reading
Want to make your code understood to colleagues?
Want to ignore certain lines whilst developing an InfoNet SQL?
A double Backslash ‘\\’ acts as a comment in InfoNet SQL Comments. In computer programming, a comment is a programmer-readable explanation or annotation in the source code of a computer program. They are added with the purpose of making the source code easier for humans to understand, and are generally ignored by compilers and interpreters. Continue reading
With the release of IWLive Pro in 2016, Innovyze delivered the next generation of IWLive Pro, a significantly refined product using the latest technology and specifically designed to provide all existing IWLive Pro users with a simple upgrade path from IWLive to the newer, more powerful, IWLive Pro platform.
The first version of IWLive was commercially released in 2010. IWLive has served the industry well, providing a live operational decision support tool however many of the underlying technology components are reaching the end of their useful life and limiting the functionality in IWLive. Continue reading
Not exactly an InfoNet specific post but for those users working with the UK’s WRc’s MSCC Sewer CCTV Survey Standard this blog may be of use, it explains how to better visualise the data exchange XML file. A typical File looks as follows and is made up of an initial standard XML Header followed by the Survey Header and then the observations. The Survey Header and Observations are then repeated for each survey.
The following link will take you to the XML Specification For MSCC4 Sewer Inspection Data on the WRc’s website and explains the above format exactly. Continue reading
We have extended our special upgrade prices for InfoWorks WS Pro to all existing InfoWorks WS users until December 15, 2017. Contact your local Innovyze representative for full upgrade information.
Current InfoWorks WS users may continue to receive support for InfoWorks WS until December 31, 2017.
When it comes to version numbers, there are different rules for the various components of InfoWorks ICM and its associated Services.
Local and Remote Simulations
When creating and scheduling a simulation from your local machine and running it on a remote machine, there must be an exact match between the version of ICM on the local machine and the version of ICM on the remote machine. The remote machine can have either a full installation of ICM, or just the Remote Agent, but either way, the version number must match, right down to the build number (i.e. v7.0.4, build 14015). This rule ensures that regardless of whether you run your simulation locally on your machine or remotely on another machine, you are guaranteed to get the same answers each time (because you’re using the exact same software version each time). The Agents and Coordinator will only allow a remote simulation when there is an exact match between Local and Remote machine, so the end-user doesn’t need to check anything at run-time. Continue reading