Profile the disaggregation hazard calculator

[Lars Butler]

Profile the disaggregation hazard calculator to analyze:

- computation
- I/O
- storage (particularly for the database)

For this profiling activity, all software versions, config files, and logs should be attached this bug as they become available.

The desired outcomes of this activity are:
1. Clearly identified performance bottlenecks or storage issues
2. Suggested solutions

[Lars Butler (lars-butler)]

Baseline versions:
https://github.com/gem/oq-engine/tree/7069e11851bcc1944ba97d1a257eded384277bbe
https://github.com/gem/oq-risklib/tree/5ae95cab3a74642e35113a2d05c736555a5ae8b7
https://github.com/gem/oq-nrmllib/tree/d9d3f18a64a16438d700fbc8ac2f7ef1ffb04894
https://github.com/gem/oq-hazardlib/tree/47101d32ceaed9ec9ca3215abd0ed6ad5a2c211b

[Lars Butler (lars-butler)]

Corrected baseline for oq-engine:
https://github.com/gem/oq-engine/tree/4233f5bc195a3a2ba4c2c544e9593f90c51be5b7

[Lars Butler (lars-butler)]

Test files: A simplified version of the California hazard map. I removed many of the sources and adjusted the region resolution so that the model could be run in a number of hours on a single processor.

[Lars Butler (lars-butler)]

The profiling job was run with the following parameters:

$ python -m cProfile -s time bin/openquake --rh=profile_jobs/cali/job.ini --log-file=cali.log --nd --exports=xml >> cali.prof

[Lars Butler (lars-butler)]

Log file

[Lars Butler (lars-butler)]

Profiling report

[Lars Butler (lars-butler)]

Test analysis:

- Nothing noteworthy terms of DB storage space. With this one job, the DB size grew to just over 20MB.
- A total of 145 XML files were exported. This includes 1 hazard curve file and 144 disagg. matrix files. Total export time was about 15 seconds, which is just fine.
- Most of the time was spent doing "number crunching". Unlike the classical hazard calculator, only a very small fraction of the computation time was spent interacting with the database.
- The profiling report indicates that the majority of the time was spent doing the core disaggregation calculation.
- Secondary to this were various geometric calculation calls required for the calculation.

At this point, I see no pressing need to optimize anything.