Arithmetic exception error

[Y S]

Hi,

This is a different question about the multilayer method, based on the test code large.c discussed in J. Comp. Phys 418.

I am getting very often an error "basilisk/src/hessenberg.h:64:error: Program received signal SIGFPE, Arithmetic exception." and I haven't been able to pinpoint what causes this. It happens when changing the initial amplitude, the wavelength, the equilibrium depth zb[] or the event times.

I first thought it was related to the initial amplitude being too high or the equilibrium depth zb[] being too shallow causing too strong nonlinearities but from more trial and error this seems not to be the case. As a random example I attach here a slightly modified version of large.c (my modifcations are annotated); the version large-modified-working.c runs without error. However, when I request a smaller amount of output profiles, i.e. I change t = 0.1e-4; t += 0.1e-4; t <= 50e-4 to t = 0.1e-4; t += 1e-4; t <= 50e-4 I get the artihmetic exception error. I chose this example because I think nothing in the physics here should change; also the exact same output times are requested, only less. 

(One note: there is no evolution in the film profile in the working code large-modified-working.c; all traces look exactly the same which made me think I had to increase the output time but that too gives arithmetic erros and will not run.)

All the best,

Yasmine

[shine Sun]

Maybe your timestep has changed when you change the write time interval?

[Y S]

Hi,

Yes, this is the case. I change the time step. How would that cause the arithmetic error though? I don 't understand why it should cause any error at all. 

Many thanks for your response, I am still stuck with this problem.

All best,

Y

[Y S]

If this adds any information, often when I try to simulate more traces (i.e. increase the end time) I also get the error  dtnext: Assertion `n < INT_MAX' failed.

[limarea...@gmail.com]

Hello Yasmine,

This error 

• dtnext: Assertion `n < INT_MAX' failed.

occurs when you have a very small physical timestep and the total number of timesteps required to do your calculation (and calculated dynamically by basilisk) is bigger than the maximum integer value that you can store in a integer variable (generally, in C, INT_MAX = 2 147 483 647).

Regards,

Alex

[Y S]

Dear Alex,

Thanks so much, yes, if it is only the n<INT_MAX error, I can resolve it by reducing the # grid points (as increasing the time step is not an option for me). However changing the grid does not resolve the "arithmetic exception" error.

So far I have not found any way at all to resolve the arithmetic exception error. Unlike the n<INT_MAX error, which is clearly related to the amount of events, I don't even uinderstand what causes the arithmetic exception error. Any advice would be much appreciated.

Best,

Yasmine

[Ning Wang]

Hi  Alex,

When I am using parallel computing, parallel computing with more than 4 threads will cause the calculation to fail:

"WARNING: CFL must be <= 0.5 for VOF (cfl - 0.5 = 4.83352)

/home/wn/basilisk/src/grid/events.h:245: Assertion `n < INT_MAX' failed. "

When I use serial computing or 4-thread parallel computing, 

there will be no CFL warnings, nor will there be Assertion `n < INT_MAX' failed errors, the program runs and outputs correct results.

Is this error mode related to parallel computing?

If you have any comment about these questions，

I'd appreciate.

2021年8月22日日曜日 17:58:13 UTC+8 limarea...@gmail.com:

[shine Sun]

Hello,

Maybe your physical condition is too strict for a converged simulation. I think you can try to prescribe the DT parameter to a small value. DT sets the maximum time interval between 2 timesteps.