itaps-parallel ITAPS tutorial submission for SC08

Lori A. Diachin diachin2 at llnl.gov
Wed Apr 9 12:49:36 CDT 2008


Tim,

Thank you for your many excellent suggestions - I incorporated most of 
them.  I think we need more discussion on how we will handle 'hands-on' 
exercises.  I see Tim's point about mixing and matching lecture and 
exercises - provides variety and breaks things up, early exercises 
provide a solid foundation for later concepts, etc.  However, I share 
Karen's concern regarding building/configuring tools - we can't 
anticipate what sort of environment folks will bring with them, so at 
the very least we need a back up plan.  I know that in the past others 
have been unsuccessful in getting a uniform environment on site (e.g. 
laptops of all one flavor) - which is why we may want to consider 
providing something we control off-site w/ guest accounts.  For obvious 
reasons this won't work at LLNL, but could it work at ANL or, perhaps, 
RPI or UBC?  

Can we consider a format that is lecture (2 hour), exercises (1 hour), 
lunch, lecture (1-1.5 hours), exercises (1-1.5 hours), so that we have 
lunch time to help mitigate unforeseen problems?

Thoughts?

Mark - do you have specific suggestions on how you would increase the 
emphasis on parallel?

The latest version is attached.  I haven't made many changes to the 
hands-on discussion yet - those are pending this discussion.

Lori


Tim Tautges wrote:
> Comments:
>
> Abstract:
>
> - "particularly as architectures move toward the petascale" - this may 
> be sacrilege, but this might be a good place to plant a flag and say 
> "particularly as applications move toward component-based designs" or 
> something like that.
>
> Goals and Target Audience:
> - The statement about scientists generally having an application in 
> hand from which they want to access services is a bit too strong, IMO 
> - we should also target those wanting to assemble such codes, e.g. the 
> groundwater and GNEP types.
>
> Prerequisites: might want to mention that cd drive may be acceptable too.
>
> Relevance:
>
> A little wordsmithing on this paragraph; my replacement:
>
> The advent of petascale computing will enable increasingly complex,
> realistic simulations of PDE- based applications. Numerous software
> tools are used to help manage the complexity of these simulations,
> including computer-aided design systems used to represent the geometry
> of the computational domain, advanced mesh generation tools to
> discretize those domains, solution adaptive methods (AMR) to improve
> the accuracy and efficiency of simulation techniques, and parallel
> tools such as dynamic partitioning to ease implementation on today's
> computer architectures.  However, managing the complexity of
> interactions between these services, in parallel, is becoming
> increasingly difficult, leaving developers little time to focus on the
> science of their applications.  The ITAPS center focuses on providing
> tools to fill specific technology gaps, along with underlying
> interfaces providing interoperability between these tools and
> mesh-based applications.  Mesh- and geometry-based tools which enable
> PDE simulation continue a trend towards high-performance libraries
> started by solvers, and we believe these tools will have similar
> influence on application scientist productivity.  We will demonstrate
> this using examples from applications ranging from accelerator and
> fusion modeling to nuclear reactor and groundwater flow simulations.
> These examples will show how scientists are leveraging ITAPS
> technologies to increase their simulation accuracy, allow them to
> operate more effectively on complex computational domains, or reduce
> the total time to solution.
>
>
> 2. ITAPS data model:
>  "... introduce the ITAPS data model and its three core data types:
> mesh geometry,  and fields. " -> "... introduce the ITAPS data model 
> and the three core ITAPS interfaces for mesh, geometry, and fields."
>
> 3 (svcs & tools), 4 (interfaces): I'd vote for switching the order 
> here, making sure to make the interfaces section short enough to not 
> interrupt the flow too much.  I don't think it'll make as much sense 
> talking about the two basic models in 3 before discussing 4.  Tough 
> call, though.
>
> 5 (using ITAPS): if you look at the Goals & Target Audience section, 
> you stress existing applications before new ones.  Given that, I'd 
> switch the order of experiences in this section.  It's probably more 
> intuitive for us to think about building a new application like 
> reactor modeling, but the apps people will want to hear about biting 
> off a smaller chunk first.
>
> Hands-on exercises: mention that they'll be dispersed through 1-5 at 
> appropriate times, to reinforce concepts.
>
> Coordination of presentation:
> - mention largely positive reviews from Scidac07
> - mention that examples from tutorials are used for testing and 
> available directly with ITAPS interfaces
>
> Description of ... Exercises:
> Content:
> - After mention of Hello ITAPS, might also want to mention that this 
> will verify installation of basic iMesh installation on attendee 
> machines, and maybe mention that ITAPS participants will be available 
> to help in this process.
> - replace mention of geometry/relations with smoothing (MSQ) service; 
> I think installation of a geometry package will be too involved, and 
> I'm not sure the OCC version of CGM will be bulletproof enough by then 
> (I would consider making this one of the advanced exercises in this 
> tutorial, I just don't want to position it so prominently).  I suggest 
> moving #4 to #6 and moving 5-6 down to 4-5.
>
> Development Plans - is this section a paste-o?
>
>
> Presentation Approach: "The most effective approach to a hands­on 
> session is to provide the students with a complete set of written 
> instructions and let them work at their own pace" - I'd change to "The 
> most effective approach to a tutorial is to mix presentation and 
> handson materials, providing students with a complete set of 
> presentation materials and allowing them to work at their own pace".  
> This might conflict with the notion of shortening the tutorial to .5 
> day, though.
>
> Facilities: Need to find out if any are available from SC08, maybe 
> from vendors (e.g. sanitized laptops with some standard linux 
> installation).  Should also make sure to encourage attendees to bring 
> own linux laptops and try installing tools there, so they can take 
> them home with them.
>
> Detailed outline: I feel fairly strongly that results would be better 
> if we mixed lectures and exercises.  Could put a note at the end 
> saying we'd remove handson stuff if only 1/2 day were available.  For 
> ITAPS, I think a full-day tutorial would be MUCH more effective at 
> evangelizing, and traction-wise this might be a good time to push for 
> that (e.g. attention we're getting from TRILINOS).
>
> That's all I have :).
>
> - tim
>
>
>
>
>
>
> Lori A. Diachin wrote:
>> Hi All,
>>
>> Here's a draft of the submission for SC08.  Please take a careful 
>> look at what I'm proposing as there may be more work here than anyone 
>> is willing to sign on for.   Also, I tried to reorganize it to some 
>> extent based on our discussions in Atlanta, but couldn't find a good 
>> way to make it work - I'm open to suggestions.
>> This is due on Monday, April 14, so please provide your input by 
>> Thursday of this week.  I'm also open to having a telecon to discuss 
>> this on Thursday if folks are available.
>>
>> I also need 3 volunteers for the actual presentation and your two 
>> page vitaes - including short courses taught.  Any takers?
>>
>> Thanks,
>> Lori
>>
>> Here's what I need to submit:
>>
>> Upload your tutorial proposal as a single file in either PDF. Your 
>> proposal should include the following sections, each labeled as such 
>> and beginning on a new page:
>>
>>   1. Abstract (150 word maximum).
>>   2. Detailed description (2 pages maximum) containing:
>>          * tutorial goals - specifically how attendees will benefit;
>>          * targeted audience;
>>          * content level (% beginner, % intermediate, % advanced);
>>          * audience prerequisites;
>>          * why the topic is relevant to SC attendees;
>>          * general description of tutorial content;
>>          * if your presenters are from different institutions, how you
>>            will ensure cohesive tutorial content;
>>          * if your tutorial has been presented previously, how you will
>>            update it for SC.
>>   3. Description of Demo or Exercises for hands-on tutorials, if
>>      applicable. (1 page maximum). Include description of any hardware
>>      needed and how you will provide it.
>>   4. Detailed Outline of the tutorial (1 page maximum in outline form).
>>   5. Resume or Curriculum Vitae for each presenter (4 presenters
>>      maximum, 2-pages maximum each). Make sure this includes a list of
>>      short courses the presenter has taught.
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itaps-proposal-sc08.pdf
Type: application/pdf
Size: 996457 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/itaps-parallel/attachments/20080409/7d16c914/attachment.pdf>


More information about the itaps-parallel mailing list