Building a Modular Interface Between a GM and three (3) Engineering Analysis Packages
It must handle computer generated node and segment IDs or names 1
Some data needed for analysis are not stored in the AM/FM/GIS. An example is the
roughness coefficient of a section of pipe. Ideally the package will accept whatever the
AM/FM/GIS can deliver. The user will spend much more time with the analysis package than
with the AM/FM/GIS. The user will change data exported from the AM/FM/GIS, insert data
not available in the AM/FM/GIS, add new parameters and loads, “change” pipe or conductor
sizes and lots of similar work to ask the “what if’ questions of the package. So, the analysis
package needs a good interface for user changes to the imported network.. In most cases, a
“mass change” fmction is important to produce a more sparse network than can be provided
by the AM/FM/GIS.
It must be able to import without all parameters complete I
Design issues and choices
The issues we found are described below.
- How much should the AM/FM/GIS system “know” about the external package?
The minimum acceptable to the analysis package is one determinant, The more the
AM/FM/GIS has to “know”, the more changes in the analysis package will cause costly
maintenance to the AM/FM/GIS. Some are unavoidable. For example, KYPLPE 2
requires fidl set of valid header “cards” before it will accept the file, so we had to add
user prompting in the AM/FM/GIS to gather these data.
- How much choice should the user have in excluding facilities from a network?
In case you did not get the point earlier, we do not allow the user to exclude anything
that will corrupt the integrity of the network topology. So, the user can “deselect”
facilities to his or her heart’s content, but the AM/FM/GIS will not export until the
integrity trace has run successfully.
- Should the AM/FM/GIS attempt to produce a sparse network? If so, how
sparse?
The objective is to duplicate what a skilled technician or engineer would do in choosing
only pipes of certain sizes so that smaller sizes are not included in the export. This
works well in our AM/FM/GIS using queries by class and attributes. It gets tricky if
there just happens to be some smaller pipe within the flow, since the integrity trace will
pick it up and export it in order to ensure network integrity.
Ignoring nodes and fittings by merging pipe or conductor segments of the same size is
another common technique to produce a sparse matrix for the analysis package. We do
not support this completely. If a facility is a node to the AM/FM/GIS, we export it as a
node to the analysis package. We are working to develop a Spockian mind meldl” that
figures out what the engineer is going to do with the data.
Common features of analysis packages
In the process of developing this interface, we categorized these common features of the
analysis packages we examined:
- They are based on nodes connected by segments.
- Computations – pressure, flow rate, voltage – are focused on nodes.
- The route is supply to sink, high pressure to low, source to demand.
- Nodes must be uniquely named and/or numbered.
- Node to segment connection must be identified either by the proximity of the
records – difficult to program – or by ID or name.
- Duplication of a node or segment causes invalid analysis results as described
above.
10Thiswillbe in the Star Trekversion.
Typical diffemcea among anatyaii packages
Storage modeling may or may not be permitted:
- GAS WorkS permits no storage
- KYPIPE 2 provides storage via tanks
- EPANet computes chemical change overtime for water quality, a kind of in-situ
storage.
Minimum data and the nature of that data varies
- KYPIPE 2 requires full headers
- GASWorkS limits node “names” to 10 characters
- Certain fields must not be missing
- Certain required fields can be null
The table – the exported file – has varying delimiter requirements:
- Some permit only commas with no spaces
- Some let the user choose the delimiter
- Some require delimiters in place of missing fields
- Some permit columnar fields of fixed length
- Some will import from a database; for example GASWorkS will read dBasel 1
Issues in importing results
Importing the analysis results into the AM/FM/GIS is not of great importance. Most modern
analysis packages produce very readable graphic displays of results for engineers. Most
package displays provide a graphical schematic, much more compact than a spatial or map
display. Besides, time-based results, e.g. chemical or level changes, cannot be practically
displayed on a map.
Limits to importing
Then there is the practicality of it all. Few packages are designed to export the results in a
machine readable form for importing to a GIS. For example, KYPIPE 2 provides a printer-type
report so variable in content that it cannot be reliably parsed. On the other hand,
GASWorkS “fills in” the results fields in the original file so it can be imported to a GIS.
Establishing readable, unique, unchanging facility “names” shared by the AM/FM/GIS and
all analysis packages is currently not possible because the thousands of facilities in the
AM/FM/GIS require longer names than the analysis packages can accommodate.
Benefits to importing
The primary benefit to importing the data into the AM/FM/GIS is that a much broader user
community can have access to the information. Displaying selected results on an
AM/FM/GIS map is more readable for most users.
11dBase is a trademark of whatever company now owns it.
There is a trap that must be considered, though. You need policies to prevent
misinterpretation of capacity and other results. In the hands of staff who like to give “no
problem” answers to capacity questions, this information could get you in serious trouble.
We have worked out some of the technical requirements. A series of additional display
methods, behaviors or procedures need to be written for the GIS to display the results. A
mechanism is also needed to manage multiple analysis results within the AM/FM/GIS.
Conclusion
Exporting network data from an AM/FM/GIS for use by an external analysis or modeling
program has two major benefits. First, ~the AM/FM/GIS keeps accurate, validated network
topology, the exported file will be more accurate than having an engineer read the paper maps
and type the network into tables. Second, you save some time for your most costly
professional staff.
The ability of an AM/FMIGIS to export to an analysis package can be exaggerated. It cannot
produce as sparse a network as a skilled technician or engineer. That can mean higher
software fees, slower performance and more voluminous output. Like most technology, you
have to judge when to use it and when not.
Exporting from an AM/FM/GIS fits best for frequent, simple analysis of sub-networks. It is
the sort of thing we avoided in the past because getting the data in was too costly and time
consuming.
Acknowledgments
This work started out as a prototype for electric. David Turvey of Laser-Scan did the work to
prove the design concepts. Mark Kennion of Laser-Scan then extended this for piped
networks and took on the daunting problems of looping. Finally, Ramesh Kumar of Williams
Associates had the pleasure of putting it all together into a practical system. They have my
thanks for adding their great technical insight and corrections to what I envisioned.
