2015-06-10 16:38 GMT+0200, Scot Breitenfeld <[email protected]>: > >> On Jun 9, 2015, at 3:12 PM, marco restelli <[email protected]> wrote: >> >> Hi Scot, >> thank you for the pointer! >> >> I see from the example how to write a ragged array, when I try to use >> the same idea for my derived type I am not sure how to handle the >> various fields. Elaborating on my previous example, let us assume for >> instance >> >> type :: t_data >> logical :: l >> integer :: i >> real, allocatable :: vals(:) >> complex, allocatable :: xyz(:,:) >> end type t_data >> >> type(t_data) :: data(100) ! the array which I want to save >> >> One possibility would be treating each field separately, creating four >> arrays, which in this specific case would be two ordinary arrays and >> two ragged arrays. Unless I am missing something, this could be done >> as in the example. >> >> However, I would prefer writing one single HDF5 array keeping the same >> structure as in the fortran derived type. Is it possible? > > In theory this should be possible, but we don’t have a test or an example > for doing this. We have a nested > example in the HDF5 source (fortran/examples/nested_derived_type.f90) but we > don’t have an > example of a VL type with nested data types. This would be a good example to > have. > > Can you provide example code that mimics your code for the nested derived > type and VL length that you would like to write so that I make sure I > understand exactly what you are wanting to do? I’m thinking at most 3 > levels > of nests would suffice for an example.
Hi Scot, I am attaching a fortran test program showing what we are doing now with ASCII output. I am including a few modules so that the program can be compiled and run, but the only relevant part for the discussion here is test.f90 and specifically the three subroutines write_t_a_vec, write_t_b_vec and write_t_c_vec. Ideally, I would like to translate this code to have HDF5 output instead of ASCII, using the HDF5 library instead of the included mod_octave_io. Of course, I understand that this might not be so easy! For instance, maybe one would need more than one subroutine for each data type, one to (recursively) collect beforehand the size of all the nested components, and then a second pass to actually write the data. The way I see it, everything is fine as long as each type can be dealt with on its own, so that the overall complexity scales linearly with the number of nested types. With this test code, this is the case: for instance, if we decide to add a new field in t_a, the lowest type in the nesting chain, we only have to change the corresponding subroutine write_t_a_vec. Well, I hope this clarifies my problem, if not please let me know if I can provide additional information. In the meanwhile, I will also look at nested_derived_type.f90, thank you a lot! Marco
HDF5-test.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
