PeerMeeting

PEER

proposal/document outlining what we are going to do to meet their list of shortcomings.

1. Better documentation in wiki format for both modeling and analysis to adderess concerns over poor documentation and difficulty developers have in getting documentation uploaded.
2. Best of practice examples for industry users.
3. User requirements doc.
4. OpenSees Lite - fewer choices with validated models
5. Educate Users
   1. voice-over workshop slides
   2. fcf on nonlinear analysis video
   3. Better documentation
6. Data Output to database - better doc & test usability.
7. Possible GUI - Mahmoud to look at existing
8. For next release - registration update & surveymonkey before get to code when user hit download button.
9. Regular Webex meeting with Users!

NEES proposal

requirements from letter dated 14 Oct 09.

1. 2 Sections:
   1. Proposed Support Section:
   2. Proposed Development Section:
2. Must Include:
   1. The proposal should describe a plan to collect data to measure support activities, and must include data describing support requests. Data must include the number of requests, demographic information on the user community seeking support, effort required to resolve problems, and the time required per request.
   2. documented user requirements
   3. specific development activities, tasks, milestones, and deadlines that are directly traceable to documented user requirements, including a requirements traceability matrix (RTM)
   4. description of specific plans and timelines for submitting at least two competitive proposals to seek funding for support and development activities from other non NEESOps sources
   5. a description of the specific deliverables and development milestones and timelines for continued development of and deployment of BuildingTCL;
   6. a final report on the outcomes of the SimPortal development effort
   7. The proposal should describe the proposed management structure for the OpenSEES effort that includes Dr. Greg Fenves in an advisory and advocate role, with a reporting line from the OpenSEES Team to the NEESComm Team at Purdue

NOTES FROM PEER MEETING

OpenSource

1. Engage community spirit
2. Recognize limitations of open-source with regards to research based fe code
   1. Developers typically students who leave
   2. Developers working on individual classes
   3. Limited follow-up on fixes, maintenance and support after submission of code
3. Given limitations how can we help.

PEER document outlining problems with OpenSees from a users point of view created by outside consultant and OpenSees guru (Z.Yang - ucsd!)

1. Solution Documentation
2. User Command and Examples Manuals.
3. ??
4. Updated tech Manual.
5. GUI

Users:

1. We need an integrated user environment for PBEE design methodology from NGA database to fragility curves.
2. User Requirements doc. Where do we get the requirements?
   1. Projects currently funded
   2. Anybody who might get a project
   3. NEES user forum
   4. Survey (surveymonkey)
   5. Questionaires at meetings
   6. Industry
3. Documentation, Training & Outreach
   1. wiki
      1. PEER to provide student for moving current documentation
   2. Video-lecture library
      1. Filip nonlinear analysis video
   3. Links to papers (.pdf viewing in wiki)
   4. Productivity modules
4. GUI
   1. mahmoud to look at existing ones and comment.
   2. Interface with existing GID, GSA
   3. Develop new - ship to India
   4. look into commercial alliance
   5. damage visualization
5. OpenSees Lite
6. Verification (could do color coding in wiki Green, Orange, Red of command)
7. Database Usage in recorders
8. Integration with BIM?

Developers:

1. How to engage
   1. Carot & Stick
   2. If OpenSees more popular .. fact code in or code ranking, download count.
   3. Sell .dll
2. institute a Developer Task Force with regular meetings
3. coordination
4. How to give developers kudos
   1. Website count downloads.
   2. Website Ranking