Notes from the NSF Panel at the Building SI2 Communities Workshop
- Almadena Chtchelkanova (CISE)
- Jennifer Schopf (GEO)
- Gabrielle Allen (OCI)
- Clark Cooper (ENG)
- Evelyn Goldfield (MPS)
- Peter McCartney (BIO)
-- How software fits into their programs
Alamadena (CISE)
-- encouraging use of software engineering
-- how do you teach your students to write programs using software engineering techniques?
-- what would you like from CISE - what tools would you like to teach your students software engineering?
Jennifer (GEO)
-- working to build a CI framework for the GEO community, share knowledge, increase participation
Clark (ENG)
-- takeaways from yesterday that resonated with Clark: hardening/robust software
-- takeaways from yesterday that resonated with Clark: career path for developers
--
Gabrielle (OCI)
-- important to continue to support software, but also community frameworks - get communities sharing more, within and across disciplines
Evelyn (MPS)
-- computational chemistry - large numbers of applications, she funds methods -
-- concerned about lack of software engineering, documentation, and duplication of effort
-- new challenges with new hardware
-- tools are often used by experimentalists - so the codes must be reliable, hardened
Question: RossW - for the various NSF directorates, is there roughly equal funding for software?
-- different disciplines provide different funding levels - fund projects that align with their vision statement
-- many software projects are jointly funded across directorates
-- amount of funding deployed is not always the same as amount set aside - depends upon proposals received
Question: Interdisciplinary software - requires more than just good software engineering - requires science domain knowledge as well testing the code against validated data/results. You can have "good code" but it could give you the wrong result. How do we get software engineering into scientific software development?
-- Scientific software development is different. NASA does this. CISE is trying to develop an education module.
-- It would be good to have funding for this. CISE is interested.
-- Difficulty - it takes 5 years to build robust, engineered code. NSF grant is 3 years.
-- Difficulty - grad students do most programming of scientific software. These are domain scientists, not computer scientists.
-- Many codes developed over 20 years. Not feasible to rewrite the entire code.
-- The solution is not as simple as "the CS guys will save us". Not all CS are software engineers or follow software engineering practices.
-- Curriculum needs to be well-defined, and the scientific software developers in this room need to provide their guidance.
-- Code documentation needs to include the "science lesson" and examples - what is the code good for, what scientific problems can it solve, what are the boundaries/limitations?
-- How different is software engineering for scientific codes vs best practices standard software engineering? Why is it different (is it?)?
-- A big difference is that users are programmers for scientific codes. For other programs, users do not write the code (like this wiki).
-- NSF Bioinformatics - recently separated projects into 2 categories of "innovative" and "development". Innovative enables the new/different and development enables the improvement/hardening.
-- There is a difference between encouraging software engineering practices and hiring software development professionals. Scientific code developers need to be encouraged to use software engineering practices (training/education, tools, incentives).
-- Innovation can be enabled by sustainability. Can focus on the science problem when extending a code and not worry about things like I/O that are already robustly handled.
-- Science Gateways can enable sustainability - scientific code is embedded in a portal that robustly handles things like I/O so scientists can focus on enhancing the science aspect.
-- Comparing to DOE labs, but they have a centralized professional staff.
-- NSF funds various platform/frameworks (Kepler, Galaxy) that are intended to provide that sustained foundation so that scientists can focus on the science aspect of the code. Too often people start completely from scratch.
-- Management - a software project needs management and oversight. Students can know what to do, but without management and oversight it is easier to not code with good documentation, etc
-- The PI must value software engineering practices - it starts there.
Question: How important is it to you that your code be readable?
-- Comments are as valuable as the code. However, not everyone adheres to this.
-- Is it possible to have a centralized team that can meet for a week with the large software projects and do training for software engineering?
-- Tools are important and again, the PI must buy in. Using a framework that includes a repository, version control, automatic backup, bug tracking ...
Supercomputing conference (SC) has a new Best Practices Track. And next year Tutorials will be accepted as well.
New SIG at ACM for HPC. (SIG is Special Interest Group)
Final Words
-- SSI Planning Grant solicitation is out there now. This is not a way to get a bunch more funding for a specific scientific software. SSI's are broader in scope and can address many of the topics we've discussed here.
-- Need for modularity, standards, and the ability to re-use modules that are common across disciplines - and have that maintained centrally for all to use (port modules to new architectures, etc)
-- Software keeping pace with hardware. Hardware changes more rapidly than software development cycles.
-- Data management software was not discussed at all.
-- And a pitch from CISE to come be PO at NSF!