<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Mohamad,<div><br><div><div>On Mar 12, 2013, at 8:28 PM, Mohamad Chaarawi <<a href="mailto:chaarawi@hdfgroup.org">chaarawi@hdfgroup.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<div text="#000000" bgcolor="#FFFFFF">
Hi all,<br>
<br>
I attached the slides that I presented at the Forum, and here are
some notes I took when discussing the proposals:<br></div></blockquote><div><br></div><span class="Apple-tab-span" style="white-space:pre"> </span>Good notes, thanks!</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">Collective I/O ticket:<br>
<ul>
<li>Need a more compelling reason to add them to the standard.
Maybe a more in-depth study and demand from users with use
cases. <br>
</li>
<li>Implementation of split collectives hard as is, so to add a
harder interface for implementers needs to be justified.</li>
<li>Will not attempt to deprecate the split collective in this
ticket.</li></ul></div></blockquote><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>OK, we can provide use cases, drawing from our experiences with HDF5.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><ul>
</ul><p>Asynchronous MPI Model:<br>
</p>
<ul>
<li>discuss whether it makes sense to introduce such a model in
MPI</li>
<li>Can something be done with generalized request?<br></li></ul></div></blockquote><div><br></div><span class="Apple-tab-span" style="white-space:pre"> </span>Someone always brings this up. :-) We should get up to speed on the GRQ routines and know what they can do...</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><ul><li>a more thorough study should be conducted on what internal MPI
features get exposed </li>
<li>Should consider an implementation path for MPI that does not
have threads.</li>
<li>No overhead should be introduced, which might not be the case
with RMA</li></ul></div></blockquote><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>What did people think of the idea in general?</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><ul>
</ul><p>Independent File View changes:<br>
</p>
<ul>
<li>The file_set_view operation should be used to do optimizations
(collectively), so adding an independent version would urge
developers to not "do the right thing" with the original
routine.<br>
</li>
<li>what happens in some cases when all processes set the file
view collectively, then 1 process changes its file view
independently? How would the other processes know that? The MPI
library might need to communicate that change to other processes
if the original set file_view did certain optimizations.<br>
</li>
<li>For our use case, we can introduce a flag on File open, that
says set_view is always independent or collective. We can
introduce also another collective routine to allow the user to
change set_view from independent to collective and vice versa.</li></ul></div></blockquote><div><br></div><span class="Apple-tab-span" style="white-space:pre"> </span>I like some of the latter ideas (file open option, etc). They would help take the backward compatibility risk out of the equation.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><ul>
</ul><p>Grouped I/O operations:<br>
</p>
<ul>
<li>A file_reopen with a sub group is a feasible solution, but
more though needs to be taken into consideration..<br>
</li>
<li>What are the consistency semantics for the new file handle
that is returned with open_grouped. this needs to be examine
more.</li>
<li>What happens if you opened the file twice, but with a
different communicator? Can MPI optimize that?</li>
<li>This also affects the file view that is set for the original
file handle. How would that play out now? allow grouped file
view changes on the new handle, or just allow independent file
changes?</li>
<li>do some benchmarking with existing MPI implementations to see
performance of Opening file multiple times.</li></ul></div></blockquote><div><br></div><span class="Apple-tab-span" style="white-space:pre"> </span>OK, sounds positive, we should work out answers to these questions...</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><ul>
</ul><p>Shared FP bug:<br>
</p>
<ul>
<li>emphasize the offset returned should be for where access
started.</li>
<li>go over all routines for shared file pointers and indicate why
only those three were chosen. We can add a position returned to
the ordered operation, it just seemed easy for the user to be
able to retrieve it.</li>
<li>generally seemed ok, but needed to emphasize use cases more in
proposal.<br>
</li>
</ul></div></blockquote><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>I would _really_like_ the "write_and_get" routine - that would make space allocation in HDF5 _so_ much easier! Getting a use case for this one won't be a problem. :-)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Sounds like a good meeting, with some things we can move forward. :-)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Quincey</div><div><br></div><br></div></body></html>