<div dir="ltr">There is still a bit of grunt work left.<div><br></div><div><div>$ grep AllocateFortran src/**/*.c</div><div>src/dm/impls/shell/ftn-custom/zdmshellf.c: PetscObjectAllocateFortranPointers(*dm,2);</div><div>src/dm/impls/shell/ftn-custom/zdmshellf.c: PetscObjectAllocateFortranPointers(*dm,2);</div>
<div>src/ksp/pc/impls/mg/ftn-custom/zmgfuncf.c: PetscObjectAllocateFortranPointers(*mat,1);</div><div>src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);</div><div>src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);</div>
<div>src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);</div><div>src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);</div><div>src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);</div>
<div>src/mat/impls/mffd/ftn-custom/zmffdf.c: PetscObjectAllocateFortranPointers(*mat,2);</div><div>src/mat/impls/shell/ftn-custom/zshellf.c: PetscObjectAllocateFortranPointers(*mat,11);</div><div>src/mat/interface/ftn-custom/zmatrixf.c: PetscObjectAllocateFortranPointers(*sp,1);</div>
<div>src/snes/linesearch/impls/shell/ftn-custom/zlinesearchshellf.c: PetscObjectAllocateFortranPointers(*linesearch,3);</div><div>src/snes/linesearch/interface/ftn-custom/zlinesearchf.c: PetscObjectAllocateFortranPointers(*linesearch,3);</div>
<div>src/snes/linesearch/interface/ftn-custom/zlinesearchf.c: PetscObjectAllocateFortranPointers(*linesearch,3);</div><div>src/sys/classes/draw/utils/ftn-custom/zzoomf.c: PetscObjectAllocateFortranPointers(*draw,1);</div>
<div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);</div><div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);</div><div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);</div>
<div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);</div><div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);</div><div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);</div>
<div>src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT)</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 10, 2013 at 6:10 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
You had a problem with this? :-) Some dusty old corners of PETSc are best never viewed.<br>
<br>
-/*<br>
-snes->fortran_func_pointers usage:<br>
-<br>
-0: oursnesfunction<br>
-1: oursnestest<br>
-2: oursnesjacobian<br>
-3: oursnesmonitor<br>
-4: oursnesmonitor ctx<br>
-5: ourmondestroy<br>
-6: unused<br>
-7: unused<br>
-8: unused<br>
-9: unused<br>
-10: ourdestroy<br>
-11: oursnestest ctx<br>
-12: unused<br>
-13: oursnesgs<br>
-<br>
- */<br>
<div class="HOEnZb"><div class="h5"><br>
On Jan 9, 2013, at 7:37 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> 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<br>
><br>
> $ grep AllocateFortran src/**/*.c<br>
><br>
> Once these are gone, we can delete the old system.<br>
><br>
> 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.<br>
><br>
> <a href="https://bitbucket.org/petsc/petsc-dev/commits/f2a68b8a037edffd463d1ee6e9014e2edcd4aad7" target="_blank">https://bitbucket.org/petsc/petsc-dev/commits/f2a68b8a037edffd463d1ee6e9014e2edcd4aad7</a><br>
><br>
> a couple more instances:<br>
><br>
> <a href="https://bitbucket.org/petsc/petsc-dev/commits/bc94ac15bf5a75c3290770efe7e624a46ddcad37" target="_blank">https://bitbucket.org/petsc/petsc-dev/commits/bc94ac15bf5a75c3290770efe7e624a46ddcad37</a><br>
><br>
><br>
> On Mon, Jan 7, 2013 at 5:48 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> 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.<br>
><br>
><br>
> On Mon, Jan 7, 2013 at 1:42 PM, Richard Tran Mills <<a href="mailto:rtm@eecs.utk.edu">rtm@eecs.utk.edu</a>> wrote:<br>
> Hi Jed,<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> Cheers,<br>
> Richard<br>
><br>
><br>
> On 12/4/12 5:43 PM, Jed Brown wrote:<br>
>> As usual, anything that is duplicated and not checked by the compiler is broken.<br>
>><br>
>> $ grep PetscObjectAllocateFortranPointers src/**/*.c<br>
>> src/dm/impls/da/ftn-custom/zda2f.c: PetscObjectAllocateFortranPointers(*da,6);<br>
>> src/dm/impls/da/ftn-custom/zda2f.c: PetscObjectAllocateFortranPointers(*da,6);<br>
>> src/dm/impls/shell/ftn-custom/zdmshellf.c: PetscObjectAllocateFortranPointers(*dm,2);<br>
>> src/dm/impls/shell/ftn-custom/zdmshellf.c: PetscObjectAllocateFortranPointers(*dm,2);<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> What should we do? The current state is a disaster.<br>
>><br>
>> src/ksp/ksp/impls/gmres/fgmres/ftn-custom/zmodpcff.c: PetscObjectAllocateFortranPointers(*ksp,3);<br>
>> src/ksp/ksp/interface/ftn-custom/zitfuncf.c: PetscObjectAllocateFortranPointers(*ksp,FTN_MAX);<br>
>> src/ksp/ksp/interface/ftn-custom/zitfuncf.c: PetscObjectAllocateFortranPointers(*ksp,FTN_MAX);<br>
>> src/ksp/pc/impls/mg/ftn-custom/zmgfuncf.c: PetscObjectAllocateFortranPointers(*mat,1);<br>
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);<br>
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);<br>
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);<br>
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);<br>
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c: PetscObjectAllocateFortranPointers(*pc,5);<br>
>> src/mat/impls/mffd/ftn-custom/zmffdf.c: PetscObjectAllocateFortranPointers(*mat,2);<br>
>> src/mat/impls/shell/ftn-custom/zshellf.c: PetscObjectAllocateFortranPointers(*mat,11);<br>
>> src/mat/interface/ftn-custom/zmatrixf.c: PetscObjectAllocateFortranPointers(*sp,1);<br>
>> src/snes/interface/ftn-custom/zsnesf.c: PetscObjectAllocateFortranPointers(*snes,14);<br>
>> src/snes/interface/ftn-custom/zsnesf.c: PetscObjectAllocateFortranPointers(*snes,14);<br>
>> src/snes/interface/ftn-custom/zsnesf.c: PetscObjectAllocateFortranPointers(*snes,14);<br>
>> src/snes/interface/ftn-custom/zsnesf.c: PetscObjectAllocateFortranPointers(*snes,14);<br>
>> src/snes/interface/ftn-custom/zsnesf.c: PetscObjectAllocateFortranPointers(*snes,14);<br>
>> src/snes/linesearch/impls/shell/ftn-custom/zlinesearchshellf.c: PetscObjectAllocateFortranPointers(*linesearch,3);<br>
>> src/snes/linesearch/interface/ftn-custom/zlinesearchf.c: PetscObjectAllocateFortranPointers(*linesearch,3);<br>
>> src/snes/linesearch/interface/ftn-custom/zlinesearchf.c: PetscObjectAllocateFortranPointers(*linesearch,3);<br>
>> src/sys/draw/utils/ftn-custom/zzoomf.c: PetscObjectAllocateFortranPointers(*draw,1);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
>> src/ts/interface/ftn-custom/ztsf.c: PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);<br>
><br>
><br>
> --<br>
> Richard Tran Mills, Ph.D.<br>
> Computational Earth Scientist | Joint Assistant Professor<br>
> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences<br>
> Oak Ridge National Laboratory | University of Tennessee, Knoxville<br>
> E-mail:<br>
> <a href="mailto:rmills@ornl.gov">rmills@ornl.gov</a> V: <a href="tel:865-241-3198" value="+18652413198">865-241-3198</a> <a href="http://climate.ornl.gov/~rmills" target="_blank">http://climate.ornl.gov/~rmills</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>