'model' parameters are not stored in the HDF5 ouput

[fsohn]

Most 'model' parameters are not stored correctly in the HDF5 file in the 'model' section. The values of

/parameters/definitions/model.beta Dataset {SCALAR}
/parameters/definitions/model.command_line_mode Dataset {SCALAR}
/parameters/definitions/model.coulomb_tensor_input_file Dataset {SCALAR}
/parameters/definitions/model.delta_input_file Dataset {SCALAR}
/parameters/definitions/model.hopping_matrix_input_file Dataset {SCALAR}
/parameters/definitions/model.n_tau_hyb Dataset {SCALAR}
/parameters/definitions/model.sites Dataset {SCALAR}
/parameters/definitions/model.spins Dataset {SCALAR}

were either zero or empty, depending on the datatype. I'm not sure about

/parameters/definitions/model.basis_input_file Dataset {SCALAR}

since I don't use it.

[shinaoka]

You may be looking at different locations.
For example, /parameters/dictionary/model.beta contains the actual value.

[fsohn]

Ok, that is true. Is there a reason to have a 'definitions' group as well as a 'dictionary' group? How about setting the correct values in the 'definitions' group and removing the 'dictionary' group, since it is superfluous in that case? That will clean up the output file. Backwards compatibility will be broken though...

[galexv]

The reason of having 'definitions' group is that it keeps part of the state of parameter object. Essentially, the content of the archive file is a result of serialization of parameters object, so it also contains some book-keeping info.

I am working now on a new version of parameters (where i intend to break the backward compatibility anyway) and i will see how we can make the archive file cleaner.

[shinaoka]

yeah, this is one of reasons why I want to publish "official" Python bindings of ALPSCore. It will allow users to read data from a HDF5 file without knowing the underlying data format.

[dombrno]

I am not so convinced about the usefulness of python bindings. It is good for pedagogical purposes, but I imagine that most users develop their own code for the self-consistent loop. Most likely, this code is not written in Python, hence the best option for them is to access the h5 file directly, from whatever language they use, most likely C, C++, Fortran. For what it's worth, I have never used any of these bindings in the matrix or the segment code (including the Alps 2.0 version, which offered some), except for running some tutorials, and even then, it is not that easy to get the python setup to work. It is already sometimes a not so easy matter to get the compilation and execution in a compiled language to run, but setting up a python environment on top of it is a pain I find not worth the effort.

In a nutshell, I would say that the level of expertise that is required to use this kind of code is such that it makes "black box interfaces" like python bindings not very useful. But that is only my personal experience of course.

[shinaoka]

Thank you for the comment.
Yes, I agree that setting python environment is kind of pain (even for me).
But, once it is already constructed properly in a local cluster,
such environment may be very useful (e.g. for undergraduate students).

Regarding the CT-HYB code,
the current interface based on text and hdf5 files will remain the main interface.
I do not want to introduce a mandatory dependency on Python.