[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