On Tue, Feb 5, 2013 at 12:08 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Mon, Feb 4, 2013 at 11:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > >> Now we need to make several more decisions. >> >> 1) are PETSc package registrations collective? sys, vec, mat, dm, ksp, >> snes, ts >> currently as Jed noted they are not except with dynamic loading of >> PETSc libs >> >> 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. > 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. 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/8a2dbbd4/attachment.html>
