View Full Version : Committting Changes (map layers)

Kristian Ravnkilde
February 27, 2013, 06:55 AM
Is it really necessary for changes to display of map layers to be registered as a "change" for committing purposes? It's especially annoying when you try to run a sim with no other changes to the network, and get told (TWICE) that only the latest committed version will be used - then you worry that you've changed something else without realising it!

Andrew Walker
February 27, 2013, 11:43 AM
Any changes made to GIS backgrounds, or the addition of new GIS layers, now forms part of the overall model development. This is so that when you work as part of a modelling workgroup any 'visual' changes you make to the model are subsequently inherited by anyone else working on the model when they 'get changes made by others'. This provides aconsistent view of the model (and any related sim results) to all concerned.

If you work 'stand-alone' for the most part then I can appreciate that this additional change-tracking might seem slightly excessive, but do bear in mind it was implemented in the wider context of the Workgroup functionality offered by InfoWorks ICM.

Kristian Ravnkilde
February 28, 2013, 12:36 AM
But not everybody will be interested in the same map background or similar data, or themes - you could end up with any number of commits that just undo each other - but I see where you're coming from.

Alistair Dalton
February 28, 2013, 02:30 AM
I too have noticed this and as I have only been using standalone databases so far it is annoying! I can appreciate its usefulness for workgroup situations with multiple users but maybe you could give the option to turn this off for standalone databases?

I have found, however, that if all you have changed since your last commit is changes to GIS backround layers you can simply click the "revert changes" button and the need to commit will disappear but the changes you made to the GIS layers will remain.


July 12, 2013, 07:11 AM
This is a VERY frustrating problem with ICM!!!! The worst part is having to re-validate the model after changing the GIS layer backgrounds (even though none of the model parameters or properties changed). I am working with a very large model that takes up to 20 minutes to validate. The re-validation issue significantly impacts model editing/running workflow.

Andrew Walker
July 12, 2013, 07:30 AM
Map layer changes require validation – this changed between CS and ICM because of a desire from customers (particularly asset management customers) to have more control over the map layer settings and other network preferences. However, it's fair to say the change has not been universally welcome by modellers, not least because of the requirement to revalidate the model when layers change, which can take some time for very large models.

For the next edition of ICM (v4.5, late 2013), the Development Team will implement a change to the validation so that if you change the GIS layers you won’t have to validate again as long as that's the only type of change you’ve made. It will still mark it as a change to the network (so it’ll still tell you there are uncommitted changes), but the need to re-validate won't be triggered. This alteration in behaviour will also affect some other changes to the network that the simulation engine doesn’t care about, such as renaming scenarios.

There’s an argument that an even more relaxed approach is suitable in a modelling environment, so if the modelling community would prefer a free-for-all on map layers and other network preferences, we could implement this for 4.5 too. Please make your views known on this thread.

July 12, 2013, 07:57 AM
The "more relaxed" approach proposed for 4.5 sounds great!

Along the same "validation" lines, any approach that would minimize the validation time in ICM would be extremely beneficial. For example, during model calibration we are making minor tweaks to single subcatchments, pipes, etc. prior to each calibration run. Say I bump up the depth of sediment in one pipe by a small amount, and I want to run the model to check the sensitivity of that parameter. Currently this single iteration would take up to 20 minutes due to the need to validate the ENTIRE model (even though only one property of one conduit was changed). It would be helpful if during validation only the elements that were changed in the previous iteration needed to be validated instead of the entire model. Again, this validation issue SIGNIFICANTLY impacts model calibration workflow.

Its a running joke in the office that you can tell when myself and colleagues are calibrating a model due to the amount of cussing that can be heard over cubicle walls while we are having to wait for a model to validate for every calibration run.

Andrew Walker
July 12, 2013, 08:07 AM
Validating – the increased complexity of models and greater inter-relationships between network objects mean that validation has got slower. Many of the validation checks for a particular object involve cross-referencing other objects, which may be different in different scenarios even if the object being validated is the same. However, the Development Team are aware that this issue is becoming more pressing as model complexity increases and are already looking for ways to improve it in the future. Watch this space!

Kristian Ravnkilde
July 15, 2013, 12:47 AM
Coming back for another bite of the cherry, the "revert changes" idea works if you're ABSOLUTELY certain that's all you did! Gload to hear it's not going to be a validation issue any longer, and I thoroughly support Chris' comments on validation time. Will definitely keep watching, Andrew!