[petsc-dev] de-global variablelizing PETSc
Matthew Knepley
knepley at gmail.com
Sun Nov 10 07:31:47 CST 2013
On Sat, Nov 9, 2013 at 6:09 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> As Jed has already noted I have an extremely ugly branch
> barry/make-petscoptionsobject-nonglobal which was a minimal effort change
> to get the PetscOptions… code to not use any global variables. I made
> PetscOptionsObject be inside the PetscOptionsBegin() macro but tried to
> hide it from the API and secretly pass it to the PetscOptionsInt() etc
> function. But it cannot be completely secret since it has to be passed to
> things like (*obj->setfromoptions)()
>
> I had to make it even uglier by having PetscInitialize() call
>
> +
> + ierr = PetscThreadCommInitializePackage();CHKERRQ(ierr);
> + ierr = PetscThreadCommWorldInitialize();CHKERRQ(ierr);
> + ierr = AOInitializePackage();CHKERRQ(ierr);
> + ierr = PetscSFInitializePackage();CHKERRQ(ierr);
> + ierr = CharacteristicInitializePackage();CHKERRQ(ierr);
> + ierr = ISInitializePackage();CHKERRQ(ierr);
> + ierr = VecInitializePackage();CHKERRQ(ierr);
> + ierr = MatInitializePackage();CHKERRQ(ierr);
> + ierr = DMInitializePackage();CHKERRQ(ierr);
> + ierr = PCInitializePackage();CHKERRQ(ierr);
> + ierr = KSPInitializePackage();CHKERRQ(ierr);
> + ierr = SNESInitializePackage();CHKERRQ(ierr);
> + ierr = TSInitializePackage();CHKERRQ(ierr);
> + {
> + MPI_Comm comm;
> + ierr = PetscCommDuplicate(PETSC_COMM_SELF,&comm,NULL);CHKERRQ(ierr);
> + ierr = PetscCommDuplicate(PETSC_COMM_WORLD,&comm,NULL);CHKERRQ(ierr);
> + }
>
> since they all set global variables and thus having multiple threads
> around would cause grief.
>
> I have two questions
>
> 1) Currently PetscOptionsObject is sometimes hidden and sometimes
> visible. I propose making it completely visible, the code would declare the
> variable before calling PetscOptionsBegin() then actually pass it into the
> various PetscOptionsInt() etc as opposed to secretly passing it in. Sound
> OK?
>
Yes.
> 2) We need a way for initializing all the packages in PetscInitialize()
> instead of as needed. In master I see
>
I really do not like this since then we are creating circular dependencies,
and people who would like to "use
only a part" will be upset. What about having the user who wants completely
threadsafe stuff call *Initialize(),
and then have this cascade all the way down (I think it should anyway).
Matt
> #if !defined(PETSC_HAVE_DYNAMIC_LIBRARIES)
> /*
> This just initializes the most basic PETSc stuff.
>
> The classes, from PetscDraw to PetscTS, are initialized the first
> time an XXCreate() is called.
> */
> ierr = PetscSysInitializePackage();CHKERRQ(ierr);
> #else
> preload = PETSC_FALSE;
> ierr =
> PetscOptionsGetBool(NULL,"-dynamic_library_preload",&preload,NULL);CHKERRQ(ierr);
> if (preload) {
> PetscBool found;
> #if defined(PETSC_USE_SINGLE_LIBRARY)
>
> Is this suppose to be here? Or is there some branch that does it
> differently that is not yet in master? We could change the
> -dynamic_library_preload flag to something more general like
> -initialize_all_on_start (need better name) that forces all the
> initializations for both dynamic and not. This will mess up the multiple
> PETSc library case, how will we deal with that? So, how should we force
> initialization of everything at start up?
>
> Thanks
>
> Barry
>
>
>
>
>
>
--
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/20131110/eb8b07b2/attachment.html>
More information about the petsc-dev
mailing list