Transport R1 Problems

Dear All,

I am having a rather bizarre problem with some R1 cards for TRANSPORT. We are inputting 50 different hydrographs and pollutographs (just fecal coliform) that were generated by another consultant into an open channel model. In one of our runs we noticed that the final output was not getting back to baseline long after the event had passed (there is no storage in the system). After asking SWMM to echo the input hydrographs and pollutographs I found one bizarre input. The echoed input was correct until flows started to take off (>900 cfs) and then there was no apparent relationship between the numbers we thought we'd input and what SWMM was echoing. One thing I noticed is that there are some flow discontinuities in the original hydrograph. Could this be causing the problem? I have been trying to smooth it out, but still no success with the final output. Has anyone seen this kind of thing before? I am stumped.

I appreciate any and all help. What was once a set of cake walk design runs has become a potential nightmare.

Scott Dierks, PE
Limno-Tech, Inc.

What version of the SWMM engine are you using (1.e. version and date)?

Problems with R1 lines in TRANSPORT have occurred several times over the past few years, and may not yet been corrected. I have just searched the SWMMQ&A and found several references to the problem. In fact I wrote in 1999:

"I strongly recommend against R1 lines in TRANS unless you use just one simple block hydrograph only. Reason is that multiple or complex hydrographs won't work. To really see the effect you should plot a very large number of computed points using an output package like PCSWMM."

There has been subsequent discussion of the R1 line problem, mostly relating to whether TRANSPORT produces reasonable output, whereas the problem is that it generates faulty input from complex input hydrographs in R1. You could see Please use a shell that plots the input at high resolution.

In my version of the manual I have given a cautionary note (p.19 of vol 2).

It is most important that you forward your problem datafiles to wayne Huber and Bob Dickenson and that this problem be corrected.

Thanks for an important question.
Bill James

Bill,

I want to say thanks for the reply----but this is unsettling. I wasn't aware this was a problem. By the way, I am using 4.4gu. Here's one example of an input file that doesn't work---unfortunately there's more where this came from.

Thanks again,
Scott

Wayne,

I appreciate your help. Since I sent that email, I have discovered that the error is related to the maximum intensity of the event. That is, I have compared the flow and fecal coliform loads in (that is, the loads that are supposed to be going in) versus total model-predicated load out and found that the difference increases as the maximum event rainfall intensity increases (we're running a series of design events as well as a typical year continuous simulation). Below, say an inch or so an hour, the difference appears negligible. Based on this and some cursory examination of the inputs, I am thinking it may be at least partially due to some instabilities in the R1 inputs we received from the other consultant.

Also, the reason we have to use the R1 cards in the first place is because we have to assign FC concentrations to the flows based on a dry weather/wet weather concentration assignment scheme we're using.

Thanks again,
Scott

Well, it's one of our typical SWMM mysteries. I thought I had fixed the R1 input a few years ago. I use it now and then without problem -- I don't have Bill's reservations.

Wayne

Scott, this may well be in the manner of three months too late to help but I've been working on other code issues and got back to your message about the Transport R1 lines:

In a nutshell, I don't see anything wrong. I arrive at this conclusion by comparing the input flows and concentrations on your input-echo (NNYN locations, listed on the J1 lines) with the values in your massive R1 arrays. They match number for number at the indicated times.

I wonder if you forgot that in the input file you sent me (MC_CP5yb.inp) you use NFLEW = 1 on the B0 line. This means that the echoed inflow concentrations include *all* incoming flows, including upstream and constant inflows. If NFLEW = 0, it only echoes the R1 line input. When I use INFLEW = 0, I get exactly the values from the R1 lines.

If you use NFLEW = 1, then the input pollutograph echo is the mixed concentration, including all inflows to an element. If you compare that with the R1 lines, of course, they won't be the same. Also be aware, that if you use NFLEW = 0 and have input from both the R1 lines and from an interface file (e.g., from the Runoff Block), then the input-echo will be the mixed concentration.

So, I don't see a problem here. If you still have such a problem or if you haven't got it figured out on your own, please let me know.

One other point: remember that there will be linear interpolation between values entered on the R1 lines. You enter values every 15 minutes but have a 1-min time step. That means that the inflows and their concentrations "ramp" up and down from zero. Hence, you have inflows and loads coming in from 15 minutes before your first non-zero value and for 15 min. after you last non-zero value. You can force a step-function input if that's what you want by inputing two sets of flow/concentration values for the same time. For instance, if you want your first inflow/concentration to begin as a step function at 10:00, then enter a first flow/concentration value at time 10:00 of zero. Then follow with another R1 line at 10:00 with the desired flow/concentration. There will still be a slight averaging effect but this will only occur over the length of one time step (1-min in your case) instead of the R1 time interval you happen to be using (15 min in your case). Unfortunately, if you have flows starting and stopping at many different intervals for, in your case, 50 different inflow locaitons, you might have to drastically increase the number of R1 rows to get all these step changes worked out.

And finally, remember the R1 times do not have to be evenly spaced. There only needs to be an entry when there is a change in flow or concentration at one of the input locations.

Thanks,
Wayne