Client Service Managers/Technical Sales Engineers (Monrovia, CA and Broomfield, CO)
We have immediate full-time openings for ambitious, enthusiastic and outgoing client service managers/technical sales managers (technical sales professionals) for supporting our Marketing Team with sales and events through demos and benchmarks. You will also be responsible for creating and managing new businesses and maintaining excellent client relationships for existing accounts. We are seeking candidates who enjoy working with a team and have strong oral communication skills for the development of technical demos, interfacing with customers, and participating in trade shows.
Qualifications: A degree in civil or environmental engineering or a related field; extensive knowledge of EPANET and SWMM5 experience; excellent communication, presentation and negotiation skills.
If interested, please send your resume (CV) to Tim Gallagher at Timothy.J.Gallagher@innovyze.com.
For customers who use ESRI ArcGIS or ArcEngine version 10.3, these products are now supported by InfoWorks and InfoNet. In order to use ArcGIS or ArcEngine 10.3 you will need to download the latest patch from our website.
The patches required are:
- InfoWorks ICM 5.5.5
- InfoWorks ICM SE 5.5.5
- ICMLive 5.5.5
- InfoNet 15.5.5
- InfoWorks WS 15.5.3
- IWLive 15.5.3
- InfoWorks RS 15.5.3
- InfoWorks CS 15.5.3
- InfoWorks SD 15.5.3
These patches are now available to download from the product updates section of our website for all supported customers.
Note that earlier versions of these products will not recognise ArcGIS 10.3 installations and will generate the following error message: “ArcGIS Licence Error: ArcGIS product not installed”.
Copying SQL syntax directly from an internet browser (Windows Internet Explorer, Google Chrome, Mozilla Firefox etc.) into an SQL dialog box in InfoNet will return an error when the user attempts to test or to run the query. Error messages similar to the following are returned.
Initial NAPI Values in InfoWorks ICM
In the New UK runoff model was calibrated against a variety or urban catchments in the UK. It uses a value of the antecedent wetness conditions (NAPI) which can vary depending on the soil type. The soil type is defined as part of the subcatchment data or as part of the user defined defaults. In the UK, the soil type classification is derived from Maps. There are 5 different soil types although commonly soil type 5 is not used. The soil type effects the value of a constant which is used in the calculation of NAPI. It is common to set an initial value of NAPI which as above can vary depending on the soil type.
A feature of InfoWorks ICM which has been inherited from InfoWorks CS and its predecessor HydroWorks, is that it is only possible to use one value of NAPI with any one rainfall profile. This is a problem in catchments with different soil types where a different value of NAPI is needed for each soil type. This blog describes how it is possible to represent the effect of different soil types on NAPI values within subcatchments.
Initial NAPI Values in InfoWorks ICM
Posted in InfoWorks CS, InfoWorks ICM
Tagged Antecedent Conditions, Catchment Conditions, CRD, Design Rainfall, NAPI, New PR Model, New UK, Observed Rainfall, Rainfall Event, RED, Runoff Model, UCWI, UKWIR, Wallingford
First, establish expected lifetimes of your pipes. This can be achieved by many different means in InfoMaster, some available options are:
- Reliability Analysis – incorporating statistical models (Cox, LEYP, Herz, Weibull, NHPP…)
- Likelihood of Failure – incorporating any data you have available, be it GIS layers or ODBC tables
InfoMaster can perform a variety of different complex statistical deterioration models. Though these models are extremely complex mathematically, all the user needs to do is to specify install dates for pipes (when the pipes ‘began their life’) and specify criteria that defines which pipes have reached the end of their useful life, be it that the pipes have had previous failures, or based on age, material, or any other criteria. The InfoMaster tools will take that data from a sample-size of the network and scale the statistical results to the whole system.
InfoWorks ICM and CS have a number of different ways to model pumps. The two most commonly used are:
- Fixed Pumps (a simplistic method where the discharge is independent of the head on the pump) and
- Rotodynamic Pumps (where a head-discharge curve is used to determine the flow rate of the pump, but there is no speed control of the pump).
Variable Frequency Drive Pumps allows the user to change the speed of a rotodynamic pump by use of an Real Time Control (RTC). These are not to be confused with the Variable Speed Pump – which regulates discharge, and not speed of the pump.
Step 1: Create the model and include the pump as type VFDPump.
Recently I had a query asking if it was possible to summarise information based on a polygon loaded as a background layer. The specific information they wanted to summarise was the average pressure from a water supply network in InfoWorks WS. Here are the steps to do this.
- Open the results that you want to analyse
- Load in the background layer
- Create a new SQL Group
- Create a new SQL within this group and name it “01…” Maybe something like “01 Set Polygon ID”. This SQL will be used to set a temporary field for each customer point saying which polygon they lie within. This assumes that your polygon boundaries are accurate and you do not have any customer points that lie outside of the polygon boundaries or are in the incorrect one. It is run on the customer point table. It is important to set the GIS search Type to Inside and select the layer that contains the polygons. The first row sets a temporary field $polyID that stored which polygons the customer point is in, this is equal to the correct field in the GIS layer. The second line will just produce a table with all of the customer points and the value that has been set for $polyID. This is useful for testing but you can remove it when you are happy with the SQL group. The SQL you will need for this is shown below;
H2OMAP Sewer is a stand-alone GIS-based computer program for use in the planning, design, analysis, and expansion of sanitary, storm and combined sewer collection systems. Here are twenty interesting features about H2OMAP Sewer and an inverse color Map look at the H2OMAP Sewer Interface (Figure 1).
| GIS Gateway, Import and Export
of CSV and Shapefiles
| Run Manager
| Sewer Map based on MapInfo
|| Steady State Simulation
| Bird’s Eye View
|| Design Simulation
| Contouring and Annotation, Map Display of Input and Output Variables
|| EPS Simulation
| Ten or More Unpeakable or
Peakable Loads per Manhole
| Input Data in the Attribute Browser
| Point and Peaking Factor Loads for Steady State
|| Output Parameters in the Attribute Browser
| Two Pass Solution with Adjusted Depth
and Adjusted Velocity on the 2nd Pass
| Advanced Force Main Iterative Solution for complex Hazen Williams Force Main Modeling, Optional Stormwater and RTK modeling
| DB Tables with DB Queries
|| Modified Muskingum – Cunge Numerical Solution
| Scenario, Facility Manager,
| Control over the number of link segments and Flow Attenuation
| Data Inference, Network Tracing Tools
|| Output Graphics, Complete Mass Balance Report and Output Gravity Main, Force Main and Manhole Reports
This post was authored by our Primary InfoMaster Product Support Engineer.
Combine ML and MLI table to create a single inspection header table
- Open the exported mdb database file with MS Access
- Create a new Query
- Add tables ML and MLI, the two tables should be automatically linked by ML_ID
- Double click on * in table MLI to add all columns from table MLI
- Double click on each column in table ML except ML_ID
- Change Query Type to Make Table Query
Pumps are routinely cycled between duty and standby. This can be modeled by using an Real Time Control (RTC) object.
In the example below the pumps are modeled for simplicity as Fixed Pumps. They have the same ON and OFF settings, and the same discharge. This example can be downloaded using the link at the bottom of this post.
The RTC uses the RANGE type pumpstate (which displays the idle time of the pump as a value less than 0 and the running time as a value greater than zero). By using a variable (DELTA_IDLE) to calculate the difference we can determine which pump needs to operate next.
A logic determines if the ON criteria is met, as well as checking whether this pump is the one scheduled to run.