Re: [netcdfgroup] Compound type and Fortran90

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
  • 2013 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: