Exec/RegTests/FlameSheet

[Alex-jian522]

Hi, everyone, I would like to ask you a question.
I follow the PeleLM Quickstart to run FlameSheet and it turns all right.
But when I only change the max_step from 20 to 200, it will abnormally stop at 115 step.
So what wrong with it and how can I make it run correctly?

[Alex-jian522]

The following is the Backtrace that may be helpful for you to understand my mistakes:
=== If no file names and line numbers are shown below, one can run
addr2line -Cpfie my_exefile my_line_address
to convert my_line_address (e.g., 0x4a6b) into file name and line number.
Or one can use amrex/Tools/Backtrace/parse_bt.py.

=== Please note that the line number reported by addr2line may not be accurate.
One can use
readelf -wl my_exefile | grep my_line_address'
to find out the offset for that line.

0: ./PeleLM2d.gnu.MPI.ex(+0x4463c4) [0x555738b533c4]
amrex::BLBackTrace::print_backtrace_info(_IO_FILE*) at /home/ubuntu/test/amrex//Src/Base/AMReX_BLBackTrace.cpp:179

1: ./PeleLM2d.gnu.MPI.ex(+0x44834f) [0x555738b5534f]
amrex::BLBackTrace::handler(int) at /home/ubuntu/test/amrex//Src/Base/AMReX_BLBackTrace.cpp:85

2: /usr/local/lib/libsundials_cvode.so.6(cvProcessError+0x14d) [0x7ff79323c2eb]
?? ??:0

3: /usr/local/lib/libsundials_cvode.so.6(+0x147fe) [0x7ff7932387fe]
?? ??:0

4: /usr/local/lib/libsundials_cvode.so.6(CVode+0x1258) [0x7ff79323360f]
?? ??:0

5: ./PeleLM2d.gnu.MPI.ex(+0x146733) [0x555738853733]
pele::physics::reactions::ReactorCvode::react(amrex::Box const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, double&, double&)::{lambda(int, int, int)#1}::operator()(int, int, int) const [clone .constprop.93] at /home/ubuntu/test/PelePhysics//Reactions/ReactorCvode.cpp:1397

6: ./PeleLM2d.gnu.MPI.ex(+0x150527) [0x55573885d527]
pele::physics::reactions::ReactorCvode::react(amrex::Box const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, double&, double&) at /home/ubuntu/test/amrex//Src/Base/AMReX_GpuLaunchFunctsC.H:118
(inlined by) pele::physics::reactions::ReactorCvode::react(amrex::Box const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, amrex::Array4 const&, double&, double&) at /home/ubuntu/test/PelePhysics//Reactions/ReactorCvode.cpp:1392

7: ./PeleLM2d.gnu.MPI.ex(+0x21fe47) [0x55573892ce47]
PeleLM::advance_chemistry(amrex::MultiFab&, amrex::MultiFab&, double, amrex::MultiFab const&) at /home/ubuntu/test/PeleLM/Exec/RegTests/FlameSheet/../../../Source/PeleLM.cpp:5764

8: ./PeleLM2d.gnu.MPI.ex(+0x23b629) [0x555738948629]
PeleLM::advance(double, double, int, int) at /home/ubuntu/test/PeleLM/Exec/RegTests/FlameSheet/../../../Source/PeleLM.cpp:5176

9: ./PeleLM2d.gnu.MPI.ex(+0x4d8182) [0x555738be5182]
amrex::Amr::timeStep(int, double, int, int, double) at /home/ubuntu/test/amrex//Src/Amr/AMReX_Amr.cpp:2017

10: ./PeleLM2d.gnu.MPI.ex(+0x4d01fd) [0x555738bdd1fd]
amrex::Amr::coarseTimeStep(double) at /home/ubuntu/test/amrex//Src/Amr/AMReX_Amr.cpp:2127

11: ./PeleLM2d.gnu.MPI.ex(+0x1a5fa) [0x5557387275fa]
main at /home/ubuntu/test/IAMR//Source/main.cpp:128

12: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7ff792057c87]

13: ./PeleLM2d.gnu.MPI.ex(+0x2058a) [0x55573872d58a]
?? ??:0

[drummerdoc]

It might be that PeleLM is not entirely up to date to use the latest versions of the chemistry integrators in PelePhysics. A simple alternative strategy is to try running the same problem setup using PeleLMeX (see https://github.com/AMReX-Combustion/PeleLMeX). PeleLM and PeleLMeX are very similar, but PeleLMeX is under more active development; PeleLM may be lagging behind. A great deal of work is being done currently to improve the robustness and speed of the chemistry integrators in PelePhysics and PeleLM may not be properly setup yet to exploit these modifications.

The primary difference between LM and LMeX is that LM subcycles the time integration, with time step sizes that satisfy a fixed CFL number across levels. This requires a complex synchronization operation whenever two AMR levels reach the same physical time. LMeX steps all levels in the hierarchy at the same dt, determined by the most restrictive constraint across the entire problem. Although this difference has many subtle ramifications, the two codes share much of the infrastructure that supports how users specify initial and boundary conditions and refinement criteria. Thus, many configurations have the same or very similar setups between LM and LMeX.

All this is to say, try LMeX and let us know how it goes.

[Alex-jian522]

Thanks a lot ! I will have a try. If there are meaningful results ,I will come back and reply!

[Alex-jian522]

Thanks again! I have used PeleLMex to run the same case(Flamesheet) and it works correctly .
But I cann't find the ACTIVE CONTROL in PeleLMex . So ACTIVE CONTROL can not be used in PeleLMex ?

[esclapez]

Hi there,

Indeed, the active control code hasn't been ported to PeleLMeX. I've checked the PeleLM side and I think it is up-to-date, but the FlameSheet has a such a low convective velocity that a sensible CFL number (e.g. 0.5) leads to time step size too big for the chemistry integrator (dt>2.e-5). PeleLMeX doesn't have the same issue because without subcycling, the time step is kept in the ~2e-6 range. Keeping the step size in PeleLM in that range by decreasing the CFL should allow the simulation to complete up to 200 steps.
Are you interested in the active control for a particular case ? I can add that to the list of things to implement in PeleLMeX.