Changes between Initial Version and Version 1 of Ticket #380


Ignore:
Timestamp:
12/08/09 02:00:02 (15 years ago)
Author:
arango
Comment:

I don't know what its problem here. The Fout variable argument to get_ngfld can be an array of rank 1, 2, or 3. Maybe this is the problem in your case. This is a standard trick in the old Fortran. This is the reason why I didn't put this routine inside of a module. I didn't want to have so many special routines for processing non-grided data.

Anyway, I think that your suggestion is a good one. It makes these routines more robust. Thank you.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #380

    • Property Resolution → Fixed
    • Property Status new → closed

  • Ticket #380 – Description

    initial v1  
    1 I have a limited-area ocean modelling application in which the usual variables are being read from a boundary file. On one of the platforms I run this on (Cray T3E), it fails in NETCDF_GET_FVAR_1D with a message about an invalid floating-point value. The failure occurs somewhere in the following section of code:
     1I have a limited-area ocean modelling application in which the usual variables are being read from a boundary file. On one of the platforms I run this on (Cray T3E), it fails in '''netcdf_get_fvar_1d''' with a message about an invalid floating-point value. The failure occurs somewhere in the following section of code:
    22
    33{{{
    … …  
    1111}}}
    1212
    13 I set up a toy example with Lm=78, Mm=87 and N=25, serial with 1 tile in each direction. The failure occurred when reading vbar data from the southern boundary. NETCDF_GET_FVAR_1D was being called by GET_NGFLD with the optional argument total set to 80 (the number of v points on the southern boundary, as expected) and being passed a 1D array much larger than this: I think the size was 2025 or 2225. In the above loop, Asize(1) was set to the size of the output array and the failure occurred on the 81st point, which had a value of NaN.
     13I set up a toy example with Lm=78, Mm=87 and N=25, serial with 1 tile in each direction. The failure occurred when reading vbar data from the southern boundary. '''netcdf_get_fvar_1d''' was being called by '''get_ngfld''' with the optional argument total set to 80 (the number of v points on the southern boundary, as expected) and being passed a 1D array much larger than this: I think the size was 2025 or 2225. In the above loop, Asize(1) was set to the size of the output array and the failure occurred on the 81st point, which had a value of NaN.
    1414
    1515As I said, this failure occurs on only one platform, but processing uninitialized values is always dangerous and, in this case, inefficient: why process 2000-odd values when you only want 80 of them?
    … …  
    2929}}}
    3030
    31 NB: I test for the presence of both start and total because that is the test done when NF90_GET_VAR is called.
     31NB: I test for the presence of both start and total because that is the test done when '''nf90_get_var''' is called.
    3232
    33 I see no reason not to apply the same logic to all the NETCDF_GET_$VAR_$D routines, so I have done so in my copy of the source code, which is here:
     33I see no reason not to apply the same logic to all the '''netcdf_get_$var_$d''' routines, so I have done so in my copy of the source code, which is here:
    3434
    3535https://www.myroms.org/projects/omlab/browser/branches/hadfield/trunk/ROMS/Modules/mod_netcdf.F
    3636
    37 PS: I don't know why GET_NGFLD is creating such a large array to collect 1D boundary data, but I presume the same array is being used for other purposes.
     37PS: I don't know why '''get_ngfld''' is creating such a large array to collect 1D boundary data, but I presume the same array is being used for other purposes.
    3838
    3939