<div dir="ltr">On Tue, Feb 5, 2013 at 12:08 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Mon, Feb 4, 2013 at 11:01 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>   Now we need to make several more decisions.<br>
<br>
1) are PETSc package registrations collective? sys, vec, mat, dm, ksp, snes, ts<br>
     currently as Jed noted they are not except with dynamic loading of PETSc libs<br>
<br>
2) are all PETSc packages registered upfront during PetscInitialize()?<br>
    currently only with dynamic loading of petsc libs<br></div></blockquote><div><br></div></div><div>I don't like the reverse dependency that this implies.</div></div></div></div></blockquote><div><br></div><div style>
This is not a real argument against, but I don't think this is the only place we have this dependency.</div><div style>For example, even with dynamic loading, we have a list of libraries to load up front. I don't think this</div>
<div style>is any different.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
2a) If all PETSc packages are registered up front what is the mechanism to turn off registering some? Thought Matt disagrees there is always some asshole who says, I don't use TS so I don't want it registered.<br>

</div></blockquote></div></div><br>Can we make XXInitializePackage() collective on an explicit comm _and_ safe to call on a communicator for which some ranks are already initialized?<br></div><div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I think this would make it possible to provide a deadlock-safe implementation. A user should explicit call XXInitializePackage(comm) if they ever encounterd IO performance issues (due to collective loads on many small comms).</div>

</div>
</blockquote></div><br>This sounds really fragile to me, since all the logging stuff relies on it and it collective.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>
-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener
</div></div>