Scenarios

Base scenario: Glider operation. At any time during the experiment observational data from radar and satellite as well as current glider status information is combined with numerical ocean forecast models to provide situational awareness for scientists and glider pilots. Several gliders are in the water and one of these can be tasked with waypoints for the purposes of this experiment. Shore planning procedures are performed interactively during the dive interval of this glider to prepare tasking for the next interval. Dive intervals are set to 3-6 hours. Shore planning includes coarse waypoint planning, path optimization, detailed planning and dynamic simulation.

Scenario 1: Virtual simulation. Decide on a one week time period and specific local area with sufficient available historic observational data coverage and archived forecast products and existing recorded glider paths. A virtual glider is prepared in simulation mode on the bench connected to a glider simulator. The glider simulator computes the movement of the glider given its tasking in a virtual environment. The glider interfaces to the dockserver in the same way as during a field deployment.

Scenario 2: Field Deployment. Use real-time observational data and forecast data products. Have 5 gliders deployed in a region in the ocean and one of them taskable using the shore planning process.

Data Flow

1A Acquire observational data (for each data source)

Group: Rutgers

Input: Observational data sources

• CoDAR: coastal currents
  • Provides a 2D map of coastal currents vectors and velocity, based on measurements from shore-based coastal radar stations. Similar to altimetry data, which is used in the open ocean.
  • Typically provided as average every hour and as daily average
  • Is impacted by weather. Data gaps can occur
  • Rutgers is the east coast hub and collects all Codar data. Also provides visualizations in GIF on the Rutgers website.
  • Used to initialize numerical models and to validate model output
  • Data available in NetCDF. Historic data and real-time data.
  • John will work on putting data on Rutgers THREDDS server, e.g. hourly data set update
• Satellite: SST (sea surface temperature) and ocean color
  • Provides a 2D map of both SST and ocean color
  • Different satellites measure SST and ocean color.
  • Updates available with satellite passes. It takes some time to download and to process (~1 hour). On average 16 sat passes each day: 12 SST and 4 ocean color
  • Is impacted by weather (cloud coverage). Data gaps can occur. Morning hours might be less impacted than afternoon hours due to cloud buildup.
  • IOOS algorithms exist to compensate for weather related gaps
  • Used to find fronts. Either SST or ocean color might be relevant.
  • Data available in NetCDF. Historic data and real-time data.
  • John will work on putting data on Rutgers THREDDS server
• Glider data
  • Glider communicates a part of its collected engineering and science data during each surfacing
  • Communicated engineering data includes: position lat/long, timestamp, leak detect, flight characteristics (velocity, vertical angle at 1-2 Hz)
  • Science data includes vertical profiles, e.g. CTD, optical sensor (backscatter, chlorophyll florescence)
  • Derived data produced on dockserver using Matlab etc scripts immediately after the glider surfaces and communicates: Images, depth average current (1 value), next surfacing, waypoints in various representations
  • Provided as KML. Has embedded description tag contains HTML table with further detailed information.
  • Need Example

Procedure

• Collect data from data source in regular intervals
• Observational data will be historic data in case of virtual simulation - How do we feed that into a "virtual real-time" data flow?
• Compute overlay images - yes/no, make sense?

Outputs

• Observational real-time or historic data on server. THREDDS for Codar, Satellite and KML for glider data
• Google Earth overlay images available on web server

1B Forecast modeling (for each operational model and team)

Group: JPL (Yi), Rutgers (Bronwyn)

Input

Primary models used for the virtual ocean, covering the Mid-Atlantic Bight region (the waters west of the tip of cape cod and north of chesapeake bay) and bounded by larger scale ocean models.

• Rutgers ROMS (John W, Javier, Julia)
  • ROMS
  • Covers mid Atlantic bight
  • THREDDS @ http://tashtego.marine.rutgers.edu:8080/thredds/roms/espresso/catalog.html
• Stevens model (Nickitas)
  • Princeton Ocean Model (POM)
  • Detailed model of Hudson Bay extending with less resolution far into the MA region (long island, south of NJ)
  • THREDDS @ http://colossus.dl.stevens-tech.edu:8080/thredds/catalog.html
• UMass Dartmouth (Avijit)
  • Harvard Ocean Model (HOPS)
  • THREDDS @ http://aqua.smast.umassd.edu:8080/thredds/catalog.html
  • Larger scale model. Represents bigger scale features such as eddies

Further models:

• MABGOM ROMS NCSU (Rouying)
  • ROMS
  • THREDDS @ http://omglnx1.meas.ncsu.edu:8080/thredds/mabgom_catalog.html
  • Larger scale model, provides realistic forcing and boundary conditions for smaller scale operational models, see above. Close integration with Navy HYCOM model.

• MIT (Pierre, Wayne)
  • MSEAS model (Multidisciplinary Simulation, Estimation, and Assimilation Systems) is providing the input for MOOS based autonomy systems
• JPL (Yi)
  • ROMS model

Procedure

• Bronwyn Cahill (Rutgers) will be the point person for all OSSE ocean models
• Compute forecast model (daily, a forecast for 48 hours)
• In case of virtual simulation, select available historic forecast data products
• Compute Google Earth overlay images yes/no?

Outputs

• Publish forecast model dataset on THREDDS/OpenDAP server.
• See also the OSSE Numerical Model page for a list of models and their respective THREDDS servers - Structure of data sets? Do we have examples?
• Google Earth overlay images

2 Shore planning: Situational Awareness

Group: JPL (Yi)

Inputs

• Numerical model data sets from THREDDS server
• Observational data sets

Procedure

• Installation of a portal similar to JPL OurOceanPortal (Yi) including all accessible datasets 
• Enables scientists and glider pilots to analyze the current situation
• See also subsequent step of using Google Earth for situational awareness

3A Shore planning: Set Coarse Waypoints

Group: JPL (Steve/David)

Inputs

• Get overlay data and data products in geotiff format from Rutgers SST, ocean color, Codar, etc website
• Initial glider position and start time (set manually in Google Earth as "initialize" activity)

Procedure

• Use Google Earth with nowcast/observational map overlays for situational awareness together with ocean portal
• Use Google Earth to perform initial waypoint definition
• Waypoints to be defined: Initial waypoint (current estimated location), goal waypoints, communication waypoints.
• Waypoint names to determine activity types and ordering (examples of legal names: "Initialize 1", "Communicate 4").

Outputs

• A KML file with list of 3-10 waypoints (example .kml file).

3B Shore planning: Interpolate Waypoints with Current-Sensitive Path Planner

Group: JPL (Steve/David)

Inputs

• KML waypoint file from previous step
• NetCDF current predictions from numerical models from THREDDS server via an OpenDAP client out of Matlab

Procedure

• Path planner interpolates waypoints sensitive to currents - Provide details

Outputs

• Refined current-sensitive path (example .kml file).

3C Automatic Conversion to Detailed Plan

Group: JPL (Steve/David)

Inputs

• Current-sensitive path from above
• Times derived from .kml-embedded timestamps (default) or current forecast start time (fallback)

Output

• detailed plan with activity start times, durations (example .ini file) in ASPEN/CASPER
• (visual) time line view with glider behavior and parameters

3D Detailed Planning in ASPEN Timeline Interface

Group: JPL (Steve/David)

Inputs

• Detailed plan from above

Procedure

• Use ASPEN iteratively and interactively to track and optimize instrument parameters, energy levels, and to command instrument activation and other behavior, and to define
• Define on-board instrument (CTD, optical instrument) activation time
• Refine fallback (variant) behavior and enabling conditions
• Define next dive time and duration

Output

• altered detailed plan, possibly containing new activities and parameters (example .ini file) in ASPEN/CASPER format.

4A Shore planning: Dynamic simulation

Group: JPL (Steve/David), MIT (Arjuna)

Input

• ASPEN/CASPER schedule containing: initial glider position, waypoints, activities
• Forecast model data set from current-sensitive planning step above (MSEAS?)

Procedure

• Execute virtual sandbox CASPER and MOOS-IvP simulation
• CASPER executes the detailed plan in virtual compressed time, provides status changes and commands to MOOS-IvP
• MOOS-IvP is driven by CASPER commanding and leaves a trace of status information based on IvP behavior evaluation
• Post-process: IvP status information is collected and used to refine the current plan - How does this work?

Outputs

• (visual) Validation; plan executes as desired?
• Optimized waypoint list, directly out of MOOS-IvP - How

4B Shore planning: Plan Correction

Group: JPL (Steve/David), MIT (Arjuna)

Input

• Real-time current position of the glider, during surfacing interval

Procedure

• Executed during the surfacing interval of the glider
• Needs to make corrections to previously computed optimized plan based on exact position
• Most be executed within 5 minutes

Outputs

• Modified waypoint list

5A Glider operations

Group: Rutgers (John)

Input

• Waypoint list - Which format? Which additional parameters?
• Glider pilot manual commands (via glider pilot interface)

Procedure

• Mission dockserver reads waypoint list and queues requests with medium priority
• Glider pilot console accepts glider commands with high priority
• Mission dockserver transforms prioritized requests into mission files
• Ready mission file transmitted to glider during communication window
• Glider status received from glider

Outputs

• Glider engineering data as KML
• Transmitted glider specific (goto) mission file

5B Virtual Glider Deployment

Group: Rutgers (John)

Procedure

• Choose historic date/time with good SST/Codar coverage and existing glider deployments
• Use observational data and forecast data for this time period
• Have a real Rutgers glider in a bench with time set to the simulation period in simulator mode
• Simulate glider navigation and communication with dockserver

Integration Steps

1. Satellite observational data to shore planning
2. Codar observational data to shore planning
3. Glider observational data to shore planning
4. Model data to shore planning
5. Path planning
6. Dynamic simulation
7. Shore planning to dockserver

Open Questions

• What about forcing and boundary conditions? Are they represented in this data flow enough?
• Which Google Earth overlay images do we need for observational, nowcast/forecast data?
• How do the OceanPortal and GoogleEarth situational awareness tools interact?
• How is potentially conflicting input from multiple data sources (SST, Codar currents, ocean color, model forecasts) managed in path planning and dynamic simulation?
  • Is there a model that takes precedence?
  • Is there an averaging over multiple data sets?
  • Is there a manual decision making step?
  • Will potential alternatives be readily available for glider pilot decision?
  • How are alternatives managed?
  • How do plans get validated and corrected
• How much time do the plans cover? What is the direct automation goal for the upcoming two experiments? (Besides proving the architecture)
• How can MOOS-IvP be used most effectively in the dynamic simulation presuming it not influencing any glider controls (depth, pitch angle etc)?
• Should we set up a means to simulate the real time data delivery in September for the flow that will be delivered during the November field effort?
• How can the results of the planning and simulation efforts during a glider dive be used effectively with uncertainty about the actual glider position? Plan correction step with without human in the loop. What time is necessary for that?