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.

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

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.

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

In a simulation run window the user has the choice to use a selection list of 'gauged' objects. This is useful so as to provide the results of some objects more frequently, or to only save the results from some objects and not others, in order to keep simulation data sizes down. Currently only links can be 'gauged' objects. It would be beneficial to allow all objects to be 'gauged' as currently to save the results for 1 node requires saving all objects in the model.

(In addition, the 2D Zone is by far the most data hungry object, so having the ability to 'switch off' saving the results from this, if it is not necessary, would be beneficial.)