InfoWorks ICM Simulations – is it best to use one very powerful Server, or many high-specification Workstations?
When it comes to the setup of Simulation Servers for InfoWorks ICM, many people believe that one centralised, very powerful, server is the best approach and will provide an optimum setup. However, in many cases, this simply isn’t true. Yes, you need a powerful (i.e. fast) Server/Workstation to get the best simulation times on an individual run, but queuing everything up on a single machine, even if it’s set to run multiple concurrent simulations, is not necessarily going to get all the simulations done in the quickest timeframe. InfoWorks ICM is designed so that simulations can be spread across a pool of Workstations and Servers, allowing you to make the most of all the IT resources available within your organisation. The individual machines don’t have to be top-spec. With several machines available, they can all be running together, and between them, they will be able to churn though all the simulation runs much more quickly than having everything queued up behind a single machine, even If that machine was top-spec.
As an example, see the (silent) video clip below which shows an example of the InfoWorks ICM Coordinator scheduling 56 simulations across a pool of eight Workstations and Servers.
In the clip, each Workstation/Server is able to run 3 or 4 simulations concurrently, which means across the pool of machines some 30 individual simulations can be active at any one time. At that rate it doesn’t take long for the queue of simulations to complete. It’s for this reason that the pricing model for InfoWorks ICM has been set so that it’s cost effective to buy additional ‘sim only’ engine licences which can be utilised across a pool of many different machines.
Results File Size and Network Transfer Speed Results file size is an important consideration when creating an InfoWorks ICM Workgroup where Simulations are distributed across a range of different PCs, Workstations and Servers. Results can often be hundreds of Megabytes in size, which can increase to Gigabytes for 2D runs. Therefore, the speed of the network link between the end-user, the ICM Coordinator, the chosen Simulation Server and the Results Store is critical. InfoWorks ICM takes measures to avoid swamping the network with traffic. For example, results are moved in one ‘push’ at the end of a simulation as opposed to ‘drip feeding’ data/results as the simulation progresses, which would create a lot of network traffic. The results files are also compressed before being transmitted, and if there are lots of results to move, they are queued up by the ICM Coordinator, rather than pushing everything at once. Again referring to the earlier video clip, you can see this in operation, it takes quite a while for all the results to be transmitted to the central store, but that’s by design, InfoWorks ICM’s active traffic management is preventing the Network from being overloaded.
InfoWorks ICM configured as a Workgroup
As always, the Innovyze Support Team are on hand if you ever need help or advice. Don’t hesitate to ask if you have technical questions about our software or the hardware it’s running on.
One issue that we periodically see come across the help line at Innovyze support is an issue where the user is unable to initialize the model when they open their model in ArcGIS. When opening the model in either InfoWater, InfoSewer, or InfoSWMM they find that the model initialization arrow button is greyed out rather than the typical colored initialization arrow normally seen. As a result the initialization button is not active and the user cannot initialize the model. This also can occur quite often after the first installation of the model software where the toolbars are not visible. This post explains the issue and how to simply resolve it.
Below is a short summary video describing the issue with an explanation of how to quickly resolve it:
As further explanation of the issue, when users are unable to initialize the model or first install the software, they may need to activate the Innovyze extension in ARCGIS that they are wanting to use.
When the Innovyze InfoWater, InfoSewer, or InfoSWMM tools are active, the specific tool’s control center toolbar will be visible and it will contain a colored arrow to the right of the tools dropdown menu. It is this colored arrow that is used to initialize the software. When users are having difficulty initializing, this colored arrow is greyed out.
This is what users are used to seeing (with the colored initialization arrows active for the InfoWater, InfoSewer, and InfoSWMM platforms)
Many people believe that InfoWorks ICM can only be configured to run as a Workgroup product if you authenticate by a Network Dongle or Floating Soft Licence. This is not the case; the choice of authentication (Local Dongle, Network Dongle, Fixed soft licence or Floating soft licence) has no impact, at all, on whether you choose to run ICM standalone or as part of a Workgroup.
The dongle or soft licence just determines whether the software can start up on the desktop and a whether a simulation can be run on the machine. The ICM Coordinator and ICM Agent Manager are used to configure how the software runs once it has started up (i.e. is it a stand-alone application, or is it running as part of a Workgroup of PC’s all running ICM).
The choice of authentication method can be summarised as ‘fixed’ or ‘floating’.
Fixed licences are either a hardware lock (local dongle) or a fixed software key. Fixed licences are tied to a specific PC, so restrict the end-user to running the software on just one nominated computer.
Floating licences are either a hardware lock (network dongle) or a floating software key. Floating licences are not tied to any one PC, instead they are consumed ‘on demand’ when the end-user attempts to start up InfoWorks on his/her chosen PC. Floating licences are held at a central location (the licence server), and handed out to a machine when InfoWorks starts up on the device. They return to the central location when the software closes. The physical network link between the licence server and PC running InfoWorks must be maintained while the InfoWorks software is running.
The Network Dongle employed for InfoWorks ICM is different to the one that used to be supplied for InfoWorks CS. It’s a USB device supplied by a company called SafeNet and referred to as a “HASP HL Net” Dongle. It gives a lot more flexibility than the old type of device in terms of licence usage monitoring and it supports 64-bit applications. The operation and configuration of the Network Dongle is done via a web-browser rather than the UI of the installed licence server application. More details about the operation of the SafeNet “HASP HL Net” Dongle can be found at The Sentinel HASP Admin Control Center.
The Floating Soft Licence Manager employed for InfoWorks ICM was introduced in 2014. The software based licence manager is written and produced by Innovyze. In its default configuration it works in very much the same way as a Network Dongle. However, it also offers the ability to ‘check- out’ a floating licence to a specific PC and then use that licence off-line for up to 14 days. Checked out licences are removed from the pool of floating licences while they are assigned to a specific PC. They can be checked back in again at any time within the 14 day period, or the check-out time can be extended to a maximum of 14 days in advance of the current date. Innovyze have produced a specific blog on the subject, please see Software based licence protection for InfoWorks and InfoNet. This also contains a short video showing the system in operation.
If you need help with configuring InfoWorks ICM to operate as a Workgroup product the following resources may be useful.
InfoWorks CS is a pure 32-bit application. InfoWorks ICM is available in both 32-bit and 64-bit editions. It’s a very common misconception that 64-bit applications are a lot faster than 32-bit ones. That is not the case in general, and certainly not the case for InfoWorks ICM. When comparing simulations times of the 32-bit and 64-bit ICM Simulation Engine you will generally find that the speeds will be about the same for any given model. The only real difference between the 32-bit edition and the 64-bit edition of ICM relates to memory usage. 32-bit applications are limited to using 2.0Gb of RAM, whereas with a 64-bit application you are only limited by the physical amount of RAM installed on the PC.
So, why run InfoWorks ICM in 64-bit mode? Well, as a general rule, if your OS is 64-bit, then you want to be running 64-bit applications where possible, as both OS and application are based on the same architecture. Running a 32-bit application on a 64-bit OS means the OS has to work in a slightly ‘degraded’ mode to support the application, but in truth you won’t see much difference for InfoWorks ICM in either the User Interface performance or Simulation runtimes. Continue reading →
Our new and improved (totally revamped) Validation tool in InfoMaster (v.6) allows users to easily compare, validate, edit, and resolve discrepancies across multiple data sources. That may include all InfoMaster analysis results, GIS layers, as well as any other ODBC compliant table that links to the assets via an ID. The query-based interface is very similar to our Rehab Planning Decision Tree, this allows users to very easily build complex logic and/or evaluating statements to compare data across multiple sources.
For example, we can easily compare the difference between our GIS values for Pipe Material and that of the observed values from a CCTV Survey.
We can build a Validation Rule, select the “Material” field (values) from our GIS for Gravity Mains; then select a CCTV Survey from our ‘InfoMaster Internal Data’ to compare those values against.
Innovyze President Dr. Paul Boulos was presented with the Best Paper Award for the Engineering and Construction Division of the American Water Works Association (AWWA) at the ACE 2015 World Water Event in Anaheim, California.
What it is? Firstly, it’s really important to understand that ICMExchange is not an extra application and is not an add-on module for ICM either. An ICMExchange licence simply activates the Application Programming Interface (API) for ICM, which is hidden by default. Think of it like a back-door into ICM. Once that door is open, software code written by a 3rd party can instruct ICM to perform certain steps/operations/tasks without anyone needing to be sat in front of the ICM software itself. In other words, ICM is made to run in the background; it’s driven by a 3rd party application/process and there is nothing to see from the end-users prospective.
With this final point in mind, you’ll appreciate that providing a standard software demo, of the type we would typically do for applications like InfoWorks or InfoSWMM, Is not really a viable proposition! The whole point about ICMExchange is that there’s nothing to see while it’s running/working. When driven via the API, ICM is no longer a desktop application, it’s just becomes a background task in a much bigger process.
How it works / what it can do
With the API opened up, ICM is controlled by writing code in the form of Ruby Scripts. The programmer would need a high degree of familiarity with Ruby and with the terminology of object oriented programming. ICMExchange would typically be instigated by running it from the command line, or via a batch file. The Filename of a Ruby script is passed as an argument and the Script will then be run and have access to the Scripting API’s classes and functions. From the command line the instruction looks something like this e.g. “C:\Program Files\Innovyze Workgroup Client 4.5\iexchange.exe” c:\myrubyscripts\icmnetwork.rb /ICM.Continue reading →
InfoWater’s fire flow tool has been updated to simplify the use of the tool and the results. Fire flow can be evaluated two ways using a standard fire flow run or a design fire flow run. A standard fire flow run maintains the residual pressure at the hydrant and the design fire flow run maintains the residual pressure at the hydrant and at the selected critical nodes. The first update made to the tool was simplifying between these two runs.
The standard fire flow run uses the residual pressure option and calculates the available flow at the hydrant only maintaining the residual pressure at the hydrant. During a standard fire flow run, the user can select the time of day, the duration of the fire flow, the maximum velocity for selected pipes, and generate hydraulic reports for any elements in the system. The options are shown below in the blue highlighted area.
Many modelers make use of the “Join all Layer Tables” feature within InfoWater as it quickly joins all of the input and output data tables for each of the six InfoWater element data types to their associated ArcGIS Layer. This workflow instructs the user in how to complete the joining or removing of layer data with a single mouse click instead of four separate mouse clicks that are necessary when using the InfoWater menu path for these commands.
Due to limitations in ArcGIS, joined tables may not always update especially if the columns associated with the output data joined are changed from when the original join occurred. Typically this may occur if you join the tables and run a Standard analysis and the rerun the analysis using the Fire flow simulator. Because the output reports for these two analyses are different and have different fields, it is not possible to directly update the data due to ArcGIS joining methodology without first removing the join and then joining the data over again. Recent InfoWater changes will now automatically remove the joined tables when certain commands are completed that would run into this type of conflict such as different output data requires new output fields. This was changed to avoid user confusion when ArcGIS limitations were found to cause the joined table data to not properly update under certain conditions.
Because joining tables using the menu tools can take four separate mouse clicks, any change that automatically breaks the table joins can lead to modeler frustration as the user would have to continually rejoin the data to make full use of this feature. This post documents how a user can simplify the join procedure down to a simple click using a custom toolbar. This workflow procedure shown below can greatly speed up the table joining ( or removing tabular joins) especially if tables may need to be joined repeatedly due to this change in the software programming. Continue reading →