Open isaaclegred opened 11 months ago
Do you have a similar configuration that works, for comparison?
Actually I'm not sure if anything is actually working, including other time steppers. I think this problem is happening across hydro, and may actually have nothing to do with memory if it turns out that the FPE is somehow causing ridiculous memory usage. It seems every configuration I can generate with both brick and sphere domains fails on develop with the default settings in the input file. it fails with the same error as above, and always after using up a large amount of memory.
The one example I thought was working is on a branch and it's using a different runtime EoS from initial data EoS which is not currently supported in develop, but now it's not clear if that was working either or just failed more slowly. One thing that characterized that run was that it wasn't using atmosphere anywhere. Maybe the default hydro settings from the input file just don't work, but I've been playing around with them and can't get the problem to go away.
Maybe @nilsdeppe could provide an example of an input file that really should work?
I can reproduce an FPE on my desktop at lower resolution. (Initial refinement 3 instead of 4. I don't have enough RAM for 4.)
It doesn't seem to have anything to do with self-start. I get it even doing a single Euler step. The run reached about 13GB of RAM before crashing. I don't have enough experience with this system to know if that's unreasonable or not.
Best guess based on the backtrace is the density is zero somewhere, so hydro::relativistic_specific_enthalpy
FPEs.
The FPE cause appears to be that the analytic solution is zero at the domain boundary, and the DirichletAnalytic
boundary condition can't handle that. (This is a documented limitation of the class.)
I will see how easily I can replace $h$ with $\rho h$ as the primitive. I think this should be fairly trivial. That'll just fix the origin of the FPE. We don't actually use $h$ anywhere
The FPE should be fixed from #5631. Is there still a problem with memory, or does that resolve this issue?
Bug reports:
Expected behavior:
A Tov star should be initializable on a sphere domain with a reasonable range of EoSs and central density
Current behavior:
For many EoS-central density configurations,
InitializeTimeStepperHistory
phase fails, with substantial memory usage. It seems though, that after expanding to multiple nodes (>=6?) the failure is actually due to a floating point error. Traceback example:Environment:
Add as an attachment
$SPECTRE_BUILD_DIR/BuildInfo.txt
or add its contents here. Develop @e621697ef,wheeler_gcc.sh
environment.Feature request:
Component:
Desired feature:
Detailed discussion:
The input file needed to reproduce is just the Ghmhd TOV star test input file (
tests/InputFiles/GrMhd/GhValenciaDivClean/GhMhdTovStar.yaml
) with the domain exchanged with a sphere