[petsc-dev] Counting Fortran function pointers
Richard Tran Mills
rtm at eecs.utk.edu
Thu Jan 10 00:37:17 CST 2013
Thanks, Jed. I did think the static numbering looked pretty kludgy when
I started messing with the DMShell Fortran stubs. I'll switch to the
new system.
--Richard
On 1/9/13 8:37 PM, Jed Brown wrote:
> Richard, I pushed a new Fortran callback handling system. It is
> subtype-safe and doesn't rely on crazy static numbering. You can see
> what is left to do by
>
> $ grep AllocateFortran src/**/*.c
>
> Once these are gone, we can delete the old system.
>
> Meanwhile, you can add new functions using the system here. The Set
> call will create a callback ID if it doesn't exist yet and the object
> will automatically handle resizing and resetting when you change subtypes.
>
> https://bitbucket.org/petsc/petsc-dev/commits/f2a68b8a037edffd463d1ee6e9014e2edcd4aad7
>
> a couple more instances:
>
> https://bitbucket.org/petsc/petsc-dev/commits/bc94ac15bf5a75c3290770efe7e624a46ddcad37
>
>
> On Mon, Jan 7, 2013 at 5:48 PM, Jed Brown <jedbrown at mcs.anl.gov
> <mailto:jedbrown at mcs.anl.gov>> wrote:
>
> Richard, it's better to mail the list. No, we haven't reworked
> subtype Fortran pointers yet, but I think we know what needs to be
> done.
>
>
> On Mon, Jan 7, 2013 at 1:42 PM, Richard Tran Mills
> <rtm at eecs.utk.edu <mailto:rtm at eecs.utk.edu>> wrote:
>
> Hi Jed,
>
> I am back at work after some extended time away and I need to
> start messing with DMShell so that I can use it to set
> operations like LocalToGlobal and GlobalToLocal updates from
> inside PFLOTRAN.
>
> Did this issue of handling the Fortran function pointers get
> resolved somehow? Is there something I need to change in how
> I am doing the Fortran bindings?
>
> Cheers,
> Richard
>
>
> On 12/4/12 5:43 PM, Jed Brown wrote:
>> As usual, anything that is duplicated and not checked by the
>> compiler is broken.
>>
>> $ grep PetscObjectAllocateFortranPointers src/**/*.c
>> src/dm/impls/da/ftn-custom/zda2f.c:
>> PetscObjectAllocateFortranPointers(*da,6);
>> src/dm/impls/da/ftn-custom/zda2f.c:
>> PetscObjectAllocateFortranPointers(*da,6);
>> src/dm/impls/shell/ftn-custom/zdmshellf.c:
>> PetscObjectAllocateFortranPointers(*dm,2);
>> src/dm/impls/shell/ftn-custom/zdmshellf.c:
>> PetscObjectAllocateFortranPointers(*dm,2);
>>
>> Note that changing the type does not reset the function
>> pointers, thus having a DMSHELL, calling DMSetType(dm,DMDA),
>> and then setting a DMDA local function will cause memory
>> corruption.
>>
>> I cannot express how much I hate this system. The full-blown
>> solution is that for each type, we register a (global) token
>> which is the index of that function pointer. That doesn't
>> have any false dependencies, but is more "initialize" code.
>>
>> An alternative, used in the TS and KSP code below, is to have
>> a common enum that lists all the Fortran functions. It's a
>> false header dependency, but not a binary dependency.
>>
>> What should we do? The current state is a disaster.
>>
>> src/ksp/ksp/impls/gmres/fgmres/ftn-custom/zmodpcff.c:
>> PetscObjectAllocateFortranPointers(*ksp,3);
>> src/ksp/ksp/interface/ftn-custom/zitfuncf.c:
>> PetscObjectAllocateFortranPointers(*ksp,FTN_MAX);
>> src/ksp/ksp/interface/ftn-custom/zitfuncf.c:
>> PetscObjectAllocateFortranPointers(*ksp,FTN_MAX);
>> src/ksp/pc/impls/mg/ftn-custom/zmgfuncf.c:
>> PetscObjectAllocateFortranPointers(*mat,1);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:
>> PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:
>> PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:
>> PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:
>> PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:
>> PetscObjectAllocateFortranPointers(*pc,5);
>> src/mat/impls/mffd/ftn-custom/zmffdf.c:
>> PetscObjectAllocateFortranPointers(*mat,2);
>> src/mat/impls/shell/ftn-custom/zshellf.c:
>> PetscObjectAllocateFortranPointers(*mat,11);
>> src/mat/interface/ftn-custom/zmatrixf.c:
>> PetscObjectAllocateFortranPointers(*sp,1);
>> src/snes/interface/ftn-custom/zsnesf.c:
>> PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:
>> PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:
>> PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:
>> PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:
>> PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/linesearch/impls/shell/ftn-custom/zlinesearchshellf.c:
>> PetscObjectAllocateFortranPointers(*linesearch,3);
>> src/snes/linesearch/interface/ftn-custom/zlinesearchf.c:
>> PetscObjectAllocateFortranPointers(*linesearch,3);
>> src/snes/linesearch/interface/ftn-custom/zlinesearchf.c:
>> PetscObjectAllocateFortranPointers(*linesearch,3);
>> src/sys/draw/utils/ftn-custom/zzoomf.c:
>> PetscObjectAllocateFortranPointers(*draw,1);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:
>> PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>
>
> --
> Richard Tran Mills, Ph.D.
> Computational Earth Scientist | Joint Assistant Professor
> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences
> Oak Ridge National Laboratory | University of Tennessee, Knoxville
> E-mail:rmills at ornl.gov <mailto:rmills at ornl.gov> V:865-241-3198 <tel:865-241-3198> http://climate.ornl.gov/~rmills <http://climate.ornl.gov/%7Ermills>
>
>
>
--
Richard Tran Mills, Ph.D.
Computational Earth Scientist | Joint Assistant Professor
Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences
Oak Ridge National Laboratory | University of Tennessee, Knoxville
E-mail: rmills at ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130110/33807884/attachment.html>
More information about the petsc-dev
mailing list