You had a problem with this? :-) Some dusty old corners of PETSc are best never viewed.
-/* -snes->fortran_func_pointers usage: - -0: oursnesfunction -1: oursnestest -2: oursnesjacobian -3: oursnesmonitor -4: oursnesmonitor ctx -5: ourmondestroy -6: unused -7: unused -8: unused -9: unused -10: ourdestroy -11: oursnestest ctx -12: unused -13: oursnesgs - - */ On Jan 9, 2013, at 7:37 PM, Jed Brown <jedbrown at mcs.anl.gov> 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> 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> > 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 V: 865-241-3198 http://climate.ornl.gov/~rmills > >
