About an error message P=00000:Aborting. Aborted (core dumped)

[王刚]

Hello professors,

    I'd like to ask what does this error message actually means. It comes when I add more refinement levels to the default flow pass a rigid cylinder example. Thank you!

    The whole message is shown as 

    P=00000:Aborting.

P=00000:

[BHE-PC-T7910-3:32607] *** Process received signal ***

[BHE-PC-T7910-3:32607] Signal: Aborted (6)

[BHE-PC-T7910-3:32607] Signal code:  (-6)

[BHE-PC-T7910-3:32607] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fac18f5d980]

[BHE-PC-T7910-3:32607] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fac18945fb7]

[BHE-PC-T7910-3:32607] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fac18947921]

[BHE-PC-T7910-3:32607] [ 3] ./main2d(+0x6ff63d)[0x562d5955d63d]

[BHE-PC-T7910-3:32607] [ 4] ./main2d(+0x6e59dd)[0x562d595439dd]

[BHE-PC-T7910-3:32607] [ 5] ./main2d(+0x27ca6f)[0x562d590daa6f]

[BHE-PC-T7910-3:32607] [ 6] ./main2d(+0x2789f2)[0x562d590d69f2]

[BHE-PC-T7910-3:32607] [ 7] ./main2d(+0x61cef5)[0x562d5947aef5]

[BHE-PC-T7910-3:32607] [ 8] ./main2d(+0x76129)[0x562d58ed4129]

[BHE-PC-T7910-3:32607] [ 9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fac18928bf7]

[BHE-PC-T7910-3:32607] [10] ./main2d(+0x683fa)[0x562d58ec63fa]

[BHE-PC-T7910-3:32607] *** End of error message ***

Aborted (core dumped)

Yours sincerely,

Haotian Hang

[Boyce Griffith]

On Feb 8, 2021, at 1:38 PM, 王刚 <hangh...@gmail.com> wrote:

Hello professors,

    I'd like to ask what does this error message actually means. It comes when I add more refinement levels to the default flow pass a rigid cylinder example. Thank you!

Which example is this for, and can you send the modified input file?

    The whole message is shown as 

    P=00000:Aborting.

P=00000:

[BHE-PC-T7910-3:32607] *** Process received signal ***

[BHE-PC-T7910-3:32607] Signal: Aborted (6)

[BHE-PC-T7910-3:32607] Signal code:  (-6)

[BHE-PC-T7910-3:32607] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fac18f5d980]

[BHE-PC-T7910-3:32607] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fac18945fb7]

[BHE-PC-T7910-3:32607] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fac18947921]

[BHE-PC-T7910-3:32607] [ 3] ./main2d(+0x6ff63d)[0x562d5955d63d]

[BHE-PC-T7910-3:32607] [ 4] ./main2d(+0x6e59dd)[0x562d595439dd]

[BHE-PC-T7910-3:32607] [ 5] ./main2d(+0x27ca6f)[0x562d590daa6f]

[BHE-PC-T7910-3:32607] [ 6] ./main2d(+0x2789f2)[0x562d590d69f2]

[BHE-PC-T7910-3:32607] [ 7] ./main2d(+0x61cef5)[0x562d5947aef5]

[BHE-PC-T7910-3:32607] [ 8] ./main2d(+0x76129)[0x562d58ed4129]

[BHE-PC-T7910-3:32607] [ 9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fac18928bf7]

[BHE-PC-T7910-3:32607] [10] ./main2d(+0x683fa)[0x562d58ec63fa]

[BHE-PC-T7910-3:32607] *** End of error message ***

Aborted (core dumped)

Yours sincerely,

Haotian Hang

--
You received this message because you are subscribed to the Google Groups "IBAMR Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibamr-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/a4ba09bb-705c-4d0b-853d-22b646d76684n%40googlegroups.com.

[Haotian Hang]

Hello professor Boyce,

     It is the flow_past_cylinder in ConstaintIB. I actually only changed the parameter MAX_LEVELS from 2 to 4. The zip file is attached in the message. It can run for several time steps, and then it would crash like this. Thank you very much for your help.

Yours sincerely

Haotian Hang

[Haotian Hang]

Hello professor Boyce,

       When look at this problem deeper, I found that before this phenomenon happen, there will be some refinement mesh at the inlet of the computational domain, and I guess this caused the problem. Could you please tell me why this phenomenon happens, and how to use finer grid in this case? 

       Also, I've tried to run the flow pass cylinder example. However, my result is not exactly the same as you reported in Bhalla et al. 2013. My average drag coefficient is 1.49116, and in the paper, it is 1.3906. And about the Flourier transformation of Fy(t) is attached. Could you kindly please tell me what are the exact parameter you are using in that great paper Bhalla et al. 2013.

       Thank you so much for your help!

Yours sincerely,

Haotian Hang

[Boyce Griffith]

On Feb 20, 2021, at 12:19 AM, Haotian Hang <haot...@usc.edu> wrote:

Hello professor Boyce,

       When look at this problem deeper, I found that before this phenomenon happen, there will be some refinement mesh at the inlet of the computational domain, and I guess this caused the problem. However, if I just simply change Reynolds number to 100, when using  MAX_LEVELS equals to 4. It will not cause any problem. Could you please tell me why this phenomenon happens, and how to use finer grid at high Reynolds number? 

Sorry for the slow reply. Are you able to run this example in a debugger?

       Also, I've tried to run the flow pass cylinder example. However, my result is not exactly the same as you reported in Bhalla et al. 2013. My average drag coefficient is 1.49116, and in the paper, it is 1.3906. And about the Flourier transformation of Fy(t) is attached. Could you kindly please tell me what are the exact parameter you are using in that great paper Bhalla et al. 2013.

These coefficients can be very sensitive to details like the size of the computational domain. Is the problem setup identical to that paper? If not, that is the first thing to look at.

— Boyce

       Thank you so much for your help!

Yours sincerely,

Haotian Hang

On Monday, February 8, 2021 at 12:10:08 PM UTC-8 Haotian Hang wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/93d54d6f-a528-42c0-bb97-1bee289d1570n%40googlegroups.com.
<Re=200_Fy_fourier_figure.eps>

[Haotian Hang]

Hello professor Boyce Griffith,

     Thank you for your reply. Actually I am running in debug mode. For the comparison with your previous paper, since I'm using the example you provided, most parameters are the same. The only differences that in your paper, the MAX_LEVELS is 3, but in the example, it is 2. When I change it from 2 to 3, I met the problem I mentioned before. Thus, I'd like to ask what else parameters do I need to change? Thank you!

Yours sincerely,

Haotian 

[Amneet Bhalla]

With more levels, you might have to change the vorticity tagging criterion to avoid generating too many patches (or patches of complex shapes). Suggest turning off vorticity tagging first, and then select a reasonable value based on visualizing the vorticity field.

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/32e7f3f4-def6-40ca-bc4c-d7f816420716n%40googlegroups.com.

--

--Amneet 

[Boyce Griffith]

On Mar 20, 2021, at 12:01 AM, Haotian Hang <haot...@usc.edu> wrote:

Hello professor Boyce Griffith,

     Thank you for your reply. Actually I am running in debug mode. For the comparison with your previous paper, since I'm using the example you provided, most parameters are the same. The only differences that in your paper, the MAX_LEVELS is 3, but in the example, it is 2. When I change it from 2 to 3, I met the problem I mentioned before. Thus, I'd like to ask what else parameters do I need to change? Thank you!

Yours sincerely,

Haotian 

I just ran the example, changing MAX_LEVELS to 3, and it seems to run at least for the first 20 steps. When do you encounter the error?

If I change MAX_LEVELS to 4, then I get this error message after time step # 2:

P=00000:Program abort called in file ``/Users/boyceg/code/IBAMR/ibtk/lib/../src/utilities/HierarchyIntegrator.cpp'' at line 234

P=00000:ERROR MESSAGE:

P=00000:IBHierarchyIntegrator::advanceHierarchy():

P=00000:  at time = 0.004: time step size dt = 0.002

P=00000:  minimum time step size = 0

P=00000:  maximum time step size = 0.00113493

P=00000:

This kind of error means that the time step size probably needs to be reduced to satisfy a CFL-type condition, but the time stepper is set up to use a fixed-sized time step.

Amneet, is there any difficulty in just using a floating time step size (determined by CFL + growth conditions) with ConstraintIB?

By the way, Haotian, this seems to be different from the error that you are getting…?

— Boyce

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/32e7f3f4-def6-40ca-bc4c-d7f816420716n%40googlegroups.com.

[Haotian Hang]

Hello professor Boyce Griffith and Amneet, 

    Thank you so much for your help. I tried to run it for another time. It is true that when using  MAX_LEVELS=3, it can run longer than  MAX_LEVELS=4. The code can run for about 300 timestep for MAX_LEVELS=3, and stoped at the same time as you for MAX_LEVELS=4. The error information for these two are the same, but not exactly the same as you, maybe because I'm using an older version.  The error message is shown as follows.

     Moreover, although the calculation finally shutdown because of timestep problem, I think the problem is that it is putting some refinement mesh at the inlet as shown in the attached figure.

MAX_LEVELS=3:

At beginning of timestep # 288

Simulation time is 0.576

P=00000:Program abort called in file ``../../IBAMR/lib/../src/IB/IBHierarchyIntegrator.cpp'' at line 180

P=00000:ERROR MESSAGE: 

P=00000:IBHierarchyIntegrator::preprocessIntegrateHierarchy():  Time step size change encountered.

P=00000:Aborting.

P=00000:

[BHE-PC-T7910-3:12494] *** Process received signal ***

[BHE-PC-T7910-3:12494] Signal: Aborted (6)

[BHE-PC-T7910-3:12494] Signal code:  (-6)

[BHE-PC-T7910-3:12494] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f0ec1c82980]

[BHE-PC-T7910-3:12494] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f0ec166afb7]

[BHE-PC-T7910-3:12494] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f0ec166c921]

[BHE-PC-T7910-3:12494] [ 3] ./main2d(+0x6defe2)[0x563df954bfe2]

[BHE-PC-T7910-3:12494] [ 4] ./main2d(+0x1e3102)[0x563df9050102]

[BHE-PC-T7910-3:12494] [ 5] ./main2d(+0x1ded5b)[0x563df904bd5b]

[BHE-PC-T7910-3:12494] [ 6] ./main2d(+0x5a386d)[0x563df941086d]

[BHE-PC-T7910-3:12494] [ 7] ./main2d(+0x69872)[0x563df8ed6872]

[BHE-PC-T7910-3:12494] [ 8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f0ec164dbf7]

[BHE-PC-T7910-3:12494] [ 9] ./main2d(+0x7f39a)[0x563df8eec39a]

[BHE-PC-T7910-3:12494] *** End of error message ***

Aborted (core dumped)

[Boyce Griffith]

On Mar 22, 2021, at 2:08 PM, Haotian Hang <haot...@usc.edu> wrote:

Hello professor Boyce Griffith and Amneet, 

    Thank you so much for your help. I tried to run it for another time. It is true that when using  MAX_LEVELS=3, it can run longer than  MAX_LEVELS=4. The code can run for about 300 timestep for MAX_LEVELS=3, and stoped at the same time as you for MAX_LEVELS=4. The error information for these two are the same, but not exactly the same as you, maybe because I'm using an older version.  The error message is shown as follows.

     Moreover, although the calculation finally shutdown because of timestep problem, I think the problem is that it is putting some refinement mesh at the inlet as shown in the attached figure.

There shouldn’t be any difficulty in having refinement at the inlet. We use these kinds of set ups all the time.

The problem is that reported here is that the time step size had to change to accommodate a requirement on the CFL condition, but the input file is set up to emit an error if the time step size changes. (Time step size changes can be an indication that an IB model with an elastic structure is going unstable.) You should be able to avoid the error by either reducing the maximum time step size. Also, if ConstraintIB allows for variable time step sizes, then you should be able to use the CFL condition to determine the time step size in higher-speed flow conditions.

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/4c278688-093b-4c9e-93f9-2e328e77fa1an%40googlegroups.com.
<Screen Shot 2021-03-22 at 11.04.41 AM.png>

[Amneet Bhalla]

Also, if ConstraintIB allows for variable time step sizes, then you should be able to use the CFL condition to determine the time step size in higher-speed flow conditions.

Yep, this is allowed, and you can suppress this error via the input file directly. 

On Mon, Mar 22, 2021 at 11:14 AM Boyce Griffith <boy...@gmail.com> wrote:

On Mar 22, 2021, at 2:08 PM, Haotian Hang <haot...@usc.edu> wrote:

Hello professor Boyce Griffith and Amneet, 

    Thank you so much for your help. I tried to run it for another time. It is true that when using  MAX_LEVELS=3, it can run longer than  MAX_LEVELS=4. The code can run for about 300 timestep for MAX_LEVELS=3, and stoped at the same time as you for MAX_LEVELS=4. The error information for these two are the same, but not exactly the same as you, maybe because I'm using an older version.  The error message is shown as follows.

     Moreover, although the calculation finally shutdown because of timestep problem, I think the problem is that it is putting some refinement mesh at the inlet as shown in the attached figure.

There shouldn’t be any difficulty in having refinement at the inlet. We use these kinds of set ups all the time.

The problem is that reported here is that the time step size had to change to accommodate a requirement on the CFL condition, but the input file is set up to emit an error if the time step size changes. (Time step size changes can be an indication that an IB model with an elastic structure is going unstable.) You should be able to avoid the error by either reducing the maximum time step size.

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/7FCF1038-CBBC-4333-9DF5-5F7F84387929%40gmail.com.

--

--Amneet 

[Boyce Griffith]

On Mar 22, 2021, at 2:33 PM, Amneet Bhalla <mail2...@gmail.com> wrote:

Also, if ConstraintIB allows for variable time step sizes, then you should be able to use the CFL condition to determine the time step size in higher-speed flow conditions.

Yep, this is allowed, and you can suppress this error via the input file directly. 

Good. In that case, what you would do in the input file is set:

IBHierarchyIntegrator {

   // … other settings …

   dt_max = DT_MAX

   error_on_dt_change = FALSE

   // … other settings …

}

Amneet, do you know if this is what was done in the paper that Haotian is trying to replicate, or did it report results using a fixed time step size? If it reported fixed time step size results, then probably the fix is simply to rescale the time step size appropriately with grid refinement.

— Boyce

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/CAMETWJ1Y%2BbaRFikpV7r2J0cdF2CuP39C-0KTcOv_nexeb__uHw%40mail.gmail.com.

[Haotian Hang]

Hello professor Boyce Griffith and Amneet, 

    Thank you so much for your help. I'll try these things to solve these problems. Thank you again for your help.

Yours sincerely

Haotian

[Amneet Bhalla]

On Mon, Mar 22, 2021 at 12:16 PM Boyce Griffith <boy...@gmail.com> wrote:

On Mar 22, 2021, at 2:33 PM, Amneet Bhalla <mail2...@gmail.com> wrote:

Also, if ConstraintIB allows for variable time step sizes, then you should be able to use the CFL condition to determine the time step size in higher-speed flow conditions.

Yep, this is allowed, and you can suppress this error via the input file directly. 

Good. In that case, what you would do in the input file is set:

IBHierarchyIntegrator {

   // … other settings …

   dt_max = DT_MAX

   error_on_dt_change = FALSE

   // … other settings …

}

Amneet, do you know if this is what was done in the paper that Haotian is trying to replicate, or did it report results using a fixed time step size?

That was done around 2012. I don't recall what I read yesterday these days :-(

 

If it reported fixed time step size results, then probably the fix is simply to rescale the time step size appropriately with grid refinement.

Yeah it should be easy to change DT_MAX by observing the actual CFL number in the .log file. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/60EE329F-4ADE-4FF7-A341-4933BE770701%40gmail.com.

--

--Amneet 

[Haotian Hang]

Hello professor Boyce Griffith and Amneet, 

    Sorry for bothering you again. I've tried to add this several lines in the input file and this is the input file I'm using. However, it seems that in this situation, the code didn't put refinement grids according to vorticity tagging although I set "using_vorticity_tagging" to be True, and the vorticity in the wake have increase the threshold. I tried several times, but the results are the same, as shown in the figure given below. I'd like to ask where the problem is and how can I fix it. Thank you so much for your help!

Yours sincerely,

Haotian

[Haotian Hang]

In the zip is the input file and screenshot I'd like to attach before.