We'd like to have model results as an input in the TVD connectors. An example is where we have observed flows that we would like to use at a tributary and then switch to catchment flows when the observations run out. We know this can be done using a set up of sluices and dummy objects but it would be a lot more elegant to simply have the subcatchment as Input B. I'm sure there are plenty of other examples of where using model results as an input would be useful.

Options such as 'Reintegrate' & Duplicate'

As a use the ability to 'schedule' statistical reports would be extremely useful. currently if i'm generating a spill report on several overflows for a 10yr TSR series this can take several hours. The process effectively locks the software and prevents any other operation from been undertaken. This is highly inefficient and costly especially when optioneering if several iterations are needed. Shorter TSR's can be run in this case however even a year with several CSO's can take 20-30mins.

I am working on project which includes 50 models. where we have to give runs for different return periods and durations for each model. It is a time taking process, which unnecessarily create chances of error by creating run setup every time. is it possible to include a run set up template, which can be changed as per the user requirement and saved for the further use.?

With the large amounts of data generated it would be beneficial if a supported configuration would be to have a WDS installed on a server but pointing at databases (and solves etc) over the network on a remote storage system (such as NAS). This would make the whole solution far more scalable as the need arose.

Please include weirs and orifices in the ARR Ensemble Statistics summary. Currently, only conduits or natural channels are included.

Creating or amending ICMTs is slow, especially if they contain ground models. Even deleting or creating new 'folder' items in ICMTs is slow. Speeding this process up would increase productivity.

I have a model that has masses of roughness polygons. invariably some of these overlap. I also have overlapping roughness zones where I have 'donut' features. My life would be SO much easier if meshing didn't fail when the roughness zones overlap. Can we p[ease have the restriction on these relaxed? If we have to specify a priority then that would be acceptable. It doesn't seem to be a problem with HEC-RAS or TUFLOW.... :-)

Is there a matrix type tool in ICM that allows you to easily set up complicated run set ups? i.e. for this 1 Model Network, these runs with use these rainfall files, inflow files, WWG, etc are needed.

Model Name
Base Model

Rainfall Inflow WWG Tradeflows
M5-30 Inf-M5-30 WWG1 Trade1
M5-240 Inf-M5-240 WWG1 Trade1
M5-960 Inf-M5-960 WWG1 Trade1
M10-30 Inf-M10-30 WWG1 Trade1
M10-240 Inf-M10-240 WWG1 Trade1
M10-960Inf-M10-960 WWG1 Trade1

With same timesteps and 2D parameters?

We all make mistakes!

When applying direct rainfall onto 2D zones traditional roughness values do not typically apply, especially where the depths of water on the mesh element are very small. Often the workaround is to apply much higher roughness values in order to 'slow the flow'. It would be helpful to have a depth varying roughness that could be phased out as the water depth increases. This would put ICM in line with how TUFLOW and Flood Modeller Pro deal with the problem.

Can we please have net/effective rainfall as a result?

Currently the only GeoTIFF standard supported in ICM Spatial TSDB is the MeteoGroup standard. But some Authorities in Germany deliver rainfall data as generic TIFF.
It would be nice to extend the import feature to a generic GeoTIFF format.

Keyboard shortcuts can really help speed up processes and workflows in InfoWorks ICM but some of the menu options do not yet have these. Would it be possible to add the missing keyboard shortcuts, specifically for repeatable tasks such as updating objects from ground models?

Sometimes when evaluating results at structures we see strange results that require investigation; invariably we find out that this is because the flow mode has changed. (e.g. from free to drowned). It would be very helpful if the ICM results were able to report the flow mode as a time-varying output. This would result in a lot of time saving when investigating models. For reference I am referring to the Flow Mode functionality that is available in InfoWorks RS and Flood Modeller Pro.

Our team uses Python scripting extensively for data analysis and manipulation, while Ruby is foreign to us.
Please provide scripting support for Python for model manipulation and analysis.