Skip to end of metadata
Go to start of metadata

Extended Collaborative Support Service (ECSS)

What is ECSS?

The Extended Collaborative Support Service (ECSS) pairs members of the XSEDE user community with expert ECSS staff members for an extended period to work together to solve challenging science and engineering problems through the application of cyber infrastructure. In depth staff support, lasting weeks to up to a year in length can be requested at any time through the XSEDE allocations process. This support is more than technical support in the ordinary sense of the phrase. It may even lead to joint papers, presentations and other collaborations.

Expertise is available in a wide range of areas, from performance analysis and petascale optimization to the development of community gateways and work and data flow systems. ECSS staff members also participate in reviewing adaptive proposals associated with XRAC meetings.

ECSS efforts are divided into two parts, one designated as Projects, headed by Phil Blood at  PSC, and the other, designated as Communities, headed by Bob Sinkovits at SDSC.

ECSS-Projects consist of ESRT (Extended Support for Research Teams) and NIP (Novel and Innovative Projects). ECSS-Communities consist of ESCC (Extended Support for Community Codes), ESSGW (Extended Support for Science Gateways) and ESTEO (Extended Support for  Training, Education and Outreach). ECSS staffers are often members of multiple groups in varying percentages. When you first become a member of the ECSS team, you’ll be asked to provide a description of your expertise. You can see what others have done in the ECSS staff listing. This will help with project assignments. Ken Hackworth will also ask for expertise in the various NSF Fields of Science. This facilitates adaptive reviews described elsewhere in this document.

The 5 ECSS groups have very close interactions, with common Project Management support.  ECSS consists of 27 FTEs, spread over ~70 people at about ten sites.

ECSS Groups

Extended Support for Research Teams (ESRT)
Level 3 Manager – Lonnie Crosby, NICS
An ESRT project is a collaborative effort between an XSEDE user group and one or more ECSS staff members, whose goal is to enhance the research group’s capability to transform knowledge using XD resources and related technologies.

Novel and Innovative Projects (NIP)
Level 3 Manager – Sergiu Sanielevici, PSC
The mission of the NIP team is to provide proactive, sustained efforts to jump-start XSEDE projects by non-traditional (to HPC/CI) users. Activities may range from initial contact to the development and execution of successful projects, including those that receive extended collaborative support. The scope of NIP includes disciplines whose practitioners have rarely availed themselves of HPC/CI resources in the past.

Extended Support Community Codes (ESCC)
Level 3 Manager – John Cazes, TACC
ESCC efforts are aimed at deploying, hardening, and optimizing software systems necessary for extensive research communities to create new knowledge using XSEDE resources and related technologies. ESCC projects are focused on helping users with community codes and tools on XSEDE systems. 

Extended Support for Science Gateways (ESSGW)
Level 3 Manager – Marlon Pierce, IU
ESSGW is tasked to provide assistance to researchers wishing to access XSEDE resources through web portals and science gateways. The group assists both new and advanced groups and has experience in the use of web technologies, grid software, fault tolerance, complex workflows, and security and accounting aspects of the program. The group also works closely with the XSEDE Engineering Teams (Architecture & Design, Software Development & Integration, Operations) in providing usecases, validating requirements and testing software deployments.

Extended Support for Training Education and Outreach (ESTEO)
Level 3 Manager – Jay Alameda, NCSA
ESTEO work covers several areas - live training and tutorials, webinars, content review/updates, and one to one long term interactions / mentoring such as that conducted through the Campus Champions Fellows program. Training and education/outreach requests come in from those areas of XSEDE and ESTEO staff are asked to help in various capacities - by presenting at events, delivering, developing and/or reviewing content, testing example problems for students, etc.

What’s expected of me?

Details on all activities are provided throughout this document, but summarized here.

  • Contribution to one or more ECSS areas
  • Project reporting
  • Adaptive reviews
  • Symposium attendance and presentation
  • Attendance at ECSS meetings
  • Campus Champion Fellow mentor (only a small number of ECSS staff)
  • Upload publications to the XSEDE user portal on a continual basis

 

We have a telecon number that may be used for project calls and desktop sharing. Please check with our project managers Karla Gendler <gendlerk@tacc.utexas.edu> or Marques Bland <mbland@tacc.utexas.edu> to make sure the number is not in use.

  • 217 332 6338
  • 312 994 8410
  • 888 983 3631
  • Conference ID: 1839361


 

The Project Process       

Project proposals are submitted through the XRAC process on a quarterly basis, as a supplement request throughout the year, or as a startup request. Qualifying projects are sent to the ECSS group for assignment and staffing to one of the three project areas ESRT, ESCC or ESSGW. 
The following are the steps an ECSS Expert should take when they are assigned to a project:
 

1. Contact the Principal Investigator (PI)

Contact the PI within 3 business days of the expert’s being assigned to a project. This initial contact should serve as your introduction to the PI and an opportunity to get more information about the project. You can familiarize yourself with the PI’s answers to the “5 questions” that describe what they’d like to accomplish with ECSS support by looking up the PI’s proposal submission at http://xras-admin.xsede.org/. Remember though that proposals are confidential. You should establish in this meeting the goal of working with the PI to create a project workplan. In fact, if the “5 questions” were answered well enough, you may be able to create a preliminary workplan to jumpstart work with the PI.

If the PI is unresponsive after a month of repeated contact attempts,  you may let the PI know that the project will be closed, and they may submit a supplemental request for ECSS support at a later time.  If the PI still doesn’t respond, please send a short final project report outlining your attempts to contact the PI to your L3 manager and the ECSS project managers.  If you feel uncomfortable notifying the PI that the project will be closed, you may notify your L3 manager and let them handle the final correspondence with the PI.

Helpful Tip: The PI may name others working on the project (grad student etc.) that you can contact if the PI is unresponsive. These people may be named in the answers to the “5 questions” described above. You do not have to make contact only with the PI to develop your plan, you can work with other project staff.

2. Develop a Workplan

The workplan should be a collaboration between the PI and the ECSS expert. The plan should consist of a project timeline, milestones, and deliverables. The plan will mention activities to be conducted both by the PI’s research group and the ECSS staff members and the level of effort anticipated for these activities. ECSS projects work best, and have a much higher likelihood of being incorporated into the research group’s day-to-day activities if they are developed collaboratively.

In addition to setting the goals of the project, the workplan also gives the PI a clear idea of the expectations up front for both sides.

Initial workplans do not have to be “perfect” and can be revised after submission. They often need to be revised as it can be difficult to estimate how long activities will take until some initial work has been done (such as code profiling, for example). A workplan should be developed within one month of initial contact with the PI. If a plan requires a longer time, notify your L3 manager of the estimated completion date.

Completed workplans are submitted to the L3 manager for approval. Once approved, work can officially begin on the project.

Helpful Tip: Spend 1-2 days revisiting the workplan after working for one quarter, when you know the project better. Then you'll be able to set PI expectations appropriately for what can be accomplished. Also, the workplan may change later in the cycle due to work going faster or slower than expected.  Be sure to update the workplan after each quarter.

Link to workplan templates: Sample Workplan Template

3. Required Reports

Quarterly Reports

Quarterly reports are mandatory for the project. All staff working on the project will be notified by email when quarterly reports are due. The message will include the name of the project you are working on and a template of the information required. Reports do not need to be extensive. Templates are provided to spark additional thoughts in some areas.

Quarterly report components:
  • Project Title
  • PI Name and Institution
  • Project Team:
  • Summary (1-2 paragraphs)
  • Figures (optional)
  • Quarterly Objectives
  • Efforts
  • Workplan Updates
  • Kudos Received (optional)
  • Additional Questions for Consideration
    • Is this project ready to highlight in a symposium talk?
    • Is there any advanced topic documentation I need to prepare?
    • If the PI was satisfied, have I asked for a quote regarding the value of the collaboration?
    • Would others benefit from a tutorial (asynchronous or other) on the techniques I used in this project?
    • Should I present about this work at a domain conference (paper, poster)?
    • Is the work worthy of a paper, either in collaboration with the PI or individually?
    • Are there new user requirements that have resulted from this work? Would a change in XSEDE’s offerings make this project much easier? If so, feed info UREP
    • Is it a good time for Nancy and Ralph to check in with the PI?

If more than one expert is assigned to a project, the lead expert should gather input and prepare a single report

Helpful Tip: Highlight any changes to the schedule in the report so the information can be updated in the project reporting system

Final Reports

Final Reports are mandatory for all projects including projects that are closed before their end date.  This includes projects that are terminated early. The report should include a statement as to why the project ended, for example, “ PI was unresponsive” “PI not ready for ECSS support” “Received help desk assistance” etc.

The information required for the final report differs from the quarterly report; the report should include:

  • Executive Summary
  • Statement by the PI
  • Chronology
  • Technical Details
  • Collaboration Details
  • Outcome and Recommendations
  • Lessons Learned
  • Impact
  • Publications
Final reports should be submitted within 3 months of the end of the project.
 
Link to final report template: Sample Final Report Template

 

NIP and ESTEO Assignment

ECSS experts assigned to non-project areas NIP and ESTEO have different requirements than those assigned to project areas.

NIP Activities

 

  • Meetings: Team teleconference meetings occur bi-weekly, all members are encouraged to attend.
  • Scouting: Leverage XSEDE outreach, user engagement, etc. to seek out user groups, communities, and digital services new to HPC/CI, with input from advisory bodies, NSF program directors, etc.
  • Selection: Help the "most ready" of these groups to launch and sustain successful projects using XSEDE resources. This may mean getting a startup grant and successfully applying for a research grant 1 year later, with or without advanced support. It may be necessary to convey new requirements for services and technologies to XSEDE, without which these projects cannot succeed.
  • Extended Collaborative Support: Recognize instances when these PIs and/or their communities need ECSS (ESRT, ESCC, ESSGW, or ESTEO) and make sure they obtain it.

For a project that was launched as NIP, this staff member will likely be the same NIP sponsor who scouted and selected it. The NIP sponsor may have to be part of the project team until the project reaches a point where the other team members clearly understand their tasks. At that time the NIP member should pull out to focus on scouting and selecting the next project.

ESTEO Activities

ESTEO team members may be contacted when XSEDE User Services or TEOS group submits a request for advanced support for training, education and outreach. When such requests are made, the Level 3 manager will evaluate the request, and if necessary identify staff to develop and deliver the content.
Members may develop their own advanced training materials based on their work with ECSS and are encouraged to do so. ESTEO members are often asked to review training materials or deliver training or represent XSEDE at different outreach events. Members are also asked to review educational allocation requests.

Outreach activities may also include conference/paper presentations based on ECSS projects.
 

Adaptive Proposal Reviews

All ECSS-ers are expected to help review “adaptive” proposals. On a quarterly basis, researchers submit allocation requests to the XSEDE Resource Allocation Committee or XRAC. The top 100 largest proposals are considered at a face-to-face meeting of XRAC reviewers. The rest of the proposals are reviewed by ECSS staff. Ken Hackworth (hackworth@psc.edu) manages the review process and will send out requests. New staff members should contact Ken to provide expertise based on the NSF Field of Science codes for easier proposal assignments. Proposal review tips are available at ECSS proposal review.pptx
 

ECSS Tools

 

ECSS Staff Meetings

Team Meetings: The Level 3 managers schedule team meetings for their areas. Each manager determines the frequency of these meetings. Members are encouraged to attend these teleconferences when scheduled. Full ECSS telecons are scheduled as needed.

Symposiums: ECSS presents a monthly symposium featuring the work of one or more staff member. The primary goal of this monthly symposium is to allow the ~80 staff members working in ECSS to exchange information about successful techniques used to address challenging science problems. Tutorials on new technologies may also be featured. Two 30-minute, technically-focused talks are presented each month. On a rotating basis, all ECSS-ers are expected to give a talk on their XSEDE work. This event occurs on the third Tuesday of the month and is open to the entire XSEDE community. Talks are listed at http://www.xsede.org/ecss-symposium.

Face to Face:  In person meetings occur annually at the XSEDE conference. This meeting gives the management team an opportunity to meet with staff members to share information and to get feedback on any issues or concerns.
 

XSEDE Wiki Page

The XSEDE wiki page is the online presence for the staff community. All areas of the XSEDE project are represented. The ECSS section of the wiki includes informational pages for each of the five areas and a management section. Information that can be found on the wiki includes meeting notes, workplans and reporting templates and staff contact information. These pages provide excellent resources and should be visited frequently.

XSEDE Wiki Link:XSEDE Staff Wiki, all ECSS areas have links from here

Campus Champions Fellows program

This program, described at https://www.xsede.org/web/guest/ccfellows, pairs a selected XSEDE Campus Champion with an ECSS staffer to work side by side for a year on an ECSS project(s). The goal is to transmit ECSS expertise to those who can have a big impact on campuses. Typically in the spring a list of active ECSS projects is compiled. Project PIs give their consent to participate. ECSS staff assigned to the projects compile prerequisite skill descriptions. Generally by June, Fellows are selected and assigned. PIs and ECSS staff are part of the decision-making process. Fellows are assigned to an ECSS mentor for one year. Fellows are paid a stipend equivalent to 20% effort in order to set aside other duties to focus on the collaboration. For ECSS staff members, a Fellow assignment counts as if it were a project assignment, so an ECSS staffer working on a project and mentoring a Fellow would be considered to be working on two ECSS projects.
 

ECSS Contact Information

A list including all ECSS staff members, their contact information and their areas of expertise is available at ECSS Staffing- Updated June 3, 2019.

Ralph RoskiesLevel 2 ManagerECSS-Projectsroskies@psc.edu
Nancy Wilkins-DiehrLevel 2 ManagerECSS-Communitieswilkinsn@sdsc.edu
Jay AlamedaLevel 3 ManagerESTEOjalameda@ncsa.uiuc.edu
John CazesLevel 3 ManagerESCCcazes@tacc.utexas.edu
Lonnie CrosbyLevel 3 ManagerESRTlcrosby1@utk.edu
Marlon PierceLevel 3 ManagerESSGWmarpierc@iu.edu
Sergiu SanieleviciLevel 3 ManagerNIPsergiu@psc.edu
Karla GendlerProject ManagerECSSgendlerk@tacc.utexas.edu
Marques BlandProject ManagerECSS

mbland@tacc.utexas.edu

  • No labels