I have created a github issue for this here: https://github.com/Unidata/netcdf-fortran/issues/72 in order to allow for public discussion. All further discussion should be as comments on that issue. I will close this issue for now, though you can continue to send support message here if you want. > So will I be kept informed about this issue? > How should I proceed? > > best regards, > > Emanuel J C Pinho > > address@hidden>: > > > Since you are using netcdf-4, the NC_STRING type should be available. > > Looks like a hole in our Fortran API that we need to fix. > > The use of an extra dimension is purely for the netcdf-3 format. > > It is a hack to simulate strings, which the netcdf-3 format lacks. > > > > > > > > I don't know if I should address this question to support-netcdf or > > > support-netcdf-decoders. > > > Please let me know if I should resend it to the correct address. > > > > > > I am facing an apparent inconsistency between C and fortran versions of > > the > > > netCDF API, for which I ask your support. > > > > > > The company I work for has established netCDF-4 as a standard for > > > exchanging some geophysical data. The dimensions and variables naming > > > conventions we use in this format are already defined and there is not > > much > > > flexibility for changing it in the near future. > > > > > > One of our collaborators needs to write a fortran-90 code to access the > > > information stored in these netCDF files. The code is failing when > > > nf90_get_var is called to read string variables. It issues an error > > message > > > about not being able to convert between text and numbers. There is > > > apparently no fortran counterpart to the c-function nc_get_var_string > > > function. > > > > > > I have seen this page in your online documentation, where it is > > recommended > > > to create a dimension with the maximum length of the strings, to > > circumvent > > > the fact that fortran does not deal with variable length strings: > > > https://www.unidata.ucar.edu/software/netcdf/netcdf-4/ > > newdocs/netcdf-f90/Reading-and-Writing-Character-String-Values.html. > > > But, as I said above, changing the format is not a real option in the > > near > > > future and the whole idea of using netCDF-4 was its ability to work with > > > variable length strings, so loosing it is kind of a step backwards. The > > > referred page also sounds confusing to me, as it states that "Character > > > strings are not a primitive netCDF external data type", when there is a > > > NC_STRING in the c-library. > > > > > > Are we missing something or is it really impossible to read/write string > > > variables with nf90_* functions? If that is the case, what would be the > > > work around recommended by the netCDF team? > > > > > > I thank you in advance for your support, > > > > > > Emanuel J C Pinho > > > > > > > > > > =Dennis Heimbigner > > Unidata > > > > > > Ticket Details > > =================== > > Ticket ID: WPE-165732 > > Department: Support netCDF > > Priority: Normal > > Status: Open > > =================== > > NOTE: All email exchanges with Unidata User Support are recorded in the > > Unidata inquiry tracking system and then made publicly available through > > the web. If you do not want to have your interactions made available in > > this way, you must let us know in each email you send to us. > > > > > > > > =Dennis Heimbigner Unidata Ticket Details =================== Ticket ID: WPE-165732 Department: Support netCDF Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.