Hello, The meeting last Friday with ASCR and NNSA went very well. I've checked the slides into the repo, and the next step is some very hard work gathering information and planning. Sorry... but expect more mail and to-do items. Here are some notes from the meeting that Jack, Paul Messina, Rick, and I put together: ((in no particular order, just notes on the conversation)) * Folks liked the concept that modest hardware architecture/functionality changes could simplify some of the system software that has to be developed and that it is realistic to believe that hardware vendors would consider implementing such suggestions. The topic came up while we were discussing Blue Gene and some changes we had pushed to allow diagnostics that could be run as backfill jobs in the queue. * There was a discussion about "mortgages". NNSA has invested in several technologies that have become widely used by application scientists at NNSA labs (Open Speedshop, Totalview, Lustre, etc). NNSA now carries the "mortgage" on these packages since they don't have a large enough market or user base to get key enhancements from the community -- meaning to carry them forward for each successive platform requires rather significant funds. Thuc pointed out that whatever the ESC plan, we should carefully consider the mortgages created. * In a similar discussion, Thuc pointed out that data analysis software and viz tools were largely up to the applications. Since the data analysis and viz is still funded, the issue really seemed to be more of an accounting issue --- which funding bucket does the work come from... the apps or the system software. Thuc seemed to indicate having the apps fund it helped her, but I'm not sure how. * We discussed the new world of checkpointing... Dan agreed that standard checkpointing to a filesystem would not scale, and that in-system storage could support more sophisticated error recovery (and probably not full-system checkpointing). We discussed for example, that with in-system storage, maybe a "file" was not the right abstraction, but that saving out persistent arrays and objects to NVRAM may be more suitable. * Along the same lines, we discussed data analysis, and that pushing all the data to a filesystem for later exploration would not scale well. Dan gave the analogy of the LHC... there is some filtering that has to happen between the experiment (detector) and the disks. Likewise, he agreed that doing in-situ analysis, and supporting the framework for that (even if the specific tool was supported via the application team) would be good. * Both of these topics (checkpointing and viz/analysis) would require more sophisticated run-time systems. * Everyone suggested we start with a narrow scope, and then grow it with funds and success. * HQ would like an observer at the January meeting, and by then we should have a good estimate of version 1.0 * It is important that at the March review we have a good communication plan, one that includes discussion of education, web sites, blogs, workshops, etc. * We do not need to track DARPA carefully. Folks said it was a "long story", but not to worry about aligning too closely. Nevertheless, it seems we need to be prepared to answer questions and explain any overlapping work. * We had a very animated discussion about virtual machines and emulation environments. Environments like Google/Android and the iPhone have development environments that can be downloaded. (I demonstrated virtualbox and my ubuntu and winxp images running on my mac). The notion that we might want to have a simple to download virtual machine environment like ARM and x86 have was well received. We discussed the idea that the hardware RFP might just want to specify that as part of the system. It could help test different ideas as well as support QA and even education. * At the review in the Spring, it was suggested that we prioritize things kind of like a travel guide book... one '$' or '$$' or '$$$' depending on the money a portfolio may require. * In the spring, ASCR is going to have a meeting where they will showcase the research they are funding. Any ESC plan should understand that effort. * We agreed that the ESC was focused on Open Source, and not commercialization or productization. We should (as explained above) have a plan for the "mortgage". However, from what I could gather from the discussion, I didn't get the impression that folks thought vendors reduced the mortgage. * Folks believe BSP is dead and that task and graph methods of programming may be more scalable. Someone said "BSP does not scale to 1 billion cores", and everyone agreed. * The notion of a unified run-time system that can support composition of programming models so folks could move away from their current model in an incremental fashion was well received. -Pete