Ok, great :)
-Øyvind 2013/10/3 Garth N. Wells <[email protected]> > On 3 October 2013 13:01, Øyvind Evju <[email protected]> wrote: > > How about an interface like this: > > > > u = Function(V) > > hdf5file = HDF5File("file.hdf5", 'w') > > > > hdf5file.write(u, "BaseFunction") > > > > # ... some manipulation of u > > > > hdf5file.write(u.vector(), "NewFunction", "BaseFunction") > > > > Where the last write will link the x_cell_dofs, cell_dofs and cells of > > BaseFunction to NewFunction. > > > > Read will still work like: > > hdf5file.read(u, "BaseFunction") > > hdf5file.read(u, "NewFunction") > > > > You're trying to make HDF5File do too much. The abstraction level need > to be raised. > > I spoke with Chris today and he'll give a design some thought. Getting > a good solution for this needs time. > > Garth > > > > > -Øyvind > > > > > > > > > > 2013/10/3 Garth N. Wells <[email protected]> > >> > >> On 3 October 2013 09:49, Chris Richardson <[email protected]> wrote: > >> > On 03/10/2013 09:40, Maximilian Albert wrote: > >> >> > >> >> 2013/10/3 Garth N. Wells <[email protected]>: > >> >> > >> >>> What's required is the right abstraction for handling Functions and > >> >>> files. I think the hashing approach is more a hack. What about > >> >>> something along the lines of: > >> >>> > >> >>> Function u(V); > >> >>> Function w(V); > >> >>> > >> >>> HDF5Function hdf5_function_file("my_filename.h5", "w"); > >> >>> hdf5_function_file.register(u, "u_name"); > >> >>> hdf5_function_file.register(w, "w_name"); > >> >>> > >> >>> hdf5_function_file.parameters["common_mesh"] = true; > >> >>> hdf5_function_file.parameters["write_mesh_once"] = true; > >> >>> > >> >>> // Write all registered functions > >> >>> hdf5_function_file.write(); > >> >>> > >> >>> // Write all registered functions again > >> >>> hdf5_function_file.write(); > >> >>> > >> >>> // Write u only > >> >>> hdf5_function_file.write("u_name"); > >> >> > >> >> > >> >> I can't comment on the efficienty/implementation side of things, but > >> >> from a user's point of view my first reaction is that I like this > >> >> idea. > >> >> > >> >> My question is, how does this relate to time-dependent problems? > Would > >> >> it be easy to associate timestep information with the saved functions > >> >> through the interface suggested above? From a UI point of view I > would > >> >> imagine that something like this makes sense: > >> >> > >> >> // Write all functions at timestep t=0 > >> >> hdf5_function_file.write(t=0); > >> >> > >> >> // Write u only at timestep t=2.5 > >> >> hdf5_function_file.write("u_name", t=2.5); > >> >> > >> >> (If no timestep is provided, it could just increase in steps of 1 or > >> >> so.) > >> >> > >> >> Are there any fundamental problems with this approach I'm missing? If > >> >> not, is it something you'd be willing to implement/support? Also, > >> >> could this be easily intergrated with XDMF files, so that animations > >> >> (e.g. in Paraview) would use the correct timesteps? I haven't checked > >> >> recently, but a while ago whenever a field was saved in dolfin this > >> >> created a new timestep in the XDMF file so that it was impossible to > >> >> animate a timeseries of two fields simultaneously. > >> >> > >> > > >> > I am not entirely convinced that this extra level of complexity is > >> > required. > >> > I think the HDF5File should be a generic container which can accept > >> > different types of object inside it, rather than having different > types > >> > of > >> > file for different types of object. > >> > > >> > >> The point is to reduce the complexity for the user via a wrapper for > >> managing the IO details for a Function. > >> > >> The IO to file would still be managed through HDF5File, and a user > >> could still work at a lower level directly with HDF5File if they wish. > >> This cleaner because HDF5File can be more abstract. > >> > >> I think that it's too much to ask one class to manage the IO details > >> of all object types. > >> > >> Garth > >> > >> > It is quite reasonable to attach tags (such as timestamps) to HDF5 > >> > datasets, > >> > and we should support this through the HDF5 attributes interface. > >> > > >> > The HDF5File interface to Function is fundamentally incompatible with > >> > visualisation, because it supports a wider range of FunctionSpaces > >> > > >> > Chris > >> > > >> > > >> _______________________________________________ > >> fenics mailing list > >> [email protected] > >> http://fenicsproject.org/mailman/listinfo/fenics > > > > > > > > _______________________________________________ > > fenics mailing list > > [email protected] > > http://fenicsproject.org/mailman/listinfo/fenics > > >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
