Rainfall/Storm Curve

[jbensabat]

Hello
I am trying to understand the structure of the rainfall input and I would be grateful if you could confirm or correct
the grid file provide the total amount of rain falling on a cell (m3/m2).
The question is about the storm curve:

1. does it need to provide the cumulative proportion of the rain at a certain time ?
2. does it need to provide the proportion of the rainfall for the time interval

Also if I have rainfall event which start at time t0 and ends at time t1 while the simulation continues up to time t2 > t1, how do I stop the rain ?
thanks
jac

[tasseff]

Each cell of the corresponding rainfall grid input file defines the cumulative amount of rainfall (in meters) over the duration of the storm curve. The storm curve should state the cumulative proportion of rainfall that has fallen by a given time.

Yes, you can stop the rainfall and simulation at different times. To do this, ensure that the last time specified in your storm curve is t1 and that the end time in the scenario JSON file is t2. If you look at the rainfall/flat example in the nuflood-examples repository, the simulation is twice as long as the rainfall's duration (again, specified by the storm curve).

[jbensabat]

Hello and thanks for your support. I am running a very simple example that U have built on the basis of the one you have provide (V-Catchment) The rainfall storm duration is 90 minutes (27 mm at 18mm/hr). If I use the cumulative rainfall storm the flux at the outlet increases at each time step even during the time when there is no rainfall I looked into the code to find out where you apply rainfall if (rainfall_grid != nullptr) { if (R.storm_curve_proportion()*rainfall_grid[center] > (prec_t)0) { prec_t rainfall_rate = rainfall_grid[center] * R.storm_curve_proportion() / T.step(); S0 += rainfall_rate; } } Here you seem to be applying the rain proportion from the file (a cumulative one). So I have two concerns: 1. It seems that using the cumulative curve leads to an ever increasing rainfall 2. The code does not seem to stop the source of the rainfall after the rain stops Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Thursday, August 6, 2020 5:27 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Each cell of the corresponding rainfall grid input file defines the cumulative amount of rainfall (in meters) over the duration of the storm curve. The storm curve should state the cumulative proportion of rainfall that has fallen by a given time. Yes, you can stop the rainfall and simulation at different times. To do this, ensure that the last time specified in your storm curve is t1 and that the end time in the scenario JSON file is t2. If you look at the rainfall/flat example in the nuflood-examples repository, the simulation is twice as long as the rainfall's duration (again, specified by the storm curve). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2GGODX5QQNQRVJJHBLR7K4UBANCNFSM4PWQ4LOQ>.

[jbensabat]

Hi Sorry for my previous mail It indeed shuts of the rain properly. Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Thursday, August 6, 2020 5:27 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Each cell of the corresponding rainfall grid input file defines the cumulative amount of rainfall (in meters) over the duration of the storm curve. The storm curve should state the cumulative proportion of rainfall that has fallen by a given time. Yes, you can stop the rainfall and simulation at different times. To do this, ensure that the last time specified in your storm curve is t1 and that the end time in the scenario JSON file is t2. If you look at the rainfall/flat example in the nuflood-examples repository, the simulation is twice as long as the rainfall's duration (again, specified by the storm curve). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2GGODX5QQNQRVJJHBLR7K4UBANCNFSM4PWQ4LOQ>.

[tasseff]

Yes, for reference, here is the function that updates storm_curve_proportion:

nuflood/source/common/isources.cpp

Lines 55 to 64 in f169df4

	void ISources::Update(const ITime& T) {
	if (!storm_curve_.IsEmpty()) {
	if (T.current() + T.step() <= storm_curve_.end_time()) {
	storm_curve_proportion_ = storm_curve_.interpolated_value(T.current() + T.step()) -
	storm_curve_.interpolated_value(T.current());
	} else {
	storm_curve_proportion_ = (prec_t)(0);
	}
	}
	}

[jbensabat]

Hi Thanks a lot I managed to run the flat example and got an expected behavior. Sorry to bother you. I know you are busy but I would ready like if you could address these questions: * Are the discharges in units of m3/m2/sec ? so I want to have the discharge value for a channel I need to multiply the value by the cell size ? * Then I ran the V-Catchment example, which has an analytical solution * I ran it with “open” boundary conditions on the borders I got non-physical results (fluxes are very high and increase steadily with time even after the rain ceases; * Then I ran it by setting no boundary conditions I got results that look more similar to the analytical solution but with a non-physical solution for the flux at early times (see file TSOutlet01.xlsx) * Then I changed the value of the parameter desingularizationConstant from 0.1 in the example you supplied to 0.01 , then I got a far better solution (see file TSOUTLET03.xlsx), although the peak is somewhat 10% less then the one from the analytical solution. So my question is how the “open” BC conditions works ? Is there a way to a priori determine the value of the parameter desingularizationConstant ? Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Friday, August 7, 2020 5:57 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Yes, for reference, here is the function that updates storm_curve_proportion: https://github.com/lanl/nuflood/blob/f169df41888ec9e92f65a8c48f870ef16c42f761/source/common/isources.cpp#L55-L64 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2AFOURUZPJH3Q5MWCTR7QI4TANCNFSM4PWQ4LOQ>.

[tasseff]

Discharges are in meters squared per second. I'm not sure what boundary conditions you should be using for your benchmark problem. Open boundary conditions assume values of discharges and water surface elevation equivalent to the cell adjacent to the boundary. Regarding the desingularization constant, you are getting deep into technical details at this point. You can read more about the desingularization approach used by the original authors of the discretized model here. Very briefly, for rainfall scenarios, a smaller value of desingularization will typically result in more accurate computation of discharges at the expense of having smaller time steps. This is the most fragile aspect of the model I've encountered while running rainfall scenarios.

[jbensabat]

Thanks for your reply I will look into this aspect of the paper. In principle the BC in the V-catchment should be open but I get un-physical results. I shall play with the value of the desingularization constant. Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Sunday, August 9, 2020 10:25 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Discharges are in cubic meters per second. I'm not sure what boundary conditions you should be using for your benchmark problem. Open boundary conditions assume values of discharges and water surface elevation equivalent to the cell adjacent to the boundary. Regarding the desingularization constant, you are getting deep into technical details at this point. You can read more about the desingularization approach used by the original authors of the discretized model here<https://projecteuclid.org/download/pdf_1/euclid.cms/1175797625>. Very briefly, for rainfall scenarios, a smaller value of desingularization will result in more accurate computation of discharges at the expense of having shorter time steps. This is the most fragile aspect of the model I've encountered while running rainfall scenarios. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2CL3ENJ3WRHUU5SC6DR73ZYFANCNFSM4PWQ4LOQ>.

[jbensabat]

Hi One more question that bothers me. The vertical discharge is defined in the code as hv (depth times velocity in the y-direction). Therefore the dimensions are L^2/T. In order to get the discharge should we multiply by the size of the cell, or is it done somewhere in the code before the printing ? Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Sunday, August 9, 2020 10:25 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Discharges are in cubic meters per second. I'm not sure what boundary conditions you should be using for your benchmark problem. Open boundary conditions assume values of discharges and water surface elevation equivalent to the cell adjacent to the boundary. Regarding the desingularization constant, you are getting deep into technical details at this point. You can read more about the desingularization approach used by the original authors of the discretized model here<https://projecteuclid.org/download/pdf_1/euclid.cms/1175797625>. Very briefly, for rainfall scenarios, a smaller value of desingularization will result in more accurate computation of discharges at the expense of having shorter time steps. This is the most fragile aspect of the model I've encountered while running rainfall scenarios. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2CL3ENJ3WRHUU5SC6DR73ZYFANCNFSM4PWQ4LOQ>.

[tasseff]

No, this isn't done in the code. You need to multiply by the size of the cell while post-processing the results if you want something in units of cubic meters per second.

[jbensabat]

Hi Thanks. This is what I guessed from visiting the code but I wanted to make sure. Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Monday, August 10, 2020 6:56 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) No, this isn't done in the code. You need to multiply by the size of the cell while post-processing the results. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2GODYVX4MY7Z27MLALSAAKCNANCNFSM4PWQ4LOQ>.

[jbensabat]

Hello I have now a couple of questions with regard to the grid. Since its Finite-Difference grid, I understand that the cells on the border (North, East etc) are used for setting the BCs. Do you use only the cells on the border or also one layer inside. To clarify my question How many cells from the border should I start looking for the results of the simulation. Also if I have an irregular domain (using the NODATA value in the grid files) how to you address the BC (first cell from the border with data ?) Thanks Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Monday, August 10, 2020 6:56 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) No, this isn't done in the code. You need to multiply by the size of the cell while post-processing the results. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2GODYVX4MY7Z27MLALSAAKCNANCNFSM4PWQ4LOQ>.

[tasseff]

You can see how boundary conditions are calculated here. In most cases, two border cells are used to define the boundary condition. These boundary cells are added to the original grid prior to computation. Note that the discretization also shifts the original grid cells by one half cell to define the cell centers, which are returned in the output. You'll see here that the outputted grids remove these boundary cells:

nuflood/source/common/ioutput.cpp

Lines 61 to 71 in 32c61f5

	void IOutput::WriteGridIfInList(const prec_t current_time, const Grid<prec_t>& grid) const {
	if (grid_list_.Contains(grid.name())) {
	grid.WriteWithoutBoundaries(folder_, current_time);
	}
	}
	void IOutput::WriteGridIfInList(const Grid<prec_t>& grid) const {
	if (grid_list_.Contains(grid.name())) {
	grid.WriteWithoutBoundaries(folder_);
	}
	}

NODATA cell values are not handled elegantly within the domain. I believe those values (e.g., in an elevation file) will be replaced with a value of zero. I would advise not having any NODATA values in your input rasters but instead replacing those values with something more reasonable.

[jbensabat]

Hi Thanks a lot. Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Thursday, August 13, 2020 12:01 AM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) You can see how boundary conditions are calculated here<https://github.com/lanl/nuflood/blob/master/source/models/kurganov_petrova/update_boundaries.cpp>. In most cases, two border cells are used to define the boundary condition. These boundary cells are added to the original grid prior to computation. Note that the discretization also shifts the original grid cells by one half cell to define the cell centers, which are returned in the output. You'll see here that the outputted grids remove these boundary cells: https://github.com/lanl/nuflood/blob/32c61f51fe5e416ce357be38852694df6613c302/source/common/ioutput.cpp#L61-L71 NODATA cell values are not handled elegantly within the domain. I believe those values (e.g., in an elevation file) will be replaced with a value of zero. I would advise not having any NODATA values in your input rasters but instead replacing those values with something more reasonable. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2FVAF6A64CFJHN5RKLSAL7JJANCNFSM4PWQ4LOQ>.

[jbensabat]

Hi I am now looking at the mass balance and I observe that the mass balance (volume conservation) error increases with time in the simulation I am conducting. It seems that you compared the volume of water in the model domain with the volume of water added to it, without taking into consideration the volume of water leaving the model domain. In the example I am testing the outflow discharge is substantial so the volume in the system (the calculated volume) decreases with time. Am I correct in my conclusion ? Thanks Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Thursday, August 13, 2020 12:01 AM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) You can see how boundary conditions are calculated here<https://github.com/lanl/nuflood/blob/master/source/models/kurganov_petrova/update_boundaries.cpp>. In most cases, two border cells are used to define the boundary condition. These boundary cells are added to the original grid prior to computation. Note that the discretization also shifts the original grid cells by one half cell to define the cell centers, which are returned in the output. You'll see here that the outputted grids remove these boundary cells: https://github.com/lanl/nuflood/blob/32c61f51fe5e416ce357be38852694df6613c302/source/common/ioutput.cpp#L61-L71 NODATA cell values are not handled elegantly within the domain. I believe those values (e.g., in an elevation file) will be replaced with a value of zero. I would advise not having any NODATA values in your input rasters but instead replacing those values with something more reasonable. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2FVAF6A64CFJHN5RKLSAL7JJANCNFSM4PWQ4LOQ>.

[tasseff]

Correct, I don't compute mass that exits the boundaries.

[jbensabat]

Hi Thanks a lot for the info Now , truly the last question on this example. It is a about the boundary conditions. What I am simulating is a V-catchment (See picture). I applied a rainfall of 10.8 mm/for 1.5 hours and a simulations of 3 hours I did the following attempts 1. No boundary conditions (North-South-East -West) 2. Open boundary conditions (North-South-East-West) 3. Open boundary conditions (South) 4. Critical depth (south) 2 and 4 gave non-physical results (discharge at the channel outlet increasing even when rainfall ceases) 1 and 4 gave similar results. The true discharge (the one corresponding to the analytical solution) was obtained at the third line of cells from the southern border (4.86 m^3/sec for the channel) . The second line of cells provided a higher value (4.95 m^3/sec) and the border line provided a much lower value (3.99 m^3/sec). Do you have an explanation for this ? Best Jac When I tried open boundary conditions, I got non-physical results, as if water was getting in from the borders Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Thursday, August 13, 2020 5:17 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Author <author@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Correct, I don't compute mass that exits the boundaries. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2HKPLBBXCF6426UAPTSAPYW5ANCNFSM4PWQ4LOQ>.

[tasseff]

@jbensabat, I cannot see any attached images. Could you please login to GitHub and add the attachments as links?

[jbensabat]

Hello I uploaded the pdf file with the illustration of the catchment I can provide the data files too if there is a way to upload them Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Monday, August 17, 2020 8:15 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Mention <mention@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) @jbensabat<https://github.com/jbensabat>, I cannot see any attached images. Could you please login to GitHub and add the attachments as links? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2BY3QAAPOP4SMO56VDSBFQQNANCNFSM4PWQ4LOQ>.

[tasseff]

I cannot provide much advice without knowing the inputs you are using or how close the simulation results are to the observed discharge. The only thing I would recommend is to try using wall boundary conditions for the east, west, and north boundaries, and critical depth boundary conditions for the south.

[jbensabat]

Hi Thanks a lot again I shall try the wall conditions (zero flux I guess) I can provide the data files and the analytical solution if there’s an interest in it BR Jac

…

Sent from my iPhone On 18 Aug 2020, at 18:20, Byron Tasseff <notifications@github.com> wrote:  I cannot provide much advice without knowing the inputs you are using or how close the simulation results are to the observed discharge. The only thing I would recommend is to try using wall boundary conditions for the east, west, and north boundaries, and critical depth boundary conditions for the south. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2DKYALNIKBURVWYOR3SBKL2XANCNFSM4PWQ4LOQ>.

[tasseff]

Another thought: have you tried further reducing the desingularization constant? I'm unsure when numerical issues arise, but you may want to try decreasing sequentially by factors of ten and seeing how the results change (e.g., 1.0e-2, 1.0e-3, 1.0e-4).

[jbensabat]

Hi I tested that below a value of 0.01 the solutions are not substantially different. Best Jac Jacob Bensabat, Ph.D. EWRE Ltd. 3, Shaar Halevanon Street Haifa – 3445402 Israel. Tel: +972-4-8383919 Mobile: +972-544417511 [EWRELogoNew] From: Byron Tasseff <notifications@github.com> Sent: Tuesday, August 18, 2020 6:48 PM To: lanl/nuflood <nuflood@noreply.github.com> Cc: Jbensabat <jbensabat@ewre.com>; Mention <mention@noreply.github.com> Subject: Re: [lanl/nuflood] Rainfall/Storm Curve (#5) Another thought: have you tried further reducing the desingularization constant? I'm unsure when numerical issues arise, but you may want to try decreasing sequentially by factors of ten and seeing how the results change (e.g., 1.0e-2, 1.0e-3, 1.0e-4). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZNJ2GAYR34IDYDPRREXSLSBKPEHANCNFSM4PWQ4LOQ>.