Skip to end of metadata
Go to start of metadata

*****************************************
January 21, 2010

Participants:

  • Chris
  • Tim L.
  • Charly
  • Jeff DLB
  • Matthew Arrott
  • John Graybeal

Actions Items:

  • (Chris) Create email group (include current attendees)
  • (Chris) Bring John Graybeal up to speed on where EOI stands, notably on variables involved in supporting the current modelers, and the sources for those variables(?)
  • (Chris/John) Speak with Rich – Let him know to back off the call to participation
  • (Jeff) Start communication with Frank Bub to him bring on board
  • (Chris/Tim) We need LOE for integrating Bob Wheller's Buoy Data (mostly FTP)
  • (???) Produce webinar that helps explain to (this) community what OOI is doing

Agenda:

  • EOI Status Update
  • Note from Rich
  • New Data Source from the OOI Marine Operator (CG)
  • http://uop.whoi.edu/UOP_realtime_files.html
  • Jeff DLB's Mini-LCA questions:
  • CO-OPS beta-test server is now offering ASCII CSV and TSV in addition to IOOS GML. See http://opendap.co-ops.nos.noaa.gov/ioos-dif-sos-test/ . This will be migrated to production server on or after January 27.
  • Mention was made of stress-testing the OOI-CI system. Can you really stress-test if data from EOs are at a lower data rate than your planned observatories?
  • Is there a semantic or functional model for the types of notifications to be handled by OOI-CI DDN?
  • Should EOI register IOOS pre-production or beta-test servers as potential backup sources?
  • You have or will have an interface control document describing your interface to IOOS SOS. Can we see, comment on and possibly republish that?
  • What additional service metadata or behavior does EOI need from IOOS services? Example: Information about reporting interval to help you decide how often to poll the service.
  • OOI-CI will be monitoring the services to which it connects for outages. Meanwhile, IOOS has said that it needs a System Monitor function. Should OOI-CI provide the system monitor for IOOS, or should IOOS expose system monitoring information to OOI? In the latter case, how exactly should it be exposed?
  • Navy has data or model outputs that may no longer be publicly accessible unless NOAA (or other civilian agency) puts them on a public server. Has OOI seen the spreadsheet listing those datasets, and do OOI customers want any of them?

Notes:

Matt: Do we need an email group to ease this communication? Sure - Include current attendees
Chris: Tasks are in Jira, dataset agent + netcdf libs being refactored. We are taking one of the workflows and making it work such that we can start the conversation with Rutgers folks
Matt: Where are action items from meeting so that we can monitor progress? What have we pulled from the experience (of the meeting)?
Chris: We've gone through the notes and boiled down to clearer notes/action items. Email sent earlier includes these primary action items for OOI. We need to pool our efforts to better understand what datasets we have.. and where we are getting these datasets. Get input from [???] to ensure these are the same. Large action item includes having Rich talk to the modelling community. Others include having Jim talk to Glider group at UH, etc.
Notes from HIOOS Kickoff - https://docs.google.com/document/d/1Mdx5wPFMMvXuAoqzMgZ7onTRsNQ5KQ9-Ga6toFannCs/edit?hl=en&authkey=COH2-JoE#
Matt: Did you persue this with Jim? Chris: All that was sent was the email including the action items. No follow-up thus far.
Matt: Recommends John be brought up to speed (offline) as to where we are. Specifically discuss the variables required. Would also like to see a plan so that we can understand the domain of work:
what variables
what sources for those variables
still the necessity to characterize the integration strategy for that specific modeller

Jeff: May have another modeller.
Matt: Communicate this through Rich.
Charly: Matt discussed making a broader connection to modeling community. Challenges: Although Rich is taking this charge, there isn't a formal goto guy for this connection.
Matt: Is there community there?
Charly: One is emerging.
Chris: Spoke with Rich.. He has talked to Josie Cantrell at NRA. Talked about pulling the modeling subcommittee together. She was enthusiastic, but have yet to see movement to pull them together. Challenge is how to create community without impacting other important projects. Ex: Rich is not IOOS, Josie is representative to RAs (?). If we were to have a workshop, breaks would be put on that meeting.

Matt: Would not like to see ooi be the center of the modeling community. would like to take advantage of the fact that there is a communittee involved that would like to take advantage of OOI.
Chris: We should be clear that this is a call to participation, not at the same level of support as our first few.
Matt: This requires us to focus on how to deal with a larger number of participants.
Charly: call for information (rather than participation), reveals the next round of use case. Modelers arent the only customers. As long as we are practical to this notion of collaboration, we won't build ourselves into a set of requirements that can't be fulfilled.

Matt: Do we actually go down the road for a call to proposal? Lowers commitment level
Charly: Confine it, finish it. The scaled up notion is a candidate for a second round.
Matt: there was a sense of enthusiasm that we are close. How do we become more efficient with our resources to satisfy the community.
Charly: Once we get the thumbs up, it might be useful as a candidate for an execution strategy.

Jeff: consideration of new potential customer - was able to express the use case we are attempting to solve.

Charly: Jeff is discussing replacing Hetland with Frank Bub. (Agrees that this may be a good connection.)
Matt: How do you feel Chris? Chris: Thinks we are "almost" ready. (Quotes courtesy John.) We should probably line things up before incorporating.

Frank Bub is an operational modeler rather than a research modeler - opens us to a different aspect of the modeling community. He is at Stennis, MS and runs operational NCOM and HYCOM models. ASA already has a solid relationship with him.

Matt: This would lend credibiliity to this first year effort.
Charly: We should substitute without scaling up the scope.

John: Concurs with this approach. The process can take some time, and be managed to constrain the impact. But the advantage of waiting is that it lets Charlys modeling group become more cohesive and allows us to go to the group as a whole.

Matt: Propose that we review this with Rich (go through R1 with 3 modellers).

There is also the need for explaining what we are doing to this community. We can also provide a webinar that helps bring these things along, without committing to any further engagement.

Charly: Progess being made on coastal modeling on two fronts: working with OOI & [gulf work]

Jeff: Frank wants to know more but did not commit. Matt: Thats fine to provide info as step 1.
Charly: We can facilitate communication with Frank through Jeff and Rich.
Chris: ASA has a standing relationship and may be able to provide this connection.
Charly: Jeff is his reasonable? Jeff: Sure [he'll make the contact].
Chris: This may fill another area of concern with integrating with community. Frank runs HYCOM and NCOM.

Matt: John and Chris can you work with Rich.. let him know to back off (rescheduling rather than cancelling) on the call to participation. If he's made progress, we should setup a strategy to provide insight as to OOIs involvement.
Chris: Not sure that anymore progress has been made other than Rich touching base with Josie.

Matt: Bob Wheller (PI) already deployed what is comparable to [??] buoy. CI has committed that we will integrate the data coming from these buoys. Chris/John we need an assessment on how long it will take to integrate this data (mostly FTP).
Variables etc should be understood, work envolved should just be coding the integration of this data into CDM.

CO-OPS beta-test server is now offering ASCII CSV and TSV in addition to IOOS GML. See http://opendap.co-ops.nos.noaa.gov/ioos-dif-sos-test/ . This will be migrated to production server on or after January 27.
Jeff: Does SOS undersand GML. Chris: Nope. If its the same format we should be able to just drop this in as another source.

Mention was made of stress-testing the OOI-CI system. Can you really stress-test if data from EOs are at a lower data rate than your planned observatories?

Is there a semantic or functional model for the types of notifications to be handled by OOI-CI DDN?

Should EOI register IOOS pre-production or beta-test servers as potential backup sources?
Jeff: Is this a good idea of not. Sometimes differ from production server, etc. Because we wanted to test falling back to an alternate source, this might be good to investigate.
Matt: This raises an interesting question. We subscribe to a topic (dataset) – dataset can be found from different sources (though identical). Another concept is that datasets can be equivalent but not identical. We must say that these are different datasets with a preference for one over the other. Who makes this choice of priority and failover??
Chris: There should be a default fallback.. and manual intervention if needed.
Matt: Env should not make this call. Not hardwired into overall inf. should be hardwired into an agreement that the process should go a particular way.-- Different communities have different norms.

You have or will have an interface control document describing your interface to IOOS SOS. Can we see, comment on and possibly republish that?

What additional service metadata or behavior does EOI need from IOOS services? Example: Information about reporting interval to help you decide how often to poll the service.

OOI-CI will be monitoring the services to which it connects for outages. Meanwhile, IOOS has said that it needs a System Monitor function. Should OOI-CI provide the system monitor for IOOS, or should IOOS expose system monitoring information to OOI? In the latter case, how exactly should it be exposed?

Navy has data or model outputs that may no longer be publicly accessible unless NOAA (or other civilian agency) puts them on a public server. Has OOI seen the spreadsheet listing those datasets, and do OOI customers want any of them?
Jeff: (Frank Bub connection related?)
Matt: OOI would like to have private relationship with Navy and act as a distributor (not the only one however)
Jeff: NCDDC dist. some of Navy data.
Charly: We are exploring that if Navy believes the community has a use for the data, would they like OOI to be the public face of this data
Matt: We should not be the public face - but rather a distributor. We are the infrastructure for a private relationship between them – we are also the dist. to the community

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.