> On Feb 6, 2024, at 3:49 PM, Yi Hu <[email protected]> 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 <[email protected]> <mailto:[email protected]> >>> 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 <[email protected]> <mailto:[email protected]> >>>>> 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 <[email protected]> <mailto:[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>>> <mailto:[email protected]> 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 [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> >>>>>>>>> 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 [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> ------------------------------------------------- >>>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------- >>>>>>> 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 [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> >>>>>>> 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 [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> ------------------------------------------------- >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------- >>>>> 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 [email protected] >>>>> <mailto:[email protected]> >>>>> >>>>> 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 [email protected] >>>>> <mailto:[email protected]> >>>>> ------------------------------------------------- >>>> >>> >>> >>> ------------------------------------------------- >>> 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 [email protected] >>> <mailto:[email protected]> >>> >>> 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 [email protected] >>> <mailto:[email protected]> >>> ------------------------------------------------- >>> <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 [email protected] > > 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 [email protected] > ------------------------------------------------- > <ex1f.F90>
