When opening an ICM network for the first time (i.e. no network files in the local files "Working" folder), the WDS reads through the database file in 4 kB chunks to retrieve the requested version of the network. This read process appears to be limited to a disk "queue depth" of 1 and is therefore very sensitive to drive latency. In a cloud environment, drive latency can be in single digit milliseconds. Therefore, the read process might achieve 400 x 4 kB = 1.6 MB per second. If the database file is large, it can take many minutes for the network to open. A similar process appears to take place when producing graphs or statistical reports from results files. Would it be possible to re-engineer the database read process so that a larger queue depth or i/o size could be used to achieve a significant improvement in read times?

Infoworks ICM pump station modelling principle is very basic, adding a pump between two nodes is highly hypothetical. There is no way to add pump station head losses.
I would like to suggest incorporating pump station modelling (for Rotodynamic pumps) with pump curve and system curve theory. Then the model results would be much more realistic.
There must be a tool to incorporate all the accessories in pump stations, between two nodes. Like pump station type, drywall wet well. And Parameters to calculate Pump suction and discharge losses, like all fittings, non-return valves, discharge valves, flow meters etc. This would be helpful for model calibration purposes.

As a toggle setting in the run settings or in a wastewater/tradewaste pattern, this would shift the diurnal patterns based on the simulation date and daylight savings time start/end dates instead of working on standard time all year long. Mathematically, this is really straightforward, but may require internal indexes (and warning messages?) for the DST start/end dates. It would also require something to turn this feature on and off as there are several areas that do not observe DST. This feature would help us more accurately predict combined sewer overflow volumes and durations where base wastewater flow has a significant influence on CSO activity.

ICM and Infoasset databases offer a system that allow hyperlinked documents to be connected to the database. Primarily this to allow survey, as laid and other background data to be available to the user and is a powerful function that if used correctly would allow databases to become much easier / quicker to check, improving quality and confidence. Currently the models are abstract representations of the systems, and to check detail requires arduous library time retracing other people's steps. Having the data bundled with the model is a significant improvement.

However, two practical problems arise, since many different organizations work on models over their lifetimes, using their own IT systems, it is currently impossible to maintain the hyperlinks. The hyperlinks are set relative to the "remote files root" which serves an entire master database, thus there would be many files relating to many catchments within the "remote files root" and many models could also reference the same files.

So the proposal is for Innovyze to develop and dictate a standard directory file structure for the "remote files root" which can then be adopted by everybody wishing to use the function. It would need to be simple, visible in windows and probably reflect the data structure of the master database, the detail of structure is not actually that important, what's important is that everyone adopts the same protocol. Further, a compiling function is needed that would create a transportable data file containing some or all of the attached documents, on receipt the complier would also explode a transportable data file into the remote file root. Thus ensuring that the links are maintained at both ends of the transfer.

I can already batch print geoplans and Long Sections by themselves. How to print them together? My current approach is to learn how to manipulate the output PDFs using PDF TK server, ghostscript, and potentially pdfjam, but some of these are new tools for me and I haven't yet made it work. Is there some way to do it using the Print Layout?

Current work in progress:

Batch printing geoplan
Save each spatial extents using Spatial Bookmarks
Set up print layout, then select batch print button from toolbar in the Print Layout
Geoplan showing each bookmark is saved on its own page in the PDF

Batch printing Long Section
Identify the page number using conduit Branch ID
Create a selection list for all conduits to be shown
Open a new long section window
Load the selection list
Right click, in the long section window, "create from selected branches"
Each branch is shown on its own page
Print from the long section window
PDF is created showing the long section of each branch on its own page

Thanks!
Nicholas Bear
San Francisco

I would like a feature in which you can see individual rainfall event files within a model group once you have generated rainfall rather than the current setup of having to export from the software then having to import back into the software to see the generated rainfall split into the individual event files.

Although you can view the individual event files by right-clicking the generator files and selecting Open As>Grid Editor (TVD read-only), this is not helpful if you wanted to simulate specific rainfall events in which it is easier to select the specific rainfall event file you want rather than selecting the generator file and cancel the events you do not require.

Attached is a screenshot of the generator files in the model group named "Original Generator Files" and the end product that is often preferred is shown in the model group "Final Rainfall Files". It would be great if there was a feature which allowed the files shown in "Final Rainfall Files" to be created without needing to export from the model.

Pond nodes:
- allow variable infiltration at different levels (up to 3 different rates)
- allow variable perimeter with level i.e. plan area through which side infiltration can occurs can vary
- no porosity function

Storage nodes:
- 1 porosity value (which only works below ground, above ground it is assumed to be 100%)
- fixed perimeter for infiltration i.e. assumes cylindrical shape for infiltration (despite the plan area changing with level)
- fixed infiltration rate (no change with height)

It is not possible to model both porosity and a change in infiltration with height.

I propose that pond and storage nodes are merged into 1 unit (they are effectively the same thing anyway).
Within the storage-plan area array allow extra columns for: perimeter, porosity and infiltration.
There should be a simple tick box to say whether to allow infiltration through the base and/or/neither sides.

This functionality would be essential for modelling SuDS for example a biorientation SuDS unit with variable medium at different layers, or a lined infiltration system with no base, but side infiltration etc.
At present modelling SuDS units is quite a 'fudge'.