Memory Efficiency of the freezeout

[nilssass]

I recently found out that a large fraction of the size of the freezeout.dat is caused by storing white spaces. In my own case, I started with a freezeout.dat of 128MB.

Afterwards I removed all but one white spaces to separate the columns. Removing the white spaces resulted in a freezeout of 59MB which means a reduction of $\sim$ 54% without losing any physical information. As a consequence I recommend the following points:

• Getting rid of leading white spaces at the start of each line as they are unnecessary
• Reducing the precision from 15 to 10 digits precision. I doubt that a 15 digits precision is really needed
• Instead of using setw(24) one could use a single white space separation if it is not strongly needed that the columns are aligned for readability. The freezeout anyhow is too large to be readable. If readability is still needed, then setw(24) should at least be reduced to setw(16)

With these recommendations we could save roughly up to 60% memory for each freezeout surface file.

[yukarpenko]

Thanks for looking into this Nils! Yes indeed, I do not clearly remember anymore why I printed the numbers with 15-digit precision. It might be that at the LHC energy, where the velocities are up to ~0.999 longitudinally, there may have been some energy skew basically because of this. I usually don't print the output with such precision.
So, let me make the fixes you've suggested.

[nilssass]

One further suggestion: if you want full control over the precision, you could set it to a 8 digit precision as default and introduce a key in the config to increase it if needed in some cases. Like this you have a memory efficient but still precise default and the user can decide whether to ask for even higher precision.

Speaking about the output, maybe even one further point before opening a new issue. I think it would be very helpful to introduce a header line that tells a user which quantity is printed to which column and with what unit, something like

#  𝜏    x    y    η   dΣ[0]   dΣ[1]   dΣ[2]   dΣ[3]   u[0]   u[1]  ...
# fm/c fm   fm  ...

I am getting confused with the columns myself quite oftenly and then I need to look it up in the source code to check which column corresponds to which quantity. The fact that the sampler needs to skip these lines while reading is a minor fix and I can do that.