Modelr is a web application for seismic forward modelling. The tool is hybrid approach of open core (like OpendTect, which has proprietary add-ons) and software-as-a-service (like WordPress.org vs WordPress.com).
Open source back end
We believe scientific software should be open source. The open core of Modelr is a Python web app for producing synthetic seismic models, in much the same way that the now-deprecated Google Image Charts API used to work: the user provides a URL, which contains all the relevant data, and a JPEG image is returned. Along with the image, we return some computed data about the model, such as the elastic properties of the rocks involved. The mode of the tool is described by ‘scripts’, which for now reside on the server, but which we plan to allow users to provide as part of the API. Scripts have various parameters, such as the P-wave and S-wave velocities, and the bulk density of the rocks in the model, and it is these parameters that make up most of the data in the API call. Other parameters include the type and frequency of wavelet to use, and the computation method for the reflectivity (for example the Zoeppritz equations, or the Aki–Richards approximation). The app has no user interface to speak of, on ly a web API. It is licensed under the Apache 2 license and can be found on GitHub. We are running an instance of our app on a T1.micro Amazon EC2 instance running Ubuntu.
Proprietary front end
The commercial, proprietary front end is a Python web app that lives in the Google App Engine walled garden. This app, which uses the Twitter Bootstrap framework, is serving at modelr.io and provides a user object in which a geoscientist can save rocks and scenarios — consisting of a script and all its parameters. We chose App Engine for its strong infrastructure, good track record, and the easy availability of tools like the datastore, memcache, login, and so on. We also host support channels and materials through this front end, which has a very lightweight ‘demo’ mode, and otherwise requires a subscription to use, handled by Stripe. This necessitated serving both the front and back ends over HTTPS — something we wanted to do anyway, because of industry mistrust of the cloud.