Dust Storm Usecase

Use Case AQ.Dust.1.a: Supporting dust storm detection algorithm to work on large data repository

Definition

An algorithm is being developed to improve the detection of dust storms within remote sensing data 
sets, i.e. MODIS.  In order to search through large amounts of remote sensing data, an implementation 
of this algorithm needs to be available to be run against data available at NASA data centers.  The 
results need to be available for visualization.

Define the use case in plain sentences and wherever possible, avoid
specifying technical solutions or implementation choices. Concentrate
on the application aspects of the intended scenario.

Purpose

Phytoplankton plays an important role in the marine ecosystems since they form one of the primary links in      
marine food chain.  Since phytoplankton accounts for more than half of the global photosynthetic activity,
they act as an important sink of atmospheric carbon dioxide and thus have the potential to impact climate.
Emission of Dimethly Sulfide (DMS) is another pathway through which plankton affects climate.  DMS emissions 
increases cloud condensation nuclei (CCN) present in the relatively clean marine atmosphere, altering the 
microphysical nature of marine stratus.  Increase in CCN results in more but smaller size cloud droplets in 
marine stratus thereby increasing cloud albedo and creating a cooling effect.  Growth of plankton in remote 
ocean locations is limited by the availability of iron [Martin and Fitzwater, 1988].  Dust storm from arid and 
semi arid regions transport dust containing iron to remote ocean locations, which spur the growth of plankton.  
Since the response to iron fertilization is very vigorous, intentional iron fertilization has been suggested 
as remedy for climate change resulting from increased atmospheric carbon dioxide.  The idea of intentional 
iron fertilization was tested by artificially introducing iron at a remote ocean location.  The artificial 
fertilization experiment elicited a vigorous plankton growth which was readily visible in satellite imagery 
[Boyd et al., 2000].  Studies also show a global reduction in atmospheric carbon dioxide with an accompanying 
a increase in oxygen [Watson, 1996] following the eruption of Mt. Pinatubo. 

Even though there have been several in situ studies that explore connections between intentional iron 
fertilization and plankton growth, very few studies have utilized remotely sensed satellite imagery data to 
study fertilization of oceans by dust storms and resulting plankton growth.  In order to study these 
connections, a robust algorithm is required to detect and identify Sahran dust storm passage over remote 
locations in the Atlantic. 

A verbose description of why this use case exists, what the problem is
to be solved, what resources are generally needed (if known) and what
a successful outcome and impact may be.

Revision Information

Version draft (can be labeled draft if X=0)

Prepared by 
  Ken Keiser and Rahul Ramachandran 
    The Information Technology and Systems Center, The University of  Alabama  in Huntsville
  Chris Lynnes 
    GES DISC (GSFC DAAC)

April 9, 2007 

Revision History

Modified by <Modifier Name/Affil>, <Date/time>, <Brief Description>

Use Case Identification

Use Case Designation

AQ.Dust.1.a

<Cluster>.<SubArea>.<number>.<letter>

Use Case Name

Supporting dust storm detection algorithm to work on large data repository

<Insert short name and long name>

Use Case Definition

First paragraph is short description, second paragraph, etc. may contain
further details.

This use case attempts to describe a workflow to define and execute a user defined algorithm, running against a large data repository, such as a NASA DAAC. The workflow needs to be remotely defined, published with a workflow manager and then submitted for execution against data at the repository.

Successful Outcomes

• 1. User able to define workflow
• 2. User able to submit job to run against data at a repository
• 3. User able to retrieve and utilize results.

Failure Outcomes

• 1.User unable to successfully define workflow
• 2.User unable to submit workflow for execution against data at the repository
• 3.User unable to retrieve results

General Diagrams

Schematic of Use case

A diagram of how the different elements and people/processes
may fit together in the use case (if possible do not refer to 
specific technologies).

General Requirements

List any performance or metric requirements for this use case and 
any other considerations that a user would expect.

Use Case Elaboration

Actors

Always identify primary actors, may be more than one. Also identify other actor
including any other systems or services which are important. Primary actors 
are usually ones that invoke the use case and are beneficiaries of the
result. They may be human or computer. They are actionable. Other actors
are those that support the primary actor, i.e. would be part of the use case
without the tasks, work flow, resource, or requirements implied by the needs
of the primary actor.

Primary Actors

The actor that initiates this use case is the portal User. Providers may also initiate this use case as a precursor to use case EIE05, Manage Collections/datasets.

Other Actors

Security actor, who authenticates the user requests and issues authorizations for access to relevant data/resources.

Preconditions

• 1.Algorithms need access to the large data store with out transporting
• 2.Algorithm needs to be deployable across distributed systems for integration with other workflows
• 3.

Postconditions

• 1.Results need to be web-accessible for integration with other workflows
• 2.

Normal Flow (Process Model)

• 1)The user defines workflow of services (algorithm)
• 2)The user specifies data coverage parameters (spatial/temporal)
• 3)User publishes workflow to be accessible for execution
• 4)User submits request for execution at data center
• 5)User visualizes results

Alternative Flows

• 1)User defines workflow
• 2)Data selection criteria is specified
• 3)Requested data is staged at service location
• 4)Workflow executed on distributed systems with staged data

Special Functional Requirements

None

Extension Points

• <Cluster>.<SubArea>.<number>.<letter+1> something added or a variant.

E.g. AQ.Smoke.1.b something added or a variant

• <Cluster>.<SubArea>.<number>.<letter+2> something added or a variant
• <Cluster>.<SubArea>.<number>.<letter+3> something added or a variant

References

None