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.

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'.

Allow the user to choose the flood type of pond or storage nodes from a drop down as is the case for manholes. As opposed to the current state where the flood type depends on the relationship between the highest level entry in the storage array and the ground level of the node.

From help file: "Storage nodes or ponds can flood. If the highest level entry is below ground level, the pond is considered to have a roof at that level and is therefore sealed. If the highest level entry is equal to the ground level then any water above ground is lost from the system. If the highest level is above the ground level then water is stored in the node."

Currently when a porosity value is applied to a storage node, the porosity is only applied for storage array entries which are below ground level. Storage array entries above ground level are assumed to have a porosity of 100%. Between the highest storage array level value below ground and the lowest storage array level value above ground the porosity is assumed to increase linearly between the value you applied and 100%. i.e. the storage is assumed to be conical.
This should be corrected. The porosity value applied should be applied to the whole storage array both above and below ground.
An improved version beyond the above correction would be the ability to vary porosity throughout the storage. For example, a SuDS bioretention unit, or pervious pavement would have variable porosity with depth.

ICM's default representation of manholes could be more accurate. The limitations of current setup allows accurate representation of either the shaft or the benching but not both. Thus most people tend to apply chamber areas to invert which overestimates the volume prior to surcharge or the shaft to top of benching which overestimates the volume at the surface.

Because we can now define the benching in the database, it would be better if the default dimensions for manholes were altered to represent 4 critical levels, invert, top of benching, roof, and cover. With associated areas as channel, chamber and shaft.

In this setup given a fully benched manhole, the channel volume is marginal since it is already accounted for in the connecting pipes. The chamber volume would start at top of benching and shaft from roof to cover.

This would also allow better representation of ancillary structures without the need to use storage ponds.

Further to this, the default chamber area calculations could also be improved by applying a specification database field (or date of construction) to the manhole, thus sewers for adoption or CP2005 etc. The specification would drive the default chamber area / shaft calculations based on the rules set out in these specs. This is important as the current default calculations underestimate the volumes of manholes on small diameter systems. Since these systems make up the vast majority of any network, the combined loss in system volume overall is large and contributes to overpredictions of flow and flood volume in extreme events.

Can we please revisit the assumptions in the additional storage routines.

In a world where everyone has access to accurate property location data, via customer seed points and subcatchments can be any shape or size. The distances between properties and sewers can be much more accurately determined in the calculation than is currently the case, based on the existing A/4L.

The calculation also makes no allowance for private inspection chambers, which in many instances would provide more volume than the pipe.

Two versions of the equation driven by a new field in the subcatchment would also be better allowing lateral connections as now, and section 24 connections, derived from the distance between the furthest property from the receiving manhole.

Inlet capacity creates a second node internally to XPSWMM. Currently, the rating curve methods for it are calculated based on node depth, rather than head differential, which doesn’t work right with 2D if the storm sewer HGL is above the gutter.

I really like how inlet capacity doesn’t require adding an extra node. I would like to suggest it be expanded as follows:

1) Simply add a head differential rating curve.

2) Add a structure-based option for inlets,

For a structure-based inlet, it could essentially be a multi-link. I would like to have a global database of standard inlet types that describe the geometry and choose which one to apply, set the inlet invert/grate elevation, and have XPSWMM handle splitting the node to create the link.

This is mostly good for sag inlets. For on-grade inlets and 2-D, I haven’t tested, but the “rated by approach flow” seems promising. I suggest to have a 1D/2D interface where XPSWMM calculates the total flow across the line, then uses that flow and the gutter geometry to calculate the depth and inlet capture. That would, of course need to have a submergence reduction, where high head in the storm sewer would reduce the capture or cause reverse flow.