<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 11:10 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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><div>

This is not a real argument against, but I don't think this is the only place we have this dependency.</div><div>For example, even with dynamic loading, we have a list of libraries to load up front. I don't think this</div>

<div>is any different.</div></div></div></blockquote><div><br></div><div style>We still have --with-single-library=0 and I think it's good to keep something like that working for low-memory environments. I would be willing to have it called automatically for --with-single-library=1 and to require the user to explicitly call XXInitializePackage(comm) when using split libraries (instead of doing it automatically in XCreate, or only do it automatically when the comm is COMM_WORLD, otherwise error), where XX can be only the highest level package the user wants to interact with.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><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>
<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></div><br>This sounds really fragile to me, since all the logging stuff relies on it and it collective.</div><div class="gmail_extra"></div></blockquote></div><br>Yeah, the implementation is not especially simple so I'm happy to retract this idea.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Does this withdrawing autoloads mean we should remove the third argument of XXRegisterDynamic? Maybe autoloads should exist, but be registered alongside a comm.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>What do you think about having one registration implementation that would use PetscClassId to index the PetscFunctionList? I think that could remove a huge amount of copy/paste code.</div>
</div>