Skip to content

Patrick Moore

My feedback

4 results found

  1. 5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    Patrick Moore supported this idea  · 
  2. 10 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Patrick Moore commented  · 

    This has always been a bit of a challenge to users and would be a nice change if doable. This would eliminate the need to make most "Tank Sets" due solely to the initial tank level.

    The challenge to making the change is likely how to keep models with data stored in the old way (the tank set) to still work and now store the new data in a new table as any change would have to be backward compatible to old functionality.

    Unfortunately since EPANET cannot give an initial status this way there is no way to assign an initial status for a tank level without potentially confusing users when they look at the model in EPANET, but if there was away to do this and I would include the data with the control set as that is where initial status data is stored this would be the best dataset to use for it.

    The element modeling/hydraulic tables generally cover the modeling data that can be scenario specific and likely the reason this was put into the tank hydraulic/modeling tables, but like you in my 16 years of consulting I really wished this was part of the control set rather than the tank set. But given that the data is not incorporated as an initial status in EPANET (an unfortunate circumstance in EPANET) this almost had to be incorporated in the hydraulic.modeling data for the tanks even though it was generally the only value that changed for most tank sets.

    If there is a way to adjust this though it would be very useful, but given the way the data is stored and the need for backward compatibility it may unfortunately be difficult or not feasible to make this change.

    Patrick Moore supported this idea  · 
  3. 23 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Patrick Moore commented  · 

    While this would only be applicable to InfoWater Pro as it is 64 bit b.c ArcGIS pro is 64 bit while regular InfoWater b.c ArcGIS 10x is 32 mit, this would be a very valuable tool.

    You must have 64 bit programming to take advantage of multiple CPUs.

    But for larger models and certain tasks that can easily be run concurrently this should definitely be explored and taken as full advantage of as much as possible to reduce building input files, running the model and writing output data..

    Patrick Moore supported this idea  · 
  4. 8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    Patrick Moore supported this idea  · 
    An error occurred while saving the comment
    Patrick Moore commented  · 

    I think this would be very useful to InfoSurge users to have datasets for Surge data.

Feedback and Knowledge Base