Attending:
Emelie - UNL
Marko - FNAL
Suchandra, Lincoln, Rob - UC
Rob: (slides)
There has been an issue keeping connectbook up to date and managing components. Would also like to expand the base, so that new applications for one user group can serve as a template for other user groups.
Add rigor to code base by putting it into github. Place tutorial modules in there, and make updates with git. Track changes, etc.
Other part: mapping from github to connectbook doesn't have to be 1-to-1. Another application that is working on osgconnect can be loaded in as a repository.
Following software carpentry model: if we have osg tutorial session/bootcamp that uses specific version of what is running on osgconnect, we can create a repo just for that tutorial/bootcamp. Keep it there and refer back to it later. Nice place to capture materials and keep it organized.
Would be nice to have contributions from everyone.
Second slide:
A student here (Anton) is working on a continuous integration testing service. Checks out what is in the repo on a continuous basis. Validate that all the tutorial models are working all the time on osg connect. A series of unit tests that will get run periodically. If not working, can figure out what happened and fix/update it.
Can use this for other kinds of test to make sure things are working right (stash, etc).
Suchandra: (slides)
Installed modules and software for python 2.7.7 and 3.4.1 and various packages.
Currently working on R and Octave.
Helping a friendly user move workflow over to lmod - python modules are working correctly.
Moving forward: get R and Octave installed. Find a user group to help test the installs?
Also ran scripts to test python functionality on various sites.
12 sites tested. Was not able to run on 2 sites (probably because they were busy or some other reason). Both versions of python worked using modules. And the libraries worked as well.
Module tracking:
A group at harvard added functionality to track whenever users load modules. Adapted that method to our modules so that whenever a module gets loaded it pings a web server with information about site, user, hostname, module name. Web script accepts ping and loads into a db for later processing. Verified that all components work, and in the process of installing on oasis.
In answer to Emelie's questions:
db currently stored at UFC.
non-osg vo users should still have access to modules.
Emelie:
Installed NAMD module in OASIS.
Rob:
We should document this (modules) for users:
how to set up, how to use/load. And advertise it to osg connect users at least.
Question from Emelie about end-user code (can end-users install code/modules?)
Answer from Rob:
No, it doesn't really solve end-user code problem.
This is a little bit of a hybrid model that we're following here.
Reducing burden on end user by installing some software and leave door open for requests as well. This is providing a service essentially. Rather than having everyone install their own version of the same software. There will always be individual packages that some users want.
We will have an external repo for osg-connect users. If users don't need/want a formal software install (managed by modules), just copy code over into osgconnect external oasis repo which is then published and available at sites. This is the model that Brian has.
Details of how this is implemented in practice, is still to be determined.
Lincoln:
Installed and tested Blender modules.
Also just added Blast, but haven't done extensive testing of these.
Emelie:
What are some ideas for coming up with an initial list of software to install in the repo? I can list the module installed on HCC clusters and ask people here which ones would be most useful for OSG users.
Marko:
Could ask existing users what they need.
Send email to them, or just more organic: find out what users need as they come in.
Lincoln:
We should probably be proactive about it. If they see it is already here, then that is better.
Suchandra:
We probably have idea of what ~80% of users want/need.
Stuff we've already talked about:
R, Python, octave, namd, etc...
Marko:
Things like event generators - everyone uses different ones.
And the maintenance of the software could also be an issue (not just install once and forget about it).
Emelie:
Yes, we don't need to probably install software that only one person will use (unless they specifically ask for it - maybe).
Emelie: question about OASIS external repos. Is it too early to be thinking about this (testing)? Is anybody (VO) already using this?
Lincoln:
External repos still in pre-production. Would be premature probably.
Emelie asks about getting a ready-talk number.
Others:
Ready-talk is being phased out apparently.
No alternative at fermi yet. Might ask Chander.
Some other options:
uberconference
vidyo - fermi does not have contract with.
Skype
UNL telecom phone conferencing service
Emelie will be gone for most of July (back on July 30th). Will meet again July 15th, and Aug 5th.
For next time:
Emelie will look into quantum espresso - decide whether to install in OASIS and add module. And come up with software list based on HCC modules and feedback.
Suchandra will continue work with modules and begin writing user documentation to include on connectbook.
Lincoln will continue working on modules/installing packages.
Next meeting:
Tuesday July 15th at 2:00 p.m. (central)
Using Marko's Readytalk:
dial-in #: 866-740-1260
code: 6643420#