[netcdfgroup] [netCDF #KJX-899747]: Ragged Arrays in Fortran and netcdf4

[Roy Mendelssohn]

An example of how to properly define the vlen type in the fortran  
call for exactly the data structure as in the C example would clarify  
it.

Thanks!

-Roy

On Apr 17, 2008, at 6:40 PM, Unidata netCDF Support wrote:

>
>> On Apr 10, 2008, at 10:52 AM, Unidata netCDF Support wrote:
>>>> Hi All:
>>>>
>>>> I am working on creating a netcdf4 file with the structure we are
>>>> trying to achieve.  I have a file with Box10 groups and B0x2
>>>> subgroups, works great.  Now I am trying to do ragged arrays.   
>>>> Below
>>>> is the only fortran example I can find that does ragged arrays.  It
>>>> is only writing one,1-dimensional array, so I am unsure what I do
>>>> when I am writing an N-dimensional ragged array.   Do I just write
>>>> each "column" in a loop - if so how does it know that it is writing
>>>> to the same structure?  Or if I can do multiple "columns" at once,
>
> Howdy Roy!
>
> To answer some more of your questions, you define your vlen type,  
> and then create a variable of that type, with whatever dimensions  
> you want, 1D, 2D, 3D, whatever.
>
> Then you call the nf_put_vara() and nf_get_vara() functions to  
> write and read the data. You give them the address of the array of  
> data, whether in fortran or C.
>
> If your fortran compiler's memory map of the data are the same as  
> the C version, everything will just work.
>
> There is one caveat: this is untested. I have never tried this from  
> fortran.
>
> There is one twist: you must free each VLEN separately or you will  
> have memory leaks. There is a function nf_free_vlen() for this.
>
>>>> how do I set that up.  More realistic examples would be very  
>>>> helpful,
>>>> including an example that writes an N-dimensional ragged array, and
>>>> an example that adds one more column to an existing ragged array.
>>>> Even just the fortran equivalent of the program tst_vl.c would be
>>>> very helpful
>
> I agree with you that there needs to be a realistic example, but my  
> experience is that even more necessary are some basic tests. The  
> fortran version of tst_vl.c, as you say. We are not there yet...
>
> I will add some tests for this after my upcoming beta2 release  
> (which will happen any day now). As for the scientifically  
> realistic example, well, perhaps we should be asking you for that! ;-)
>
>>>>
>>>> It is clear how to do it in C (I set up an array of structures  
>>>> of the
>>>> given form), but not in either version of FORTRAN.
>>>>
>
> It works like this: the f77 layer is just the a bunch of C wrapper  
> shells around the C API functions, with a little macro magic to  
> convert C-like 0-based indexes into F77-like 1-based indexes, and  
> to reorder dimensions so that the first C dimension will come last,  
> etc.
>
> Then the F90 API is built right on top of those F77 calls. Just  
> look at the F90 code and you will see that most of the functions  
> are just F90 wrappers around the F77 function.
>
> It is the same in Fortran as C, except that the HDF5 build knows  
> about the C structs, but not about the fortran structs. So it  
> guarantees to work from C, but not from fortran. However, if  
> fortran uses the same layout for the data in memory as the C  
> compiler does (including any rules for padding or boundaries, or  
> whatever), then everything will work. (Because everything is  
> happening at the C layer anyway.)
>
> But the code will not be portable, because if another fortran  
> compiler does something different, the data will not look the same  
> in memory.
>
> (This portability problem does not matter once the data are  
> written. HDF5 uses a known system of storage, which is always the  
> same, no matter what platform you are on. So once you get the data  
> into the HDF5 file, it is portable. It's just the code that gets  
> the data into the file is not portable.)
>
> Does this shed any light on your problem space?
>
> Thanks!
>
> Ed
>
>
> Ticket Details
> ===================
> Ticket ID: KJX-899747
> Department: Support netCDF
> Priority: Normal
> Status: Open
>

**********************
"The contents of this message do not reflect any position of the U.S.  
Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division	
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097

e-mail: Roy.Mendelssohn at noaa.gov (Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."