itaps-parallel ITAPS tutorial submission for SC08

[Devine, Karen D]

Here is just a thought -- not a requirement -- on Mark's suggestion.

Another option to increase the emphasis on parallelism would be to *not*
call parallelism out only with specific bullets but, rather, incorporate
parallelism into many of the existing bullets.  That is, we could make it a
pervasive, integral part of the entire tutorial, rather than only a separate
item.  For example, part two of the outline could be something like the
following:

2.  ITAPS data model (lecture format)
a. Core data types: Meshes, Partitions, Geometry, and Fields
/** here would include both the mesh data type and the underlying parallel
partition model.  **/
b. Basic Building blocks: Parts, Entities, Entity Sets, Tags
c. Managing the relationships between core data types

Part four could be something like:

4. ITAPS interfaces (lecture format)
a. Design philosophy and basic tenets
a2. Accessing global (or meta) information
/** here would include both serial and parallel interface, e.g., both
getNumEnts and getNumEntsAll, as well as partition interface functions; or
the partition interface functions e.g., getNumParts, could be a separate
bullet. **/
b. Accessing local information using arrays and iterators
c. Modifying the underlying parallel database
/** here would include adding entities locally as well as off-processor. **/
d. Parallel operations /** here would include communication/ghosting
interfaces **/
e. Language interoperability through the C interface and through SIDL/Babel


BTW, Lori, thanks for putting the proposal together.  Vitus and I think it
is very good!

Karen


On 4/9/08 1:08 PM, "Mark Shephard" <shephard at scorec.rpi.edu> wrote:

> Lori,
>
> The most concrete change would be to the Tutorial outline. Currently the
> only obviously parallel stuff is items d in two of the overall topic
> areas. For super computing I would suggest having one of the top level
> items being out overall approach to parallelism and the parallel interface.
>
> Past that, I would just say emphasize more about parallel mesh and its
> importance various places in the discussions.
>
> Mark
>
> Lori A. Diachin wrote:
>> 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.
>>>>
>>>>
>>>
>
>
>