Thanks Steven. I have to agree with you that having one standard HDF output and using additional available tools to convert it to the format one likes is more general than implementing every possible output directly in meep. Of course using such a conversion the time is longer by a factor of about 2 than for a direct input. For example in my program which is working on 8 processors, outputting once an array of size 200x60x200 with HDF and then converting it to VTK takes about 10s. In the same conditions the direct VTK output time in my Fortran simulation takes about 4s. It is not a big difference and I can live with it but I am just wandering if maybe I can make it faster.
However in such case it would be nice to have at least a function like fields::field_to_array(component, double*** ) that would store the entire field from all the nodes into a double*** array on just one node so that the node could then operate on it easily and save it to a desired format by itself, without even needing to use the parallel I/O. What do you think of that ? Thomas Jefferson 2008/8/7 Steven G. Johnson <[EMAIL PROTECTED]>: > On Aug 6, 2008, at 9:52 PM, Jefferson Thomas wrote: >> The problem is that the function fields::get_field works to slow when >> used for copying >> the field from the entire volume into a new array, which would be >> needed for VTK output. >> >> So is there maybe a way to copy the entire field array into a new >> double*** array >> or something like that ? > > You don't want to do it using the get_field function. You would want > to do it using the loop_in_chunks function, just as for output_hdf5. > > One problem with the VTK file format is that I'm not aware of any > parallel I/O libraries for this format (although I could be missing > something), so you would have to implement this yourself. > > You say that calling output_hdf5, then h5tovtk, then deleting the .h5 > file, is too slow. Do you have any benchmarks to illustrate this? I > would have thought that the time to run h5tovtk would be fine compared > to the time for output_hdf5. > > I disagree that writing an HDF5 file and then converting it is > "definitely not elegant". The alternative is for every program to > implement support for every major file format, which is definitely not > elegant. Writing to a single standard interchange file format and > then using converter programs for other formats and programs follows > the the spirit of the Unix philosophy. > > Steven > > > _______________________________________________ > meep-discuss mailing list > meep-discuss@ab-initio.mit.edu > http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss > _______________________________________________ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
