FPE failure when sim.stopTime_ = 0.0

[chongchonghe]

Describe the bug
FPE failure when sim.stopTime_ = 0.0.

To Reproduce
Steps to reproduce the behavior:

1. Compile any problem, e.g. RadStreaming, and see it passes.
2. Set sim.maxTimesteps_ = 0 or sim.stopTime_ = 0.0 and observe it failed. The error message is copied below:

SIGILL Invalid, privileged, or ill-formed instruction
See Backtrace.0 file for details

3. Alternatively, comment out this line: sim.evolve();, compile and run. See the same error message.

Additional context

The same test ran without a problem a few month ago. I speculate it started to fail after the FPE commit.

Contents of Backtrace.0:

 0: amrex::BLBackTrace::print_backtrace_info(__sFILE*) (in test_radiation_streaming) + 64

 1: amrex::BLBackTrace::handler(int) (in test_radiation_streaming) + 644

 2: _sigtramp (in libsystem_platform.dylib) + 56

 3: QuokkaSimulation<StreamingProblem>::computeAfterEvolve(amrex::Vector<double, std::__1::allocator<double>>&) (in test_radiation_streaming) + 1256

 4: AMRSimulation<StreamingProblem>::evolve() (in test_radiation_streaming) + 1444

 5: problem_main() (in test_radiation_streaming) + 168

 6: main (in test_radiation_streaming) + 172

 7: start (in dyld) + 2476

Line 1256 of QuokkaSimulation is: amrex::Gpu::streamSynchronizeAll(); // just in case

[BenWibking]

I suppose this is technically a bug, but also: is there a reason to support running a simulation with a stopTime or maxTimesteps of 0?

[BenWibking]

The + some_integer here does not refer to a line number:

 3: QuokkaSimulation<StreamingProblem>::computeAfterEvolve(amrex::Vector<double, std::__1::allocator<double>>&) (in test_radiation_streaming) + 1256

Instead it refers to a byte offset in the binary file. To get line numbers, you have to compile it in debug mode (or at least with -g to get debugging information embedded in the binary).

[BenWibking]

The problem is from this line that divides by stopTime_:

quokka/src/simulation.hpp

Line 859 in 8668640

amrex::Print() << "\nCoarse STEP " << step + 1 << " at t = " << cur_time << " (" << (cur_time / stopTime_) * 100. << "%) starts ..."

[chongchonghe]

OK then, it's an easy fix.

I want to support stopTime_=0, because that's the easiest way to plot the initial condition.