Dust Storm Usecase
- 1 Use Case AQ.Dust.1.a: Supporting dust storm detection algorithm to work on large data repository
- 1.1 Definition
- 1.2 Revision Information
- 1.3 Use Case Identification
- 1.4 Use Case Definition
- 1.5 General Diagrams
- 1.6 General Requirements
- 1.7 Use Case Elaboration
- 1.8 Diagrams
- 1.9 Non-Functional Requirements
- 1.10 Selected Technology
- 1.11 References
Use Case AQ.Dust.1.a: Supporting dust storm detection algorithm to work on large data repository
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.
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.
Application Area Detail
Definition of Success
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
Modified by <Modifier Name/Affil>, <Date/time>, <Brief Description>
Use Case Identification
Use Case Designation
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.
- 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.
- 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
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).
List any performance or metric requirements for this use case and any other considerations that a user would expect.
Use Case Elaboration
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.
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.
Security actor, who authenticates the user requests and issues authorizations for access to relevant data/resources.
- 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
- 1.Results need to be web-accessible for integration with other workflows
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
- 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
- <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
Use Case Diagram
Other Non-functional Requirements
Overall Technical Approach