2016-07-27 21:42 GMT+02:00 Barry Smith <bsm...@mcs.anl.gov>: > > Actually there is currently no way to PetscInitialize from Fortran without > adding the command line options to the database. In the middle > of petscinitialize_() is the code fragment > > PETScParseFortranArgs_Private(&PetscGlobalArgc,&PetscGlobalArgs); > FIXCHAR(filename,len,t1); > *ierr = PetscOptionsInsert(NULL,&PetscGlobalArgc,&PetscGlobalArgs,t1); > > We'll need to do a bit of code refactoring to provide a Fortran > petscinitializenoarguments_(). The simplest way to refactor would be to > change the name of petscinitialize_ to say PetscInitializeFortran_Internal() > and add a bool argument whether to process the arguments and then write two > trivial routines petscinitialize_ that calls the new routine with PETSC_TRUE > and petscinitializenoarguments_() that calls it with PETSC_FALSE.
Thanks Barry. It would be really nice if PETSc comes with that feature in future, because I would prefer not to make any changes to the PETSc code that disappear with every new PETSc release. > > Barry > > Of course you can have a C/C++ main routine that calls > PetscInitializeNoArguments(); followed by PetscInitializeFortran() and then > have the bulk of your code in Fortran. That would work, but we have a rather large fortran code without any C. So, for now we will probably stick to your first approach and keep our code fotran only. Thanks again, Volker > > >> On Jul 27, 2016, at 10:55 AM, Tim Steinhoff <kandanov...@gmail.com> wrote: >> >> 2016-07-27 16:04 GMT+02:00 Matthew Knepley <knep...@gmail.com>: >>> On Wed, Jul 27, 2016 at 4:59 AM, Tim Steinhoff <kandanov...@gmail.com> >>> wrote: >>>> >>>> Hi all, >>>> >>>> we coupled PETSc with our fortran code. Is there any way to let PETSc >>>> (PetscInitialize) ignore all arguments passed by the command line? >>>> Since our code is controlled by command line arguements as well, it >>>> leads to a mess, when those arguments are read twice. >>> >>> >>> 1) You can use PetscInitializeNoArguments() >> >> Thanks! I thought that function was for C/C++ only. >> >>> >>> 2) What goes wrong? PETSc should just ignore any options it does not >>> recognize. >> >> >> The problem is that our code uses the same or similar argument names >> as PETSc does and our end user should not have access to all petsc >> options. >> >> >>> >>> Thanks, >>> >>> Matt >>> >>>> >>>> Thanks and kind regards, >>>> >>>> Volker >>> >>> >>> >>> >>> -- >>> 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 >