Contact us

Interstation Area Issue

Home › Forums › Bug reports › Interstation Area Issue

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • February 23, 2018 at 2:12 PM #940
    JesseDavis
    Participant

    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.
    February 23, 2018 at 2:36 PM #943
    Matt Scorah
    Moderator

    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.
    February 23, 2018 at 3:43 PM #945
    JesseDavis
    Participant

    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.

    February 23, 2018 at 3:48 PM #946
    JesseDavis
    Participant

    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.
    February 23, 2018 at 3:59 PM #948
    Matt Scorah
    Moderator

    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.
    February 28, 2018 at 3:22 PM #950
    JesseDavis
    Participant

    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.
    February 28, 2018 at 3:38 PM #952
    Matt Scorah
    Moderator

    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.
    February 28, 2018 at 4:02 PM #954
    JesseDavis
    Participant

    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.
    February 28, 2018 at 4:19 PM #956
    DavidStephens
    Moderator

    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.

    October 4, 2018 at 10:15 AM #1354
    zmatar
    Participant

    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.
    October 4, 2018 at 10:20 AM #1357
    zmatar
    Participant

    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, 1 month ago by zmatar.
    • This reply was modified 6 years, 1 month ago by zmatar.
    Attachments:
    You must be logged in to view attached files.
    June 14, 2022 at 4:20 PM #2549
    roloko3965
    Participant

    http://doramasmp4.cl/

  • Author
    Posts
Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.
Linkedin
Melbourne

Phone: +61 3 9908 2160

Suite 3, 41 Railway Rd
Blackburn VIC 3130

Sydney

Phone: +61 2 8381 6840

PO Box 399
Frenchs Forest NSW 1640

Brisbane

Phone: +61 7 3340 4373

Suite 3 Level 1, 31 Station Rd
Indooroopilly QLD 4068

Copyright © 2024 HARC Services Pty Ltd. All rights reserved.