[petsc-users] KSP has an extra iteration when use shell matrix
Barry Smith
bsmith at petsc.dev
Tue Feb 6 15:11:12 CST 2024
> On Feb 6, 2024, at 3:49 PM, Yi Hu <y.hu at mpie.de> wrote:
>
> Dear Barry,
>
> Thanks for your help. You suggestion works.
>
> I found out another approach. I can still use Vec as ctx of my MatShell, then I just need to initialize my MatShell with my solver Vec x. Then I can use an empty FormJacobShell(), coz my MatShell ctx is automatically updated with my solver vec (as I initialized with it). In MyMult the ctx of MatShell is the current solve vec.
>
This is slightly dangerous and may not always work. This is because the x passed to the computeJacobian routine is not guaranteed to be exactly the vector you passed into SNESSolve() as the solution (it could potentially be some temporary work vector). I think it is best not to rely on the vector always being the same.
> Best regards,
>
> Yi
>
> On 2/6/24 01:39, Barry Smith wrote:
>>
>> You cannot do call MatShellSetContext(jac,X,ierr) in subroutine FormJacobianShell(snes,X,jac,B,dummy,ierr) because Fortran arguments are always pass by address and the address of the X being passed in may not be valid after the routine that called FormJacobianShell() has returned. This is why the GetContext works inside this function but not later in MyMult.
>>
>> Instead add a Vec Xbase member to the MatCtx type and update that inside FormJacobShell(). Like
>>
>> TYPE(MatCtx),POINTER :: ctxF_pt
>> MatShellGetContext(jac,ctxF_ptr,ierr)
>> ctxF_pt%Xbase = X
>>
>> The reason this works is because ctxF_pt%Xbase = X copies the value of X (the PETSc vector) to Xbase, not the address of X.
>>
>> Barry
>>
>>
>>
>>
>>> On Feb 5, 2024, at 4:18 PM, Yi Hu <y.hu at mpie.de> <mailto:y.hu at mpie.de> wrote:
>>>
>>> Dear Barry,
>>>
>>> the code is attached.
>>>
>>> Just to let you know. When I commented out MatShellSetContext() in FormJacobianShell(), then the code seems to work, meaning that the base vector is passed to shell matrix context behind the scene.
>>>
>>> Best regards,
>>>
>>> Yi
>>>
>>> On 2/5/24 19:09, Barry Smith wrote:
>>>>
>>>> Send the entire code.
>>>>
>>>>
>>>>> On Feb 4, 2024, at 4:43 PM, Yi Hu <y.hu at mpie.de> <mailto:y.hu at mpie.de> wrote:
>>>>>
>>>>> Thanks for your response. You are correct. I overlooked this step.
>>>>>
>>>>> Now I am trying to correct my "shell matrix approach" for ex1f.F90 of snes solver (https://github.com/hyharry/small_petsc_test/blob/master/test_shell_jac/ex1f.F90). I realized that I need to record the base vector X in the context of shell matrix and then use this info to carry MyMult. However, the context cannot be obtained through MatShellGetContext(). Here are the critical parts of my code.
>>>>>
>>>>> INTERFACE MatCreateShell
>>>>> SUBROUTINE MatCreateShell(comm,mloc,nloc,m,n,ctx,mat,ierr)
>>>>> USE solver_context
>>>>> MPI_Comm :: comm
>>>>> PetscInt :: mloc,nloc,m,n
>>>>> Vec :: ctx
>>>>> Mat :: mat
>>>>> PetscErrorCode :: ierr
>>>>> END SUBROUTINE MatCreateShell
>>>>> END INTERFACE MatCreateShell
>>>>>
>>>>> INTERFACE MatShellSetContext
>>>>> SUBROUTINE MatShellSetContext(mat,ctx,ierr)
>>>>> USE solver_context
>>>>> Mat :: mat
>>>>> !TYPE(MatCtx) :: ctx
>>>>> Vec :: ctx
>>>>> PetscErrorCode :: ierr
>>>>> END SUBROUTINE MatShellSetContext
>>>>> END INTERFACE MatShellSetContext
>>>>>
>>>>> INTERFACE MatShellGetContext
>>>>> SUBROUTINE MatShellGetContext(mat,ctx,ierr)
>>>>> USE solver_context
>>>>> Mat :: mat
>>>>> Vec, Pointer :: ctx
>>>>> PetscErrorCode :: ierr
>>>>> END SUBROUTINE MatShellGetContext
>>>>> END INTERFACE MatShellGetContext
>>>>>
>>>>> in my FormShellJacobian() I did
>>>>>
>>>>> subroutine FormJacobianShell(snes,X,jac,B,dummy,ierr)
>>>>>
>>>>> ......
>>>>>
>>>>> call MatShellSetContext(jac,X,ierr)
>>>>>
>>>>> ......
>>>>>
>>>>> Then in MyMult() I tried to recover this context by
>>>>>
>>>>> call MatShellGetContext(J,x,ierr)
>>>>>
>>>>> call VecView(x,PETSC_VIEWER_STDOUT_WORLD,ierr)
>>>>>
>>>>> Then the program failed with
>>>>>
>>>>> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
>>>>> [0]PETSC ERROR: Null argument, when expecting valid pointer
>>>>> [0]PETSC ERROR: Null Pointer: Parameter # 1
>>>>>
>>>>> In MyMult, I actually defined x to be a pointer. So I am confused here.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Yi
>>>>>
>>>>> On 1/31/24 03:18, Barry Smith wrote:
>>>>>>
>>>>>> It is not running an extra KSP iteration. This "extra" matmult is normal and occurs in many of the SNESLineSearchApply_* functions, for example, https://petsc.org/release/src/snes/linesearch/impls/bt/linesearchbt.c.html#SNESLineSearchApply_BT It is used to decide if the Newton step results in sufficient decrease of the function value.
>>>>>>
>>>>>> Barry
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jan 30, 2024, at 3:19 PM, Yi Hu <y.hu at mpie.de> <mailto:y.hu at mpie.de> wrote:
>>>>>>>
>>>>>>> Hello Barry,
>>>>>>>
>>>>>>> Thanks for your reply. The monitor options are fine. I actually meant my modification of snes tutorial ex1f.F90 does not work and has some unexpected behavior. I basically wanted to test if I can use a shell matrix as my jacobian (code is here https://github.com/hyharry/small_petsc_test/blob/master/test_shell_jac/ex1f.F90). After compile my modified version and run with these monitor options, it gives me the following,
>>>>>>>
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 0 SNES Function norm 6.041522986797e+00
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 6.041522986797e+00
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 5.065392549852e-16
>>>>>>> Linear solve converged due to CONVERGED_RTOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 1 SNES Function norm 3.512662245652e+00
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 3.512662245652e+00
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 6.230314124713e-16
>>>>>>> Linear solve converged due to CONVERGED_RTOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 2 SNES Function norm 8.969285922373e-01
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 8.969285922373e-01
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 0.000000000000e+00
>>>>>>> Linear solve converged due to CONVERGED_ATOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 3 SNES Function norm 4.863816734540e-01
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 4.863816734540e-01
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 0.000000000000e+00
>>>>>>> Linear solve converged due to CONVERGED_ATOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 4 SNES Function norm 3.512070785520e-01
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 3.512070785520e-01
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 0.000000000000e+00
>>>>>>> Linear solve converged due to CONVERGED_ATOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 5 SNES Function norm 2.769700293115e-01
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 2.769700293115e-01
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 1.104778916974e-16
>>>>>>> Linear solve converged due to CONVERGED_RTOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 6 SNES Function norm 2.055345318150e-01
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 2.055345318150e-01
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 0.000000000000e+00
>>>>>>> Linear solve converged due to CONVERGED_ATOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 7 SNES Function norm 1.267482220786e-01
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 1.267482220786e-01
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 1.498679601680e-17
>>>>>>> Linear solve converged due to CONVERGED_RTOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> 8 SNES Function norm 3.468150619264e-02
>>>>>>> ++++++++++++ in jac shell +++++++++++
>>>>>>> 0 KSP Residual norm 3.468150619264e-02
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> 1 KSP Residual norm 5.944160522951e-18
>>>>>>> Linear solve converged due to CONVERGED_RTOL iterations 1
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> ( in rhs )
>>>>>>> ( leave rhs )
>>>>>>> === start mymult ===
>>>>>>> === done mymult ===
>>>>>>> Nonlinear solve did not converge due to DIVERGED_LINE_SEARCH iterations 8
>>>>>>> Number of SNES iterations = 8
>>>>>>>
>>>>>>> After each "Linear solve converged due to CONVERGED_ATOL iterations", the code starts to do mymult again. So I thought it did an extra (unwanted) KSP iteration. I would like to ask if this extra iteration could be disabled, or maybe I am wrong about it.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Yi
>>>>>>>
>>>>>>> On 1/30/24 18:35, Barry Smith wrote:
>>>>>>>>
>>>>>>>> How do I see a difference? What does "hence ruin my previous converged KSP result" mean? A different answer at the end of the KSP solve?
>>>>>>>>
>>>>>>>> $ ./joe > joe.basic
>>>>>>>> ~/Src/petsc/src/ksp/ksp/tutorials (barry/2023-09-15/fix-log-pcmpi=) arch-fix-log-pcmpi
>>>>>>>> $ ./joe -ksp_monitor -ksp_converged_reason -snes_monitor > joe.monitor
>>>>>>>> ~/Src/petsc/src/ksp/ksp/tutorials (barry/2023-09-15/fix-log-pcmpi=) arch-fix-log-pcmpi
>>>>>>>> $ diff joe.basic joe.monitor
>>>>>>>> 0a1,36
>>>>>>>> > 0 SNES Function norm 6.041522986797e+00
>>>>>>>> > 0 KSP Residual norm 6.041522986797e+00
>>>>>>>> > 1 KSP Residual norm 5.065392549852e-16
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 1 SNES Function norm 3.512662245652e+00
>>>>>>>> > 0 KSP Residual norm 3.512662245652e+00
>>>>>>>> > 1 KSP Residual norm 6.230314124713e-16
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 2 SNES Function norm 8.969285922373e-01
>>>>>>>> > 0 KSP Residual norm 8.969285922373e-01
>>>>>>>> > 1 KSP Residual norm 0.000000000000e+00
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 3 SNES Function norm 4.863816734540e-01
>>>>>>>> > 0 KSP Residual norm 4.863816734540e-01
>>>>>>>> > 1 KSP Residual norm 0.000000000000e+00
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 4 SNES Function norm 3.512070785520e-01
>>>>>>>> > 0 KSP Residual norm 3.512070785520e-01
>>>>>>>> > 1 KSP Residual norm 0.000000000000e+00
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 5 SNES Function norm 2.769700293115e-01
>>>>>>>> > 0 KSP Residual norm 2.769700293115e-01
>>>>>>>> > 1 KSP Residual norm 1.104778916974e-16
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 6 SNES Function norm 2.055345318150e-01
>>>>>>>> > 0 KSP Residual norm 2.055345318150e-01
>>>>>>>> > 1 KSP Residual norm 1.535110861002e-17
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 7 SNES Function norm 1.267482220786e-01
>>>>>>>> > 0 KSP Residual norm 1.267482220786e-01
>>>>>>>> > 1 KSP Residual norm 1.498679601680e-17
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>> > 8 SNES Function norm 3.468150619264e-02
>>>>>>>> > 0 KSP Residual norm 3.468150619264e-02
>>>>>>>> > 1 KSP Residual norm 5.944160522951e-18
>>>>>>>> > Linear solve converged due to CONVERGED_RTOL_NORMAL iterations 1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 30, 2024, at 11:19 AM, Yi Hu <y.hu at mpie.de> <mailto:y.hu at mpie.de> wrote:
>>>>>>>>>
>>>>>>>>> Dear PETSc team,
>>>>>>>>>
>>>>>>>>> I am still trying to sort out my previous thread https://lists.mcs.anl.gov/pipermail/petsc-users/2024-January/050079.html using a minimal working example. However, I encountered another problem. Basically I combined the basic usage of SNES solver and shell matrix and tried to make it work. The jacobian of my snes is replaced by a customized MATOP_MULT. The minimal example code can be viewed here https://github.com/hyharry/small_petsc_test/blob/master/test_shell_jac/ex1f.F90
>>>>>>>>>
>>>>>>>>> When running with -ksp_monitor -ksp_converged_reason, it shows an extra mymult step, and hence ruin my previous converged KSP result. Implement a customized converged call-back also does not help. I am wondering how to skip this extra ksp iteration. Could anyone help me on this?
>>>>>>>>>
>>>>>>>>> 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at 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 rco at mpie.de <mailto:rco at mpie.de>
>>> -------------------------------------------------
>>> <ex1f.F90>
>>
>
>
> -------------------------------------------------
> 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 rco at 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 rco at mpie.de
> -------------------------------------------------
> <ex1f.F90>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240206/1748e075/attachment-0001.html>
More information about the petsc-users
mailing list