You need have no concerns when going from InfoWorks CS (or CS/2D) to InfoWorks ICM as there’s a 100% match in the approach used for building Stormwater and/or Wastewater models in InfoWorks CS and InfoWorks ICM. A migration file is exported from CS and imported into ICM. This maintains all your data and database components. All the CS techniques you’ve used to date will be just as relevant for InfoWorks ICM. It’s a little different for ‘Rivers’, with a number of items being done differently between river models such as HECRAS, ISIS, Tuflow, InfoWorks RS and InfoWorks ICM, although the basic concepts are, of course, the same. The approach for adding 2D elements in InfoWorks ICM is also very similar to the approach and techniques used in both InfoWorks CS/2D and InfoWorks RS/2D.
The success, or otherwise, of going from CS to ICM and back to CS again all depends on the original CS model. Providing a seamless path from ICM back to CS is not always a practical proposition as there are only a limited number of occasions when a model built in ICM can cleanly go back to CS. The outline below should help you understand where the limits are.
InfoWorks CS 1D models
If the CS model is a basic 1D pipe model, it will remain unchanged when migrated into ICM and when run in ICM will produce the same result. If you then export the model as a CSV file and re-import it into CS it will be unchanged from the original CS model, so will produce the same result when run again in CS.
If the CS model is a 1D network with ‘river’ sections, these will be changed to ‘reaches’ when the model is migrated to ICM. As the model will be slightly different once it’s in ICM, the results can no longer be expected to be exactly the same as CS. An ICM model with ‘reaches’ can’t be imported into CS, so there’s no return path to CS.
InfoWorks CS/2D models
If the model is a CS/2D pipe model, if it is run, unmodified, after being migrated in to ICM (i.e. it’s not re-meshed), when run in ICM it will produce the same result. If you re-mesh, the model will change as the ICM meshing process is more optimised, so the mesh will be different. As the model will be slightly different, the results can no longer be expected to be exactly the same as CS/2D.
If the CS/2D model contains ‘river’ sections these will be changed to ‘reaches’ when the model is migrated to ICM. As the model will be slightly different once it’s in ICM, the results can no longer be expected to be exactly the same as the original CS/2D model.
If you export an ICM model containing 2D elements to a CSV file, it’s only the 2D boundaries that are exported (i.e. main 2D zone boundary and any mesh zone boundaries), not the actual 2D mesh. The model would need to be re-meshed in CS/2D to generate a new 2D blanket. This will be different to the 2D blanket created by ICM (different, less optimised, meshing algorithm in CS). An ICM model with ‘reaches’ can’t be re-imported into CS/2D, so there’s no return path to CS/2D for that type of model.
Other important considerations
When comparing runs done in CS and ICM, it’s important you use compatible versions of the ‘engine’. If the CS model is v12.5, then you would have to compare results with ICM v2.5. If the model is in ICM v3.0, then the comparable edition of CS is v13.0. You should not compare editions of ICM that are earlier than v2.5, as CS and ICM were not in sync until that point in ICM’s development.
Also, InfoWorks CS is a 32-bit application with a 32-bit engine. So, when comparing results with InfoWorks ICM, it’s important you use the 32-bit edition of InfoWorks ICM with the 32-bit engine. Comparing CS results with the 64-bit edition of ICM will reveal slightly different outputs, especially on large models. This is down to minor rounding issues generated by the two different compilers. Sometimes comparing the results produced by the 32-bit and 64-bit editions of InfoWorks ICM can reveal slightly different answers within InfoWorks ICM itself.