Seven questions you may have

...and their answers

1. Why use OpenDA when I can build it all myself?

Well, you can save yourself a lot of trouble using OpenDA. First of all, it gives you ready-made, well tested and efficient implementations of many data assimilation methods and calibration methods. Others have done a lot of work to implement, debug and optimize them, so why not use them? Secondly, using OpenDA, you can experiment with different types of filters or parameter estimation methods at no extra cost. This will allow you to find the best method for your application. And by the way, using OpenDA does not require more alterations to your model code than a custom made implementation of data-assimilation. You will not save yourself time or work by building it all yourself. The only thing is that you will have to learn to use OpenDA. But that investment will pay itself back in no time.
If you're still not convinced, perhaps you should consider to at least using the building blocks from OpenDA. That way, you can still do your own implementation but do it a lot quicker.

2. Why yet another data-assimilation framework?

We are not the only ones to build a data-assimilation framework. And we are also not the first. But we do think that we are the most ambitious in terms of scope. Most other frameworks have a limited number of data-assimilation methods whereas OpenDA is explicitly designed to support a wide variety of data-assimilation and calibration methods. This is why the framework has a modular architecture, allowing reuse of all kinds of convenient software components. Another advantage of OpenDA over others is its permissive licence, the LGPL. Basically, this tells you that you can do anything you like with the software as long as you don't blame us for the consequences.

3. How can a framework like OpenDA support variational methods?

True, variational methods usually require some sort of adjoint and OpenDA can not supply adjoints for your specific model. But it can do all the rest. So, if you supply the adjoint, we give you the tooling for its operational use. Furthermore, there are methods with similar functionality that do not require adjoints and OpenDA can support those.

4. How mature is it?

OpenDA is pretty mature. Some major government organisations, institutes and commercial companies rely on OpenDA for their data-assimilation. It is applied in fields like geomechanical engineering, water management and air quality monitoring. It has been developed by professional scientific software engineers and there is commercial support available for those who need it. So: yes, OpenDA supplies operational-quality software. And in the end, it is Open Source. So if interest in OpenDA should somehow discontinue, then you can still use and extend the software for your own purposes.

5. Do I need to reprogram my software?

No, not necessarily. OpenDA supplies tools to work with closed-source models, i.e. models that you just cannot reprogram. But usually, it is more efficient if you add a number of subroutines to your model software to make a direct connection to OpenDA. This set of extra subroutines (the model interface) is not very extensive. And once you have done that, you can use all the tools from OpenDA.

6. Does it cost much performance?

No, not necessarily. We have done experiments comparing an OpenDA RRSQRT Kalman filter implementation for a large scale model with a custom-build implementation. There was a slight degradation in performance, but it was no more than a few percent. And by tweaking the coupling between model and OpenDA, or the filter implementation, perhaps that few percent could be reduced even further. This is no surprise, because OpenDA was designed for high performance. Obviously, getting this high performance from OpenDA does require some carefull programming. But others in the community (or the commercial helpdesk) are probably willing to help you.

7. Whatever happended to COSTA and DATools?


For those who never heard about these terms: COSTA and DATools were two similar initiatives to develop a generic data-assimilation and calibration toolbox. But early on, these initiatives got involved in each other and in 2010 a complete merger was decided. In the current OpenDA software, you can still see the COSTA/DATools origin: the computational core is what used to be called COSTA and the java interfaces and tools are the DATools legacy.