In part I of the blog I covered installing GeoNode onto Ubuntu 10.10 server and adding a client application. Part II covers using Django-schemata/South in the context of GeoNode and adding multiple Django applications to GeoNode.

Step 3: Adding a Django a Application

If you also have a Django application that you would like to integrate there are just a few steps needed.

First place a copy of the application somewhere on your server or local machine and then create a symlink of your Django application in /var/lib/geonode/src/GeoNodePy/geonode with a comment like:

ln -s /location/of/Django_app/ /var/lib/geonode/src/GeoNodePy/geonode/Django_app

Then let GeoNode know that there is a new Django application by editing the client build.xml

<property name="app.proxy.MYDJANGOAPP" value="http://localhost/MYDJANGOAPP/"/>

Next add your Django application to INSTALLED_APPS in /var/lib/geonode/src/GeoNodePy/geonode/settings.py:

INSTALLED_APPS = (
    'geonode.YOURDJANGOAPP',
    ....
)

You will then need to restart tomcat, apache, and postgres.

How are you feeling? Everything ok?  At this point you should be able to view your application at the IP address you used above or localhost.

For my application it does not end here, there’s more… I need GeoNode to handel database schema migrations. I will be adjusting tables and views frequently. I also need my geometry columns to be properly registered within geometry_columns in the database.

Django south and Django Schemata are a solution. This allows one to migrate database changes, it allows one to use multiple database schemas, and it registers the geometry columns.

Step 4: Adding a Django-Schemata & South

Install Django South. * note you need to install south from inside your GeoNode virtual environment, to do so run:

 source /var/lib/geonode/bin/activate

and then:

pip install South

You need to clone the Django-schemata github repository to your GeoNode server and the make a symlink to django_schemata/ directory from /var/lib/geonode/src/GeoNodePy/geonode

Now you’ve installed South system-wide, you’ll need to configure Django to use it. Doing so is simple; just edit your settings.pyand add to the end of INSTALLED_APPS:

'south'

and

'django_schemata'

Also in settings.py add to MIDDLEWARE_CLASSES:

'django_schemata.middleware.SchemataMiddleware'

In local_settings.py I have the following settings for the DATABASE:

DATABASES = {
      'default': {
            'ENGINE': 'django_schemata.postgresql_backend',
            'NAME': DATABASE_NAME,
            'USER': DATABASE_USER,
            'PASSWORD': DATABASE_PASSWORD,
            'HOST': DATABASE_HOST,
            'PORT': DATABASE_PORT,
        }
    }

Also add to local_settings.py:

SOUTH_DATABASE_ADAPTERS = {
   'default': 'south.db.postgresql_psycopg2',
}

To test and see if Django-Schemata and South are running correctly, and to set up your domains please refer to the schemata management commands
For more information:

At this point I am going to pass you along to other resources. You can find more information about GeoNode’s plans to use these tools here. You can learn more about how to setup and use Django-Schemat here at the project’s GitHub project repository, and in a nice blog written my colleague: PostgreSql schema support, PostGIS and Django. At this point I apologies for the limited documentation on the topic as we have been limited on time, here you can see some information about what was done on our specific application.

In summary you need to install Django South

Step 5: Adding multiple Django applications to GeoNode

With all of this in place you can now merge multiple Django application into one GeoNode environment, each one managing it’s own perspective database schema, while conglomerating all the required geometry columns into the public geometry_columns table.

First create a new Django app from your root Django project directory using django south with:

sudo python ./manage.py startapp YOURNEWDJANGOAPP

Add the new Django app to INSTALLED APPS in settings.py as we did above in step 3.

Then add the application to SCHEMATA_DOMAINS in /var/lib/geonode/src/GeoNodePy/geonode/local_settings.py this should look something like this:

SCHEMATA_DOMAINS = {
    '178.79.183.128': {
        'schema_name': 'gem',
    },
    '178.79.185.195': {
        'schema_name': 'ged',
    },
    'django': {
        'schema_name': 'public',
    },
}

Now add the symlink for the new Django application in /var/lib/geonode/src/GeoNodePy/geonode/

then run (within your GeoNode virtual environment) in /var/lib/geonode/src/GeoNodePy/geonode:

python ./manage.py schemamigration YOURNEWAPPIP --initial

export DJANGO_SCHEMATA_DOMAIN=YOURNEWAPPIP

python ./manage.py migrate_schemata YOURNEWAPPNAME # add "--fake" depending on weather sync db has been used

If you have made it this far, congrats! You should now have fully functioning GeoNode that has multiple Django applications, all of which are maintaining their perspective database schemas.

Hope this helps and happy GeoNoding

It’s important to stress though that OpenQuake is still alpha software; it is not complete. However in recent months OpenQuake has reached a point where it is starting to offer some early adopters through OATS accounts a view to the capabilities that are being developed within the tool.

Another noteworthy item to mention is the release of the OpenQuake book

Below is a list of items that have been worked on in this release of OpenQuake.

OQ 0.4.5 bugs

Critical Priority
Oenquake error on gemsuns cluster – long calculation
Ubuntu packages for libjhdf4-java+libjhdf5-java and h5py are conflicting and causing weird crashes
Some GMPEs in OpenSHA-lite are not available from OpenQuake
Make IA and RSD valid parameters for INTENSITY_MEASURE_TYPE
Mean hazard curves are calculated even if COMPUTE_MEAN_HAZARD_CURVE = false
Error when using intensity_measure_type = RSD
Our software provides no reliable indication of progress
Rename the risk deterministic event-based calculator

High Priority
FE tool – Django API to join features (Part I)
Add disaggregation calculator mixin class
Add celery task for disaggregation matrix computation
FE tool – python fault source computation
Blackbox test(s) for Disaggregation calculator
Write Disaggregation NRML/XML
Celery comes to a halt after approx. 8500 tasks
Add NFS ‘base_dir’ to openquake.cfg
Disagg calculator is missing two site params
Disaggregation calculator does not sample inside of the logic tree sample loop
UHS core calculator (Java)
Create sample UHS ‘demo’ files
UHS additions to job & params DB tables, object models, param definitions
UHS config param validation
Benefit-cost ratio calculator blueprint review
FE tool – generate a fault source polygon
Celery task queues are not deleted
upgrade to kombu-1.4.3 breaks supervisor
Use @task(ignore_result=True) for all hazard tasks
We need to interleave curve computation and serialization
Circular import in java.py and utils/__init__.py

Medium Priority
FE tool – Django API to join features (part II)
FE tool – fault section join API client integration
FE tool – fault join API client integration
FE tool – fault source polygon
FE tool – enable clickablefeatures pluging for trace layer
Revisit binary disaggregation matrix result structure
Job config param enhancements
Use one form for disaggregation result types
FE tool – add scale bar to the UI
FE tool – generate sample shapefiles for the uploader
Extract_subsets() is the only task function without job_id
FE tool – The FE tool needs a fault source trace table to house the simplified fault source mulilinestring
Update rabbitmq-server and python-celery on the gemsun cluster
Progress indicator counters must be reset at job start time
Simplify clonky utils.task code
Execute() and release_curve_data_from_kvs() should not return kvs key purged in production
HAZARD_BLOCK_SIZE should move from config.gem to openquake.cfg
Release_curve_data_from_kvs() lacks a test
Broken kvs purge tests (jenkins failure)
FE tool – fix feature editor on the trace layer
FE tool – test the trace and site-observation shapefile uploader
FE tool – refresh trace layer when new features are added
FE tool – style line types
FE tool – create a new server and deploy a GeoNode for the tool
FE tool – change the order of the accordion
FE tool – migrate project to FE domain

OQ 0.4.6 bugs

Critical Priority
Replace the attribute VFReference for Taxonomy in vulnerability and exposure model
Openquake error on gemsuns cluster – long calculation
Ubuntu packages for libjhdf4-java+libjhdf5-java and h5py are conflicting and causing weird crashes
Some GMPEs in OpenSHA-lite are not available from OpenQuake
Make IA and RSD valid parameters for INTENSITY_MEASURE_TYPE
Mean hazard curves are calculated even if COMPUTE_MEAN_HAZARD_CURVE = false
Error when using intensity_measure_type = RSD
Our software provides no reliable indication of progress
Rename the risk deterministic event-based calculator

High Priority
FE tool – Django API to join features (Part I)
Add disaggregation calculator mixin class
Add celery task for disaggregation matrix computation
FE tool – python fault source computation
Blackbox test(s) for Disaggregation calculator
Write Disaggregation NRML/XML
Celery comes to a halt after approx. 8500 tasks
Add NFS ‘base_dir’ to openquake.cfg
Disagg calculator is missing two site params
Disaggregation calculator does not sample inside of the logic tree sample loop
UHS core calculator (Java)
Create sample UHS ‘demo’ files
UHS additions to job & params DB tables, object models, param definitions
UHS config param validation
Benefit-cost ratio calculator blueprint review
FE tool – generate a fault source polygon
Celery task queues are not deleted
Upgrade to kombu-1.4.3 breaks supervisor
Use @task(ignore_result=True) for all hazard tasks
We need to interleave curve computation and serialization
Circular import in java.py and utils/__init__.py
Package celery-2.4
Package kombu-1.4.3
python-oq is missing the python-h5py dependency
The broken demos need to be excluded from the 0.4.6 python
Packagepostinst fails to change permissions for /var/lib/openquake in python-oq

Medium Priority
FE tool – Django API to join features (part II)
FE tool – fault section join API client integration
FE tool – fault join API client integration
FE tool – fault source polygon
FE tool – enable clickablefeatures pluging for trace layer
Revisit binary disaggregation matrix result structure
Job config param enhancements
Use one form for disaggregation result types
FE tool – add scale bar to the UI
FE tool – generate sample shapefiles for the uploader
Extract_subsets() is the only task function without job_id
FE tool – The FE tool needs a fault source trace table to house the simplified fault source mulilinestring
Update rabbitmq-server and python-celery on the gemsun cluster
Progress indicator counters must be reset at job start time
Simplify clonky utils.task code
Execute() and release_curve_data_from_kvs() should not return kvs key purged in production
HAZARD_BLOCK_SIZE should move from config.gem to openquake.cfg
Release_curve_data_from_kvs() lacks a test
Broken kvs purge tests (jenkins failure)
FE tool – fix feature editor on the trace layer
FE tool – test the trace and site-observation shapefile uploader
FE tool – refresh trace layer when new features are added
FE tool – style line types
FE tool – create a new server and deploy a GeoNode for the tool
FE tool – change the order of the accordion
FE tool – migrate project to FE domain
Package the 0.4.6 rev of openshalite
Package the 0.4.6 rev of openquake (python)
Package the 0.4.6 rev of openquake (java)
Create /var/lib/openquake if needed

#!/bin/bash

if [ $# > 1 ]; then

adduser $1

pushd /usr/openquake
mkdir $1

cp -r /usr/openquake/openquake1/demos_12_10_11/ /usr/openquake/$1/demos_12_10_11/

chown $1: /usr/openquake/$1 -R

chmod 750 /home/$1

chmod 750 /usr/openquake/$1

echo "@$1   hard limit    maxlogins    1" >> /etc/security/limits.conf
fi

As you can see, each new user account is given a copy of the demos folder that contains sample models to run through OpenQuake. The script also sets user permissions, and session log-in limits.
Each user can then ssh into the server, run, manipulate demos and explore results. Users can also interface with input files and results via a sftp desktop applications.
We also setup a Google form that captures requests for accounts into a Google spreadsheet, so then I am notified by email every time someone requests an account. And we also made a users guide for the service.

Anyway, it’s just another use of the Cloud.

Version 0.1 of the OpenQuake Manual has been published today. This manual provides users of OpenQuake the knowledge to configure OpenQuake, build input models for both Hazard and Risk and understand the various outputs. The manual provides step by step instruction on how to build an Input model with descriptions for each of the parameters. We plan to continue to update the manual over the coming weeks and months as the features set continues to expand.

The Manual is being drafted using the same open source practices as the source code of OpenQuake, i.e. using a distributed version control system on GitHub, where all the latex files are openly available. This allows the various contributors and authors of the manual to work together on the manual, without need to continuously exchange Word documents. Git then assures that all contributions are properly merged. We hope that in the near future, when other scientists and developers contribute to the source code of OpenQuake, they will also contribute to keeping the OpenQuake Manual up-to-date.

Download version 0.1 of the OpenQuake User Manual now.

I recently installed GeoNode and integrated an application into it and thought I would share some notes on the process.
By the end of the guide you should have a fully functioning GeoNode installed including multiple client and Django application locally or on a server.

Step 1: Install GeoNode onto Ubuntu 10.10 server

Before installing GeoNode, there was one dependency that was not included in the GeoNode package that added some python packages, to meet this requirement I first I ran:

sudo apt-get install python-software-properties

Installing GeoNode: OpenGeo has made great progress in recent months with the process of installing GeoNode, and now you can simply follow the three commands here to install GeoNode to your local machine or to a server.

Once GoeNode is installed please follow the required and recommended settings as needed on the Configuring GeoNode for Production.

Check that your GeoNode is working by opening your browser to http://YOURIPADDRESS, you should see the GeoNode welcome page.

Now that you have a working GeoNode it is likely that you are going to want to integrate an application into it. If you do not already have an application, a good place to start is with the readygxp which has been set up specifically to provide a simple reusable template for GeoExt/GXP applications bound for a servlet container.

Step 2: Adding a Client Application
Now for the nuts and bolts of this guide, integrating the client application into GeoNode.
If you have deployed GeoNode locally or on a server and if you have your own application or have used the readygxp this guide should help get it all set up.

I would recommend to place a copy of the client application onto the server or local machine. Then you will need to prepare your client application by setting up the application build.xml to reflect the new GeoNode IP address and project name. This is done by navigating to the root directory of the client application and editing the build.xml, your setting should look like:

<property name="app.proxy.geoserver" value="http://localhost/geoserver/"/>

You will need to create a .war file of your application, lets pretend it’s called application.war. From your client root directory run (don’t forget to first run git submodule init and git submodule update if needed and ant init (just the first time after cloning the application from github)):

ant static-war

Now copy the application.war to your GeoNode /var/lib/tomcat6/webapps path.

Next add the correct IP address to the /var/lib/geonode/src/GeoNodePy/geonode/local_settings.py:

 SITEURL = YOURIPADDRESS

If you have a SCHEMATA_DOMAINS defined in your local_settings.py, then you will also have to change it’s IP address

You will also need to add the project IP to /var/lib/tomcat6/webapps/geoserver/WEB-INF/web.xml:

GEONODE_BASE_URL

Add proxies for application in /etc/apache2/sites-available/geonode it should look something like this:

ProxyPass /YourApplication http://localhost:8080/YourApplication
ProxyPassReverse /YourApplication http://localhost:8080/YourApplication

**NOTE you also need to add a path to your additional applications to the first line of /etc/apache2/sites-available/geonode so that the customized applications can be found, in my case the path looks like this:

:/var/lib/geonode/src/GeoNodePy/geonode/

Add the ip address to /var/lib/geoserver/geonode-data/gs-data/printing/config.yaml under # the list of allowed hosts:

- !dnsMatch host: YOUIPADDRESS port: 80

If you use PGAdmin to view or manage your database and your GeoNode installation is on a remote server, optionally you can allow postgress to be accessed via ssh by adding ‘trust’ to /etc/postgresql/8.4/main/pg_hba.conf and restart postgres, my settings looked like this:

local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust

once this is done you can view the database via PGAdmin with this ssh string:

ssh -L5433:127.0.0.1:5432 user@YOUIPADDRESS

Then open PGAdmin and change the port to 5433

One more thing to note… when adding or removing layers in GeoServer, GeoNode is not aware of these changes. To make GeoNode aware of layer changes navigate to /var/lib/geonode/ directory you need to run:

source bin/activate

then:

django-admin.py updatelayers --settings=geonode.settings

If this command fails then if could be that you need to increase the time-out time in:
/var/lib/tomcat6/webapps/geoserver-geonode-dev/WEB-INF/classes/applicationSecurityContext.xml
This completes part I of this topic, please check out part II which covers:

• Adding a Django a Application
• Adding a Django-Schemata & South
• Adding multiple Django applications to GeoNode

A significant addition to the schema for storing loss maps produced from the probabilistic event-based and classical PSHA-based risk calculators has been made. Since many assets might exist at the same location, it is necessary to store many asset instances in the same site. This means, a loss map can have many sites, and each site can have many assets. For each asset only two parameters are required: a loss value (absolute value of the loss) and the asset reference (the asset id from the exposure model).

This OpenQuake release also includes 14 new GMPEs (Ground Motion Prediction Equations).

A number of GMPEs (8) (implemented by Laurentiu Danciu, ETH Zurich, Switzerland) have been ported in the OpenSHA-lite codebase for the SHARE (http://www.share-eu.org/) project:

• Atkinson and Boore 2003 (for PGA, SA)
• Akkar and Bommer 2010 (for PGA, PGV, SA)
• Cauzzi and Faccioli 2008 (for PGA, PGV, SA)
• Campbell 2003 (for PGA, SA) (a version specific for the SHARE project has been also developed (Campbell_2003_SHARE) which is corrected for a Vs30=800 m/s and takes into account faulting style)
• Lin and Lee 2008 (for PGA, SA)
• Toro et al 2002 (a version specific for the SHARE project has been also developed (ToroEtAl_2002_SHARE) which is corrected for a Vs30=800 m/s and takes into account faulting style)
• Youngs et al 1997 (for PGA, SA)
• Zhao et al 2006 (for PGA, SA)

A number of GMPEs (6) (Implemented by John Douglas, BRGM Orlean, France) developed for Relative Significant Duration and Arias Intensity have been ported in the OpenSHA-lite codebase for the PERPETUATE (http://www.perpetuate.eu/) project:

• Abrahamson and Silva 1996, (for Relative Significant Duration)
• Bommer et al 2009, (for Relative Significan Duration)
• Foulser-Piggot and Stafford 2011 (for Arias Intensity)
• Kempton and Stewart 2006 (for Relative Significant Duration)
• Stafford et al. 2009 (for Arias Intensity)
• TravasarouEtAl 2003 (for Arias Intensity)

The code of the implemented GMPEs can be viewed at the following link: https://github.com/gem/OpenSHA/tree/master/java/org/opensha/sha/imr/attenRelImpl. Even if present in the OpenSHA-lite codebase, the GMPEs for Relative Significant Duration and Arias Intensity cannot be yet used by OpenQuake as some adaptions in the configuration file are required and they will be probably available in the next OQ release.

Also, a number of critical bugs have also been resolved with this new release (see list below), which has led to a much more stable performance of the risk calculators.

As usual, please report any bugs or errors to the developers mailing list or just come and say hello and maybe even share a story about your work and what you’ve done with OpenQuake. We’d love to hear from you.

Features for 0.4.4 release:

• Validation on all job parameters
• 10 new GMPEs
• Design output/export format for PMFs in preparation for desegregation calculation

Version 0.1 of the OpenQuake Book has been published today. This book aims to provide users of OpenQuake with a detailed description of the theoretical background of the algorithms used in the various hazard and risk calculators of OpenQuake, including a description of where OpenQuake relies on the source code of other projects such as OpenSHA. A distinction between the features that are currently supported and those that are on the road map for OpenQuake is also included. We plan to continue to update the book over the coming weeks and months.

The Book is being drafted using the same open source practices as the source code of OpenQuake, i.e. using a distributed version control system on GitHub, where all the latex files are openly available. This allows the various contributors and authors of the book to work contemporaneously on the Book, without needing to send back and forth Word documents, and Git makes sure that all contributions are properly merged. We hope that in the near future, when other scientists will contribute algorithms to the source code of OpenQuake, they will also contribute to keeping the OpenQuake Book up-to-date.

OpenQuake release 0.4.3 is loaded with new features and improvements and is the result of a very productive four week sprint!

As we reflect on this milestone, we should remember that OpenQuake is everyone’s project. Whether you are new to the project and report a bug or are a developer contributing code, you are part of a large and thriving community. Your work, and your funding, helps improve the software.

So the next time someone asks why one would pay for ‘free’ software, take a look at the list below. OpenQuake is yours—and your collaboration, contributions and funding makes it happen, thats something to be proud of.

Don’t forget to apply for an OpenQuake Alpha Testing Service (OATS) account to give OpenQuake a test drive.

Features for 0.4.3 release:

• Engine can now perform computations on a set of sites
• All OQ logs are linked to their respective job
• Risk exposure importer from NRML to Database
• New demos for testing out OpenQuake

OQ 0.4.3 bugs

Critical Priority

• aggregate in probabilistic still reads from kvs

High Priority

• We need to profile/optimise the risk calculator
• Make the engine capable to collect the correct sites to compute
• Tests using python-mock are brittle
• Provide function to initialise RabbitMQ backend for OQ signalling
• A RabbitMQ backend implementation for python logging is needed
• A message consumer process code template is needed
• All OQ log records must be linked to job in question
• Supervisors must detect and document failed OQ jobs
• Each OQ job must start its supervisor process
• Supervisors must detect and document succeeded OQ jobs
• Crashed supervisors must be respawned
• Make the job id available in the java code base
• A RabbitMQ backend implementation for java logging is needed
• How do we test the python RabbitMQ logging backend?
• How do we test the Java RabbitMQ logging backend?
• Risk exposure Importer from nrml to db needed
• Fix the KVS keys to use again the job_id marker
• Provide a celery task init() function
• black box test failure in master
• Revise db users and django/ORM router logic
• Fix job set-up code and helper methods to use Django ORM
• Fix classical PSHA smoke test
• Out of Memory

Medium Priority

• The OQ logging sink needs to start at every system (re)start
• Package the openquake 0.4.3 release
• Clean up database users in 0.4.3 package
• Remove stdout log capture
• Complete OQ log records need to be stored in central place
• Add an ‘error_msg’ table to the schema
• Model the aggregate loss curves db fragment
• Installation of python-oq fails if openquake was already installed manually
• Convert existing SQLAlchemy models to Django models
• Complete the model code representation of the OQ database
• Don’t store the site in the hazard curves serialized in the KVS
• Make db revision step numbers global
• Discrepancy in the number of tests runs
• tests/tools_dbmaint_unittest.py test problems
• Bitrot in test suite
• openquake –version info should use UTC time
• OpenQuake credentials management
• OpenQuake credentials management
• Implement bulk insert using Django
• Add Django and GeoDjango as OQ package dependencies
• Add Django model class for collapse maps
• package python-ampqlib rev. 1.0.0
• package python-kombu rev. 1.2.1
• package python-celery rev. 2.3.1
• python-dateutil fails to build
• python-celery fails to build
• Capture job completion time
• Add job_stats table to db
• Capture job start time and number of sites when a job is launched
• Move the “from openquake import job” line to the bottom

Low Priority

• openquake.kvs.reader is unused and can be deleted
• Engine shouldn’t print output file names which don’t exist
• Merge ‘tests’ and ‘db_tests’
• hzrdr.hazard_curve_data should really be called hzrdr.hazard_curve
• Cleanup the access to the job id in the python code base
• Align upgraded database with a freshly-created one
• Un-skip test_compute_risk_in_the_classical_psha_mixin
• AMQPLogSetupTestCase.test_log_configuration should *not* test ordering
• amqp routing keys should be lowercase
• Simplify model loaders
• Use the OQ DB as the input for the risk calculations
• Model the BCR distribution db fragment
• Model the collapse map db fragment
• Re-write SourceModelLoader with Django ORM
• Re-write HazardMapDBReader with Django ORM
• Re-write HazardMapDBWriter with Django ORM
• Re-write HazardCurveDBReader with Django ORM
• Re-write HazardCurveDBWriter with Django ORM
• Re-write LossMapDBReader with Django ORM
• Re-write LossMapDBWriter with Django ORM
• Re-write LossCurveDBReader with Django ORM
• Re-write LossCurveDBWriter with Django ORM
• Re-write CsvModelLoader with Django ORM
• junit test org.gem.log.AMQPAppenderTest fails
• Implement job supervisor
• Add a ‘supervisor_pid’ to the ‘oq_job’ table
• Re-write GMFDBReader with Django ORM
• Re-write GMFDBWriter with Django ORM
• Re-write test set-up code with Django ORM
• Remove SQLAlchemy writer common code
• Fix risk calculators to use Django ORM
• SQLAlchemy final cleanup
• alpha testing service blueprint review

Wish List

• We should get rid of the python-guppy package dependency
• Package the python-pika RabbitMQ bindings

Features for 0.4.2 release:

• Optimization of the computation of the aggregate loss curve when running Probablistic Risk computations
• DB serialization is now default, so you need –output_type=xml to produce XML output
• Computation fails cleanly when there is a Java exception in a Celery task
• Optimization of classical PSHA hazard jobs
• Optimization of hazard curve KVS storage
• All OQ results are now stored in the postgres database
• Celery worker sends result message
• Fixed redundant loss curve computation
• Speed improvement to calculation of mean hazard curves
• Hazard curves are stored more efficiently
• OQ job status is capable of reporting failure from database
• Database schema license has been updated
• Celery automatic startup script

OQ 0.4.2 bug list

Critical

• Celery worker fails to send result message

High

• Error in classical risk computation
• Each OQ job needs to have a record in the postgres database
• All OQ results must be stored in the postgres database
• Model the risk exposure db fragement
• Model the risk vulnerability db fragment
• Redundant loss curve computation
• Supervision of OQ jobs blueprint review
• [JREDIS] – PROBLEM: serviceRequest() — ClientRuntimeException => in.read returned -1
• Calculation of mean hazard curves is too slow
• Hazard curves need to be stored more efficiently
• We need to have a single-rooted source code tree
• Move the xml schema files into the openquake src tree
• Handle database upgrades across versions
• openquake executable doesn’t run without a celeryconfig.py file
• The status of a job is not set to ‘failed’ when the failure is on the database
• Packaged version 0.4.1 of openquake can’t find cache_gc.py

Medium

• Package the RabbitMQ AMQP Java client library
• Change license in databases schemas
• We should add automatic startup scripts for celeryd
• tools/dbmaint.py must terminate with non-zero exit code in case of a failure
• Clean up database name spaces and users
• We need a method for capturing stacktraces from Java
• Refactor CsvModelLoader tests
• The various get_*_*_session() functions need default users
• oq_job.status remains ‘pending’ despite job completion
• The name of the default db should be ‘openquake’
• The oqmif.exposure_model table needs an owner
• oqmif.exposure_model.site needs an index
• Code relocation broke tools/dbmaint.py
• Exception when comparing Java sites
• oqmif.exposure_data needs a FK to riski.vulnerability_model

Low

• errors while running bin/create_oq_schema are easy to miss
• log4j.properties needs to live in the openquake source code tree
• Remove GEM1ERF class from OpenQuake java codebase
• celeryd startup scripts