Climate Prediction "Resolution Independent" Trickle Data Interface for Distributed Computing

Abstract
Current climate prediction programs that are deployed in distributed computing have very high attrition rates (~10% participant loss per ~15% simulation completion). On top of this these programs in their current form have almost non-existent data return. In spite of the advent of using trickle 'work units' to grant participant credit, not much has been achieved with respect to advancing the technology.

Fundamental distributed computing problems relating to climate prediction that need to be fixed and must be fixed

Climate Prediction programs currently deployed in the distributed computing sector return very little data most of the time, except for very infrequent large uploads of datasets. This is not optimal science by any measure, but it is the status quo. Although the current way of doing things is better than nothing, it is also not doing anyone any good.
There is little if any intellectual "model innovation" taking place since numerical climate prediction was adapted to distributed computing. There needs to be innovation in the return data link sector. Certainly returning real time data to policymakers is of highest importance. However, it is also of equal importance to return real time data to the climate scientists that are doing long term and short term research.
People running climate simulations have no idea what their model is doing in spite of the graphical user interface. This is one of the profound cases of the user interface totally failing the tell the user anything useful.
The attrition rates for numerical climate prediction are the highest in distributed computing. The lack of return data is a contributing factor to this attrition. People that run these kinds of programs are into statistics (or at least they want statistics). The climate simulation program (with the aid of the website) should give users the statistics they want or need.
Educationally speaking, the current websites and simulations programs are failures as teaching tools. Having 600,000 people that understand climate modeling is better than 16,000.

API Scope

Trickle messages, as of this time are specified here

Trickle messages let applications communicate with the server during the execution of a workunit.
These trickle messages are intended for applications that have long workunits (running over multiple days or weeks).

Trickle messages are XML documents, and they may go from client to server or vice-versa.
Trickle messages have been designed to be asynchronous, ordered, and reliable.
Since these messages are conveyed in scheduler RPC messages, they may not be delivered immediately after being generated.

Trickle-up messages

Trickle-up messages go from application to server. They are handled by trickle handler daemons running on the server. Each message is tagged with a 'variety' (a character string). Each daemon handles messages of a particular variety. (This is used, typically, to distinguish different applications.)

Example uses:

The application sends a trickle-up message containing its current CPU usage, so that users can be granted incremental credit (rather than waiting until the end of the work unit).
The application sends a trickle-up message containing a summary of the computational state, so that server logic can decide if the computation should be aborted.
To create a trickle handler daemon, modify the program sched/trickle_handler.cpp, replacing the function handle_trickle() with your own function.
Add an entry in your config.xml to run this program as a daemon.

Client-side API

To send a trickle-up message, call : int boinc_send_trickle_up(char* variety, char* text)

Server-side API

To handle trickle-up messages, use a 'trickle_handler' daemon.
This is a program, based on sched/trickle_handler.cpp, linked with a function

int handle_trickle(MSG_FROM_HOST&);

struct MSG_FROM_HOST { ... };

This function should return zero if the message was handled successfully; otherwise it will be retried later.
The 'hostid' field identifies the host from which the message was sent.
The daemon must be passed a '-variety X' command-line argument, telling it what kind of messages to handle.
The daemon should be specified in the project configuration file.

Overall design goals and principals

This class of standardized "Trickle Up Message" should be as compact as possible.
XML coding should be mandatory so as to future proof the protocols.
XML database formats should be supported, where a small database needs to be sent.
XML compression should not be required as the messages should be under 8k.
Version numbers within the protocol should be mandatory.
The trickle 'work unit' needs to send back 'resolution independent' data because model resolutions can change (namely model resolution will increase as time goes on).
The trickle needs to be sent back far more often than is the current practice, as most trickle work units are being sent back in the 1 to 3 month range (the model needs to iterate thru a multi-month window in order to reach a trickle point).
The trickle work unit needs to send back data trends in these recommended model time windows

The Pulse (2.25 days)
The Week (4.50 days)
The Fortnight (15.25 days)
The Month (28.50 days) -- making for at least 4 kinds of trickle work units.

The trickle needs to be disposable, that is to say you should be able to throw away 50% to 75% of them with no loss in return information. As time goes on this will be less necessary to delete trickle work units due to disk space becoming cheaper.
The trickle must return regional and global data that is resolution independent, that is to say based on map lines not fixed resolution blocks (in spite of the underlying interface being of fixed resolution blocks).
The trickle program must be a separate program from the main climate simulation.
The trickle software program must be usable with vastly different datasets and models. There is no guarantee that the current models will not be modified or replaced. The trickle work unit uploaded must be above the minutiae of the datasets and programs currently deployed.
The ordinary trickle work unit currently being used must continue to be used.

Model Data	Why needed
Model date range for trickle (start time, stop time)	Format START: YYYYYY-DDD; STOP: YYYYYY-DDD, forced leading zeros
Overall model stability	Should only be reported fortnightly
Ocean model stability	Not required for slab ocean models, but should be mandatory for non-slab models.
Land model stability	Should only be reported fortnightly
Flux correction stability	Should be reported every 7 days
Convention stability	Not needed in models that have no support for convection, optional
Clausius Clapeyron trends	The C-C equation governs the water-holding capacity of the atmosphere. Ideally, there should be numbers for the Arctic, Mid-Latitudes (N & S hemispheres), Tropics and Antarctic.
CFL Stability	Three mathematicians named Courant, Friedrichs, and Lewy created a criterion that, if violated, would lead to the "blowing up" of a finite-difference weather prediction model. This CFL criterion is: The speed of fastest winds in model must be less than or equal to grid spacing divided by the time step. Update daily.
Model data version numbers	For version tracking as well as core science code tracking ... {CC=1; CFL=2; ...} one standardized string in one XML field, printable not binary.

Global Data
Average temperature	Arbitrary
Average daily rainfall	Arbitrary
Average daily snowfall	Arbitrary
Number of High Pressure Cells (+ average size)	Shape and vector categorization is possible for up to 5 cells
Number of Low Pressure Cells (+ average size)	Shape and vector categorization is possible for up to 5 cells
Number of Median Pressure Cells	For statistical monitoring of the model
Pressure cell deviation	Highest vs Lowest pressure cells, the standard deviation units away from each other
Accumulated snowfall : Sea	TBA
Accumulated snowfall : Land	TBA
Accumulated rainfall : Sea	TBA
Accumulated rainfall : Land	TBA
Global data version numbers	For version tracking as well as core science code tracking

Regional Data
Number of High Pressure Cells (+ average size)	Tropics, Mid Latitudes, Arctic AND Americas, Europe-Africa, Asia, Australasian differential; vector data possible for up to 5 cells in this dataset
Number of Low Pressure Cells (+ average size)	Tropics, Mid Latitudes, Arctic AND Americas, Europe-Africa, Asia, Australasian differential; vector data possible for up to 5 cells in this dataset
Tropical average temperature	Area inside the Tropic of Capricorn & Tropic of Cancer
Tropical average temperature : LAND	Area inside the Tropic of Capricorn & Tropic of Cancer
Tropical average temperature : SEA	Area inside the Tropic of Capricorn & Tropic of Cancer
Mid Latitudes average temperature
Mid Latitudes average temperature : LAND
Mid Latitudes average temperature : SEA
Arctic & Antarctic average temperature	Using Arctic & Antarctic Geodesic Circle
Antarctica differential average temperature	Antarctica is mostly land, not sea as with the Arctic
Clausius Clapeyron trends (Arctic, Tropics, Mid Latitudes)	The C-C equation governs the water-holding capacity of the atmosphere -- but it may play out differently in different parts of the world due to seasonal variation and model input variation.
Ocean sector level average temperature	North Atlantic (North & South), Caribbean Sea, South Atlantic (North & South), Indian Ocean (North, Central & South), Pacific (North, Tropics & South), Tazman Sea, Mediterranean Sea, Southern Ocean (surrounds Antarctica) -- FOR NON SLAB OCEAN MODELS
"Cold Equator" trend line	Mainly for slab ocean models, although no model is totally immune from this effect; for monitoring only. If too frigid, abort the model!
Regional data version numbers	For version tracking as well as core science code tracking

National Level Data
SEE APPENDIX A	National level data is vital for the national weather agencies -- and national weather data available may vastly expand funding for this branch of science.
National Level data version numbers	For version tracking as well as core science code tracking

Optional Data
Pollution dispersion (National or Regional Level)	Useful for Sulfur models, volcanoes and smokestacks are equal here...
Sea Ice granulation or solidification events	Trend data that applies to Antarctic and Arctic regions only, may require some math and climate database reads to find.
Sea Ice extent	Trend data that applies to Antarctic and Arctic regions only, a snapshot number.

Runtime Diagnostic Data
Trickle version number (software + science code)	The trickle software should be upgradeable during a simulation. The climate simulation programs should not even know it is there ... except for some geoiddatabase locking policies no changes needed.
CPU Time (seconds)	For granting credit to users
Average seconds per timestep	For user to track real CPU speed & credit calibration
Median seconds per timestep	For user to track real CPU speed & credit calibration
Minor exceptions handled (+ type)	For debugging and program optimization
Start & Stop record	For tracking restarts
Program loop diagnostic data	For beta testing
Hashsums for data groups	Data integrity

Data formatting issues
The data should be in the XML or XML-DB form. It should be readable, as well as unambiguously structured.

Trickle up issues
It would be advisable to have each trickle be no more than 4 kb in size.

Further reading

(ClimatePrediction.net) There are 72 Trickles in a Slab Model, 120 in a sulfur Cycle model and around 2000 in a Transient Coupled Model. So at worst you only have to wait for about 12 hours to trickle on a fast PC running sulfur. The stats updates are currently once per day.
(Tables showing current trickle update frequencies) http://www.boinc-wiki.info/index.php?title=Trickle
(No modification is needed to the API) : http://www.boinc-wiki.info/Trickle_Message_API
(Trickle API guide) : http://www.boinc-wiki.info/Using_the_BOINC_Trickle_Message_API
(The baseline data structure to interface with the trickle message) : http://www.boinc-wiki.info/Trickle_Message
(Tables summarizing upload and download bandwidth) http://www.boinc-wiki.info/Climateprediction_Size_Table
CFL stability applet : http://profhorn.meteor.wisc.edu/wxwise/kinematics/barotropic.html

APPENDIX A: National Level Data

North America 1 2 3 4 5	Greater Europe * 1 * 2 * 3 * 4 * 5	South Asia * 1 * 2 * 3 * 4 * 5
Central America 1 2 3 4 5	Lesser Europe European exclaves and overseas territories	East Asia * 1 * 2 * 3 * 4 * 5
South America 1 2 3 4 5	Africa 1 2 3 4 5	Australasia 1 2 3 4 5

At this time these are suggestions.

APPENDIX B: Prehistoric Oceans & Land masses

There needs to be a long term working group set up to determine best how to upload data for ocean arrangements that date back further than 2 million years. Until the trickle work unit technology is adequately working, this avenue of research should be put on hold. Ideally geographic reporting regions should be set out in 50mya chunks.

APPENDIX B: Outer Planets Climate Simulations

There needs to be a working group set up to define a common message set for this application. Both rocky and gas planets need to have a common answerback API.

Author
Max Power

Initial idea
21 April 2006

Document created
15 May 2007

Last modified
01 February 2010

Last edit
API, Outer Planets