<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">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 id=":1e4">   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 style>I don't like the reverse dependency that this implies.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1e4">
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><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" style>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>