Primer on use of the SWIM IPS now available
CS Notes
Document Actions
Notes on CS issues that have come up during the discussions.
Visualization
- We should collect CAD files for the tokamaks we're simulating for use in creating nice visualizations (i.e. with Visit)
- How to specify monitor files on Elvis command line?
Data Management
- Need to capture simulation inputs (many obtained from outside sources) and metadata/annotations to help insure that we know what they are, who/where they're from, etc.
- Idea 1: Use SVN to record. Developer helper scripts to collect/validate metadata that needs to be collected. Use SVN commit hooks to enforce them. Need to make sure that data files people are actually using are actually checked into SVN (not modified). Is this enforcable?
- Idea 2: Setup a database (associated with portal?) for data and metadata. Put collection and enforcement on web. Design IPS (or helper) to retrieve desired inputs from a URL at job setup or execution time.
- Scott Kruger has experiences with this kind of thing from other projects. Suck his brain dry!
Portal
- How to open up portal status submissions to more than a few specific hosts (jaguar, franklin, viz, mhd)?
- Need to have mechanisms to indicate whether particular runs should be kept or purged
- Post-run command line to indicate keep/purge for the run
- iTunes-like star ratings
- Make tables sortable
- Provide search capabilities
- Annotations for runs. Auto-populated wiki?
- Conventions for run comments (perhaps more structured?)
Version Control
- Need to develop project guidelines for versioning.
- Production vs development versions, and how fast does production version change?
- Maybe all development should be done in a branch and then merged into trunk only after it is complete and tested? Currently we have multiple people changing the trunk simultaneously for different purposes.
Testing
- Tools for comparing simulation results
- Intelligent (i.e. floating point-aware) versions of diff
- Comparison of netCDF (or HDF) files (or selected elements)
- Guidelines for responding to test failures (i.e. who is responsible for resolving problems, how quickly?)
- Guidelines for testing prior to checkin or merger into trunk or going into production.
- Regression tests: If you depend on functionality of other parts of the software system, it is your responsibility to provide tests to insure that the functionality is still there. It is the responsibility of the developer of the other part to insure that all such tests are passed after any changes to the code.
Plasma State
- What to do with large data items? Make them "part of" the plasma state? A separate state instance? Standardized representations are needed.
- What to add to plasma state? (especially large items)
- First priority to large data items exchanged between components
- Next priority to component-specific state/restart data
- How to represent distribution functions?