HDF5Output for the logger

[amolchanov86]

Hi guys,
I am currently in need of recording trajectories of experiments, hence, I will add my own hdf5 logger. Hence the feature request to have the capability to log HDF5 files with data in the future.

Justification:
The current params.pkl is not a very convenient way to store trajectories (and other heavy statistics/data) for a few reasons:

• pkl files usually quite large, hdf5 files are more compact
• current params.pkl requires running a session and using joblib. I need more framework-independent storage (for example, you can imagine if I would like to use Matlab later to load trajectories and do some postprocessing for the paper).

[ryanjulian]

Can you provide examples of what you want to send to HDF5?

Params?
Trajectories?
Training progress?

[amolchanov86]

At the moment I am saving trajectories (i.e. "paths").
Btw, I have already written a small, but more or less generic library for saving (and loading from) dictionaries into HDF5, but I haven't wrapped it inside of the logger. I also need a capability to provide a single path for a bunch of experiments to store all paths in a single h5, hence it is kept separate for now.
But I can share this lib if someone is willing to add the feature to the garage.

[amolchanov86]

It is also convenient to store class arguments inside of the HDF5, hence the paths and the parameters that were used to generate them are kept in the same place.
RIght now I am using the following structure inside HDF5 due to the specifics of my project:

# teacher_info/
#   - [teacher_indx]: 
# traj_data/ 
#   - [teacher_indx] * [iter_indx] * traj_data

For example traj_data/0000/0000 refers to data of the first run (teacher) in the first iteration
Where by "teacher" I mean the optimization run. Iteration is just a ppo policy iterations. Teacher info contains parameters associated with the run.

Hope it helps.

[ryanjulian]

@pelillian is rewriting the logger now and it seems like this could be a good addition.

it's meant to be a single frontend with pluggable backends. this could be a great project to see if the plugging system works nicely.

@krzentner might be interested in this issue.