<div dir="ltr">On Tue, Feb 5, 2013 at 12:29 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: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><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><div>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></div></blockquote><div><br></div><div style>I see nothing wrong with those tradeoffs, its just beginning to sound complicated to me (like the Fortran stuff I can never remember).</div><div style>I would say, if you split the libraries, you have to do everything manually, and we just error out if you don't. That is easy to remember,</div>
<div style>and I think its harder for a user to have a working code that breaks mysteriously when one thing changes, like the comm.</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 class="gmail_extra"><div class="gmail_quote">
<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>
<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></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">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"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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>
</blockquote></div><br>I think this sounds workable.</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>