Re: [petsc-users] Fortran Interface NULL object / Casting

[Matthew Knepley]

On Thu, Dec 8, 2022 at 2:56 PM Barry Smith  wrote:

>
>You would use *PETSC_NULL_DM*LABEL but Matt needs to customize the
> PETSc Fortran stub for DMAddField() for you to handle accepting the NULL
> from PETSc.
>

Sorry, I missed this message. The customization is done.

  Thanks,

 Matt


>Barry
>
>
>
>
>
> On Dec 8, 2022, at 1:05 PM, Nicholas Arnold-Medabalimi 
> wrote:
>
> Hi Petsc Users
>
> I am trying to use DMAddField in a Fortran code. I had some questions on
> casting/passing NULL. I follow how to pass NULL for standard types (INT,
> CHAR, etc).
>
> Is there a method/best practice for passing NULL for Petsc type arguments?
> (In this case DMAddLabel I'd want to pass NULL to a DMLabel Parameter not
> an intrinsic type)
>
> For the 2nd question, In some cases in C we would cast a more specific
> object to Petsc Object
> DMAddField(dm, NULL, (PetscObject)fvm); (where fvm is a PetscFVM type)
> Is there a method or practice to do the same in Fortran.
>
> Thanks
> Nicholas
>
> --
> Nicholas Arnold-Medabalimi
>
> Ph.D. Candidate
> Computational Aeroscience Lab
> University of Michigan
>
>
>

-- 
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

https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Y7V3ljA2ftwwmUl996o8LBEkPFj2p3sNz4c1MmdMRf8S5xQVjNjWnUACSD3Ys6A2ER8jLncCxWS5fZjxqnnF$
  

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Barry Smith]

   I apologize; please ignore my answer below. Use MatCreateShell() as 
indicated by Jed.


> On Dec 20, 2023, at 2:14 PM, Barry Smith  wrote:
> 
> 
> 
>> On Dec 20, 2023, at 11:44 AM, Yi Hu  wrote:
>> 
>> Dear Jed,
>> 
>> Thanks for your reply. I have an analytical one to implement.
>> 
>> Best, Yi
>> 
>> -Original Message-
>> From: Jed Brown  
>> Sent: Wednesday, December 20, 2023 5:40 PM
>> To: Yi Hu ; petsc-users@mcs.anl.gov
>> Subject: Re: [petsc-users] fortran interface to snes matrix-free jacobian
>> 
>> Are you wanting an analytic matrix-free operator or one created for you 
>> based on finite differencing? If the latter, just use -snes_mf or 
>> -snes_mf_operator.
>> 
>> https://petsc.org/release/manual/snes/#jacobian-evaluation
>> 
>> Yi Hu  writes:
>> 
>>> Dear PETSc team,
>>> 
>>> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
>>> saw the useful C interface like MatCreateSNESMF(), 
>>> DMSNESCreateJacobianMF(). I am wondering if you have the fortran 
>>> equivalence?
> 
>   You can use DMSNESCreateJacobianMF() (MatCreateSNESMF is not appropriate 
> when you are providing the operation).
> 
> 
>>> 
>>> I think for my problem in the main program I need to do 
>>> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). 
>>> Then in myJacobian() subroutine I have to create the operator from 
>>> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
>>> MatShellSetOperation(). Am I correct?
> 
> Not exactly. Do not use DMDASNESsetJacobianLocal() use 
> DMSNESCreateJacobianMF() to create a Mat J where you create the SNES and use 
> SNESSetJacobian()  and pass the J matrix in along with myJacobian().
> 
>>> 
>>> Are these fortran subroutines available? I saw an example in ts module 
>>> as ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
>>> would like to use ngmres, I then need to stay in the SNES.
>>> 
>>> Thanks for your help.
>>> 
>>> Best wishes,
>>> Yi
>>> 
>>> -
>>> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>>> 
>>> Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1
>>> D-40237 Düsseldorf
>>> 
>>> Handelsregister B 2533
>>> Amtsgericht Düsseldorf
>>> 
>>> Geschäftsführung
>>> Prof. Dr. Gerhard Dehm
>>> Prof. Dr. Jörg Neugebauer
>>> Prof. Dr. Dierk Raabe
>>> Dr. Kai de Weldige
>>> 
>>> Ust.-Id.-Nr.: DE 11 93 58 514
>>> Steuernummer: 105 5891 1000
>>> 
>>> 
>>> Please consider that invitations and e-mails of our institute are only 
>>> valid if they end with …@mpie.de.
>>> If you are not sure of the validity please contact r...@mpie.de
>>> 
>>> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails 
>>> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
>>> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
>>> -
>> 
>> 
>> -
>> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>> 
>> Max-Planck-Institut für Eisenforschung GmbH
>> Max-Planck-Straße 1
>> D-40237 Düsseldorf
>> 
>> Handelsregister B 2533 
>> Amtsgericht Düsseldorf
>> 
>> Geschäftsführung
>> Prof. Dr. Gerhard Dehm
>> Prof. Dr. Jörg Neugebauer
>> Prof. Dr. Dierk Raabe
>> Dr. Kai de Weldige
>> 
>> Ust.-Id.-Nr.: DE 11 93 58 514 
>> Steuernummer: 105 5891 1000
>> 
>> 
>> Please consider that invitations and e-mails of our institute are 
>> only valid if they end with …@mpie.de. 
>> If you are not sure of the validity please contact r...@mpie.de
>> 
>> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
>> aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
>> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
>> -

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Barry Smith]

> On Dec 20, 2023, at 11:44 AM, Yi Hu  wrote:
> 
> Dear Jed,
> 
> Thanks for your reply. I have an analytical one to implement.
> 
> Best, Yi
> 
> -Original Message-
> From: Jed Brown  
> Sent: Wednesday, December 20, 2023 5:40 PM
> To: Yi Hu ; petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] fortran interface to snes matrix-free jacobian
> 
> Are you wanting an analytic matrix-free operator or one created for you based 
> on finite differencing? If the latter, just use -snes_mf or -snes_mf_operator.
> 
> https://petsc.org/release/manual/snes/#jacobian-evaluation
> 
> Yi Hu  writes:
> 
>> Dear PETSc team,
>> 
>> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
>> saw the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). 
>> I am wondering if you have the fortran equivalence?

   You can use DMSNESCreateJacobianMF() (MatCreateSNESMF is not appropriate 
when you are providing the operation).
 
   
>> 
>> I think for my problem in the main program I need to do 
>> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). 
>> Then in myJacobian() subroutine I have to create the operator from 
>> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
>> MatShellSetOperation(). Am I correct?

Not exactly. Do not use DMDASNESsetJacobianLocal() use DMSNESCreateJacobianMF() 
to create a Mat J where you create the SNES and use SNESSetJacobian()  and pass 
the J matrix in along with myJacobian().

>> 
>> Are these fortran subroutines available? I saw an example in ts module 
>> as ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
>> would like to use ngmres, I then need to stay in the SNES.
>> 
>> Thanks for your help.
>> 
>> Best wishes,
>> Yi
>> 
>> -
>> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>> 
>> Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1
>> D-40237 Düsseldorf
>> 
>> Handelsregister B 2533
>> Amtsgericht Düsseldorf
>> 
>> Geschäftsführung
>> Prof. Dr. Gerhard Dehm
>> Prof. Dr. Jörg Neugebauer
>> Prof. Dr. Dierk Raabe
>> Dr. Kai de Weldige
>> 
>> Ust.-Id.-Nr.: DE 11 93 58 514
>> Steuernummer: 105 5891 1000
>> 
>> 
>> Please consider that invitations and e-mails of our institute are only 
>> valid if they end with …@mpie.de.
>> If you are not sure of the validity please contact r...@mpie.de
>> 
>> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails 
>> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
>> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
>> -
> 
> 
> -
> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
> 
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße 1
> D-40237 Düsseldorf
> 
> Handelsregister B 2533 
> Amtsgericht Düsseldorf
> 
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
> 
> Ust.-Id.-Nr.: DE 11 93 58 514 
> Steuernummer: 105 5891 1000
> 
> 
> Please consider that invitations and e-mails of our institute are 
> only valid if they end with …@mpie.de. 
> If you are not sure of the validity please contact r...@mpie.de
> 
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -
> 

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Jed Brown]

Then just use MatShell. I see the docs need some work to clarify this, but 
MatCreateSNESMF is to specify matrix-free finite differencing from code 
(perhaps where one wants to customize parameters).

Yi Hu  writes:

> Dear Jed,
>
> Thanks for your reply. I have an analytical one to implement.
>
> Best, Yi
>
> -Original Message-
> From: Jed Brown  
> Sent: Wednesday, December 20, 2023 5:40 PM
> To: Yi Hu ; petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] fortran interface to snes matrix-free jacobian
>
> Are you wanting an analytic matrix-free operator or one created for you based 
> on finite differencing? If the latter, just use -snes_mf or -snes_mf_operator.
>
> https://petsc.org/release/manual/snes/#jacobian-evaluation
>
> Yi Hu  writes:
>
>> Dear PETSc team,
>>  
>> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
>> saw the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). 
>> I am wondering if you have the fortran equivalence?
>>  
>> I think for my problem in the main program I need to do 
>> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). 
>> Then in myJacobian() subroutine I have to create the operator from 
>> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
>> MatShellSetOperation(). Am I correct? 
>>  
>> Are these fortran subroutines available? I saw an example in ts module 
>> as ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
>> would like to use ngmres, I then need to stay in the SNES.
>>  
>> Thanks for your help.
>>  
>> Best wishes,
>> Yi
>>
>> -
>> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>>
>> Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1
>> D-40237 Düsseldorf
>>  
>> Handelsregister B 2533
>> Amtsgericht Düsseldorf
>>  
>> Geschäftsführung
>> Prof. Dr. Gerhard Dehm
>> Prof. Dr. Jörg Neugebauer
>> Prof. Dr. Dierk Raabe
>> Dr. Kai de Weldige
>>  
>> Ust.-Id.-Nr.: DE 11 93 58 514
>> Steuernummer: 105 5891 1000
>>
>>
>> Please consider that invitations and e-mails of our institute are only 
>> valid if they end with …@mpie.de.
>> If you are not sure of the validity please contact r...@mpie.de
>>
>> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails 
>> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
>> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
>> -
>
>
> -
> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße 1
> D-40237 Düsseldorf
>  
> Handelsregister B 2533 
> Amtsgericht Düsseldorf
>  
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>  
> Ust.-Id.-Nr.: DE 11 93 58 514 
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are 
> only valid if they end with …@mpie.de. 
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Yi Hu]

Dear Jed,

Thanks for your reply. I have an analytical one to implement.

Best, Yi

-Original Message-
From: Jed Brown  
Sent: Wednesday, December 20, 2023 5:40 PM
To: Yi Hu ; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] fortran interface to snes matrix-free jacobian

Are you wanting an analytic matrix-free operator or one created for you based 
on finite differencing? If the latter, just use -snes_mf or -snes_mf_operator.

https://petsc.org/release/manual/snes/#jacobian-evaluation

Yi Hu  writes:

> Dear PETSc team,
>  
> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
> saw the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). 
> I am wondering if you have the fortran equivalence?
>  
> I think for my problem in the main program I need to do 
> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). Then 
> in myJacobian() subroutine I have to create the operator from 
> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
> MatShellSetOperation(). Am I correct? 
>  
> Are these fortran subroutines available? I saw an example in ts module 
> as ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
> would like to use ngmres, I then need to stay in the SNES.
>  
> Thanks for your help.
>  
> Best wishes,
> Yi
>
> -
> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>
> Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1
> D-40237 Düsseldorf
>  
> Handelsregister B 2533
> Amtsgericht Düsseldorf
>  
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>  
> Ust.-Id.-Nr.: DE 11 93 58 514
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are only 
> valid if they end with …@mpie.de.
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails 
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -


-
Stay up to date and follow us on LinkedIn, Twitter and YouTube.

Max-Planck-Institut für Eisenforschung GmbH
Max-Planck-Straße 1
D-40237 Düsseldorf
 
Handelsregister B 2533 
Amtsgericht Düsseldorf
 
Geschäftsführung
Prof. Dr. Gerhard Dehm
Prof. Dr. Jörg Neugebauer
Prof. Dr. Dierk Raabe
Dr. Kai de Weldige
 
Ust.-Id.-Nr.: DE 11 93 58 514 
Steuernummer: 105 5891 1000


Please consider that invitations and e-mails of our institute are 
only valid if they end with …@mpie.de. 
If you are not sure of the validity please contact r...@mpie.de

Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
-

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Jed Brown]

Are you wanting an analytic matrix-free operator or one created for you based 
on finite differencing? If the latter, just use -snes_mf or -snes_mf_operator.

https://petsc.org/release/manual/snes/#jacobian-evaluation

Yi Hu  writes:

> Dear PETSc team,
>  
> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
> saw the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). 
> I am wondering if you have the fortran equivalence?
>  
> I think for my problem in the main program I need to do 
> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). Then 
> in myJacobian() subroutine I have to create the operator from 
> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
> MatShellSetOperation(). Am I correct? 
>  
> Are these fortran subroutines available? I saw an example in ts module as 
> ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
> would like to use ngmres, I then need to stay in the SNES.  
>  
> Thanks for your help.
>  
> Best wishes,
> Yi
>
> -
> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße 1
> D-40237 Düsseldorf
>  
> Handelsregister B 2533 
> Amtsgericht Düsseldorf
>  
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>  
> Ust.-Id.-Nr.: DE 11 93 58 514 
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are 
> only valid if they end with …@mpie.de. 
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -

[petsc-users] fortran interface to snes matrix-free jacobian

[Yi Hu]

Dear PETSc team,
 
My  solution scheme relies on a matrix-free jacobian in the SNES solver. I saw 
the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). I am 
wondering if you have the fortran equivalence?
 
I think for my problem in the main program I need to do 
DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). Then 
in myJacobian() subroutine I have to create the operator from 
DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
MatShellSetOperation(). Am I correct? 
 
Are these fortran subroutines available? I saw an example in ts module as 
ex22f_mf.F90 which behaves similar as what I would like to do. Because I would 
like to use ngmres, I then need to stay in the SNES.  
 
Thanks for your help.
 
Best wishes,
Yi

-
Stay up to date and follow us on LinkedIn, Twitter and YouTube.

Max-Planck-Institut für Eisenforschung GmbH
Max-Planck-Straße 1
D-40237 Düsseldorf
 
Handelsregister B 2533 
Amtsgericht Düsseldorf
 
Geschäftsführung
Prof. Dr. Gerhard Dehm
Prof. Dr. Jörg Neugebauer
Prof. Dr. Dierk Raabe
Dr. Kai de Weldige
 
Ust.-Id.-Nr.: DE 11 93 58 514 
Steuernummer: 105 5891 1000


Please consider that invitations and e-mails of our institute are 
only valid if they end with …@mpie.de. 
If you are not sure of the validity please contact r...@mpie.de

Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
-

Re: [petsc-users] Fortran Interface

[Palmer, Bruce J via petsc-users]

Thanks, that clears things up nicely.

Bruce

From: Barry Smith 
Date: Wednesday, December 13, 2023 at 6:28 AM
To: Sanjay Govindjee 
Cc: Palmer, Bruce J , petsc-users@mcs.anl.gov 

Subject: Re: [petsc-users] Fortran Interface
fixed



On Dec 12, 2023, at 11:17 PM, Sanjay Govindjee  wrote:

did you mean to write

type (userctx)   ctx

in this example?



subroutine func(snes, x, f, ctx, ierr)
SNES snes
Vec x,f
type (userctx)   user
PetscErrorCode ierr
...

external func
SNESSetFunction(snes, r, func, ctx, ierr)
SNES snes
Vec r
PetscErrorCode ierr
type (userctx)   user



On Tue, Dec 12, 2023 at 7:10 PM Barry Smith 
mailto:bsm...@petsc.dev>> wrote:

See 
https://petsc.gitlab.io/-/petsc/-/jobs/5739238224/artifacts/public/html/manual/fortran.html#ch-fortran
 and https://gitlab.com/petsc/petsc/-/merge_requests/7114




On Dec 12, 2023, at 3:22 PM, Palmer, Bruce J via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:

What do you do with something like a void pointer? I’m looking at the 
TaoSetObjectiveAndGradient function and it wants to pass a void *ctx pointer. 
You can set this to null, but apparently you have to specify the type. What 
type should I use? Is there something called PETSC_NULL_VOID or 
PETSC_NULL_CONTEXT or do I use something else?

From: Matthew Knepley mailto:knep...@gmail.com>>
Date: Tuesday, December 12, 2023 at 8:33 AM
To: Palmer, Bruce J mailto:bruce.pal...@pnnl.gov>>
Cc: petsc-users@mcs.anl.gov<mailto:petsc-users@mcs.anl.gov> 
mailto:petsc-users@mcs.anl.gov>>
Subject: Re: [petsc-users] Fortran Interface
Check twice before you click! This email originated from outside PNNL.

On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
Does documentation for the PETSc fortran interface still exist? I looked at the 
web pages for 3.20 (petsc.org/release<http://petsc.org/release>) but if you go 
under the tab C/Fortran API, only descriptions for the C interface are there.

I think after the most recent changes, the interface was supposed to be very 
close to C, so we just document the differences on specific pages, and put the 
general stuff here:

  https://petsc.org/release/manual/fortran/

   Thanks,

 Matt

Bruce Palmer


--
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

https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Barry Smith]

fixed


> On Dec 12, 2023, at 11:17 PM, Sanjay Govindjee  wrote:
> 
> did you mean to write
> type (userctx)   ctx
> in this example?
> 
> subroutine func(snes, x, f, ctx, ierr)
> SNES snes
> Vec x,f
> type (userctx)   user
> PetscErrorCode ierr
> ...
> 
> external func
> SNESSetFunction(snes, r, func, ctx, ierr)
> SNES snes
> Vec r
> PetscErrorCode ierr
> type (userctx)   user
> 
> 
> 
> On Tue, Dec 12, 2023 at 7:10 PM Barry Smith  <mailto:bsm...@petsc.dev>> wrote:
>> 
>> See 
>> https://petsc.gitlab.io/-/petsc/-/jobs/5739238224/artifacts/public/html/manual/fortran.html#ch-fortran
>>  and https://gitlab.com/petsc/petsc/-/merge_requests/7114
>> 
>> 
>> 
>>> On Dec 12, 2023, at 3:22 PM, Palmer, Bruce J via petsc-users 
>>> mailto:petsc-users@mcs.anl.gov>> wrote:
>>> 
>>> What do you do with something like a void pointer? I’m looking at the 
>>> TaoSetObjectiveAndGradient function and it wants to pass a void *ctx 
>>> pointer. You can set this to null, but apparently you have to specify the 
>>> type. What type should I use? Is there something called PETSC_NULL_VOID or 
>>> PETSC_NULL_CONTEXT or do I use something else?
>>>  
>>> From: Matthew Knepley mailto:knep...@gmail.com>>
>>> Date: Tuesday, December 12, 2023 at 8:33 AM
>>> To: Palmer, Bruce J mailto:bruce.pal...@pnnl.gov>>
>>> Cc: petsc-users@mcs.anl.gov <mailto:petsc-users@mcs.anl.gov> 
>>> mailto:petsc-users@mcs.anl.gov>>
>>> Subject: Re: [petsc-users] Fortran Interface
>>> 
>>> Check twice before you click! This email originated from outside PNNL.
>>>  
>>> On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
>>> mailto:petsc-users@mcs.anl.gov>> wrote:
>>> Does documentation for the PETSc fortran interface still exist? I looked at 
>>> the web pages for 3.20 (petsc.org/release <http://petsc.org/release>) but 
>>> if you go under the tab C/Fortran API, only descriptions for the C 
>>> interface are there.
>>>  
>>> I think after the most recent changes, the interface was supposed to be 
>>> very close to C, so we just document the differences on specific pages, and 
>>> put the general stuff here:
>>>  
>>>   https://petsc.org/release/manual/fortran/
>>>  
>>>Thanks,
>>>  
>>>  Matt
>>>  
>>> Bruce Palmer
>>> 
>>>  
>>> --
>>> 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
>>>  
>>> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Mark Adams]

yep, that's a cut and paste bug.
"user" is a common name for a user context.

On Tue, Dec 12, 2023 at 11:17 PM Sanjay Govindjee via petsc-users <
petsc-users@mcs.anl.gov> wrote:

> did you mean to write
>
> type (userctx)   ctx
>
> in this example?
>
>
> subroutine func(snes, x, f, ctx, ierr)
> SNES snes
> Vec x,f
> type (userctx)   user
> PetscErrorCode ierr
> ...
>
> external func
> SNESSetFunction(snes, r, func, ctx, ierr)
> SNES snes
> Vec r
> PetscErrorCode ierr
> type (userctx)   user
>
>
>
>
> On Tue, Dec 12, 2023 at 7:10 PM Barry Smith  wrote:
>
>>
>> See
>> https://petsc.gitlab.io/-/petsc/-/jobs/5739238224/artifacts/public/html/manual/fortran.html#ch-fortran
>>  and https://gitlab.com/petsc/petsc/-/merge_requests/7114
>>
>>
>>
>> On Dec 12, 2023, at 3:22 PM, Palmer, Bruce J via petsc-users <
>> petsc-users@mcs.anl.gov> wrote:
>>
>> What do you do with something like a void pointer? I’m looking at the
>> TaoSetObjectiveAndGradient function and it wants to pass a void *ctx
>> pointer. You can set this to null, but apparently you have to specify the
>> type. What type should I use? Is there something called PETSC_NULL_VOID or
>> PETSC_NULL_CONTEXT or do I use something else?
>>
>>
>> *From: *Matthew Knepley 
>> *Date: *Tuesday, December 12, 2023 at 8:33 AM
>> *To: *Palmer, Bruce J 
>> *Cc: *petsc-users@mcs.anl.gov 
>> *Subject: *Re: [petsc-users] Fortran Interface
>> Check twice before you click! This email originated from outside PNNL.
>>
>> On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users <
>> petsc-users@mcs.anl.gov> wrote:
>>
>> Does documentation for the PETSc fortran interface still exist? I looked
>> at the web pages for 3.20 (petsc.org/release) but if you go under the
>> tab C/Fortran API, only descriptions for the C interface are there.
>>
>>
>> I think after the most recent changes, the interface was supposed to be
>> very close to C, so we just document the differences on specific pages, and
>> put the general stuff here:
>>
>>   https://petsc.org/release/manual/fortran/
>>
>>Thanks,
>>
>>  Matt
>>
>>
>> Bruce Palmer
>>
>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>> <http://www.cse.buffalo.edu/~knepley/>
>>
>>
>>

Re: [petsc-users] Fortran Interface

[Sanjay Govindjee via petsc-users]

did you mean to write

type (userctx)   ctx

in this example?


subroutine func(snes, x, f, ctx, ierr)
SNES snes
Vec x,f
type (userctx)   user
PetscErrorCode ierr
...

external func
SNESSetFunction(snes, r, func, ctx, ierr)
SNES snes
Vec r
PetscErrorCode ierr
type (userctx)   user




On Tue, Dec 12, 2023 at 7:10 PM Barry Smith  wrote:

>
> See
> https://petsc.gitlab.io/-/petsc/-/jobs/5739238224/artifacts/public/html/manual/fortran.html#ch-fortran
>  and https://gitlab.com/petsc/petsc/-/merge_requests/7114
>
>
>
> On Dec 12, 2023, at 3:22 PM, Palmer, Bruce J via petsc-users <
> petsc-users@mcs.anl.gov> wrote:
>
> What do you do with something like a void pointer? I’m looking at the
> TaoSetObjectiveAndGradient function and it wants to pass a void *ctx
> pointer. You can set this to null, but apparently you have to specify the
> type. What type should I use? Is there something called PETSC_NULL_VOID or
> PETSC_NULL_CONTEXT or do I use something else?
>
>
> *From: *Matthew Knepley 
> *Date: *Tuesday, December 12, 2023 at 8:33 AM
> *To: *Palmer, Bruce J 
> *Cc: *petsc-users@mcs.anl.gov 
> *Subject: *Re: [petsc-users] Fortran Interface
> Check twice before you click! This email originated from outside PNNL.
>
> On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users <
> petsc-users@mcs.anl.gov> wrote:
>
> Does documentation for the PETSc fortran interface still exist? I looked
> at the web pages for 3.20 (petsc.org/release) but if you go under the tab
> C/Fortran API, only descriptions for the C interface are there.
>
>
> I think after the most recent changes, the interface was supposed to be
> very close to C, so we just document the differences on specific pages, and
> put the general stuff here:
>
>   https://petsc.org/release/manual/fortran/
>
>Thanks,
>
>  Matt
>
>
> Bruce Palmer
>
>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
>
>

Re: [petsc-users] Fortran Interface

[Barry Smith]

See 
https://petsc.gitlab.io/-/petsc/-/jobs/5739238224/artifacts/public/html/manual/fortran.html#ch-fortran
 and https://gitlab.com/petsc/petsc/-/merge_requests/7114



> On Dec 12, 2023, at 3:22 PM, Palmer, Bruce J via petsc-users 
>  wrote:
> 
> What do you do with something like a void pointer? I’m looking at the 
> TaoSetObjectiveAndGradient function and it wants to pass a void *ctx pointer. 
> You can set this to null, but apparently you have to specify the type. What 
> type should I use? Is there something called PETSC_NULL_VOID or 
> PETSC_NULL_CONTEXT or do I use something else?
>  
> From: Matthew Knepley mailto:knep...@gmail.com>>
> Date: Tuesday, December 12, 2023 at 8:33 AM
> To: Palmer, Bruce J mailto:bruce.pal...@pnnl.gov>>
> Cc: petsc-users@mcs.anl.gov <mailto:petsc-users@mcs.anl.gov> 
> mailto:petsc-users@mcs.anl.gov>>
> Subject: Re: [petsc-users] Fortran Interface
> 
> Check twice before you click! This email originated from outside PNNL.
>  
> On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
> Does documentation for the PETSc fortran interface still exist? I looked at 
> the web pages for 3.20 (petsc.org/release <http://petsc.org/release>) but if 
> you go under the tab C/Fortran API, only descriptions for the C interface are 
> there.
>  
> I think after the most recent changes, the interface was supposed to be very 
> close to C, so we just document the differences on specific pages, and put 
> the general stuff here:
>  
>   https://petsc.org/release/manual/fortran/
>  
>Thanks,
>  
>  Matt
>  
> Bruce Palmer
> 
>  
> --
> 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
>  
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Palmer, Bruce J via petsc-users]

What do you do with something like a void pointer? I’m looking at the 
TaoSetObjectiveAndGradient function and it wants to pass a void *ctx pointer. 
You can set this to null, but apparently you have to specify the type. What 
type should I use? Is there something called PETSC_NULL_VOID or 
PETSC_NULL_CONTEXT or do I use something else?

From: Matthew Knepley 
Date: Tuesday, December 12, 2023 at 8:33 AM
To: Palmer, Bruce J 
Cc: petsc-users@mcs.anl.gov 
Subject: Re: [petsc-users] Fortran Interface
Check twice before you click! This email originated from outside PNNL.

On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
Does documentation for the PETSc fortran interface still exist? I looked at the 
web pages for 3.20 (petsc.org/release<http://petsc.org/release>) but if you go 
under the tab C/Fortran API, only descriptions for the C interface are there.

I think after the most recent changes, the interface was supposed to be very 
close to C, so we just document the differences on specific pages, and put the 
general stuff here:

  https://petsc.org/release/manual/fortran/

   Thanks,

 Matt

Bruce Palmer


--
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

https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Palmer, Bruce J via petsc-users]

I think having a link to your fortran interface page on the C/Fortran API tab 
is probably sufficient, particularly if the interfaces are similar. If 
functions have significant differences between C and Fortran, it would be 
helpful if the notes about it are on the page describing the function.

I’m the project lead for Global Arrays and we wrote our API documentation in 
LaTeX. Each function has C and Fortran-specific documentation as well as some 
generic documentation that can apply to either interface. We run the tex files 
through a preprocessor that filters out just the C or Fortran-specific text to 
build the documentation for the C or Fortran API. It sorta works, but it is a 
fair amount of effort to keep everything synched up and we have a lot fewer 
functions in our API than you do. The one advantage is that everything about a 
particular function is located in one spot, so it makes it relatively easy to 
fix everything up if you make changes.

Bruce

From: Barry Smith 
Date: Tuesday, December 12, 2023 at 9:07 AM
To: Palmer, Bruce J 
Cc: Matthew Knepley , petsc-users@mcs.anl.gov 

Subject: Re: [petsc-users] Fortran Interface

  It is unlikely we will ever be able to maintain full manual pages for Fortran 
for all routines. But yes, the current pages are C-centric.

  Do you have any suggestions on what we could add to the current manual pages 
or how to format them etc that would make them better for Fortran users who are 
not used to C?  A Fortran synopsis as well as the C one, or a single synopsis 
that is easier for both Fortran and C users to follow?

  Barry

I am not sure it is trivial to automatically generate the Fortran synposis with 
appropriate use and include information but one could argue that we should.




On Dec 12, 2023, at 11:40 AM, Palmer, Bruce J via petsc-users 
 wrote:

Thanks! It might be useful if there were a link to this page near the top of 
the C/Fortran API page.

Bruce

From: Matthew Knepley mailto:knep...@gmail.com>>
Date: Tuesday, December 12, 2023 at 8:33 AM
To: Palmer, Bruce J mailto:bruce.pal...@pnnl.gov>>
Cc: petsc-users@mcs.anl.gov<mailto:petsc-users@mcs.anl.gov> 
mailto:petsc-users@mcs.anl.gov>>
Subject: Re: [petsc-users] Fortran Interface
Check twice before you click! This email originated from outside PNNL.

On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
Does documentation for the PETSc fortran interface still exist? I looked at the 
web pages for 3.20 (petsc.org/release<http://petsc.org/release>) but if you go 
under the tab C/Fortran API, only descriptions for the C interface are there.

I think after the most recent changes, the interface was supposed to be very 
close to C, so we just document the differences on specific pages, and put the 
general stuff here:

  https://petsc.org/release/manual/fortran/

   Thanks,

 Matt

Bruce Palmer


--
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

https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Sanjay Govindjee via petsc-users]

I agree with Bruce that having a link to 
https://petsc.org/release/manual/fortran/ at the top of the C/Fortran 
API page (https://petsc.org/release/manualpages/) would be helpful.   
The C descriptions themselves are 98% of the way there for Fortran users 
(like myself).  The only time that more information would be help on the 
manual pages themselves is when there
is a strong variance between the C and Fortran usage, but that can not 
be easily automated.


-sanjay

On 12/12/23 9:07 AM, Barry Smith wrote:


  It is unlikely we will ever be able to maintain full manual pages 
for Fortran for all routines. But yes, the current pages are C-centric.


  Do you have any suggestions on what we could add to the current 
manual pages or how to format them etc that would make them better for 
Fortran users who are not used to C?  A Fortran synopsis as well as 
the C one, or a single synopsis that is easier for both Fortran and C 
users to follow?


  Barry

I am not sure it is trivial to automatically generate the Fortran 
synposis with appropriate use and include information but one could 
argue that we should.




On Dec 12, 2023, at 11:40 AM, Palmer, Bruce J via petsc-users 
 wrote:


Thanks! It might be useful if there were a link to this page near the 
top of the C/Fortran API page.

Bruce

*From:*Matthew Knepley 
*Date:*Tuesday, December 12, 2023 at 8:33 AM
*To:*Palmer, Bruce J 
*Cc:*petsc-users@mcs.anl.gov
*Subject:*Re: [petsc-users] Fortran Interface

Check twice before you click! This email originated from outside PNNL.
On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
 wrote:


Does documentation for the PETSc fortran interface still exist? I
looked at the web pages for 3.20 (petsc.org/release
<http://petsc.org/release>) but if you go under the tab C/Fortran
API, only descriptions for the C interface are there.

I think after the most recent changes, the interface was supposed to 
be very close to C, so we just document the differences on specific 
pages, and put the general stuff here:

https://petsc.org/release/manual/fortran/
   Thanks,
     Matt

Bruce Palmer


--
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
https://www.cse.buffalo.edu/~knepley/ 
<http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Barry Smith]

  It is unlikely we will ever be able to maintain full manual pages for Fortran 
for all routines. But yes, the current pages are C-centric. 

  Do you have any suggestions on what we could add to the current manual pages 
or how to format them etc that would make them better for Fortran users who are 
not used to C?  A Fortran synopsis as well as the C one, or a single synopsis 
that is easier for both Fortran and C users to follow?

  Barry

I am not sure it is trivial to automatically generate the Fortran synposis with 
appropriate use and include information but one could argue that we should.



> On Dec 12, 2023, at 11:40 AM, Palmer, Bruce J via petsc-users 
>  wrote:
> 
> Thanks! It might be useful if there were a link to this page near the top of 
> the C/Fortran API page.
>  
> Bruce
>  
> From: Matthew Knepley mailto:knep...@gmail.com>>
> Date: Tuesday, December 12, 2023 at 8:33 AM
> To: Palmer, Bruce J mailto:bruce.pal...@pnnl.gov>>
> Cc: petsc-users@mcs.anl.gov <mailto:petsc-users@mcs.anl.gov> 
> mailto:petsc-users@mcs.anl.gov>>
> Subject: Re: [petsc-users] Fortran Interface
> 
> Check twice before you click! This email originated from outside PNNL.
>  
> On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
> Does documentation for the PETSc fortran interface still exist? I looked at 
> the web pages for 3.20 (petsc.org/release <http://petsc.org/release>) but if 
> you go under the tab C/Fortran API, only descriptions for the C interface are 
> there.
>  
> I think after the most recent changes, the interface was supposed to be very 
> close to C, so we just document the differences on specific pages, and put 
> the general stuff here:
>  
>   https://petsc.org/release/manual/fortran/
>  
>Thanks,
>  
>  Matt
>  
> Bruce Palmer
> 
>  
> --
> 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
>  
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Palmer, Bruce J via petsc-users]

Thanks! It might be useful if there were a link to this page near the top of 
the C/Fortran API page.

Bruce

From: Matthew Knepley 
Date: Tuesday, December 12, 2023 at 8:33 AM
To: Palmer, Bruce J 
Cc: petsc-users@mcs.anl.gov 
Subject: Re: [petsc-users] Fortran Interface
Check twice before you click! This email originated from outside PNNL.

On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
Does documentation for the PETSc fortran interface still exist? I looked at the 
web pages for 3.20 (petsc.org/release<http://petsc.org/release>) but if you go 
under the tab C/Fortran API, only descriptions for the C interface are there.

I think after the most recent changes, the interface was supposed to be very 
close to C, so we just document the differences on specific pages, and put the 
general stuff here:

  https://petsc.org/release/manual/fortran/

   Thanks,

 Matt

Bruce Palmer


--
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

https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-users] Fortran Interface

[Matthew Knepley]

On Tue, Dec 12, 2023 at 11:27 AM Palmer, Bruce J via petsc-users <
petsc-users@mcs.anl.gov> wrote:

> Does documentation for the PETSc fortran interface still exist? I looked
> at the web pages for 3.20 (petsc.org/release) but if you go under the tab
> C/Fortran API, only descriptions for the C interface are there.
>

I think after the most recent changes, the interface was supposed to be
very close to C, so we just document the differences on specific pages, and
put the general stuff here:

  https://petsc.org/release/manual/fortran/

   Thanks,

 Matt


> Bruce Palmer
>


-- 
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

https://www.cse.buffalo.edu/~knepley/ 

[petsc-users] Fortran Interface

[Palmer, Bruce J via petsc-users]

Does documentation for the PETSc fortran interface still exist? I looked at the 
web pages for 3.20 (petsc.org/release) but if you go under the tab C/Fortran 
API, only descriptions for the C interface are there.

Bruce Palmer

Re: [petsc-users] Fortran Interface NULL object / Casting

[Barry Smith]

   You would use PETSC_NULL_DMLABEL but Matt needs to customize the PETSc 
Fortran stub for DMAddField() for you to handle accepting the NULL from PETSc.

   Barry





> On Dec 8, 2022, at 1:05 PM, Nicholas Arnold-Medabalimi  
> wrote:
> 
> Hi Petsc Users
> 
> I am trying to use DMAddField in a Fortran code. I had some questions on 
> casting/passing NULL. I follow how to pass NULL for standard types (INT, 
> CHAR, etc). 
> 
> Is there a method/best practice for passing NULL for Petsc type arguments? 
> (In this case DMAddLabel I'd want to pass NULL to a DMLabel Parameter not an 
> intrinsic type)
> 
> For the 2nd question, In some cases in C we would cast a more specific object 
> to Petsc Object 
> DMAddField(dm, NULL, (PetscObject)fvm); (where fvm is a PetscFVM type)
> Is there a method or practice to do the same in Fortran.
> 
> Thanks
> Nicholas
> 
> -- 
> Nicholas Arnold-Medabalimi
> 
> Ph.D. Candidate
> Computational Aeroscience Lab
> University of Michigan

[petsc-users] Fortran Interface NULL object / Casting

[Nicholas Arnold-Medabalimi]

Hi Petsc Users

I am trying to use DMAddField in a Fortran code. I had some questions on
casting/passing NULL. I follow how to pass NULL for standard types (INT,
CHAR, etc).

Is there a method/best practice for passing NULL for Petsc type arguments?
(In this case DMAddLabel I'd want to pass NULL to a DMLabel Parameter not
an intrinsic type)

For the 2nd question, In some cases in C we would cast a more specific
object to Petsc Object
DMAddField(dm, NULL, (PetscObject)fvm); (where fvm is a PetscFVM type)
Is there a method or practice to do the same in Fortran.

Thanks
Nicholas

-- 
Nicholas Arnold-Medabalimi

Ph.D. Candidate
Computational Aeroscience Lab
University of Michigan

Re: [petsc-users] Fortran interface of some petsc routines seem to be missing

[Natacha BEREUX via petsc-users]

Dear Barry
thank you very much for this very detailed answer. It's perfectly clear now.
I'll start writing the missing interfaces
I need to wait until I have made progress on writing the interfaces before
deciding whether to create a pull request or send part of the interface
definitions.
In any case, thank you again for your help,
Best regards
Natacha


On Tue, Nov 27, 2018 at 10:49 PM Smith, Barry F.  wrote:

>
> PETSc uses the Sowing packages bfort tool for automatically generating
> "Fortran stub functions" and interface definitions.  There are certain C
> functions that bfort cannot handling including (at least)
>
> 1) functions with character string arguments
> 2) functions with function pointer arguments (such as SNESSetFunction())
> 3) functions that support polymorphism between array and non-array
> arguments (for example VecSetValues() where the ix and y arguments can be
> either scalars or arrays).
> 4) functions that can take a NULL argument.
>
> Functions that bfort can automatically generate the stub and the
> interface definition are marked with /*@ at the beginning of the comment
> above the function (see for example src/ksp/ksp/interface/itcreate.c
> KSPCreate()). If bfort cannot work then the comment begins with /*@C (see
> for example src/sys/objects/pinit.c PetscInitiialize()).
>
> It is our intention to provide manual Fortran stubs and interface for
> functions that bfort cannot handle.
>
> As you note we do not currently provide all the interface definitions,
> many even basic ones are missing. This is because we wrote the manual stub
> functions many, many years ago when we wrote the C functions but only in
> the past couple of years have we been providing interfaces and no one went
> back and added all the required manual interface definitions.
>
>I did not know about the gfortran option -Wimplicit-interface; this is
> a great tool for finding missing interfaces. Thanks for letting us know
> about it.
>
>The manually generated stub functions are stored in files in the
> subdirectories ftn-custom from where the C function is defined. The
> filename is the C file name prepended with a Z and appended with an f. For
> example snes.c   becomes ftn-custom/zsnesf.c   The manually generated
> interface definitions should go into the file src/XXX/f90-mod/petscYYY.h90
> for example the interfaces for VecSetValues are in
> src/vec/f90-mod/petscvec.h90
>
>If you are ambitious and know about pull requests we'd be very happy to
> accept a pull request that provided the missing manual interface
> definitions. If you are less ambitious you could send us the interface
> definitions that you create and we'll add them ourselves to the PETSc
> repository. Or eventually we'll provide more and more of the interface
> definitions as time permits.
>
>
>Barry
>
>
>
>
>
>
>
> > On Nov 27, 2018, at 9:28 AM, Natacha BEREUX via petsc-users <
> petsc-users@mcs.anl.gov> wrote:
> >
> > Hello,
> > I work on a Fortran software that uses PETSc for linear solvers.
> Therefore, we have a PETSc interface to convert our matrices to PETSc Mat.
> > I have noticed several compiler warnings ( I use gfortran with
> -Wimplicit-interface)  during compilation. The warnings point out that some
> (but not all) fortran interfaces are missing.
> >
> > The behaviour is the same when I compile a PETSC example. Below is
> src/vec/vec/examples/tutorials/ex9f.F compiled with gfortran.
> >
> > mpif90 -c -fPIC -Wall -ffree-line-length-0 -Wno-unused-dummy-argument
> -Wimplicit-interface  -g -O
> -I/home/H03755/Librairies/petsc-3.10.1/include
> -I/home/H03755/Librairies/petsc-3.10.1/linux-opt-mumps-ml-hypre-superlu/include
> -I/home/H03755/dev/codeaster-prerequisites/v14/prerequisites/Mumps-512_consortium_aster3/MPI/include
> -I/home/H03755/local/petsc/petsc-3.10.1/include-o ex9f.o ex9f.F90
> > ex9f.F90:34.53:
> >
> >   call PetscInitialize(PETSC_NULL_CHARACTER,ierr)
> >  1
> > Warning: Procedure 'petscinitialize' called with an implicit interface
> at (1)
> > ex9f.F90:42.91:
> >
> >   if (size .ne. 2) then; call
> PetscError(PETSC_COMM_WORLD,1,0,'Requires 2 processors'); call
> MPIU_Abort(PETSC_COMM_WORLD,1); endif
> >
>   1
> > Warning: Procedure 'petscerror' called with an implicit interface at (1)
> > ex9f.F90:42.128:
> >
> >   if (size .ne. 2) then; call
> PetscError(PETSC_COMM_WORLD,1,0,'Requires 2 processors'); call
> MPIU_Abort(PETSC_COMM_WORLD,1); endif
> >
>1
> > Warning: Procedure 'mpiu_abort' called with an implicit interface at (1)
> > ex9f.F90:81.56:
> >
> >  &PETSC_DECIDE,nghost,ifrom,tarray,gxs,ierr)
> > 1
> > Warning: Procedure 'veccreateghostwitharray' called with an implicit
> interface at (1)
> > ex9f.F90:99.53:
> >
> >call VecGetOwnershipRange(gx,rstart,rend,ierr)
> >  

Re: [petsc-users] Fortran interface of some petsc routines seem to be missing

[Smith, Barry F. via petsc-users]

PETSc uses the Sowing packages bfort tool for automatically generating 
"Fortran stub functions" and interface definitions.  There are certain C 
functions that bfort cannot handling including (at least)

1) functions with character string arguments
2) functions with function pointer arguments (such as SNESSetFunction())
3) functions that support polymorphism between array and non-array arguments 
(for example VecSetValues() where the ix and y arguments can be either scalars 
or arrays).
4) functions that can take a NULL argument. 

Functions that bfort can automatically generate the stub and the interface 
definition are marked with /*@ at the beginning of the comment above the 
function (see for example src/ksp/ksp/interface/itcreate.c KSPCreate()). If 
bfort cannot work then the comment begins with /*@C (see for example 
src/sys/objects/pinit.c PetscInitiialize()).

It is our intention to provide manual Fortran stubs and interface for 
functions that bfort cannot handle. 

As you note we do not currently provide all the interface definitions, many 
even basic ones are missing. This is because we wrote the manual stub functions 
many, many years ago when we wrote the C functions but only in the past couple 
of years have we been providing interfaces and no one went back and added all 
the required manual interface definitions.

   I did not know about the gfortran option -Wimplicit-interface; this is a 
great tool for finding missing interfaces. Thanks for letting us know about it.

   The manually generated stub functions are stored in files in the 
subdirectories ftn-custom from where the C function is defined. The filename is 
the C file name prepended with a Z and appended with an f. For example snes.c   
becomes ftn-custom/zsnesf.c   The manually generated interface definitions 
should go into the file src/XXX/f90-mod/petscYYY.h90 for example the interfaces 
for VecSetValues are in src/vec/f90-mod/petscvec.h90   

   If you are ambitious and know about pull requests we'd be very happy to 
accept a pull request that provided the missing manual interface definitions. 
If you are less ambitious you could send us the interface definitions that you 
create and we'll add them ourselves to the PETSc repository. Or eventually 
we'll provide more and more of the interface definitions as time permits.


   Barry





   

> On Nov 27, 2018, at 9:28 AM, Natacha BEREUX via petsc-users 
>  wrote:
> 
> Hello, 
> I work on a Fortran software that uses PETSc for linear solvers. Therefore, 
> we have a PETSc interface to convert our matrices to PETSc Mat. 
> I have noticed several compiler warnings ( I use gfortran with 
> -Wimplicit-interface)  during compilation. The warnings point out that some 
> (but not all) fortran interfaces are missing.  
> 
> The behaviour is the same when I compile a PETSC example. Below is 
> src/vec/vec/examples/tutorials/ex9f.F compiled with gfortran.  
> 
> mpif90 -c -fPIC -Wall -ffree-line-length-0 -Wno-unused-dummy-argument 
> -Wimplicit-interface  -g -O-I/home/H03755/Librairies/petsc-3.10.1/include 
> -I/home/H03755/Librairies/petsc-3.10.1/linux-opt-mumps-ml-hypre-superlu/include
>  
> -I/home/H03755/dev/codeaster-prerequisites/v14/prerequisites/Mumps-512_consortium_aster3/MPI/include
>  -I/home/H03755/local/petsc/petsc-3.10.1/include-o ex9f.o ex9f.F90
> ex9f.F90:34.53:
> 
>   call PetscInitialize(PETSC_NULL_CHARACTER,ierr)
>  1
> Warning: Procedure 'petscinitialize' called with an implicit interface at (1)
> ex9f.F90:42.91:
> 
>   if (size .ne. 2) then; call PetscError(PETSC_COMM_WORLD,1,0,'Requires 2 
> processors'); call MPIU_Abort(PETSC_COMM_WORLD,1); endif
>   
>  1
> Warning: Procedure 'petscerror' called with an implicit interface at (1)
> ex9f.F90:42.128:
> 
>   if (size .ne. 2) then; call PetscError(PETSC_COMM_WORLD,1,0,'Requires 2 
> processors'); call MPIU_Abort(PETSC_COMM_WORLD,1); endif
>   
>   1
> Warning: Procedure 'mpiu_abort' called with an implicit interface at (1)
> ex9f.F90:81.56:
> 
>  &PETSC_DECIDE,nghost,ifrom,tarray,gxs,ierr)
> 1
> Warning: Procedure 'veccreateghostwitharray' called with an implicit 
> interface at (1)
> ex9f.F90:99.53:
> 
>call VecGetOwnershipRange(gx,rstart,rend,ierr)
>  1
> Warning: Procedure 'vecgetownershiprange' called with an implicit interface 
> at (1)
> ex9f.F90:115.93:
> 
>call 
> PetscViewerGetSubViewer(PETSC_VIEWER_STDOUT_WORLD,PETSC_COMM_SELF,subviewer,ierr)
>   
>1
> Warning: Procedure 'petscviewergetsubvi

Re: [petsc-users] Fortran interface of MatNullSpaceCreate

[Smith, Barry F.]

> On Feb 26, 2018, at 5:38 PM, Sanjay Govindjee  wrote:
> 
> If PETSc is expecting an integer, I presume it is fine to pass 
> PETSC_NULL_INTEGER(1)?

  Not if the function has an interface definition. Fortran interfaces 
distinguish between   passing an integer a and an integer a(1) so you can
only use PETSC_NULL_INTEGER if it expects an array.

> 
> On 2/26/18 11:53 PM, Smith, Barry F. wrote:
>> PETSC_NULL_INTEGER is actually declared as an array of size 1 (this is why 
>> you get the confusing message about no specific subroutine that matches). 
>> PETSC_NULL_INTEGER  can only be passed where PETSc expects and integer 
>> array, not an integer scalar.
>> 
>>   Barry
> 
> -- 
> ---
> Sanjay Govindjee, PhD, PE
> Horace, Dorothy, and Katherine Johnson Professor in Engineering
> 
> 779 Davis Hall
> University of California
> Berkeley, CA 94720-1710
> 
> Voice:  +1 510 642 6060
> FAX:+1 510 643 5264
> s...@berkeley.edu
> http://faculty.ce.berkeley.edu/sanjay
> ---
> 
> Books:
> 
> Engineering Mechanics of Deformable
> Solids: A Presentation with Exercises
> http://ukcatalogue.oup.com/product/9780199651641.do
> http://amzn.com/0199651647
> 
> Engineering Mechanics 3 (Dynamics) 2nd Edition
> http://www.springer.com/978-3-642-53711-0
> http://amzn.com/3642537111
> 
> Engineering Mechanics 3, Supplementary Problems: Dynamics
> http://www.amzn.com/B00SOXN8JU
> 
> ---
> 

Re: [petsc-users] Fortran interface of MatNullSpaceCreate

[Sanjay Govindjee]

If PETSc is expecting an integer, I presume it is fine to pass 
PETSC_NULL_INTEGER(1)?


On 2/26/18 11:53 PM, Smith, Barry F. wrote:

PETSC_NULL_INTEGER is actually declared as an array of size 1 (this is why you 
get the confusing message about no specific subroutine that matches). 
PETSC_NULL_INTEGER  can only be passed where PETSc expects and integer array, 
not an integer scalar.

   Barry


--
---
Sanjay Govindjee, PhD, PE
Horace, Dorothy, and Katherine Johnson Professor in Engineering

779 Davis Hall
University of California
Berkeley, CA 94720-1710

Voice:  +1 510 642 6060
FAX:+1 510 643 5264
s...@berkeley.edu
http://faculty.ce.berkeley.edu/sanjay
---

Books:

Engineering Mechanics of Deformable
Solids: A Presentation with Exercises
http://ukcatalogue.oup.com/product/9780199651641.do
http://amzn.com/0199651647

Engineering Mechanics 3 (Dynamics) 2nd Edition
http://www.springer.com/978-3-642-53711-0
http://amzn.com/3642537111

Engineering Mechanics 3, Supplementary Problems: Dynamics
http://www.amzn.com/B00SOXN8JU

---

Re: [petsc-users] Fortran interface of MatNullSpaceCreate

[Smith, Barry F.]

> On Feb 26, 2018, at 4:47 PM, frank  wrote:
> 
> Hello,
> 
> It works after changing PETSC_NULL_INTEGER to 0. Thank you so much.
> 
> Does this mean the 3rd argument is a Fortran integer rather than PestcInt?

  No it is actually a PetscInt so technically you should declare

   PetscInt   zero

   zero = 0

   and pass in zero.

   The reason PETSC_NULL_INTEGER doesn't work is 1) it should not be used as a 
synonym for 0; it is a "pointer" to null not zero 2) PETSC_NULL_INTEGER is 
actually declared as an array of size 1 (this is why you get the confusing 
message about no specific subroutine that matches). PETSC_NULL_INTEGER  can 
only be passed where PETSc expects and integer array, not an integer scalar.

  Barry
 

> 
> Regards,
> 
> Frank
> 
> On 02/26/2018 02:35 PM, Smith, Barry F. wrote:
>>   It should be
>> 
>>> call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 0, dummyVecs, 
>>> nullspace, ierr)
>>   If this doesn't work please send your test code that I can compile myself 
>> and figure out what is going on.
>> 
>>   Barry
>> 
>> 
>> 
>> 
>>> On Feb 26, 2018, at 4:18 PM, frank  wrote:
>>> 
>>> Hello,
>>> 
>>> I have a question of the Fortran interface of subroutine MatNullSpaceCreate.
>>> 
>>> I tried to call the subroutine in the following form:
>>> 
>>> Vec :: dummyVec, dummyVecs(1)
>>> MatNullSpace :: nullspace
>>> INTEGER :: ierr
>>> 
>>> (a) call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 
>>> PETSC_NULL_INTEGER, dummyVec, nullspace, ierr)
>>> 
>>> (b) call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 
>>> PETSC_NULL_INTEGER, dummyVecs, nullspace, ierr)
>>> 
>>> (a) and (b) gave me the same error during compilation: no specific 
>>> subroutine for the generic MatNullSpaceCreate.
>>> 
>>> I am using the latest version of Petsc. I just did a "git pull" and 
>>> re-build it.
>>> How can I call the subroutine ?
>>> 
>>> In addition, I found two 'petscmat.h90' : 
>>> petsc/include/petsc/finclude/ftn-auto/petscmat.h90 and 
>>> petsc/src/mat/f90-mod/petscmat.h90.
>>> The former defines a subroutine MatNullSpaceCreate in the above form (b). 
>>> The latter provides generic interface for both (a) and (b).
>>> I am not sure if this relates to the error I get.
>>> 
>>> Thank you.
>>> 
>>> Frank
> 

Re: [petsc-users] Fortran interface of MatNullSpaceCreate

[Smith, Barry F.]

  It should be 

> call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 0, dummyVecs, 
> nullspace, ierr)

  If this doesn't work please send your test code that I can compile myself and 
figure out what is going on.

  Barry




> On Feb 26, 2018, at 4:18 PM, frank  wrote:
> 
> Hello,
> 
> I have a question of the Fortran interface of subroutine MatNullSpaceCreate.
> 
> I tried to call the subroutine in the following form:
> 
> Vec :: dummyVec, dummyVecs(1)
> MatNullSpace :: nullspace
> INTEGER :: ierr
> 
> (a) call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 
> PETSC_NULL_INTEGER, dummyVec, nullspace, ierr)
> 
> (b) call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 
> PETSC_NULL_INTEGER, dummyVecs, nullspace, ierr)
> 
> (a) and (b) gave me the same error during compilation: no specific subroutine 
> for the generic MatNullSpaceCreate.
> 
> I am using the latest version of Petsc. I just did a "git pull" and re-build 
> it.
> How can I call the subroutine ?
> 
> In addition, I found two 'petscmat.h90' : 
> petsc/include/petsc/finclude/ftn-auto/petscmat.h90 and 
> petsc/src/mat/f90-mod/petscmat.h90.
> The former defines a subroutine MatNullSpaceCreate in the above form (b). The 
> latter provides generic interface for both (a) and (b).
> I am not sure if this relates to the error I get.
> 
> Thank you.
> 
> Frank

[petsc-users] Fortran interface of MatNullSpaceCreate

[frank]

Hello,

I have a question of the Fortran interface of subroutine MatNullSpaceCreate.

I tried to call the subroutine in the following form:

Vec :: dummyVec, dummyVecs(1)
MatNullSpace :: nullspace
INTEGER :: ierr

(a) call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 
PETSC_NULL_INTEGER, dummyVec, nullspace, ierr)


(b) call MatNullSpaceCreate( PETSC_COMM_WORLD, PETSC_TRUE, 
PETSC_NULL_INTEGER, dummyVecs, nullspace, ierr)


(a) and (b) gave me the same error during compilation: no specific 
subroutine for the generic MatNullSpaceCreate.


I am using the latest version of Petsc. I just did a "git pull" and 
re-build it.

How can I call the subroutine ?

In addition, I found two 'petscmat.h90' : 
petsc/include/petsc/finclude/ftn-auto/petscmat.h90 and 
petsc/src/mat/f90-mod/petscmat.h90.
The former defines a subroutine MatNullSpaceCreate in the above form 
(b). The latter provides generic interface for both (a) and (b).

I am not sure if this relates to the error I get.

Thank you.

Frank

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Hossein Talebi]

1. You really need to profile.  Copying a vector is cheap.

>>>You are right. Maybe I make a big thing for this copy in/out and it is
not that problematic or slow even for the whole 2D matrix. I have to test
it with a large one to see.



> 2. If you make your functions (to evaluate residuals, etc) take their
>inputs as explicit arguments, you can just pass the PETSc objects (or

   get the arrays from PETSc).
>

>>>I did not understand this completely.

>
> 3. Parallel matrix assembly is almost certainly not something for which
>you want to hard-code the data structure.  PETSc provides generic
>interfaces for _incrementally_ assembling matrices, so that there is
>no extra storage and so the resulting data structure can be chosen at
>run-time.  I challenge you to find evidence that you can do this
>better.
>
> >>>Well, no wonder petsc is a very general and mature solution. I have
coded this already and it works fine with couple of other solvers. I cannot
say it is faster/better than petsc and I even don't think the comparison
would be correct. Though I would accept the challenge if I had time :-). I
have the single code/single language strategy so my code should be able to
compile and run without any external library. I attach many external
libraries for additional tasks. Anyhow, my primary aim is to use petsc for
its nice linear equation solvers.



> 4. If you really want to use _your_ storage for a Vec or Mat, you can
>use VecCreateMPIWithArray, MatCreateMPIAIJWithSplitArrays, and the
>like.
>
This looks to be a solution. Thank you.



> All of the above are available through _public_ interfaces that are
> already available to Fortran callers.  Please don't use F2003 to expose
> the _private_ struct definitions that we do not even offer to C callers.
>
> >>>I agree.


> > 3) easy definitions of petsc namespace through the Fortran modules, so I
> > can choose what to import (using the Fortran 'only' statement).
>
> PETSc uses prefixes for namespaces.  You can use "only" with the normal
> modules, but I can't tell if you are suggesting changing the names to
> avoid the prefix (which I don't think is a good idea and will lead to
> some collisions).
>
>>>Not to change the namespace but to limit it. When I put C-type include
statements it brings all mostly unnecessary namespace which might collide
with others, as you mentioned.

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Jed Brown]

Hossein Talebi  writes:

> Exactly, I personally look for:
>
> 1) type checking during the function calls. This helps also not looking
> into the manual for every single petsc function call.
>
> 2) low level access to petsc data structure. For example in my own code I
> already have my own hadnling of parallel vectors and matrices. When I use
> petsc, I have to always copy in/out all the data which is not optimal. So,
> it would be great if I can share or be change the petsc data in my Fortran
> code i.e. not through the petsc function calls. I understand this might be
> dangerous or not duable etc. But, I see no other solution.

1. You really need to profile.  Copying a vector is cheap.

2. If you make your functions (to evaluate residuals, etc) take their
   inputs as explicit arguments, you can just pass the PETSc objects (or
   get the arrays from PETSc).

3. Parallel matrix assembly is almost certainly not something for which
   you want to hard-code the data structure.  PETSc provides generic
   interfaces for _incrementally_ assembling matrices, so that there is
   no extra storage and so the resulting data structure can be chosen at
   run-time.  I challenge you to find evidence that you can do this
   better.

4. If you really want to use _your_ storage for a Vec or Mat, you can
   use VecCreateMPIWithArray, MatCreateMPIAIJWithSplitArrays, and the
   like.

All of the above are available through _public_ interfaces that are
already available to Fortran callers.  Please don't use F2003 to expose
the _private_ struct definitions that we do not even offer to C callers.

> 3) easy definitions of petsc namespace through the Fortran modules, so I
> can choose what to import (using the Fortran 'only' statement).

PETSc uses prefixes for namespaces.  You can use "only" with the normal
modules, but I can't tell if you are suggesting changing the names to
avoid the prefix (which I don't think is a good idea and will lead to
some collisions).

> There is no general automatic interface generation for Fortran, as much as
> I'm aware of. The gtk-fortran project, they wrote a python script to
> generate this interface automatically and it really works nicely. I could
> not imagine writiing such nice GTK GUI with Fortran.

Hmm, it may be interesting to look at that script and see if it can be adapted.


pgpyqyFZyNKmp.pgp
Description: PGP signature

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Hossein Talebi]

Exactly, I personally look for:

1) type checking during the function calls. This helps also not looking
into the manual for every single petsc function call.

2) low level access to petsc data structure. For example in my own code I
already have my own hadnling of parallel vectors and matrices. When I use
petsc, I have to always copy in/out all the data which is not optimal. So,
it would be great if I can share or be change the petsc data in my Fortran
code i.e. not through the petsc function calls. I understand this might be
dangerous or not duable etc. But, I see no other solution.

3) easy definitions of petsc namespace through the Fortran modules, so I
can choose what to import (using the Fortran 'only' statement).

There is no general automatic interface generation for Fortran, as much as
I'm aware of. The gtk-fortran project, they wrote a python script to
generate this interface automatically and it really works nicely. I could
not imagine writiing such nice GTK GUI with Fortran.




On Mon, Oct 28, 2013 at 2:15 PM, Jed Brown  wrote:

> Hossein Talebi  writes:
> > What was in my mind is to create an interface additional to what is
> already
> > there in petsc. So this should be compiled along with anyone's code if
> the
> > used ocmpiler supports F03 or the necessary features of F03.
>
> I don't think anyone will want to manually maintain the interface
> definitions for all of PETSc.  (F2003 users can call the C interface
> using the C types support now, but of course you'd rather have Fortran
> interfaces so that you can have type checking.)  It seems to me that the
> big win of F2003 is that it should be possible to automatically generate
> almost all these definitions.  But how would you manage callbacks?
>



-- 
Dr.-Ing. Hossein Talebi

Bauhaus-Universität Weimar
Graudate Research School 1462 "Evaluation of Coupled Numerical and
Experimental Partial Models in Structural Engineering "
Postdoctoral Researcher

Berkaer Str. 9
99425 Weimar
Tel.: +49/3643/58 41 03
Fax:  +49/3643/58 41 01
E-Mail: hossein.tal...@uni-weimar.de 
www.uni-weimar.de/grk1462

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Jed Brown]

Hossein Talebi  writes:
> What was in my mind is to create an interface additional to what is already
> there in petsc. So this should be compiled along with anyone's code if the
> used ocmpiler supports F03 or the necessary features of F03. 

I don't think anyone will want to manually maintain the interface
definitions for all of PETSc.  (F2003 users can call the C interface
using the C types support now, but of course you'd rather have Fortran
interfaces so that you can have type checking.)  It seems to me that the
big win of F2003 is that it should be possible to automatically generate
almost all these definitions.  But how would you manage callbacks?


pgp1785DDtSgZ.pgp
Description: PGP signature

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Hossein Talebi]

Well, when dealing with Fortran I also often encounter software which
cannot be changed or upgraded to a more modern style.

What was in my mind is to create an interface additional to what is already
there in petsc. So this should be compiled along with anyone's code if the
used ocmpiler supports F03 or the necessary features of F03. This way the
older codes can be kept with the original F77 interface. Same thing they
did for Mpi and F03, F08 in the Mpi 3 standard if I'm not mistaken.





On Sun, Oct 27, 2013 at 8:51 PM, Tabrez Ali  wrote:

>  On 10/27/2013 12:36 PM, Hossein Talebi wrote:
>
> Thank you for your answer.
>
>  It is not true that F2003 support is that limited: Gfortran, Intel
> Fortran, Cray Fortran, IBM Fortran and PGI Fortran all support nearly full
> F2003. Some other ones support the C portability of F2003 although not
> supporting the rest.
>
>
> You're 100% right but many systems often have older versions of these
> compilers that don't support the Fortran C interoperability. There is
> absolutely no excuse to not upgrade but then its not always possible.
>
> Unless there is a significant gain in functionality (or ease of support)
> by moving to a Fortran 2003 compiler it would be better to be conservative.
> One advantage of being able to build PETSc on a old enough system (e.g.,
> Debian Etch with GCC 4.1; glibc 2.4)  is that you can very easily build a
> static binary of your code and it will run pretty much on every Linux
> machine out there.
>
>
> T
>
>  * I can contribute on creating this interface. I have experience with
> F2003 to C++ and it works fine while C is a lot easier. My idea is to
> create the F03 interface to petsc as a separate tool. So, anyone trying to
> use petsc with a F03 compiler can compile this interface again to avoid the
> compiler inconsistency of Modules.
>
>  We can work on a python (or similar) script to generate the interfaces.
> For example, a project called gtk-fortran uses this method. Can any of you
> guys help a little for planning the interface design?
>
>
>  Cheers
> Hossein
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Oct 27, 2013 at 4:42 PM, Satish Balay  wrote:
>
>> On Sun, 27 Oct 2013, Matthew Knepley wrote:
>>
>> > On Sun, Oct 27, 2013 at 6:16 AM, Hossein Talebi <
>> talebi.hoss...@gmail.com>wrote:
>> >
>> > >  Hello All,
>> > >
>> > > I am trying to use petsc with Fortran. The initial mechanism to use
>> petsc
>> > > with FORTRAN77 that works fine. However, I found the Fortran 90
>> interfaces
>> > > difficult to work with. The very first issue is one has to recompile
>> petsc
>> > > with the Fortran compiler in case different to the one which was used
>> to
>> > > create the Fortran Mod files.
>>
>>  Yes - one cannot mix fortran code compiled with 2 different compilers
>> - or 2 different version of the same compiler wrt modules.
>>
>> But we generally recommend not mixing compilers   for C aswell as
>> this
>> can cause problems.
>>
>> Also you don't need to use modules to get f90 interfaces. You can include
>> the f90 interface include filesdirectly in your code.
>>
>> #incude "finclude/petsc.h90"
>>
>> > > Also, we would still need to use C type
>> > > #include statements along with Fortran 'use' statement which is not so
>> > > optimal.
>>
>>  Even if you were to use f90 modules #include is unavoidable as we still
>> have other stuff in include files.
>>
>> check include/finclude/petscsysdef.h  include/finclude/petscsys.h
>>
>> > > Since Fortran 2003 offers great interface to C, did anyone try to
>> write a
>> > > F03 interface to petsc? Using F03 features, we can have very low data
>> > > access to petsc database as well.
>> > >
>> >
>> > F2003 support is fairly thin in the compiler world, and we have not had
>> > much call for it. We do gratefully accept contributions.
>>
>>  Currently we have the f90 interfaces [in include/finclude/ftn-auto/]
>> automatically generated by bfort tool from the C interface. So to
>> support F03 it would be ideal if there is such a tool. [or update
>> bfort to do it]
>>
>> Satish
>>
>
>
>
>
>
> --
> No one trusts a model except the one who wrote it; Everyone trusts an 
> observation except the one who made it- Harlow Shapley
>
>


-- 
Dr.-Ing. Hossein Talebi

Bauhaus-Universität Weimar
Graudate Research School 1462 "Evaluation of Coupled Numerical and
Experimental Partial Models in Structural Engineering "
Postdoctoral Researcher

Berkaer Str. 9
99425 Weimar
Tel.: +49/3643/58 41 03
Fax:  +49/3643/58 41 01
E-Mail: hossein.tal...@uni-weimar.de 
www.uni-weimar.de/grk1462

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Tabrez Ali]

On 10/27/2013 12:36 PM, Hossein Talebi wrote:

Thank you for your answer.

It is not true that F2003 support is that limited: Gfortran, Intel 
Fortran, Cray Fortran, IBM Fortran and PGI Fortran all support nearly 
full F2003. Some other ones support the C portability of F2003 
although not supporting the rest.


You're 100% right but many systems often have older versions of these 
compilers that don't support the Fortran C interoperability. There is 
absolutely no excuse to not upgrade but then its not always possible.


Unless there is a significant gain in functionality (or ease of support) 
by moving to a Fortran 2003 compiler it would be better to be 
conservative. One advantage of being able to build PETSc on a old enough 
system (e.g., Debian Etch with GCC 4.1; glibc 2.4)  is that you can very 
easily build a static binary of your code and it will run pretty much on 
every Linux machine out there.


T

* I can contribute on creating this interface. I have experience with 
F2003 to C++ and it works fine while C is a lot easier. My idea is to 
create the F03 interface to petsc as a separate tool. So, anyone 
trying to use petsc with a F03 compiler can compile this interface 
again to avoid the compiler inconsistency of Modules.


We can work on a python (or similar) script to generate the 
interfaces. For example, a project called gtk-fortran uses this 
method. Can any of you guys help a little for planning the interface 
design?



Cheers
Hossein










On Sun, Oct 27, 2013 at 4:42 PM, Satish Balay > wrote:


On Sun, 27 Oct 2013, Matthew Knepley wrote:

> On Sun, Oct 27, 2013 at 6:16 AM, Hossein Talebi
mailto:talebi.hoss...@gmail.com>>wrote:
>
> >  Hello All,
> >
> > I am trying to use petsc with Fortran. The initial mechanism
to use petsc
> > with FORTRAN77 that works fine. However, I found the Fortran
90 interfaces
> > difficult to work with. The very first issue is one has to
recompile petsc
> > with the Fortran compiler in case different to the one which
was used to
> > create the Fortran Mod files.

Yes - one cannot mix fortran code compiled with 2 different compilers
- or 2 different version of the same compiler wrt modules.

But we generally recommend not mixing compilers   for C aswell as
  this
can cause problems.

Also you don't need to use modules to get f90 interfaces. You can
include
the f90 interface include filesdirectly in your code.

#incude "finclude/petsc.h90"

> > Also, we would still need to use C type
> > #include statements along with Fortran 'use' statement which
is not so
> > optimal.

Even if you were to use f90 modules #include is unavoidable as we
still
have other stuff in include files.

check include/finclude/petscsysdef.h  include/finclude/petscsys.h

> > Since Fortran 2003 offers great interface to C, did anyone try
to write a
> > F03 interface to petsc? Using F03 features, we can have very
low data
> > access to petsc database as well.
> >
>
> F2003 support is fairly thin in the compiler world, and we have
not had
> much call for it. We do gratefully accept contributions.

Currently we have the f90 interfaces [in include/finclude/ftn-auto/]
automatically generated by bfort tool from the C interface. So to
support F03 it would be ideal if there is such a tool. [or update
bfort to do it]

Satish







--
No one trusts a model except the one who wrote it; Everyone trusts an 
observation except the one who made it- Harlow Shapley

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Hossein Talebi]

Thank you for your answer.

It is not true that F2003 support is that limited: Gfortran, Intel Fortran,
Cray Fortran, IBM Fortran and PGI Fortran all support nearly full F2003.
Some other ones support the C portability of F2003 although not supporting
the rest.

* I can contribute on creating this interface. I have experience with F2003
to C++ and it works fine while C is a lot easier. My idea is to create the
F03 interface to petsc as a separate tool. So, anyone trying to use petsc
with a F03 compiler can compile this interface again to avoid the compiler
inconsistency of Modules.

We can work on a python (or similar) script to generate the interfaces. For
example, a project called gtk-fortran uses this method. Can any of you guys
help a little for planning the interface design?


Cheers
Hossein












On Sun, Oct 27, 2013 at 4:42 PM, Satish Balay  wrote:

> On Sun, 27 Oct 2013, Matthew Knepley wrote:
>
> > On Sun, Oct 27, 2013 at 6:16 AM, Hossein Talebi <
> talebi.hoss...@gmail.com>wrote:
> >
> > >  Hello All,
> > >
> > > I am trying to use petsc with Fortran. The initial mechanism to use
> petsc
> > > with FORTRAN77 that works fine. However, I found the Fortran 90
> interfaces
> > > difficult to work with. The very first issue is one has to recompile
> petsc
> > > with the Fortran compiler in case different to the one which was used
> to
> > > create the Fortran Mod files.
>
> Yes - one cannot mix fortran code compiled with 2 different compilers
> - or 2 different version of the same compiler wrt modules.
>
> But we generally recommend not mixing compilers   for C aswell as
> this
> can cause problems.
>
> Also you don't need to use modules to get f90 interfaces. You can include
> the f90 interface include filesdirectly in your code.
>
> #incude "finclude/petsc.h90"
>
> > > Also, we would still need to use C type
> > > #include statements along with Fortran 'use' statement which is not so
> > > optimal.
>
> Even if you were to use f90 modules #include is unavoidable as we still
> have other stuff in include files.
>
> check include/finclude/petscsysdef.h  include/finclude/petscsys.h
>
> > > Since Fortran 2003 offers great interface to C, did anyone try to
> write a
> > > F03 interface to petsc? Using F03 features, we can have very low data
> > > access to petsc database as well.
> > >
> >
> > F2003 support is fairly thin in the compiler world, and we have not had
> > much call for it. We do gratefully accept contributions.
>
> Currently we have the f90 interfaces [in include/finclude/ftn-auto/]
> automatically generated by bfort tool from the C interface. So to
> support F03 it would be ideal if there is such a tool. [or update
> bfort to do it]
>
> Satish
>

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Satish Balay]

On Sun, 27 Oct 2013, Matthew Knepley wrote:

> On Sun, Oct 27, 2013 at 6:16 AM, Hossein Talebi 
> wrote:
> 
> >  Hello All,
> >
> > I am trying to use petsc with Fortran. The initial mechanism to use petsc
> > with FORTRAN77 that works fine. However, I found the Fortran 90 interfaces
> > difficult to work with. The very first issue is one has to recompile petsc
> > with the Fortran compiler in case different to the one which was used to
> > create the Fortran Mod files.

Yes - one cannot mix fortran code compiled with 2 different compilers
- or 2 different version of the same compiler wrt modules.

But we generally recommend not mixing compilers   for C aswell as   this
can cause problems.

Also you don't need to use modules to get f90 interfaces. You can include
the f90 interface include filesdirectly in your code.

#incude "finclude/petsc.h90"

> > Also, we would still need to use C type
> > #include statements along with Fortran 'use' statement which is not so
> > optimal.

Even if you were to use f90 modules #include is unavoidable as we still
have other stuff in include files.

check include/finclude/petscsysdef.h  include/finclude/petscsys.h

> > Since Fortran 2003 offers great interface to C, did anyone try to write a
> > F03 interface to petsc? Using F03 features, we can have very low data
> > access to petsc database as well.
> >
> 
> F2003 support is fairly thin in the compiler world, and we have not had
> much call for it. We do gratefully accept contributions.

Currently we have the f90 interfaces [in include/finclude/ftn-auto/]
automatically generated by bfort tool from the C interface. So to
support F03 it would be ideal if there is such a tool. [or update
bfort to do it]

Satish

Re: [petsc-users] Fortran interface -- low level access to petsc data

[Matthew Knepley]

On Sun, Oct 27, 2013 at 6:16 AM, Hossein Talebi wrote:

>  Hello All,
>
> I am trying to use petsc with Fortran. The initial mechanism to use petsc
> with FORTRAN77 that works fine. However, I found the Fortran 90 interfaces
> difficult to work with. The very first issue is one has to recompile petsc
> with the Fortran compiler in case different to the one which was used to
> create the Fortran Mod files. Also, we would still need to use C type
> #include statements along with Fortran 'use' statement which is not so
> optimal.
>
> Since Fortran 2003 offers great interface to C, did anyone try to write a
> F03 interface to petsc? Using F03 features, we can have very low data
> access to petsc database as well.
>

F2003 support is fairly thin in the compiler world, and we have not had
much call for it. We do gratefully accept contributions.

  Thanks,

 Matt


> Cheers
> Hossein
>
>


-- 
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

[petsc-users] Fortran interface -- low level access to petsc data

[Hossein Talebi]

 Hello All,

I am trying to use petsc with Fortran. The initial mechanism to use petsc
with FORTRAN77 that works fine. However, I found the Fortran 90 interfaces
difficult to work with. The very first issue is one has to recompile petsc
with the Fortran compiler in case different to the one which was used to
create the Fortran Mod files. Also, we would still need to use C type
#include statements along with Fortran 'use' statement which is not so
optimal.

Since Fortran 2003 offers great interface to C, did anyone try to write a
F03 interface to petsc? Using F03 features, we can have very low data
access to petsc database as well.


Cheers
Hossein