Multiple ARFs in Storm Injector

[Marcela Freitas]

Hi all,

We are currently working with a big RORB model, which required a more complex approach to ARF, including having more than one set of ARF values.
Currently, we don't see any options for varying ARF factors within a model area in Storm Injector/RORB. Would that be possible to have different sets of ARF values within the same run?

Thank you,

Marcela

[Chris Ryan]

Hi Marcela,

 

ARF parameters in Storm Injector are expected to be consistent for the whole model (like all Data Hub parameters). However, you can do Partial Area Check (PAC) events to explore the effects of different ARFs on the results at various points in the model. You can find the custom event code for PACs at: https://csse.com.au/storminjector_online_help/selection-of-events.html

 

I hope this helps.

Regards,

 

Chris

--
You received this message because you are subscribed to the Google Groups "Storm Injector" group.
To unsubscribe from this group and stop receiving emails from it, send an email to storm-injecto...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/storm-injector/d96e1c1f-d6dc-419a-b534-d54705641ab8n%40googlegroups.com.

[Dylan Chenoweth]

Hi Marcela, we have had a similar experience.

It's generally not advised to use multiple ARFs throughout the same catchment because if they are all specified for individual sub-catchments or sub-areas, then typically this will result in less reduction of the original rainfall depth and therefore the downstream reach flows may be over-estimated. The logic behind ARFs is that the likelihood of Xmm of rainfall falling equally over an entire catchment reduces as the catchment area increases. So if you have a large catchment but have then specified ARFs for multiple sub-catchments inside of it, then the ARFs will be based on smaller catchments and therefore the rainfall depths won't reduce as much. It makes for more conservative modelling of the sub-catchments in question, but as mentioned, anything in the receiving reaches downstream may be considered an overestimate. Apologies if this has already been considered.

However, if the downstream reaches are largely being ignored, you can generate multiple events from the events page by adding 'custom' naming to their title e.g. 'ARF50_XXX' 'ARF100XXX' 'ARF200_XXX'. Change the ARF value to the corresponding custom name/event before hitting 'generate storms' to ensure the correct ARF is applied.

Then, when you run all storms together, you can explicitly select the custom event for the corresponding sub-catchment/node in question. You can also use the 'ARF Error %' in the Sub-catchment Results window to check how accurate the ARF value is to the sub-catchment in question. A value of 0 or close to it indicates the ARF is representative of that particular sub-catchment. 

You'd then have to modify the boundary conditions control files in a hydraulic model to look-up the hydrographs in the appropriate event file (if it is being run in a hydraulic model that is).

It'd be wise to document any limitations and considerations if using this approach, especially if reaches downstream of the modified sub-catchments are being shown in any form of mapping or used for afflux. Hope this helps.

-DC