You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered this issue (as stated in the title) when testing the ADC-WW3-NWM-NEMS coupling app on the UNC Hatteras cluster.
In module_NEMS_Rusage.F90 and in the subroutine color_by_hash, the Fortran version of crc32 hash returned from the CRC algorithm (nems_c_rusage.c) is negative. I think the problem is that the C function returns the crc32 hash as an unsigned integer data type (uint32_t), but in Fortran, the only available datatype is the signed integer (int32_t).
I am not sure if this indicates a bug in my compiler (openmpi 3.0.0)'s Fortran 2003 support or not (as noted at the beginning of this module). I also wonder if taking the absolute value of the negative Fortran hash can be a workaround for this machine/compiler dependent issue.
The text was updated successfully, but these errors were encountered:
I encountered this issue (as stated in the title) when testing the ADC-WW3-NWM-NEMS coupling app on the UNC Hatteras cluster.
In module_NEMS_Rusage.F90 and in the subroutine color_by_hash, the Fortran version of crc32 hash returned from the CRC algorithm (nems_c_rusage.c) is negative. I think the problem is that the C function returns the crc32 hash as an unsigned integer data type (uint32_t), but in Fortran, the only available datatype is the signed integer (int32_t).
I am not sure if this indicates a bug in my compiler (openmpi 3.0.0)'s Fortran 2003 support or not (as noted at the beginning of this module). I also wonder if taking the absolute value of the negative Fortran hash can be a workaround for this machine/compiler dependent issue.
The text was updated successfully, but these errors were encountered: