Open Tsunami Alert System

As I warned the other day, blog posting here is now closed. Please follow this link to http://otas.sourceforge.com .

Now that we're rolling with this, discussion has largely moved to the OTAS SourceForge site. On Monday 17 January 2005, I'll disable all comments on this site to encourage people to move to Source Forge.

Okay, so we've now got more communications infrastructure than the Department of Defense, so I guess we should do some actual work. I think the most productive comms mechanism we've got is the wiki, so I propose the following:

• Discussion of the architecture, design, and development will go on the wiki.
• Discussion of planned implementation cycles and such will go on the otas-planning mailing list.
• Announcements of significant events — releases, test cycles, our Nobel Prize — will go on the otas-announce mailing list.
• General chit-chat, flamewars, and deep psychological insights go to the forum.

I've moved the architecture discussion over to the OTAS wiki, where I hope all involved will follow me.

( Just for backup, that URL is http://otas.sourceforge.net/mediawiki/index.php/Main_Page.)

Most everyone who's email address I had as being interested in OTAS should have received this report. The one exception is the people for whom I have sourceforge project addresses; for some reason (I'm pursuing it with my ISP) email from my home email is rejected by sourceforge.

.. :Time-stamp: <2005-01-12>

*****************************************************************
Status Notes to Participants (and others)
*****************************************************************

:author: Charlie Martin
:date: 2005-01-12 19:51 (Zulu-7)

Folks, thank you all for volunteering, and forgive me for this
form letter, but I'm flat-out astonished at how much activity
this has gotten, and I just don't have time to answer everyone
individually. So, if you're getting this, you've either
volunteered your help, or you've somehow otherwise indicated
enough interest that I think you may be sucked in.

I'm anxious to bring everyone into the project as soon as
possible. This will require, primarily, that I learn how to work
the Source Forge project, which means I've got a bunch of
documentation to read.

In the mean time, here's what I'd suggest:

(1) let's keep the discussion going on the blog until I can
create a mailing list and/or forum, along with a home page.
Brian, I accept your offer with thanks, take a shot at a
couple of logos and we'll put them up for a vote ASAP.
Similarly, a simple website design. My own prejudice is
very strongly toward great simplicity and (as I'm getting to
That Age) relatively large fonts. Of course, if anyone else
wants to try their hand at logos, I'm all for it.

(2) We discussed Python and Java in order to put a stake in the
ground, and because the SF.net people, for non-obvious
reasons, wanted a choice before they'd approve the project.
My real feeling is that we'll eventually want not just
Python and Java, but also PHP, some Microsoft-specific
stuff, and very possibly Fortran so we can steal, er, obtain
appropriate numerical codes.

So, if you're not a Java person, don't think we're not
interested. "Let a thousand flowers bloom" and all that.

(3) My bias is very strongly toward openness in this whole
project, but I didn't have the foresight to mention anything
when I started the blog. What I'd *like* to do is make the
developers and associated people list open to everyone, in
something like this format:

:name: Full Name
:handle: ie, login name
:email: email address
:IM: IM addresses
:bio: Short bio, one paragraph.

Is everyone cool with that? If so, please drop me a note
with that information (leave out anything you don't want to
include) and I'll set up the list.

For that reason, I'm mailing this out to everyone under a
BCC:, in order not to expose your email addresses.

**PLEASE** unless you have a strong reason to the contrary,
let me at least pass out a handle and email address. I
won't publish them on the website(s), but it will mean I can
avoid doing a lot of middle-man stuff.

Thanks again, all of you, for volunteering. I apologize for my
failings as an instant project organizer, but bear with me and
we'll get this going.

.. Local Variables:
.. fill-column: 65
.. End:

Folks, thanks to the diligence (and greater knowledge than your humble narrator) of StuS (gurustu) we've now got a discussion and announcement mailing list set up, and a basic scratch home page installed.

The home page can be found at otas.sourceforge.net.

Mailing list subscriptions are at https://lists.sourceforge.net/mailman/listinfo/otas-planning.

Folks — As I said below, this is my first SF project, and there's a lot of documentation to be read. I'll be reading the docs and catching up with the mail tonight, and I hope will have more information tomorrow. I'm also writing architectural notes that I'll post Real Soon Now. — CRM

(PS. Until then, I can open posting on this blog to more people than Darren and me. Drop me a note.)

Yes, I've changed the template, looking for something even more simple and sparse.

Folks, I've created a first mailing list for OTAS. You should be able to sign up for it at the SourceForce page.
What I haven't done so far is figure out how to add developers or set up the home page.

BTW, is anyone a graphics designer type who'd like to develop a logo and home page?

Folks — Just to let you know, I had the job interview from hell today, and I'm just too wiped out to catch up tonight. Expect further content tomorrow. — CRM

I've started storing bookmarks related to this project on del.icio.us using the tag OTAS. This service facilitates the public sharing of hyperlinks. Feel free to add to the collection using this tag. You can view these bookmarks via the following link:

http://del.icio.us/tag/otas

Folks, there are a lot of comments volunteering to help. Thank you all. I've got a SourceForge project set up, which will help a lot; the Blogger blog was always intended as a quick stopgap. It kind of sounds like a mailing list could be good. Let me know; I'll figure out how to best set it up at SF.

(Go easy on me, this is my first SF project and I'm sort of a theory guy. Anyone who's ever administered an SF project is more than welcome to volunteer, he hinted subtley.)

Good news. We've gotten our Sourceforge project; you can find the home page here .

There's been a good bit of discussion by email; I'll try to summarize it in another posting.

UPDATE: Oh, Bullwinkle, that trick never works. That link should work now; just in case, it's http://sourceforge.net/projects/otas/

From Australia .

Some good points about weak links in such a system.

Notice the number of weak links here that would be eliminated by decentralized non-governmental OTAS.

Open Tsunami Alerting System
OTAS


Charles R Martin


INTRODUCTION
=================================================================

The recent extraordinary events in the Indian Ocean have awakened
the world to the hazards presented by tsunami. While there are
extensive tsunami warning systems available for the Pacific
Ocean[1], the tsunami warnings from the International Tsunami
Information Center[2] were not disseminated quickly enough to
prevent massive loss of life, because no warning communications
infrastructure was available in the eleven countries affected by
the tsunami of 2004 December 26.

The Open Tsunami Alerting System (OTAS) is an open-source project
to supplement the existing tsunami warning systems in a
decentralized, non-governmental fashion. OTAS *does not*
attempt to supplant any existing warning systems, and will be
designed to integrate easily into other tsunami warning systems.


GOALS
=================================================================

This sort of system presents some very interesting requirements.

First of all, the need for reliability and availability of the
network as a whole is high, but the reliability of the
individual components is low compared to the frequency of real
events. This implies high redundancy.

Second, because of the economic limitations of the countries
where these systems are most vital, the hardware and network
required cannot be very expensive; in fact, ideally the entire
network should be buildable with the sort of small PC machines
that are "cast offs" in first-world countries.

Third, the system should be built to allow many different means
for delivering the actual alerts: for example, email, telephone
alerts, and SMS messages.

Fourth, the implementation should be simple, and ideally should
not depend on complicated numerical models --- but it should be
able to make use of those models if available.


ARCHITECTURAL PRINCIPLES
=================================================================

Basic guiding principles for OTAS are:

1. OTAS will be platform independent and open source under
the GNU Public License (GPL).

2. OTAS will be built to be _simple_, _conservative_, and
_correct_. That is to say:

* _simple_ --- the design will be intentionally limited;
rather than including complicated geophysical codes, we
will concentrate on clarity and transparency.

* _conservative_ --- if OTAS makes an error, we will design
to fail safe and fail soft: we prefer issuing a false
alert to failing to issue an alert.

* _correct_ --- we will apply all available techniques to
ensure that the released packages are as nearly error
free as we can make them.

3. OTAS will be decentralized. Geophysical or seismological
data will be accepted from multiple sources (a later post
will discuss some open sources of seismo data), and no
notification site will be a "master". I currently am
thinking about a peer-peer component of the architecture to
provide for multiply redundant data paths.


IMPLEMENTATION APPROACH
=================================================================

We are still early in conceptualizing and designing OTAS. Our
current thoughts suggest the architecture will be based on a
service-oriented, web-service based, distributed network
architecture composed of two classes of nodes:

(1) prediction nodes, which receive data feeds from
seismological and geophysical data sources and produce alert
messages

(2) service nodes that display or propagate the predictions to
subscribers.

The actual throughput requirements are quite low, and probably
dominated by the necessity of maintaining some network traffic
to assure network integrity, rather than by the load of actual
predictions. As such, we don't need to worry about highly
efficient implementations (with the possible exception of
numerical prediction codes), but we want to be able to implement
quickly in a platform independent fashion.

For these reasons, we currently expect to implement the basic
network in Python, with possible FORTRAN and Java codes as
required by the situation.

LICENSING
=================================================================

We plan to release OTAS under the the GPL.

=================================================================
Footnotes:
[1] ??

[2] http://www.prh.noaa.gov/itic/

We're in the initial stages of building an Open Tsunami Alerting
System (OTAS) based on the suggestion in Bob Cringely's 2004/12/30
column[1]. Although work has just started, we've established a few
basic principles: OTAS will be very lightweight; will use openly
available geophysical or seismic data sources; will be highly
distributed and decentralized; and will be built to run on very
low-powered commodity hardware.

We currently foresee using Python and Java, but we aren't religious
about it.

Discussion and on-going notes can be found at the OTAS blog,
http://otasblog.blogspot.com.

Footnotes:
[1] http://www.pbs.org/cringely/pulpit/pulpit20041230.html

Bob Cringely passed along this set of slides on Tsunamis; interesting stuff.

Just think it's an amusing point. Where was the UN on this?

In Bob Cringeley's column of 2004/12/30 Bob suggested the notion of a simple, non-governmental, open warning system for tsunamis. The advantages of doing this are many (read the column for Pete's sake) and the effort isn't really that great. This blog will serve as a central point for collecting information about a development effort for just such a system, called OTAS or the Open Tsunami Alerting System.
I will be writing more on this in a little while, so this is more or less a placeholder, but I want to lay down a few basic principles.

1. OTAS will be platform independent and open source under the GNU Public LIcense (GPL). I'm no fanatic, so I'll listen happily to arguments for less restrictive licenses like the LGPL or BSD license, but at least right now a full GPL seems most appropriate.
2. OTAS will be built so be simple, conservative, and correct. That is to say:
• simple --- the design wll be intentionally limited; rather than including complicated geophysical codes, we will concentrate on clarity and transparency.
• conservative --- if OTAS makes an error, we will design to fail safe and fail soft: we prefer issuing a false alert to failing to issue an alert.
• correct --- we will apply all available techniques to ensure that the released packages are as nearly error free as we can make them.
3. OTAS will be decentralized. Geophysical or seismological data will be accepted from multiple sources (a later post will discuss some open sources of seismo data), and no notification site will be a "master". I currently am thinking about a peer-peer component of the architecture to provide for multiply redundant data paths.