Interstation Area Issue

[JesseDavis]

Hi,

I have previously been using interstation areas and have recently removed this and am now attempting to use the one area for the entire catchment. It seems as if RORB is remembering where the old interstation areas were located and is still using them even though it has been specified not to use them. I have tried running with an old catchment file that was made prior to putting the interstation points to begin with and I am still given two locations to give parameters to.

Attachments:

You must be logged in to view attached files.

[Matt Scorah]

Hi,

The screenshots you have provided are consistent; the “Single set of routing parameters for whole model” only controls whether or not Kc and m (the routing parameters) can be varied across the catchment. I have attached an example of how this window would appear if you had chosen the “Vary” option instead.

If you still have Code 7.2 nodes in the catchment file the program will still allow you to vary losses upstream of these locations. If you don’t want this option to be available you can change these nodes to Code 7, or simply give both interstation areas the same losses.

Attachments:

You must be logged in to view attached files.

[JesseDavis]

I have been back and double checked that no nodes have the code 7.2. I am currently only printing at the one node and have this as code 7.1. Despite this, when I get to the parameter specification page it is still acting like there is two interstation areas being used. As far as I can tell this can only be based off of previous runs when the interstation areas were used and have somehow been remembered or gotten stuck. I have attached the catchment file if this will help clear up the problem I am having.

[JesseDavis]

Didn’t realise that .catg files were not permitted, I have changed it to a .txt file

Attachments:

You must be logged in to view attached files.

[Matt Scorah]

I did not realize .CATG files were not allow either (we should address that!)

In your .catg file Node 120 is defined as Code 7.1 – functionally, 7.2 and 7.1 are identical with the exception that 7.2 does not require an input hydrograph, whereas 7.1 does. The typical intent is that a model will be calibrated with a series of gauged streamflow hydrographs entered into the model as 7.1s, and the calibrated parameters can then be used in design (where there are no gauged hydrographs to calibrate to) by simply changing the 7.1s to 7.2.

If you simply want an output hydrograph at a location with no division of the catchment into inter-station areas then you use the Code 7 (Print Calculated Discharge) option. I have attached a screenshot.

I hope this helps!

Attachments:

You must be logged in to view attached files.

[JesseDavis]

7.1 and 7.2 basically being the same options clears things up with that problem. I was wanting to print the calculated and actual discharge at that point so will use 7.1 and just keep the losses for both interstation areas identical like you suggested. The problem with this now is that 7.1 takes away the option to manually alter the continued losses, which is fine however the continued loss that RORB has given to the areas is 146.54 mm/h, which goes close to consuming the whole storm leaving very little rainfall excess. This continued loss is not representative of the catchment and I was just wondering why this would be happening and what I could do about lowering this to a more reasonable value.

I have attached a screenshot of the final rainfall excess to show how much this loss is consuming.

Attachments:

You must be logged in to view attached files.

[Matt Scorah]

The continuing loss option being unavailable is not related to the code 7.1/7.2 – this is because you have selected FIT mode rather than DESIGN (see screenshot attached).

The difference between DESIGN and FIT is that DESIGN allows you to set both IL and CL manually, whereas FIT calculates CL such that the volume error between the gauged and observed hydrograph is minimized. Given the speed of computation these days there is almost no reason to use FIT, because DESIGN allows you to calibrate using more goodness-of-fit metrics than just volume (e.g. peak, time of peak, hydrograph shape). Without seeing your observed hydrograph I can’t say why the CL fit is so high, but it shouldn’t be relevant because you should use DESIGN mode anyway.

Attachments:

You must be logged in to view attached files.

[JesseDavis]

Should I source my pluvio data and my flow data starting from the same time or should the pluvio and hydrograph data start at separate times, with the pluvio graph starting at the start of the storm and the hydrograph starting at the beginnning of the peak?

Attachments:

You must be logged in to view attached files.

[DavidStephens]

Hi Jesse
RORB is perfectly capable of handling either option within the storm file. The decision probably comes back to what is easiest for each user in regards to the practicalities of data collation, manipulation and quality assurance.
Hope this helps.

[zmatar]

Hi,

Seperate but similar query to the above.

A colleague has recently tried to run an old RORB model that has two interstation areas. He has used the parameter file attached (first attachment). When we checked the .out files, there was no Kc or initial loss values defined as shown in the snip provided in the second attachment.

Any idea where we’ve gone wrong with our parameter file or if this is a potential bug? We’ve used the RORB CMD instructions that have been provided by HARC (third attachment).

Cheers
Zaki

Attachments:

You must be logged in to view attached files.

[zmatar]

Hi,

Seperate but similar query to the above.

A colleague has recently tried to run an old RORB model that has two interstation areas. He has used the parameter file attached. The supplied paramter file format was required so as to be compatible with the automation tool – Storm Injector. We’ve used the RORB CMD instructions that have been provided by HARC (attached).

When we checked the .out files, there was no Kc or initial loss values defined as shown in the snip provided in the second attachment. We’ve raised this with the developer of Storm injector and they’ve suggested we contact HARC directly as it appears related to the RORB cmd.exe file.

Any idea where we’ve gone wrong with our parameter file or if this is a potential bug?

Apologies for any duplicate attachments.
Cheers
ZM

• This reply was modified 6 years, 2 months ago by zmatar.
• This reply was modified 6 years, 2 months ago by zmatar.

Attachments:

You must be logged in to view attached files.

[roloko3965]

http://doramasmp4.cl/

[Author]

Posts