Errors using log_field

[Samantha Pullen (SamanthaPullen)]

I have been (successfully until now) using the LFRic core subroutine log_field (https://code.metoffice.gov.uk/trac/lfric/browser/LFRic/trunk/infrastructure/source/utilities/log_field_mod.f90) to print out field values during LFRic_Apps development work. Since trying to use it in my LFRic_Apps vn2.1 branch I am getting floating point exception run-time errors: https://cylchub/services/cylc-review/view/samantha.pullen?&suite=vn2.1_multifile_iau%2Frun17&no_fuzzy_time=0&path=log/job/1/run_lfric_atm_nwp_gal9_da-C12_azspice_gnu_fast-debug-64bit-crun0/01/job.err
In my PET log the field values start being printed out (and look like valid theta field values).

I am specifying its use by:
use log_field_mod, only : log_field

and using it by:
call log_field( theta, LOG_LEVEL_INFO )

Can anyone advise on what I am doing wrong?

[Andrew Coughtrie (andrewcoughtrie)]

Are you trying to print out an integer field? That's the only thing I can think of. The code is falling over trying to write out the actual values which is deep down in the Fortran libs, nothing we've written.

[Samantha Pullen (SamanthaPullen)]

No, it's a 'real' field.
The odd thing that I have discovered is that the field values that are printed (before it fails) are offset in terms of dof index for parts of the output compared to output I get from an earlier branch.

e.g. Field values for index 6320 to 13619 match the field values at the same indices in the output from my earlier (r3645) branch
but... Field values for index 1 to 781 match the field values at index 4545 to 5325 in the output from my earlier (r3645) branch
and so on.

I have an idea of what the problem could be. There are some sections of NaN in the field printout from my older branches (and I believe this is a known issue) - I suspect that running with my vn2.1 branch on azure spice is using a different compiler version that causes a failure when log_field tries to write out whatever these NaNs hold, rather than just printing them out as NaNs

[Steve Mullerworth (stevemullerworth)]

If you are compiling with "-ffpe-trap=invalid,zero,overflow" (which are included in the full- and fast-debug flags for most LFRic builds) then fields are automatically initialised with NaN in the whole field. However, on old spice, the version of the Gnu compiler did this initialising with the wrong sort of NaN such that they would not cause numerical failures.

New Spice has Gnu 12 where the bug has been fixed. That may explain why the NaN values are (correctly) causing failures now. There are a couple of options to help you:

1. Compile without the -ffpe flag by editing the file in the infrastructure/build/fortran/gfortran.mk file. The downside of this is that it removes the NaN initialisation which would likely change your output.
2. Override the flag from within the logging routine so that you keep the NaN initialisation, but avoid the numerical failure in log_mod by adding the following lines to log_mod.f90:

    use, intrinsic :: ieee_arithmetic, only: IEEE_INVALID
    use, intrinsic :: ieee_exceptions, only: ieee_set_halting_mode, ieee_get_halting_mode
    logical :: halt_mode

    # At the start of the routine, get logical that indicates whether numerical checking is on
    call ieee_get_halting_mode(IEEE_INVALID, halt_mode)
    # Turn off numerical checking if it is on
    call ieee_set_halting_mode(IEEE_INVALID, .false.)
    
    # Original log_field code here
    
    # At the end of the routine, revert to the original state
   call ieee_set_halting_mode(IEEE_INVALID, halt_mode)

These changes are in the LFRic infrastructure code, rather than the lfric_apps code, so you would need to check out a copy of the LFRic infrastructure code at the version referenced in the dependencies.sh file in your apps working copy, and change the dependencies.sh file to point to your local copy.

[Samantha Pullen (SamanthaPullen)]

Thanks very much Steve Mullerworth (@stevemullerworth). I have overcome the problem for now by editing a working copy of log_field_mod to print out just the 1st 100 values of the field (rather than looping over the full undf) - that also has the benefit of generating a more manageable volume of output :). I will try your suggested options if/when I want to be able to output the whole field.