Describe the bug
When running ideal.exe for a WRF-Fire simulation, the model crashes due to a NaN detected in the fmc_g field. I was undecided whether this should be an issue or PR, as I have a hack to fix the issue (see below), but am unsure of the best solution.
To Reproduce
Steps to reproduce the behavior:
Use compiler and version gnu/8.3.0 configure; ./compile em_fire
Use out of the box em_fire configuration
Upon executing ideal.exe, the code crashes before successful completion:
FIRE: fmc_g( 374, 1, 95) = NaN
FIRE:fmc_g 1 412 1 412 NaN NaN NaN
FIRE:crash: NaN detected
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 152
crash: NaN detected
-------------------------------------------
Additional context
After tracing through dyn_em/module_initialize_fire.F, I was able to determine that the issue is related to the fmc_g section, specifically:
if(config_flags%fire_fmc_read.eq.0) then
write(6,*)'Setting fuel moisture in wrfinput to constant ', fuelmc_g
do j = jfds,jfde
do i= ifds,ifde
grid%fmc_g(i,j)=fuelmc_g
enddo
enddo
endif
call print_2d_stats(ifds,ifde,jfds,jfde, &
ifms,ifme,jfms,jfme, &
grid%fmc_g, 'fmc_g')
Proposed fix
The root of the issue appears to be related to the reference to domain indices, as executing ideal.exe in parallel will prevent all processors from knowing the domain indices. Simply changing the domain indices to tile indices in the print_2d_stats call resolves the issue. However, I think that the domain indices should be swapped with tile indices also for the preceding do loop. This is not my code, so I just wanted to confirm a proper solution before initiating the PR.
Describe the bug When running ideal.exe for a WRF-Fire simulation, the model crashes due to a NaN detected in the
fmc_g
field. I was undecided whether this should be an issue or PR, as I have a hack to fix the issue (see below), but am unsure of the best solution.To Reproduce Steps to reproduce the behavior:
./compile em_fire
em_fire
configurationideal.exe
, the code crashes before successful completion:Additional context After tracing through
dyn_em/module_initialize_fire.F
, I was able to determine that the issue is related to thefmc_g
section, specifically:Proposed fix The root of the issue appears to be related to the reference to domain indices, as executing
ideal.exe
in parallel will prevent all processors from knowing the domain indices. Simply changing the domain indices to tile indices in theprint_2d_stats
call resolves the issue. However, I think that the domain indices should be swapped with tile indices also for the preceding do loop. This is not my code, so I just wanted to confirm a proper solution before initiating the PR.