User Forum of Software BASEMENT

Matthias

Advanced_User

Registered: 2014-12-16

Posts: 29

Internal Error in fluxCal()

Dear Basement team

First of all, I wish you a happy new year and I am looking forward to being blown away by your future releases

I am currently setting up a 1D-Sediment Transport model and it is running quite fine for ~1 year of input data.
All of a sudden, the program crashes with the following error:

A fatal error occurred:
internal error in fluxCal().edge->tmpVar_.fluxL_[ gg ] >= 500 because its 753.872 for edge 3 and gg = 0
in file BASEchain\BCInternalFlux.cpp on line 129
Version: 2.4R169, compiled at Sep 10 2014, 11:01:08

We are sorry but BASEMENT must be terminated now.

What might be the source of this error?

Matthias

Advanced_User

Registered: 2014-12-16

Posts: 29

Re: Internal Error in fluxCal()

I have noticed that the error message does not appear when I set the initial_time_step from 100 to 20. When I set the initial_time_step to 1, the error appears again.
Is this error message related to the initial time step?

Christian Volz

User

Registered: 2014-09-04

Posts: 31

Re: Internal Error in fluxCal()

What might be the source of this error?

Dear Matthias

Actually, this error is not really an error, but rather an internal debugging message. It shouldn't be active in the current release2.4 and will be eliminated in the next release. If you need a version without this error, than let us know and specify your operating system (windows, linux(32bit/64bit)) and we will send you such a version.

However, be aware that a sediment flux of > 500 m3/s (!) is in virtually all scenarios implausible large. It usually indicates that something went wrong in the simulation and that's why this debugging message was inserted. Perhaps something is not set up correctly in your simulation? Are you starting from dry conditions? This is often problematic concerning sediment transport and it is recommended, if possible, to start from steady state hydraulic conditions. The choice of the initial_time_step may alter the sediment fluxes at the first time steps, especially if it is started from dry conditions, and hence influences the appearance of this warning.

I hope this answer is of some help for you?

Best regards
Christian

Matthias

Advanced_User

Registered: 2014-12-16

Posts: 29

Re: Internal Error in fluxCal()

Dear Christian
Thank you for your reply and for your Version without debug messaging.
I have realized that the input hydrograph showed for floods a zigzag pattern which might have led to interpolation convergence problems for the calculation steps. I have found a way to clean/simplify the hydrograph and to cut the low flow periods and only simulate the floods. This reduces the simulation time quite significantly and the model is not quitting with a numerical error or a sediment flux error. FYI, we have created the original, uncorrected hydrograph using staging points (Stützpunkte) which can be obtained by BAFU.

However, there are still very large erosion and deposition processes which lead to "Sediment exceeds lower dike level" Errors after a couple of years. I am now trying to find suitable solutions to reduce the bedload transport. Unfortunately, MPM-H does not use "local_slope" so this reduction can not be achieved. I also tried to run MPM-multi but I get a lot of "test" outputs in the console, leading to RTS of only around 1000. Is this a bug in the program? This happens with either the official 2.4 version as also with 2.4 R1808.

Warm regards
Matthias

Edit: I have identified another possible source for the strong depositions along my model. I have defined some hydraulic sources at some cross-sections where this non-explicable deposition occurs. The hydraulic sources are added as "qlateral". Could it be that a lateral inflow either on the left or right side might lead to slower flow velocity in this cross-section and thus promotes deposition? Is there a more stable option to add hydraulic sources to the model, maybe in between two cross-sections?

Last edited by Matthias (2015-01-19 11:02:29)

Christian Volz

User

Registered: 2014-09-04

Posts: 31

Re: Internal Error in fluxCal()

Unfortunately, MPM-H does not use "local_slope" so this reduction can not be achieved.

The "local_slope" modification is applied per default in BASEMENT. This is independent of the selected transport formula and, hence, applies to all transport formula. If you want to run simulations without the "local_slope" modification, you have to explicitly turn it off in the command file. I do not know if this reduces the transport significantly in your scenario. However, it influences the  the critical shear stress of incipient motion and thus can determine whether transport at low flow conditions takes place or not.

I also tried to run MPM-multi but I get a lot of "test" outputs in the console, leading to RTS of only around 1000. Is this a bug in the program? This happens with either the official 2.4 version as also with 2.4 R1808.

Well, this behaviour is not very nice...I suppose these are some sort of  warnings? It would be sufficient to show the warnings only once and then suppress them from there on. We want to change this behaviour in the next release. However, as work-around, you should be able to de-activate these outputs.

- In the BASEMENT GUI, go to the menu "menu->options->Log_level" and reduce the log level (e.g. Log level = 0). This should suppress these outputs in your simulations.

- Starting BASEMENT from console or batch file use the tag "-log 0" to change the log level.

Edit: I have identified another possible source for the strong depositions along my model. I have defined some hydraulic sources at some cross-sections where this non-explicable deposition occurs. The hydraulic sources are added as "qlateral". Could it be that a lateral inflow either on the left or right side might lead to slower flow velocity in this cross-section and thus promotes deposition? Is there a more stable option to add hydraulic sources to the model, maybe in between two cross-sections?

Yes, the lateral sources are inserted without momentum into the model. As a consequence, the flow needs some distance to accelerate again. This may lead to reduced velocites and subsequent depositions. You may want to try to split the source into multiple sources distributed over multiple cross-sections. Perhaps this helps to prevent the large depositions?

best regards!

LydiaSeitz

User

Registered: 2014-09-08

Posts: 18

Re: Internal Error in fluxCal()

Dear Christian,

my model shows the same internal flux error like Matthias. I already simplified the hydrograph and the model starts with steady state hydraulic condition. Do you know any other way to avoid this error or could you please also provide a debugged model for me?

I receive another warning which says that the "Bedload control volume mixtures differ more than 10 percent, is somofbeta = 1.0089, thickness = 0.15". I can only avoid this warning with increasing the bedload control volume to more the 1 m. Do you know what this problem is about?

Best wishes
Lydia

Matthias

Advanced_User

Registered: 2014-12-16

Posts: 29

Re: Internal Error in fluxCal()

Hi everyone
Quick update on this problem:

By changing the grain size distribution of my model I managed that the model runs for 27 years. However I am still having troubles with sediment depositions at lateral inflow points (lateral inflow of water and sediment). Now I tried the suggested approach to split the lateral inflows into multiple cross-sections. I decided to split each lateral inflow to 3 cross-sections which are interpolated between the actual "true" CS and the CS downstream.

This procedure worked fine for some tributaries as long as the distance between the interpolated CS was large enough. The simulation ran just fine.
Then I applied this procedure to more tributaries with a more narrow distance between the interpolated CS (20m). Now the simulation crashes already at 4% with the above mentioned fluxCal() error. This time the Error is huge (8.8994e+019!!). Do you have any idea why this could happen?

PS: I'm using R1692 again because I need a washed in active layer.