Closed drjfloyd closed 4 months ago
I'll look at this over the weekend. Tied up this week.
I pushed some updates to the wall routines and the case works for me. Could you try again, and if it fails, give me the OS and when it fails.
Linux and windows give the same line running in debug.
Starting FDS ...
MPI Process 0 started on pele-01
Reading FDS input file ...
Fire Dynamics Simulator
Current Date : April 12, 2024 15:59:36 Revision : FDS-6.9.0-128-gf8ab9f4-master Revision Date : Fri Apr 12 15:33:36 2024 -0400 Compiler : Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.11.1 Build 20231117_000000 Compilation Date : Apr 12, 2024 15:57:31
Number of MPI Processes: 1
MPI version: 3.1 MPI library version: Intel(R) MPI Library 2021.11 for Linux* OS
Job TITLE : Test BURN_AWAY feature Job ID string : box_burn_away11
forrtl: severe (408): fort: (2): Subscript #1 of the array WALL has value 797 which is greater than the upper bound of 600
Image PC Routine Line Source fds_impi_intel_li 0000000003C1D4B2 dump_mp_solid_pha 8436 dump.f90 fds_impi_intel_li 0000000003CF6481 dump_mp_dump_prof 9939 dump.f90 fds_impi_intel_li 0000000003872926 dump_mp_dump_mesh 149 dump.f90 fds_impi_intel_li 00000000041D1F2D MAIN__ 956 main.f90 fds_impi_intel_li 0000000000407B1D Unknown Unknown Unknown libc.so.6 000014E17E63FEB0 Unknown Unknown Unknown libc.so.6 000014E17E63FF60 __libc_start_main Unknown Unknown fds_impi_intel_li 0000000000407A35 Unknown Unknown Unknown srun: error: pele-01: task 0: Exited with exit code 152
This was a problem of scoping. Many of the subroutines in dump.f90
have a call to POINT_TO_MESH
which assigns pointers to major mesh-dependent variables. Since we USE
the MESH_POINTERS
at the top of the module, any call to POINT_TO_MESH
is good for all internal subroutines and functions. But in this case, there was no call to POINT_TO_MESH
because DUMP_PROF
does not include it and no other subroutines in the chain of calls called it. To fix, we now make the call to POINT_TO_MESH
on entry into the module, reducing the number of calls we need to make to it. Previously, we were calling it way too much, which is a waste.
Does this case now work for you?
Yes.
box_burn_away11 runs with the four cores used in the verification test, but with 1 core it dies.