Advanced Features#
This section is for advanced users, i.e. people who already know how to use the engine and are already familiar with the basic features of the OpenQuake engine calculator. If you have just started on your journey of using and working with the OpenQuake engine, this section is probably NOT for you. Beginners should study the previous sections first.
This section is intended for users who are either running large calculations or those who are interested in programatically interacting with the datastore.
Here, a calculation is considered large if it cannot be run, i.e. if it runs out of memory, it fails with strange errors or it just takes too long to complete.
There are various reasons why a calculation can be too large. 90% of the times it is because the user is making some mistakes and is trying to run a calculation larger than really needed. In the remaining 10% of the times, the calculation is genuinely large and the solution is to buy a larger machine, or to ask the OpenQuake engine developers to optimize the engine for the specific calculation that is giving issues.
The first things to do when you have a large calculation is to run the command oq info --report job.ini, that will
tell you essential information to estimate the size of the full calculation, in particular the number of hazard sites,
the number of ruptures, the number of assets and the most relevant parameters you are using. If generating the report
is slow, it means that there is something wrong with your calculation and you will never be able to run it completely
unless you reduce it.
The single most important parameter in the report is the number of effective ruptures, i.e. the number of ruptures after distance and magnitude filtering. For instance your report could contain numbers like the following:
#eff_ruptures 239,556
#tot_ruptures 8,454,592
This is an example of a computation which is potentially large - there are over 8 million ruptures generated by the model - but that in practice will be very fast, since 97% of the ruptures will be filtered away. The report gives a conservative estimate, in reality even more ruptures will be discarded.
It is very common to have an unhappy combinations of parameters in the job.ini file, like discretization parameters
that are too small. Then your source model with contain millions and millions of ruptures and the computation will
become impossibly slow or it will run out of memory. By playing with the parameters and producing various reports,
one can get an idea of how much a calculation can be reduced even before running it.
It is a good idea to read the section about Common mistakes.