Change Scan Position Variable Type from Float to Int for IODA v2 Compliance

[amstokely]

Summary:

This PR updates the scan position variable type from float to int to ensure compliance with the IODA v2 format.

Changes:

• Modified the scan position variable type from float to int.

Motivation:

• IODA v2 requires scan position to be stored as an integer rather than a floating-point value.

[st-ncar]

I processed radiance observations using the current main and this feature branch and compared the resulting IODA files. It seems that the values of scan_position change as a result of the type conversion. For example, for the first 5 entries (the files in orig are the results of the main branch)

nccmp -ldmgefs -C 5 amsua_n15_obs_2018041500.h5 orig/amsua_n15_obs_2018041500.h5
DIFFER : VARIABLE : scan_position : TYPE : INT <> FLOAT
DIFFER : TYPES : ATTRIBUTE : _FillValue : VARIABLE : scan_position : INT <> FLOAT
DIFFER : VARIABLE : scan_position : POSITION : [0] : VALUES : -999 <> 20
DIFFER : VARIABLE : scan_position : POSITION : [1] : VALUES : -999 <> 21
DIFFER : VARIABLE : scan_position : POSITION : [2] : VALUES : -999 <> 22
DIFFER : VARIABLE : scan_position : POSITION : [3] : VALUES : -999 <> 23
DIFFER : VARIABLE : scan_position : POSITION : [4] : VALUES : -999 <> 24

Many scan_position entries seem to be assigned the _FillValue, others have entries that do not correspond to _FillValue but are different from the result in orig. Is this to be expected? I would have guessed that the numerical entries in the two files should be identical up to type conversion precision differences.

[amstokely]

I processed radiance observations using the current main and this feature branch and compared the resulting IODA files. It seems that the values of scan_position change as a result of the type conversion. For example, for the first 5 entries (the files in orig are the results of the main branch)

nccmp -ldmgefs -C 5 amsua_n15_obs_2018041500.h5 orig/amsua_n15_obs_2018041500.h5
DIFFER : VARIABLE : scan_position : TYPE : INT <> FLOAT
DIFFER : TYPES : ATTRIBUTE : _FillValue : VARIABLE : scan_position : INT <> FLOAT
DIFFER : VARIABLE : scan_position : POSITION : [0] : VALUES : -999 <> 20
DIFFER : VARIABLE : scan_position : POSITION : [1] : VALUES : -999 <> 21
DIFFER : VARIABLE : scan_position : POSITION : [2] : VALUES : -999 <> 22
DIFFER : VARIABLE : scan_position : POSITION : [3] : VALUES : -999 <> 23
DIFFER : VARIABLE : scan_position : POSITION : [4] : VALUES : -999 <> 24

Many scan_position entries seem to be assigned the _FillValue, others have entries that do not correspond to _FillValue but are different from the result in orig. Is this to be expected? I would have guessed that the numerical entries in the two files should be identical up to type conversion precision differences.

This is definiately not expected. I'll look into it right now. Thanks for testing out these changes.

[amstokely]

I processed radiance observations using the current main and this feature branch and compared the resulting IODA files. It seems that the values of scan_position change as a result of the type conversion. For example, for the first 5 entries (the files in orig are the results of the main branch)

nccmp -ldmgefs -C 5 amsua_n15_obs_2018041500.h5 orig/amsua_n15_obs_2018041500.h5
DIFFER : VARIABLE : scan_position : TYPE : INT <> FLOAT
DIFFER : TYPES : ATTRIBUTE : _FillValue : VARIABLE : scan_position : INT <> FLOAT
DIFFER : VARIABLE : scan_position : POSITION : [0] : VALUES : -999 <> 20
DIFFER : VARIABLE : scan_position : POSITION : [1] : VALUES : -999 <> 21
DIFFER : VARIABLE : scan_position : POSITION : [2] : VALUES : -999 <> 22
DIFFER : VARIABLE : scan_position : POSITION : [3] : VALUES : -999 <> 23
DIFFER : VARIABLE : scan_position : POSITION : [4] : VALUES : -999 <> 24

Many scan_position entries seem to be assigned the _FillValue, others have entries that do not correspond to _FillValue but are different from the result in orig. Is this to be expected? I would have guessed that the numerical entries in the two files should be identical up to type conversion precision differences.

This is definiately not expected. I'll look into it right now. Thanks for testing out these changes.

I moved all scan_position type casting to write_obs, limiting changes to ncio_mod.f90 while ensuring the scan_position variable is correctly cast from real to integer. My previous approach would have required converting xdata%xseninfo_float to an integer array, which would have necessitated significant refactoring beyond ncio_mod and define_mod.

[st-ncar]

My comments have been addressed.