Forum Replies Created
It’s a little hard to debug this storm file without the catchment file, but a few things to try:
The hydrograph starts at time 0 and ends at time 11, but 11 readings are supplied. This is a little confusing but the hydrograph data is instantaneous (unlike rainfall, which is rain over each time increment), so under C HYDROGRAPH DATA it should be 0 10
Ensure that your model has 16 subareas in the catchment file
This wouldn’t result in the error you’re getting but I just want to flag that the pluvio temporal pattern you are using (1 in the first increment to 12 in the last increment) is odd – this will apply lots of rainfall at the end of the event, is this intended?
If these don’t help please either upload the .catg / .stm file or send it to the enquiries email address.
- This reply was modified 3 weeks, 4 days ago by Matt Scorah.
Could you please send an email to email@example.com with a copy of the files so we can debug this? I’m not sure what would be causing this from your description.
The error message quotes the last valid storage discharge that was achieved in the run (e.g. just before the storage discharge table was exceeded) – so the number quoted in the error will be in the range of the table. It is likely that not every run in the Monte Carlo sample exceeds the range of the storage discharge table, which would explain why the single run doesn’t exceed the storage discharge table (e.g. it might not become a problem until a particularly rare rainfall or low loss is experienced).
I would recommend extending the storage discharge table (and the storage elevation table if used) and seeing if the model runs in Monte Carlo. By looking at the reported peaks in the summary file you will likely see for what runs the previous maximum discharge was exceeded.
If this doesn’t fix the problem please send through your model files to firstname.lastname@example.org so that we have more information to work out a solution.
- This reply was modified 7 months ago by Matt Scorah.
ArcRORB is not compatible with ArcGIS Pro. In general, add-ins developed for ArcMap don’t support ArcGIS Pro because ArcGIS Pro is a complete re-implementation of ArcMap, so add-ins made for one must be completely remade to support the other.
We currently have no plans to support ArcGIS Pro. It would be a significant amount of effort to remake the plugin in the new environment. If, at some point, the appetite for an ArcGIS Pro version increased we may consider it, but we would have to find the right partner to commercially support this.
Sorry for the bad news!
Interesting, I didn’t even know there was an XML file there with that info! Thanks for posting your solution.
I agree with Dave’s comment that you may have to follow this one up with ESRI. ArcMap has very limited options for silent install of add-ins, and they both have issues that make them not straightforward.
As far as I know, there are two options:
1) Place the .esriAddIn file in the folder location that ArcMap searches when it opens. The problem with this is that the directory is “C:/Users/<username>/Documents/ArcGIS/AddIns/Desktop<version number>”, so you can’t use this method to install for all users
2) AddIns can be installed from a shared network location (this is documented in the installation section of the ArcRORB manual). Setting the network location to look in is usually done in the ArcMap interface, but it can be done by editing the registry. I can’t offer support on this approach (nor do I recommend it unless you are *very sure* you know what you are doing), but the relevant registry key is \\HKEY_LOCAL_MACHINE\SOFTWARE\\Wow6432Node\ESRI\Desktop<version number>\Settings\AddInFolders.
Sorry I don’t have a better answer, but this is a limitation with ArcMap so we can’t do much about it. Good luck!
The RORBWin.tmp file is separate to the output file, and typically does not contain any useful diagnostic information. You will need to look at the output file to figure out what is going wrong. The output file has the suffix “.out” – the location of this file depends on how you’ve set up your model but some common locations include the same folder as either the .catg file or the parameter file.
The selection of temporal pattern by AEP is for when you’re running Monte Carlo. If you are doing a single run, you need to specify the index of the temporal pattern to use. By default this index is “1”, i.e. the first temporal pattern in the file. The first pattern of the rare bin would be index “21”. This index is set using the “Select patterns for deterministic runs” button. Some documentation around this is in the v6.31 release notes word document
Hope this helps!
In order to generate results for a given AEP of interest you require runs that have been generated using rainfalls either side of that AEP – therefore, to estimate 1 in 100 floods you need rainfalls rarer than 1 in 100. For this reason RORB will not report Monte Carlo results for the first and last AEPs specified in your IFD input.
When downloading IFDs from the BoM website design rainfalls are split into three different tables – Very Frequent, IFD (up to an AEP of 1 in 100) and Rare (AEP of 1 in 100 to 1 in 2000). You will need to download both the IFD and Rare tables and combine them (either in the RORB interface or Excel) and rerun the model to get results for an AEP of 1 in 100.
I hope this helps!
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.
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!
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.
Thanks for raising this. In order to replicate this could I please check the following:
What version of RORB are you using?
Do you have a print node at a location which is receiving zero flow (e.g. if you turn off some print nodes does the error go away?)
- This reply was modified 2 years ago by Matt Scorah.
Thanks for this, these are good suggestions. At the moment the labeling scheme is based on the index of the design rainfall AEPs and durations (rather than the label), so for now you can get the AEP or duration of the event by looking up your user defined rainfall file. For the next release of RORB we will change this labeling scheme (e.g. using the AEP/duration labels as you suggest).