The problem is now fixed. You should be able to download the documentation at the following link
You received this message because you are subscribed to the Google Groups "OpenQuake Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openquake-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openquake-users/09ad982c-8eb8-44ba-b02d-adac8e6a0b03n%40googlegroups.com.
I can see the problem with handling all those files! I was lucky enough to have only 54 realizations (thus 432=54*8 csv files) for 4 POE, which I later post-processed. The way I handled the files, though, was a bit lame, meaning that I performed the analyses one POE at a time, such that I had the results in separate folders. I am unfamiliar with the HDF5 format, but for the csv format I agree that maybe some results could be joined together, but not necessarily per column. For instance, since the POE are usually limited (maybe corresponding to return periods of 2500, 1460, 75, 50 years and so on) you could separate those results per sheet. If only one POE is used, then the csv would have one sheet, and so on. This way, considering the example you illustrated you would have 70000/5 = 14000 files, which is still a huge number, but more manageable. If the number of sites and disaggregation types needed by the user are also low, then this sheet methodology could be also used, but it would fail otherwise, as you would have a csv file with N*P*t sheets (where t is the number of disaggregation types you need). On the other hand, if you have M>P, so more IMTs than POEs, you would have 70000/10 = 7000 files each one with 10 sheets, for M=10.
I do not know if it is possible and how intuitive might be, but maybe the user could have the option to decide how to join the results. In my case, it would have been great to have the results of different POEs in different sheets. Another user maybe would find it more interesting to join them for site (e.g. they only have 1 POE).
I think that a couple of csv files containing the information of ALL the results might be confusing, unless the columns are really well organized. In addition, there is the parsing problem you mentioned.
However, if the mean disaggregation is done internally, there would be no need at all to export all the realizations, unless for verification problems. As it is now, I think is a good compromise, as you divide the total number by R.
Thanks Marco for fixing the link, I have successfully downloaded the document.I realise now from reading your responses, that my question above has confused two aspects related to the disaggregation.1) The way OpenQuake provides disaggregation output. Yes I have also read Damiano Monelli's post to calculate the traditional % contribution. The mean magnitude and distance (or mode) can be determined from this output, per B&C99. As Gianluca advises, this conversion is described in mathematical notation in the hazard science document.2) However, my current issue I am trying to understand/ resolve is that when a GMPE logic tree is adopted, OpenQuake does not calculate the disaggregation from the mean (or some fractal such as the median) hazard curve, but the hazard curve of the realisation closest to the mean. For a non-trivial logic tree (e.g. adopting 3x GMPE for each TRT: shallow crustal, s. slab, s. int) it will not be clear which realisation (i.e. which branch of the logic tree) is selected as being 'closest to the mean', for performing the disaggregation, or how the disaggregation should be calculated (i.e. different GMPE will result in different % contributions, and different epsilon values for the same mean hazard curve - they need to be weighted appropriately to obtain the mean).I presume that one could extract disaggregation data from each realisation (potentially many results for complex logic trees!) and manually calculate weighted contributions for each M, R, epsilon bin across all realisations. It's a bit laborious to do this, and it would be good if there were an option for the OpenQuake engine to provide the option to deliver this output - perhaps a wish list for now. I need to think and learn how I can combine the available disaggregation outputs, e.g. (M, Lat, Lon) & (TRT, Lat, Lon) across all realisations to obtain sufficient information to calculate the required M, R, epsilon statistics where a complex GMPE logic tree is employed.