Hydrologic Modeling Structure (Nuts and Bolts)

March 26, 2008

 

These notes describe the structure of Hfam II from a software and tools perspective.

Hydrologic models consist of ‘algorithms’ – for example code for Manning’s equation relating flow velocity to the cross-section, slope and roughness of a stream reach – and structure – code that moves data from one model algorithm to another.

 

Structure is the foundation and skeleton of a model. It determines the scope of the model, its ease of use and its logical consistency. About ninety percent of the lines of code in a model are structure.

 

Hydrologic modeling is a miniscule specialty. It is essential to create model structure in-so-far as possible with state-of-the-art tools developed for others. Advances in hardware must also be taken into account. Ray Kurzweil, in a article about Moore’s Law in Wikipedia, shows the cost of computation in calculations per second decreasing by 100 million times between 1950 and 2000. Hydrologic analysis improves when model structures use the revolution in computational speed effectively.

 

When HSPF was designed in the late 1979/80, best practice for code development was ‘structured programming’ and modularization. HSPF was written in a logical language (Psuedo Code) before any Fortran code was written. Subroutines were limited to not more than one page. Rob Johanson supervised code development and his perseverance, insisting on structured code, was responsible for HSPF’s longevity.

 

Structured programming was supplanted in the 1990s. “Object-oriented programming developed as the dominant programming methodology during the mid-1990s, largely due to the influence of C++. Its dominance was further cemented by the rising popularity of graphical user interfaces, for which object-oriented programming is well-suited.” (Quoted from Wixipedia). Object code concepts (objects, classes, inheritance) date back to the 1960s and a subset of Algol called Simula. The Stanford Watershed Model series and all of the Hydrocomp’s early HSP code were written in Algol. HSPF was written in Fortan at the EPAs behest, which was why “F” was added to the name.

 

When HFAM II structure was designed we had, or expected to have desktop machines within one to two years with;

 

·       Physical memory on desktops of at least 4 GB

·       Disk drives with 300 or more GB

·       Continuation of Moore’s Law/ decreasing costs for calculations

 

In software tools and Internet availability we expected;

 

  • Object oriented software compilers (we use Delphi from CodeGear)
  • Adaptation of W3C XML standards (we use XML Spy)
  • World wide high speed internet connections

 

Most of these expectations have worked out – the goals of the HFAM II design have been realized.

 

  • All physical components of watersheds and facilities are objects that deal with each other in prescribed ways.
  • Objects retain physical memory only as needed (memory allocation is dynamic).
  • Calculations are made in high-speed physical memory were possible, avoiding much slower disk I/O.
  • The order of calculations among objects is solved by an algorithm (Tracey Kenward’s solution). Users no longer do this (in Hfam1.1 user’s needed to set the order of calculations).
  • All HFAM II I/O is in XML and is verified by Schemas. It is very seldom possible to make and input error in Hfam II. XML model output is read by EXCEL, WORD and many other programs.
  • Graphics for all physical processes are enhanced.

 

The main software tools used to create HFAM II are; Codegear Developer Studio (Enterprise), Altova XMLSpy, Stylevision, MapForce, Steema TeeChart Pro, Richview, Menu Machine, Blue Marble GeoGraphics, Microsoft Access, Infopath, EC Software Help and Manual.

 

For the future we need more address space per process than 4 GB (4 GB is a relic from 32-bit hardware and 8 and 16 GB desktops are available now). More software tools (compilers, applications) are needed to deal with 64-bit hardware. Software tools have historically always lagged behind hardware development. We also need more tools to better handle multi-threading for multi-core cpus.

 

 

Return to Index

 

Hydrocomp, Inc.