There is still a bit of grunt work left. $ grep AllocateFortran src/**/*.c src/dm/impls/shell/ftn-custom/zdmshellf.c: PetscObjectAllocateFortranPointers(*dm,2); src/dm/impls/shell/ftn-custom/zdmshellf.c: PetscObjectAllocateFortranPointers(*dm,2); 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/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/classes/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)
On Thu, Jan 10, 2013 at 6:10 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 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 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130110/f9ae61b6/attachment.html>
