Joe Lawrence
My feedback
20 results found
-
3 votesJoe Lawrence
supported this idea
·
-
4 votesJoe Lawrence
supported this idea
·
-
5 votes
Thank you for this suggestion. We are in discussion on some proposed work that helps with this use case.
Joe Lawrence
supported this idea
·
-
2 votesJoe Lawrence
supported this idea
·
-
5 votesJoe Lawrence
supported this idea
·
-
7 votesJoe Lawrence
supported this idea
·
-
7 votesJoe Lawrence
supported this idea
·
-
7 votes
To be clear, changes to the parent can cascade to all child scenarios as long as the same data set is used.
To inheret changes where datasets are different would introduce complexity and room for error in model management.
This seems to be specifically a request for a new parent-child relationship among data sets which could exist parallel and independent of the scenario relationships. This way a child scenario could use a child dataset that varies at certain nodes, but still inherets changes from the parent as long as they're still matching - the same way that InfoWorks software handles scenarios. I see large benefits of this approach but it could certain confuse many modelers.
This is valuable feedback as we discuss model data management in the cloud. Thank you.
An error occurred while saving the comment An error occurred while saving the comment Joe Lawrence
commented
Thanks Colin Ricks for your comment. It is good to hear from other water modelers. To respond, I would argue that it depends on the type of modeling you do, or the way you approach modeling. There are likely different modeling approaches even between the users of InfoWater Pro. Maybe this is an option that the modeler could choose in the project preferences for a model to allow or not allow cascading changes through the datasets.
The situation I run into the most with this issue is when we receive an update from the client on their existing system parameters or data. I have already created multiple proposed scenarios based off the existing system (it can be upwards of 10 proposed scenarios). If I must update the existing pipe diameters, adjust valve settings, turn off or on initial settings...I must go into each scenario that has a unique dataset and manually make those updates. It would be simpler and more efficient if I made the change to the "parent" existing scenario dataset(s) and then let the program update all child datasets (i.e., proposed datasets) unless there is a manual override. The current situation (no parent-child relationship) inherently consumes time and money. It also introduces potential for errors as someone must physically input the values into each scenario with a unique dataset. I’ve found from experience the more manual entries performed the higher percentage of error(s) will be present in the model.
Hope the sample situation above helps explain how the current setup is not always "simple" and "efficient" on my end.
Joe Lawrence
shared this idea
·
-
23 votesJoe Lawrence
supported this idea
·
-
1 voteJoe Lawrence
shared this idea
·
-
2 votes
An error occurred while saving the comment Joe Lawrence
commented
Additionally, the "Edit Domain" or "Edit Selection" tool is nice, but it also opens up a completely different table. Could you make ONE table that can view everything and easily edit what is in the domain or selection?
Joe Lawrence
shared this idea
·
-
1 voteJoe Lawrence
shared this idea
·
-
10 votesJoe Lawrence
supported this idea
·
-
6 votesJoe Lawrence
shared this idea
·
-
4 votes
An error occurred while saving the comment Joe Lawrence
commented
Please, this is a must. This isn't a new feature as it has been around for the past decade in other modeling alternatives.
Joe Lawrence
supported this idea
·
-
5 votesJoe Lawrence
supported this idea
·
Joe Lawrence
shared this idea
·
-
5 votes
An error occurred while saving the comment Joe Lawrence
commented
Agreed, this needs to be a feature in the DB tables. Specifically, the default for the string data type field should NOT be initially 20 characters. Set it much larger like 250 characters.
Joe Lawrence
supported this idea
·
-
10 votes
Partially completed: “Change ID” window is now resizable. Functionality available from InfoWater Pro 3.5 Update 2. Target release data April 2021
An error occurred while saving the comment Joe Lawrence
commented
As a modeler it is important to adapt to project changes or correct mistakes. This would help maintain consistency with referencing elements with the correct ID.
Joe Lawrence
supported this idea
·
-
2 votesJoe Lawrence
supported this idea
·
-
4 votesJoe Lawrence
supported this idea
·
Even from the discussion between Colin Ricks and I, it is apparent that the method and/or approach to modeling can and does differ slightly in the professional world.
Regarding WaterCAD/GEMS’s parent-child dataset (i.e., alternative) relationship, I personally do not feel it causes more problems. Yes it is a little more complex, but the water modelers in my company generally prefer this feature over the current setup in IWP. We find it is easier to update records in the parent dataset as this allows the changes to cascade through to the child datasets (i.e. alternatives).
Regarding implementation to IWP, this would not have to change the entire interface of the datasets in IWP. The current setup could be default, but with a setting to manually change the datasets relationships. To Colin Ricks’ point, if younger or inexperienced modelers are unfamiliar with the program or how a parent-child relationship works, this may precipitate error. However, I believe this feature would not detract, but rather add value and enhance the capabilities of IWP. This would be appreciated by modelers who choose a more complex form of modeling or prefer to work with child-parent relationships.