E3SM-Project / scorpio

A high-level Parallel I/O Library for structured grid applications
18 stars 16 forks source link

Read buffers are not reset in some Fortran unit tests #547

Closed dqwu closed 7 months ago

dqwu commented 8 months ago

In certain Fortran unit tests, the read buffers are not reset to evaluate all available IO types. A specific instance is observed in the provided test code, where 'gval' is not reset prior to invoking PIO_get_att().

PIO_TF_AUTO_TEST_SUB_BEGIN test_put_get_1datt
  Implicit none
  type(file_desc_t) :: pio_file
  character(len=PIO_TF_MAX_STR_LEN) :: filename
  type(var_desc_t)  :: pio_var, pio_cvar
  integer :: pio_dim
  integer, parameter :: DIM_LEN = 100
  PIO_TF_FC_DATA_TYPE, dimension(DIM_LEN) :: pval, gval
  PIO_TF_FC_DATA_TYPE :: init_val
  ...

  init_val = pio_tf_world_sz_

  pval = init_val
  ...
  do i=1,num_iotypes
    ...

    ret = PIO_put_att(pio_file, pio_var, 'dummy_att_val', pval);
    PIO_TF_CHECK_ERR(ret, "Failed to put attribute:" // trim(filename))
    ...

    ret = PIO_get_att(pio_file, pio_var, 'dummy_att_val', gval);
    PIO_TF_CHECK_ERR(ret, "Failed to get attribute:" // trim(filename))

    PIO_TF_CHECK_VAL((gval, init_val), "Got wrong value")
    ...
  end do
...

If read buffers remain unreset, existing Fortran unit tests may fail to detect concealed bugs, exemplified by the issue confirmed in #546. In the aforementioned code, the PnetCDF type is assessed before the ADIOS type, and 'gval' retains anticipated values read by PnetCDF. In the scenario where ADIOS type exclusively reads/writes the initial element of 'pval/gval' (a known bug), the expected failure of PIO_TF_CHECK_VAL on 'gval' does not occur as 'gval' is not reset before the invocation of PIO_get_att().

We need to examine existing Fortran unit tests and ensure that read buffers are always reset before testing the next available IO type. A comprehensive review and adjustment of Fortran unit tests are necessary to address this issue systematically.