On Sun, Jun 14, 2015 at 4:40 PM, David Knezevic <david.kneze...@akselos.com> wrote:
> In RBEvaluation::read_offline_data_from_files and > RBEvaluation::write_offline_data_to_files), we read/write from/to a bunch > of small Xdr files. I've always thought this is pretty messy and I've > wanted to find a better approach. > > I think a better approach would be to use the Cap'n Proto > <https://capnproto.org/> serialization library. I've made a start on > implementing this here: > https://github.com/dknez/libmesh/tree/rb_capnproto > > But before I go further with the implementation, I'd like to run this by > the list to confirm that this change can be incorporated into libMesh. > In my opinion, yes it definitely can be incorporated. Having used it, are you sufficiently convinced that it is the right way to go for what you want? I agree that the binary decoding feature is a good one, but I'm not crazy about the "schema/preprocessor" thing. > Some comments: > > - Cap'n Proto requires C++11. My plan would be to make Cap'n Proto an > optional package, and to keep the current reduced basis read/write code if > C++11 and Cap'n Proto aren't available. > Sounds good. I regularly build libmesh with -std=c++11 and Moosebuild currently tests c++98 mode, so both code paths will be tested. - We define a "schema" for the serialization format, e.g. see here: > > https://github.com/dknez/libmesh/blob/rb_capnproto/include/reduced_basis/rb_data.capnp > Cap'n Proto then provides a tool to compile the schema into C++ code, > which yields these files: > > https://github.com/dknez/libmesh/blob/rb_capnproto/include/reduced_basis/rb_data.capnp.h > > https://github.com/dknez/libmesh/blob/rb_capnproto/src/reduced_basis/rb_data.capnp.C > So there is a question of what to include in the libMesh source tree (just > the schema file, or the generated code as well). > My first instinct would be to provide the generated code (as long as it's not too large in size) the way we do with autotools, if only to avoid needing to add automake targets/bootstrap code for building it. This is assuming it won't change much once you get it set up the way you like... - Cap'n Proto provides a tool for "decoding" binary data: > https://capnproto.org/capnp-tool.html > This is useful for debugging, i.e. we can get an ASCII dump of the > serialized data by using the "capnp decode" command. > Agreed. - The serialization code that I've written so far uses "auto" a lot, e.g. > see here: > > https://github.com/dknez/libmesh/blob/rb_capnproto/src/reduced_basis/rb_data_serialization.C > This is convenient since otherwise we would have to write out a lot of > Cap'n Proto type names in the code. Using auto relies on C++11, but this > seems OK to me since we have to have C++11 if we're using Cap'n Proto (and > we would if-def out this code if we didn't configure with Cap'n Proto). > Does this seem reasonable, or should I avoid "auto" everywhere? > How much to use auto is definitely an area that is open to debate. In this particular instance, I think it makes sense for you to write CP code that "looks like" other CP code, so if that's how they write it in examples, etc. I think it makes sense. Since auto is part of our base-level test for C++11 compliance, so you are guaranteed to have it if that configure test passes. -- John
------------------------------------------------------------------------------
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
