Content Skeleton

This Page

Previous topic

G4DAEView geometry cache

Next topic

G4DAEView Dependencies


Current Solution : NPY

Plumped for NPY (numpy ndarray native serialization)

Alternatives serialization/deserialization to ROOT ?

Ginormous monolithic ROOT dependency, just to be able to deserialize ChromaPhotonList objects.


  1. serialization usable from Geant4 C++
  2. deserialization usable from Python
  3. in future both usable from iOS
  4. efficient handling of millions of photons!

ChromaPhotonList exists for transport alone, so can easily change the format to something else, eg go directly into capnproto structures, from Geant4 C++

Also consider what happens at other end, need to form numpy arrays with the data in order for easy uploading to GPU.


  1. schema evolution, careful versioning


  1. capnproto, improvement on protobuf from former protobuf principal
  2. cereal
  3. google protobuf
  4. boost serialization


Random quote:

It’s extremely performant for C, because its format mimics the layout of C data structures in memory. So for C, the encoding time is zero - just dump the bytes as-is, pretty much.

Hmm, what about byte buffer reinterpretation as numpy array ? (a la MySQL-numpy).

boost serialization

  • can monolithic-ness be avoided ? iOS ?