0

I'm fairly new to Fortran and try reading in 3D (80000*100*10) single precision NetCDF data (however I'd just read it 2D like (80000,100,1st)). I would need to convert them into double precision for some further code not shown below.

The .nc-File which I create to check if the reading/writing works does contain only "0" if I use real single precision for all NF90-functions as well as the variable 'values'.

It does contain mostly "0" and several weird numbers which don't seem to relate in a conceivable way to the input data if I use double precision (code shown below). At least I get any output in my nc file this way.

I don't get any compiling errors {nor error codes in 'STATUS' if I check for specific lines after NF90 functions. Update: That was mistaken}. Input_test.nc gets created exactly as expected regarding dimensions, but not regarding the actual values.

My code is:

PROGRAM read

     Implicit None

     INCLUDE 'netcdf.inc'

     INTEGER :: NCID, horstart, verstart, horlen, verlen, horcount, vercount, STATUS, STATUS2

     REAL(kind=8), DIMENSION(80000,100) :: values


     horstart = 1

     verstart = 1

     horcount = 80000 !!(tried to use this instead of horlen, doesn't change anything)

     vercount = 100 !!(tried to use this instead of verlen, doesn't change)

     varname = 'pres'




!! get input data

     STATUS = NF90_OPEN('my_valid_path/file.nc', 0, NCID)


     STATUS = NF90_INQ_DIMID(NCID, 'ncells', horid)
     STATUS = NF90_INQ_DIMID(NCID, 'height', verid)

     STATUS = NF90_INQ_DIMLEN(NCID,horid,horlen)
     STATUS = NF90_INQ_DIMLEN(NCID,verid,verlen)

     STATUS = NF90_INQ_VARID(NCID,varname,varid)

     STATUS = NF90_GET_VARA_DOUBLE(NCID,varid,[horstart,verstart,1],[horlen,verlen,1],values)

STATUS = NF90_CLOSE(NCID)    




        STATUS = NF90_CREATE ('some_path/input_test.nc', 0, ncid);     

        STATUS = NF90_DEF_DIM (ncid, 'hor',horcount, dimhor)
        STATUS = NF90_DEF_DIM (ncid, 'ver',vercount, dimver)
        STATUS = NF90_DEF_DIM (ncid, '1d',1, dimcode)

        STATUS = NF90_DEF_VAR(ncid,'pres',NF90_DOUBLE,2,[dimhor,dimver],pres_id)
        STATUS = NF90_DEF_VAR(ncid,'status',NF90_INT,1,dimcode,stat_id)

        STATUS = NF90_ENDDEF(ncid)

        STATUS = NF90_PUT_VARA_DOUBLE(ncid,pres_id,[horstart,verstart],[horcount,vercount],values)
        STATUS = NF90_PUT_VARA_INT(ncid,stat_id,1,1,STATUS2)

        STATUS = NF90_CLOSE(ncid)

The nc file I read from doesn't contain any zeroes, not even in the 3rd dimension. The Output file however does contain a lot zeroes, it is not empty though.

Example input: 0,095213220 0,099325478 0,10358732 0,10800611 0,11259078 0,11734842 0,12228279 0,12740466 0,13271827 0,13822863 0,14394356

Example output: 0 0 0 0 0 0,000493943283800036 0,000594558776356280 0,000234268474741839 2,88491937681101e-05 2,09666131608306e-16 7,30948746534081e-20

I'm probably doing something stupid, but I went temporarily out of ideas what to check for.

UPDATE: Thoroughly checking the error codes saved in STATUS did give a non-zero match at NF90_GET_VARA_DOUBLE/(also REAL). Getting back to this tomorrow.

Ted Ockham
  • 13
  • 5
  • Please note that `kind=8` is ugly and not portable. It does not mean double precision nor 8-byte in all compilers. Several compilers don't have kind 8 at all and will not compile your code. See https://stackoverflow.com/questions/838310/fortran-90-kind-parameter – Vladimir F Героям слава Dec 21 '17 at 12:50
  • Do I see correctly that you are reading the input file as double precision? You say it is in single precision. – Vladimir F Героям слава Dec 21 '17 at 12:52
  • Thank you very much! However, I tried to use REAL (then together with NF90_GET/PUT_VARA_REAL and NF90_REAL) as well as REAL(wp), and all of it does compile and create an output file, yet with no or uncorrect values in the output file. I meant that the input nc file itself seems to contain values of single precision (if checked with Matlab). – Ted Ockham Dec 21 '17 at 12:54
  • It may be informative to include the CDL description of `my_valid_path/file.nc`. – francescalus Dec 21 '17 at 13:02
  • What is the "CDL description"? :-) – Ted Ockham Dec 21 '17 at 13:08
  • But if it is single precision, why are you using `NF90_GET_VARA_DOUBLE`? Isn't that for double precision from looking at the name? – Vladimir F Героям слава Dec 21 '17 at 14:58
  • is this fixed form? Your `Intetger` declaration line looks too long and since you have not done `inplicit none` you may not be declaring everything you think. Do you have a link to netcdf.inc? There may be an implicit statement in that. – agentp Dec 21 '17 at 15:12
  • @Vladimir F Just used it recently because it gets me some values other than 0, which felt reassuring. Changing to REAL doesn't solve the problem. – Ted Ockham Dec 21 '17 at 15:31
  • @agentp Thanks, I added Implicit None now, as you mentioned. No change though. – Ted Ockham Dec 21 '17 at 15:33
  • It might not solve the problem on its own, but the the output shouldn't be the same. Or is it? – Vladimir F Героям слава Dec 21 '17 at 15:34
  • @Vladimir F Ah, I tried to explain that in my paragraphs 2 and 3 of the original post. If I declare "values" as REAL and use NF90_GET_VARA_REAL etc., the output file contains only zeroes "0". In the version shown above, the output file contains also a small number of crap values > 0. – Ted Ockham Dec 21 '17 at 15:39
  • I really can't see any sense in reading single precision numbers as doubles? How could that ever work? – Vladimir F Героям слава Dec 21 '17 at 15:41
  • @Vladimir F You're probably right. I'll change that bit. In my mind, it might have been needed if the variable to which it is written had been declared in double precision. That was probably a wrong thought. – Ted Ockham Dec 21 '17 at 15:48
  • I've now tried the following variation: NF90_GET_VARA_REAL while leaving the rest of the code as it is (I already tried twice the variation with all things REAL to no avail). Compiler doesn't object. The output is identical to the one by the code shown above. – Ted Ockham Dec 21 '17 at 15:54
  • things like `horid` are not apparently declared, which is puzzling since that should throw an error with `implicit none` In any case start writing out all that stuff ( the return values ) see if it makes sense and has the correct type. – agentp Dec 21 '17 at 16:12
  • Yeah I've mistakenly used the old version for compiling. implicit none did threw errors. I've now declared all the missing integers. And after handling the return of the NF_ lines consistently, I see now an error of NF90_GET_VARA_DOUBLE/REAL (both cases). That's a start. I'll keep you informed, however have to quit working for today. – Ted Ockham Dec 21 '17 at 17:07
  • If your netCDF package has been compiled with the true F90 api you should use that rather than this old version. Try `use netcdf`. You can then get variables with simple calls like `nf90_get_var(ncid,vid,array,start_array,count_array)` and everything will be handled automatically. I'd also invest some time invoking an error handler as explained here https://www.unidata.ucar.edu/software/netcdf/netcdf-4/newdocs/netcdf-f90/NF90_005fSTRERROR.html#NF90_005fSTRERROR – RussF Dec 22 '17 at 00:19
  • Yes, with error handler I came to the conclusion that the above code works. The errors came from spelling mistakes of the variables. – Ted Ockham Jan 04 '18 at 15:58

1 Answers1

0

With error handler I came to the conclusion that the above code works. The errors eventually came from a spelling mistake of the variables I tried to read from.

Ted Ockham
  • 13
  • 5