Changes between Version 49 and Version 50 of CodeCampIII


Ignore:
Timestamp:
Feb 26, 2015 8:33:16 PM (9 years ago)
Author:
butler
Comment:

filling out the report — still needs cleanup and editing

Legend:

Unmodified
Added
Removed
Modified
  • CodeCampIII

    v49 v50  
    88Local arrangements were made by Torben Nielsen and Thomas Larsen with details on the [wiki:CodeCampIIIPlanning planning page]. 
    99 
    10 == Goals for the Code Camp == 
     10== Initial goals set for the Code Camp == 
    1111* Release 3.1 with minimum requirements: 
    1212  * New Models interface 
     
    4040== Progress and Outcomes == 
    4141 
    42 The code camp gathered 10 developers working full time for over a week on the sasview code base.  Further, the team was joined in the latter half of the camp by 2 new developers (Wim Bouwman and Jurriaan Bakker from TUD) interested in adding support for SESANS data to the SasView package.  Several major advances were made 
     42The code camp gathered 10 developers working full time for over a week on the !SasView code base.  Further, the team was joined in the latter half of the camp by 2 new developers (Wim Bouwman and Jurriaan Bakker from TUD) interested in adding support for SESANS data to the !SasView package. 
    4343 
    44 The camp began with an introduction by Paul Butler outlining the goals for the week. A [wiki:CodeCampIIIScheduleAndWork schedule and series of work packages] were formulated to guide the work. 
     44The camp began with an introduction by Paul Butler outlining the goals for the week. Three major themes were identified as critical to the long term viability of !SasView as a collaborative, community project: good and well maintained documentation, both user and developer, low barrier to entry for new developers, and ease of including new models both for developers and users. A [wiki:CodeCampIIIScheduleAndWork schedule and series of work packages] were formulated to guide the work. 
    4545 
    46 The first task was to migrate the SasView code repository from SourceForge, which has been problematic of late, to Github. This was successfully accomplished. Migration included redirecting host names, editing trac and web pages, moving web pages hosting from UTK to github as well as updating all the developer machines.  In the process the final phase of renaming and reorganizing the folders in the SasView tree was completed.  The official build servers and Jenkins site were moved to the DMSC servers and the development finally moved from using the old wx 2.8 to using wx 3.0. 
     46Besides addressing a number of feature requests and bug fixes, the first task was to migrate the !SasView code repository from SourceForge, which has been problematic of late, to Github. This was successfully accomplished. Migration included redirecting host names, editing trac and web pages, moving web pages hosting from UTK to github as well as updating all the developer machines.  In the process the final phase of renaming and reorganizing the folders in the !SasView tree was completed.  The official build servers and Jenkins site were moved to the DMSC servers and the development finally moved from using the old wx 2.8 to using wx 3.0. 
    4747 
    48 With the move to wx 3.0 the documentation re-write started at code camp II at ISIS was completed with a porting of all the non-model documentation to RST files that can be built by sphinx. The new documentation was integrated into the gui simplifying the code in the process.  Most of the non-model documentation was also carefully edited and updated. 
     48With the move to wx 3.0 the documentation re-write, begun at code camp II at ISIS to start addressing the first theme above, was completed with a porting of all the non-model documentation to RST files that can be built by sphinx. The new documentation was integrated into the gui simplifying the code in the process. Most of the non-model documentation was also carefully edited and updated.  With this restructuring, both the user documentation, now provided in RST files, and the developer documentation, provided in the doc strings included in the code by the code author, are automatically generated and pushed to the website with each build.   Further simplification is expected when the new model structure discussed below is completed. Thus the task of editing and updating user documentation is now greatly simplified making that task more manageable and should allow for better and more timely upkeep as we move forward.  Meanwhile the ease of access to the developer documentation should encourage better code documentation and starts addressing the second theme of lowering the barrier to entry for new developers. 
    4949 
    50 A very large effort to completely restructure the models interface, move models into an independent package and support GPU computing was begun and while not finished progressed far enough that a code branch integrating the new sasmodels package into sasview was created. Approximately a quarter of the existing models were moved to the new package during the code camp. The next steps are to move the remaining models, integrate magnetic models, ensure full test coverage and generate a build with the new package for beta testing. This work was more ambitious than originally envisaged, but it provides major advantages and it was determined that it was better done as one integrated effort rather than piece by piece. 
     50With respect to that second theme, getting a developer environment properly installed has historically been a huge barrier, both for “amateur” developers lacking experience in installing the plethora of required packages and getting them running together, and for more professional programmers who may have a number of the wrong versions of required packages already installed.  To address both issues as well as others, such as ensuring that new required packages get propagated easily to developers and build machines, the Anaconda scientific python distribution was explored. This looks like a promising solution and significant progress was made in implementing it.  
     51 
     52In order to address the third theme, a very large effort to completely restructure the models interface, move models into an independent package and support GPU computing was begun and while not finished progressed far enough that a code branch integrating the new sasmodels package into sasview was created. Approximately a quarter of the existing models were moved to the new package during the code camp. The next steps are to move the remaining models, integrate magnetic models, ensure full test coverage and generate a build with the new package for beta testing. This work was more ambitious than originally envisaged, but it provides major advantages and it was determined that it was better done as one integrated effort rather than piece by piece.  When complete, the learning curve for developers adding a new model should drop from many days to a few hours while implementing a new model should also drop from a day or more to a few hours at most.  User supplied models will have full access to the SasView infrastructure (in particular the polydispersity) and will be able to be supplied in C as well as python. As an added bonus, SasView will gain transparent access to multiprocessing and GPUs on many computers. 
     53 
     54The SESANS project, a completely new feature, championed by the delft group, progressed remarkably rapidly partly aided by the new models interface.  The data is now recognized by and can be loaded into SasView.  Further, the current sasmodels can be used (by running through a Henkel transform routine), in conjunction with BUMPS optimization engine, to fit the data. Thus SESANS data can now be analyzed with SASVIEW using the command line using any models which have been ported to the new structure.  Adding support for analytical SESANS models and Fully integrating with the GUI will be the next steps.  
     55 
     56Finally, the group spent a half day discussing the long term needs, desires and dreams for the future of SasView.  Questions discussed ranged from technologies to use and where they are currently headed,  to immediate requests from instrument scientists at facilities, key new features, and to visions for pipelining, web applications and  submission of large calculations to clusters.  Priorities were also touched upon. The goal is to use that discussion to develop the first roadmap document for the project, an exercise currently underway. 
    5157 
    5258