Continuous Simulation

Dear SWMM Users of Runoff with Continuous Simulation,

I am doing an informal survey of users who do long term continuous simulation with the following characteristics:

1. Many thousands of watersheds,
2. Decades of simulation time, and
3. Multiple water quality parameters.

I would like to hear from any one who has experienced the following problems with this type of simulation:

1. Unpredictable write errors when the size of the interface file reaches 2 to 4 GB's in size.

I think I have solved this error by altering the compiler options so buffered reads and writes are used instead of one line at a time flushing but I am curious if anyone else had a different solution.

Best Regards,
Robert Dickinson
dickinsonre@cdm.com

Okay, I guess I will have to answer my own question. It does turn out that altering the Compaq Digital Fortran interface options so that I/O buffering is used by the SWMM model will prevent write errors when making multi-GB interface files. The subroutine inface.for also has to modified so the interface headers are not written twice. The interface file headers need to be saved to a common block in each of the major and minor modules of SWMM. If you as a SWMM user encountering this problem with version g or version h of SWMM you will have to get an upgrade dated probably after November, 2001 to eliminate the problem.

To all SWMM continuous simulation users:

I would like to retract an earlier email in which I mentioned that large watershed models run using the Runoff block can overcome an interface or scratch file problem by changing the record length and blocksize of the interface or scratch file. These changes do help somewhat but the underlying cause of the problem is not addressed.

The real reason large watershed models (by large I mean thousands of watersheds and at least ten pollutants) were experiencing interface and scratch file problems is that the file size was exceeding a Windows limitation. Windows 95/98/Me files have to be 2 GB or less. Windows NT with Fat32 files have to be 4 GB's or less. Windows NT with NFTS drives or Windows XP with NFTS drives supposedly can have any file size but it still seemed to fail around the 4 GB limit. We were able to reach file sizes of 4.4 or 4.2 GB by changing the blocksize but this was a false solution.

We finally realized that the SWMM architecture needed to be changed. Currently in version 4.4h of SWMM and earlier versions when you ran 5,000 watersheds without any gutters in runoff then 5,000 inlets would be saved to the interface file. Additionally, if you also wanted to print out the loads at the end of runoff then 5,000 inlet flows and loads would be saved to a scratch file. At the end of an aborted simulation you would have either two 2 GB files or two 4 GB files basically containing the same information. This results in a severe crimping of the possibilities for continuous simulation because a 5,000 watershed model could only be run for one or two years.

A change was made to the runoff layer of SWMM to allow the flow totals and loads to be calculated and saved to an array at each time step as an option. This eliminates both the need for the interface file and the scratch file in runoff. Now with this option essentially any number of watersheds can be run for any number of years because the file size limitation disappears. A further advantage is that the model runs are appreciably faster (2 to 4 times) because much of the I/O overhead has disappeared during the simulation.

Best Regards,
Robert Dickinson
dickinsonre@cdm.com

William -

It is difficult to hot-start Runoff and Transport simulations (Extran
runs are easily hot-started). You should keep in mind that Runoff
doesn't care what the flow is in the Transport piping at any given time;
it only passes discharge data to Transport, which in turn always starts
"cold" and reads flows from the interface file. In Runoff, while you
can start a new run with specified values for subsurface soil moisture
and groundwater stage (and for snowpack parameters), you cannot specify
starting conditions for the surface runoff. The depression storage and
flow depth over the catchment may be important values if one simulation
ends with water remaining in surface storage. If you have very long
times of concentration, this could throw your results off a good bit.
Otherwise, if two one-year runs produce a very different final condition
than one two-year run, I suspect your groundwater parameters aren't set
correctly. If your baseflow always drops to zero a couple of days after
a storm (even during spring flood), you need to re-examine the
groundwater stage and its relation to the channel bottom (the H2
parameters). Consider posting your H2-H4 parameters for one of your
catchments to this list, along with the evaporation values you're using,
or post a working Runoff file. Transport shouldn't have anything to do
with the results of your Runoff baseflow calculations.

Regards,
Mitch Heineman, P.E.
HeinemanM@CDM.COM