0

I'm having problems to understand what's going on with my fortran subroutine (2003 standard) to read netCDF-4 data. The compiler I'm using is gfortran.

I have to read a 32-bit integer from a netCDF file, to read the file a declare an allocatable variable as integer(KIND=4). However, if I do that the netCDF variable is not correctly stored (only 0 values are saved).

Instead, if I declare the variable as integer(KIND=8) or double the variable is correctly stored (it is, of course, stored as read using double precision).

Why I cannot use the corresponding KIND for a 32-bit variable?

I could simply do that and ignore the problem, but I'm afraid that I will do something wrong with some other variables if I don't understand what's happening.

Any ideas?

Thanks!!

cardogar
  • 359
  • 1
  • 4
  • 17
  • 2
    `Kind=4` never meant 32-bit and `kind=8` never meant 64bit in the standard. Check your compiler documentation what it mean in that one. – Vladimir F Героям слава Jun 05 '15 at 14:59
  • I see, following your suggestion I checked http://stackoverflow.com/questions/3170239/fortran-integer4-vs-integer4-vs-integerkind-4/3170438 But still I don't understand the issue. If I want to store a 32-bit variable I have to try different "selected_int_kind" until I get the good results? But, what happen if I want to use the code in some other machine with some other compiler. The code will be not portable... – cardogar Jun 05 '15 at 15:18
  • `Selected_int_kind` is portable, `kind=4` is not. If you ask for 9 digits, you typically get 32-bit integer. It is not guaranteed, but circumstances for other results would be hard to find. Still for most of the compilers `kind=4` does mean 32-bit, but not in all of them, check your manual. In that very answer you linked there is another solution, to you use the kind constant `int32`. It is supported by many compilers. It is still possible your issue is caused by something else, of course. – Vladimir F Героям слава Jun 05 '15 at 15:37
  • The problem is that I cannot use the 2008 standard. I'd still need some explanations if you do not mind. You suggested to check my compiler manual (gfortran), but that means that the code will be compiler dependent, no? I mean, I have to use `selected_int_kind(10)` to read the integer 32-bits netcdf variable with my compiler. But it is not possible that I have to specify `selected_int_kind(11)` in some other machine? – cardogar Jun 05 '15 at 15:48
  • It's clear that using `Selected_int_kind` to save my output variables into a netCDF file will work in all computers. But as I posted before, that's not the case for reading the inputs. A priori I don't know how those inputs will be stored, I just can see their bits. – cardogar Jun 05 '15 at 15:50
  • If you use gfortran `kind=4` means 32-bit integer, if you do not use any flag that can change it, your issue is probably somewhere else. In NAG you would have to use `kind=1`. – Vladimir F Героям слава Jun 05 '15 at 15:52
  • No, `Selected_int_kind(9)` is very likely to return the same 32-bit integer on all platforms in wide use. It is much more certain than specifying `kind=4`. Alas, the function was created for this very reason. Yes it could *theoretically* offer you the 64-bit one instead, but no-one does that. – Vladimir F Героям слава Jun 05 '15 at 15:55
  • You will have to edit the question to show same code that shows the problem. If the question remains the same I will have to close it as a duplicate of other kind questions or vote to close because there is not enough code to diagnose the problem. – Vladimir F Героям слава Jun 05 '15 at 16:13
  • OK, thanks for your answers. Close it since I don't know which code I could post in order to make my problem clearer. – cardogar Jun 05 '15 at 16:24
  • @cardogar I guess "ncdump -c yourdata.nc" will show the data type (integer, float, double) in your datafile. – roygvib Jun 05 '15 at 23:37
  • I will try that. What I do is to see the data type with a viewer. In particular I use hdfview and you can quickly see the bits of every variable. – cardogar Jun 06 '15 at 08:47

0 Answers0