On Tue, Feb 5, 2013 at 12:29 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Mon, Feb 4, 2013 at 11:10 PM, Matthew Knepley <knepley at gmail.com>wrote: > >> 2) are all PETSc packages registered upfront during PetscInitialize()? >>>> currently only with dynamic loading of petsc libs >>>> >>> >>> I don't like the reverse dependency that this implies. >>> >> >> This is not a real argument against, but I don't think this is the only >> place we have this dependency. >> For example, even with dynamic loading, we have a list of libraries to >> load up front. I don't think this >> is any different. >> > > 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. > I see nothing wrong with those tradeoffs, its just beginning to sound complicated to me (like the Fortran stuff I can never remember). 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, and I think its harder for a user to have a working code that breaks mysteriously when one thing changes, like the comm. > >> >>> 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. >>>> >>> >>> Can we make XXInitializePackage() collective on an explicit comm _and_ >>> safe to call on a communicator for which some ranks are already initialized? >>> >>> 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). >>> >> >> This sounds really fragile to me, since all the logging stuff relies on >> it and it collective. >> > > Yeah, the implementation is not especially simple so I'm happy to retract > this idea. > > Does this withdrawing autoloads mean we should remove the third argument > of XXRegisterDynamic? Maybe autoloads should exist, but be registered > alongside a comm. > > > 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. > I think this sounds workable. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130205/3f1f1593/attachment.html>
