Turning off IS_TROPICAL for grasses causes a floating-point exception error during Canopy structure calculations

[mccabete]

If I run grasses with IS_TROPICAL = 1, then they are able to produce output. If IS_TROPICAL = 0, it will get an error that traces back to here: https://github.com/EDmodel/ED2/blob/fa80dab6a258a69eede77b9e5c46d94173ff6ba1/ED/src/dynamics/canopy_struct_dynamics.f90#L2031

Because it is an issue with logging a height parameter, I suspect that differences in tropical allometries vs non tropical is the culprit. This is under IALLOM = 3 (the beta allometry scheme).

=== Time integration starts (model) ===
 - Simulating:   06/01/2013 00:00:00 UTC
 - Simulating:   06/02/2013 00:00:00 UTC

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x2AC02EADA6D7
#1  0x2AC02EADAD1E
#2  0x2AC03123C3FF
#3  0x2AC02EE09334
#4  0x10DEB58 in __canopy_struct_dynamics_MOD_reduced_wind8 at canopy_struct_dynamics.f90:2029
#5  0x10EFE8D in __canopy_struct_dynamics_MOD_canopy_turbulence8 at canopy_struct_dynamics.f90:1245 (discriminator 2)
#6  0xD7784C in __rk4_copy_patch_MOD_copy_rk4patch_init at rk4_copy_patch.f90:495 (discriminator 4)
#7  0xDA50B2 in __rk4_driver_MOD_rk4_timestep._omp_fn.0 at rk4_driver.F90:279 (discriminator 1)
#8  0xDA374F in __rk4_driver_MOD_rk4_timestep at rk4_driver.F90:167 (discriminator 1)
#9  0x5420CC in ed_model_ at ed_model.F90:315 (discriminator 4)
#10  0x42D7DD in ed_driver_ at ed_driver.F90:373
#11  0x42953D in MAIN__ at edmain.F90:290
/var/spool/sge/scc-tb1/job_scripts/9561976: line 55: 26372 Floating point exception"/projectnb/dietzelab/mccabete/ED/Ed2/ED/build/ed_2.2-dbg-serdp_2020_version-1cf3c34" ""
ERROR IN MODEL RUN
Logfile is located at '/projectnb/dietzelab/pecan.data/output//tmccabe/1000017717/out/1003063618/logfile.txt'

[mpaiao]

@mccabete Does it run if you set IALLOM=0? In principle IALLOM=3 should change only the functional form of allometric equations for tropical PFTs only, and not affect temperate PFTs. It sound like a bug in any case, but it would help to figure out if this is a general bug or something specific to IALLOM=3 changing more equations than what it should.

[mccabete]

Yeah, Looking back at my run logs I also get this if IALLOM is 0

[mccabete]

sorry forgot I did that test run

[mpaiao]

The routine causing the crash is reduced_wind8, and from the message you sent, the error is around here (though the exact line 2029 is just a comment)

https://github.com/EDmodel/ED2/blob/fa80dab6a258a69eede77b9e5c46d94173ff6ba1/ED/src/dynamics/canopy_struct_dynamics.f90#L2029-L2032

Because there is a division for zero and a log, my hunch is that the floating point exception is coming from there. Perhaps you could add a temporary sanity check like the one below and see what it reports.

      if ( (height < dheight) .or. rough <= 0.d0 ) then
         write(unit=*,fmt='(a)') ' Invalid height scales in reduced_wind8!'
         write(unit=*,fmt='(a,1x,es12.5)') 'Height       = ',height
         write(unit=*,fmt='(a,1x,es12.5)') 'Displacement = ',dheight
         write(unit=*,fmt='(a,1x,es12.5)') 'Roughness    = ',rough
         call fatal_error('Height scales are incorrectly set.','reduced_wind8'             &
                         ,'canopy_struct_dynamics.f90')
      end if

The default temperate C3 grass allometry make them very short, and we impose minimum vegetation height for calculating many things due to numeric stability. I guess this could create instances where height is less than displacement height. If roughness is the culprit, then I don't know... Also, it may be worth trying to run with different ICANTURB settings, to see if the problem is specific to one implementation or a more general issue.

[mccabete]

Thanks for the check code, I'll try it out. I agree, it looks like a height related thing. This was with C4 grasses (PFT 1).