NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Gerald, > è But you confirm me that one cannot write in a compound type, using netCDF functions > in Fortran90. In this case, the documentation is not correct. Is an evolution planned to make > the user defined type supported by the writing function ? If I'm understanding you correctly, I think you are mixing up *netcdf compound types* and *fortran90 derived types*. It might seem that there is a very natural correspondence between these two. For example, you might make a netcdf compund type with a real and an integer, and then make a fortran90 derived type with a real and an integer. So, from a user's point of view, they are holding the same information. However, you cannot pass the *fortran90 derived type* to the netcdf library and expect it to be able to write out the proper *netcdf compound type*. To do that, the netcdf library would have to know how to be given an arbitrary fortran90 derived type and be able to parse its components in some standards-compliant way. As far as I know, fortran does not provide this capability. (Maybe it's in some new version of fortran -- I don't know about that.) So to directly answer your question, yes, you can write a netcdf compound type in fortran90, but I believe you were thinking that that means you can write a fortran90 derived type directly to a netcdf compound type through a single nf90_put_var( fortran_derived_type ) call. You can't do that. You would have to write your own version of the ncf90_put_var() routine that took your fortran derived type and wrote the components correctly to the netcdf compound type. > (Gérald) Is it possible to manage compound types in C language ? (define/write/read ?) Your > remark about the compound types is a general remark ? I mean not only for Fortran90 using ? > In a general way and whatever the programming language, what are the recommendations on > this matter ? The compound type should be avoided ? what is the technical status ? (particular > convention ? portability problems ? programming difficulty when using it ?) As per above, you can manage *netcdf compound types* in either language (but can't write fortran90 derived types directly through a nf90_put_var( fortran_derived_type ) call). Whether or not to use compound types is more a matter of opinion and what your requirements are. There are some applications where it's extremely desirable to use a compound type, and happily, netcdf supports this use case. But I think you will find that various analysis programs support netcdf compound types to various degrees. So you might make a file and give it to a colleague, and your colleague might be using some analysis package you never heard of that doesn't support compound types very easily. In that case, you would have been better off just writing out simple types in the first place, and making it clear through established netcdf conventions that, for a simple example, the "U" field and the "V" field jointly determine the velocity field. Regards, --Dave *De :* davidwilliampierce@xxxxxxxxx [mailto:davidwilliampierce@xxxxxxxxx<davidwilliampierce@xxxxxxxxx>] > *De la part de* David W. Pierce > *Envoyé :* mardi 16 juillet 2013 20:01 > *À :* Gérald Mercadier > *Cc :* netcdfgroup@xxxxxxxxxxxxxxxx > *Objet :* Re: [netcdfgroup] Compound type and Fortran90**** > > ** ** > > Hi Gerald,**** > > When the documentation says that the data to be written "may be of any > type", it means, any fortran90 native type (real, double precision, > integer, etc.) The netcdf library does not know how to write out a derived > type that you create yourself.**** > > ** ** > > **è **(Gérald) In the documentation about compound types (see > http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-f90/Compound-Types.html#Compound-Types), > on can read ”To write data in a compound type, first use > nf90_def_compound to create the type, multiple calls to > nf90_insert_compound to add to the compound type, and then write data with > the appropriate nf90_put_var1, nf90_put_vara, nf90_put_vars, or > nf90_put_varm call.” I know how to define compound types in netCDF but I > don’t understand how to write data in a compound type as described in the > doc.**** > > ** ** > > **è **But you confirm me that one cannot write in a compound type, using > netCDF functions in Fortran90. In this case, the documentation is not > correct. Is an evolution planned to make the user defined type supported by > the writing function ?**** > > ** ** > > ** ** > > My personal advice is that you will save yourself headaches down the line, > and your netcdf files will be more widely compatible with the world of > software already out there, if you avoid netcdf compound types. Some > problems really mandate a compound type, so it's great that they are > available, but it's just limiting the usefulness of your files if you use > compound types gratuitously. I.e., if you're writing a velocity field, just > write U and V fields rather than making a compound type that has U and V > components.**** > > ** ** > > **è **(Gérald) Is it possible to manage compound types in C language ? > (define/write/read ?) Your remark about the compound types is a general > remark ? I mean not only for Fortran90 using ? In a general way and > whatever the programming language, what are the recommendations on this > matter ? The compound type should be avoided ? what is the technical > status ? (particular convention ? portability problems ? programming > difficulty when using it ?)**** > > ** ** > > **è **I don’t know very well netCDF but do you recommend to use the lib > in C or in Fortran90 ? What would be the limitations/constraints in a > Fortran90 using ?**** > > ** ** > > If you do absolutely need compound types, the solution would be to write > your own version of nf90_put_var() that would take as the argument your > derived type and write it appropriately into a netcdf compound type using > lower level calls.**** > > > Regards,**** > > --Dave**** > > ** ** > > On Tue, Jul 16, 2013 at 10:14 AM, Gérald Mercadier < > Gerald.mercadier@xxxxxxxxxxx> wrote:**** > > Dear all,**** > > **** > > I am using netCDF 4.1.3 in a Fortran90 code which is compiled with > gfortran 4.4.5. I want to use the compound types. I have no problem to > define a compound type, but I am currently encountering a problem when I > try to put values into a well-defined compound type. The problem occurs at > the compilation, when using nf90_put_var. The compilation fails with the > error “Error: There is no specific function for the generic 'nf90_put_var' > at (1)”**** > > **** > > In my code, I have defined a compound type using nf90_def_compound and > nf90_insert_compound. This type contains variables of int/double/string > type or another user defined type.**** > > The definition works well, the .nc file created is correct. Unfortunately, > the call of nf90_put_var leads to this compilation error. The third > argument of the routine is “values”, which is the derived type (or > Fortran90 structure) in my case, containing variables of different types. > The documentation of nf90_put_var (see > http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-f90/NF90_005fPUT_005fVAR.html#NF90_005fPUT_005fVAR) > says that “the data may be of any type, and may be a scalar or an array of > any rank”. I just call nf90_put_var with 3 arguments, like this > “nf90_put_var(ncid, varid, values)”. **** > > **** > > I would like to know how put a value of a derived type variable into a > compound type variable with netCDF, in a Fortran90 code. Can someone help > me please ? **** > > Thank you for your help !**** > > **** > > **** > > 153, rue du Lac <http://www.noveltis.com/>**** > > F-31670 LABEGE <http://www.noveltis.com/>**** > > Tel : +33 (0)5.62.88.11.28 <http://www.noveltis.com/>**** > > Fax : +33 (0)5.62.88.11.12 <http://www.noveltis.com/>**** > > www.noveltis.com**** > > <http://www.noveltis.com/>**** > > <http://www.noveltis.com/>**** > > *Merci de considérer toutes les informations contenues dans cet email > comme confidentielles. Vous ne devez pas les transmettre sans > autorisation. Si ce mail ne vous est pas destiné, merci de le signaler à > l’expéditeur et de l’effacer de votre système. <http://www.noveltis.com/>* > **** > > *Please, consider email information as confidential. Do not transfer > without prior authorization. If this email is not intended for you, thank > you to notify the sender and to delete this message from your > computer.<http://www.noveltis.com/> > ***** > > <http://www.noveltis.com/>**** > > *Agissons au quotidien pour préserver notre environnement. N’imprimez ce > courrier et les documents joints que si nécessaire.<http://www.noveltis.com/> > ***** > > <http://www.noveltis.com/>**** > > > _______________________________________________ > netcdfgroup mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ <http://www.noveltis.com/>**** > > > > > -- > David W. Pierce > Division of Climate, Atmospheric Science, and Physical Oceanography > Scripps Institution of Oceanography, La Jolla, California, USA > (858) 534-8276 (voice) / (858) 534-8561 (fax) > dpierce@xxxxxxxx<http://www.noveltis.com/> > **** > -- David W. Pierce Division of Climate, Atmospheric Science, and Physical Oceanography Scripps Institution of Oceanography, La Jolla, California, USA (858) 534-8276 (voice) / (858) 534-8561 (fax) dpierce@xxxxxxxx
netcdfgroup archives: