[Fwd: Re: itaps-parallel Today's phone conf]

[Mark Shephard]

I still wonder if we are chasing the wrong rabbit and going in all sorts 
of confusing directions without a clear understanding of the 
functionality we want to support for users. Since I have totally lost 
track of the actual issues on some of this latest set of discussions, I 
do not know what is of real importance and what is not.

In any case I have a lets back-up question that may be meaningless. In 
any case, in early discussions we stated that the mesh on an individual 
part was a serial mesh supported at the iMesh level with the only 
complexities being on part interfaces. If that is the case, it is a 
concern that the only way we see to proceed is to add information to 
every iMesh entity about parallel stuff, or is it really tracking the 
dealing with multiple instances (however that is defined). (Note if the 
issue is really that of working with multiple instances, I suggest we go 
back to serial iMesh and solve it there before talking parallel.

If we really find that we have to do all these things being discussed, 
then we need to, but I would like to ask those looking at the details to 
be sure to have paused and really defined the functional needs (from an 
applications viewpoint) that requires all this complication. I say this 
because to the best of my understanding, I feel we can really meet the 
applications needs without all the complexity on stuff we have a hard 
time explaining to ourselves, which means we have basically no chance of 
explaining to applications people.

Mark S.

Lori A. Diachin wrote:
> What did you all think of Mark's proposal to create a function that 
> temporarily combines the three arguments into an iMesh instance 
> temporarily?   This would require underlying iMesh instances be able to 
> keep track of the data somehow, and would require an extra function call 
> (perhaps a lot of extra function calls), but would keep the serial 
> interface clean....
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: itaps-parallel Today's phone conf
> From:
> Mark Miller <miller86 at llnl.gov>
> Date:
> Mon, 17 Dec 2007 14:24:57 -0800
> To:
> "Devine, Karen D." <kddevin at sandia.gov>
> 
> To:
> "Devine, Karen D." <kddevin at sandia.gov>
> CC:
> "itaps-parallel at mcs.anl.gov" <itaps-parallel at mcs.anl.gov>
> 
> 
> Hi all,
> 
> I just wanted to follow-up on the proposal to add partition and part
> handle args to many iMesh functions.
> 
> What if we had some function such as
> 
> iMesh_Instance *iMesh_foobar(iMesh_instance *mh, <partition handle>, <part-handle>)
> 
> that would take the three handles and produce a, *very* temporary
> iMesh_Instance thingy -- that an implementation could easily learn
> was 'special' in that it housed partition and part handles -- that
> could be passed into the iMesh interface? This would help us to avoid
> modifying the actual interface everywhere and ensure that the
> implementation could still get access to partition handle and part
> handle information when (and if) it needed to.
> 
> In particular, would this work in the presence of the multiplexor or
> not?
> 
> Also, regarding the note below regarding how 'concrete' I thought
> the parallel interface is, let me just emphasize the (implied)
> 'for him' part of that note. As in, "Mark M. commented that the 
> parallel interface is not yet concrete enough *for*him* for pseudo-code
> application." Karen was probably just being nice by not culling
> that out explicitly. But, I thought I should ;)
> 
> Mark
> 
> 
> 
> "Devine, Karen D." wrote:
>> Here are the notes from today's phone conference.
>>
>> -  We discussed Carl's proposal to overload the mesh instance argument with
>> partition instances and/or part handles to perform set operations.  Jason
>> expressed concerns that the overloading would make implementing the
>> multiplexer difficult (at best), and would complicate the implementations as
>> well.
>>
>> -  Lori proposed adding partition information to the argument lists of the
>> existing iMesh set-based functions.  We agreed that we could change the
>> iMesh interface, adding partition instance and part handle arguments to
>> needed functions.  Serial implementations could pass NULL for these
>> arguments.
>>
>> -  Karen will fold this idea and other proposed syntax into the combined
>> document for review before the next phone conference.
>>
>> -  Mark M. discussed his code that performs many parallel ITAPS functions
>> using the serial interface.  He can use this code to identify functionality
>> that is missing or extraneous in the combined document.  Mark M. commented
>> that the parallel interface is not yet concrete enough for pseudo-code
>> applications.
>>
>> -  Lori discussed the agenda for the March 11 bootcamp.  This bootcamp will
>> be our chance to describe the parallel interface to our other ITAPS team
>> members, so we should have something concrete to present and, perhaps, some
>> pseudo-code showing how to use it.  The bootcamp will also include a
>> discussion of Carl's paper and a talk by Ahmed on ORNL activities.
>>
>> -  The proposed time for the next phone conference is Jan 7 at 1:30 PST.
>> Let me know if that time doesn't work for you.
>