From 12431140 at mail.sustech.edu.cn Mon Mar 17 06:37:48 2025 From: 12431140 at mail.sustech.edu.cn (=?utf-8?B?RGF2aWQgSmlhd2VpIExVTyBMSUFORw==?=) Date: Mon, 17 Mar 2025 19:37:48 +0800 Subject: [petsc-dev] Inquiry Regarding Arc-Length Method Implementation in SNESNEWTONAL Solver Message-ID: Dear PETSc Developers, I am currently using the SNESNEWTONAL nonlinear solver and its arc-length method module. I noticed from the tutorial that, besides the standard residual and Jacobian definitions:   SNESSetFunction(snes, r, FormFunction2nd, &user);   SNESSetJacobian(snes, J, J, FormJacobian2nd, &user);   it also requires:   SNESNewtonALSetFunction(snes, ComputeTangentLoad, &user);   which is used to define the arc-length constraint function. I have several questions regarding the arc-length implementation, and I would greatly appreciate your clarification: 1. According to the tutorial, the arc-length constraint function `ComputeTangentLoad` is used to compute ( Q = dF^{ext}/d\lambda ), the derivative of the external load with respect to lambda. In the case of a linear load, i.e., ( F^{ext} = \lambda F^{ext} ), ( Q = F^{ext} ). In this scenario, is it correct to simply return ( F^{ext} ) inside `ComputeTangentLoad`? 2. From my experiments, I observed that the `ComputeTangentLoad` function is called once before assembling the residual at every iteration. Interestingly, it seems that during the first iteration, ( Q ) contributes to the residual calculation, but from the second iteration onward, it no longer does. Could you help me understand why this happens? 3. I have attached my own buckling example of a Lee Frame structure where I implemented the arc-length method as the nonlinear solver. In my implementation, I divided the arc-length method into two steps:      (1) A predictor step, which predicts the intersection of the constraint surface and the tangent;      (2) A corrector step, which uses Newton-Raphson iterations to refine the intersection point between the constraint surface and the actual equilibrium path.      This is the standard arc-length algorithm principle. I would like to know if `SNESNEWTONAL` follows a similar predictor-corrector procedure internally, or if I need to implement an outer load step loop and predictor step myself? 4. I remember that the tutorial describes solving two linear systems during each corrector step to obtain ( \Delta x^F ) and ( \Delta x^Q ) separately. Where in the SNESNEWTONAL workflow are these two solves performed? Do they happen right after assembling the residual and Jacobian? 5. Additionally, is the Jacobian matrix used in SNESNEWTONAL the original system Jacobian, or is it augmented to include the constraint surface function? Similarly, is the input vector expanded to ( n+1 ) dimensions to account for ( \lambda ), or does it remain the original size ( n ) as in the standard Newton-Raphson implementation? 6. In general, I would like to understand more about the internal iteration details of `SNESSetType(snes, SNESNEWTONAL);` compared to `SNESSetType(snes, SNESNEWTONLS);` so that I can more accurately replicate and improve upon the arc-length algorithm I have implemented in the attached code using SNES. Thank you very much for your time and assistance! Best regards,   David David Jiawei LUO LIANG ??????/??/???/2024 ?????????????1088?   -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LeeFrame.zip Type: application/octet-stream Size: 20644 bytes Desc: not available URL: From jed at jedbrown.org Tue Mar 18 12:34:36 2025 From: jed at jedbrown.org (Jed Brown) Date: Tue, 18 Mar 2025 11:34:36 -0600 Subject: [petsc-dev] Inquiry Regarding Arc-Length Method Implementation in SNESNEWTONAL Solver In-Reply-To: References: Message-ID: <878qp2jl8z.fsf@jedbrown.org> Hi, David. I'm copying Zach, who developed this implementation and will be able to more directly answer your questions. "David Jiawei LUO LIANG" <12431140 at mail.sustech.edu.cn> writes: > Dear PETSc Developers, > > > I am currently using the SNESNEWTONAL nonlinear solver and its arc-length method module. I noticed from the tutorial that, besides the standard residual and Jacobian definitions:   > > > SNESSetFunction(snes, r, FormFunction2nd, &user);   > SNESSetJacobian(snes, J, J, FormJacobian2nd, &user);   > > > it also requires:   > > > SNESNewtonALSetFunction(snes, ComputeTangentLoad, &user);   > > > which is used to define the arc-length constraint function. > > > I have several questions regarding the arc-length implementation, and I would greatly appreciate your clarification: > > > 1. According to the tutorial, the arc-length constraint function `ComputeTangentLoad` is used to compute ( Q = dF^{ext}/d\lambda ), the derivative of the external load with respect to lambda. In the case of a linear load, i.e., ( F^{ext} = \lambda F^{ext} ), ( Q = F^{ext} ). In this scenario, is it correct to simply return ( F^{ext} ) inside `ComputeTangentLoad`? > > > 2. From my experiments, I observed that the `ComputeTangentLoad` function is called once before assembling the residual at every iteration. Interestingly, it seems that during the first iteration, ( Q ) contributes to the residual calculation, but from the second iteration onward, it no longer does. Could you help me understand why this happens? > > > 3. I have attached my own buckling example of a Lee Frame structure where I implemented the arc-length method as the nonlinear solver. In my implementation, I divided the arc-length method into two steps:   >    (1) A predictor step, which predicts the intersection of the constraint surface and the tangent;   >    (2) A corrector step, which uses Newton-Raphson iterations to refine the intersection point between the constraint surface and the actual equilibrium path.   >    This is the standard arc-length algorithm principle. I would like to know if `SNESNEWTONAL` follows a similar predictor-corrector procedure internally, or if I need to implement an outer load step loop and predictor step myself? > > > 4. I remember that the tutorial describes solving two linear systems during each corrector step to obtain ( \Delta x^F ) and ( \Delta x^Q ) separately. Where in the SNESNEWTONAL workflow are these two solves performed? Do they happen right after assembling the residual and Jacobian? > > > 5. Additionally, is the Jacobian matrix used in SNESNEWTONAL the original system Jacobian, or is it augmented to include the constraint surface function? Similarly, is the input vector expanded to ( n+1 ) dimensions to account for ( \lambda ), or does it remain the original size ( n ) as in the standard Newton-Raphson implementation? > > > 6. In general, I would like to understand more about the internal iteration details of `SNESSetType(snes, SNESNEWTONAL);` compared to `SNESSetType(snes, SNESNEWTONLS);` so that I can more accurately replicate and improve upon the arc-length algorithm I have implemented in the attached code using SNES. > > > Thank you very much for your time and assistance! > > > Best regards,   > > > > David > > > > > > David Jiawei LUO LIANG > > > > ??????/??/???/2024 > > > > ?????????????1088? > > > > >   From Zach.Atkins at colorado.edu Tue Mar 18 15:24:36 2025 From: Zach.Atkins at colorado.edu (Zach Atkins) Date: Tue, 18 Mar 2025 20:24:36 +0000 Subject: [petsc-dev] Inquiry Regarding Arc-Length Method Implementation in SNESNEWTONAL Solver In-Reply-To: <878qp2jl8z.fsf@jedbrown.org> References: <878qp2jl8z.fsf@jedbrown.org> Message-ID: Hi David, Thanks for reaching out! At a high-level, I would recommend reading through the docs and source code if you haven't already, as the tutorial does not go into much detail on the details of the arc length method implementation. Docs: https://urldefense.us/v3/__https://petsc.org/main/manual/snes/*newton-with-arc-length-continuation__;Iw!!G_uCfscf7eWS!fkLQY6YXo3t6v6Di1MslMhnd9IaaagxBJ2eJStyMTIsHbXqM_XF9fAyqs0nggXxm9xDT2C63tge0xCpoFzV8wizyeLSBsA$ Source: https://urldefense.us/v3/__https://petsc.org/main/src/snes/impls/al/al.c.html__;!!G_uCfscf7eWS!fkLQY6YXo3t6v6Di1MslMhnd9IaaagxBJ2eJStyMTIsHbXqM_XF9fAyqs0nggXxm9xDT2C63tge0xCpoFzV8wiwoS3XDBQ$ (in particular, SNESSolve_NEWTONAL) > ?1. According to the tutorial, the arc-length constraint function `ComputeTangentLoad` is used to compute ( Q = dF^{ext}/d\lambda ), the derivative of the external load with respect to lambda. In the case of a linear load, i.e., ( F^{ext} = \lambda F^{ext} ), ( Q = F^{ext} ). In this scenario, is it correct to simply return ( F^{ext} ) inside `ComputeTangentLoad`? Yes, this is correct. If you have a solution-independent load, you can also just pass it as the RHS vector to SNESSolve and it will automatically be used as a linear load in terms of lambda. > 2. From my experiments, I observed that the `ComputeTangentLoad` function is called once before assembling the residual at every iteration. Interestingly, it seems that during the first iteration, ( Q ) contributes to the residual calculation, but from the second iteration onward, it no longer does. Could you help me understand why this happens? We only include Q in the full residual in the predictor step, the corrector steps use a special newton iteration over lambda. If you are using a solution-dependent external force, i.e. the force is computed in the function passed to `SNESSetFunction`, then you will need to scale the force by the current value of lambda, which can be queried via `SNESNewtonALGetLoadParameter()`. > 3. I have attached my own buckling example of a Lee Frame structure where I implemented the arc-length method as the nonlinear solver. In my implementation, I divided the arc-length method into two steps:   >    (1) A predictor step, which predicts the intersection of the constraint surface and the tangent;   >    (2) A corrector step, which uses Newton-Raphson iterations to refine the intersection point between the constraint surface and the actual equilibrium path.   >    This is the standard arc-length algorithm principle. I would like to know if `SNESNEWTONAL` follows a similar predictor-corrector procedure internally, or if I need to implement an outer load step loop and predictor step myself? We also do a predictor/corrector loop, with two options for the corrector algorithm. The docs explain the selection of lambda in both cases in detail. The arc length solver consists of an inner and outer solve, in an incremental-iterative style. Each increment is chosen via an inner iterative Newton solve which uses the predictor/corrector approach. The number of increments depends on the step size provided via -snes_newtonal_step_size, which is the 2-norm of the augmented increment vector [Delta x; Delta lambda]. > 4. I remember that the tutorial describes solving two linear systems during each corrector step to obtain ( \Delta x^F ) and ( \Delta x^Q ) separately. Where in the SNESNEWTONAL workflow are these two solves performed? Do they happen right after assembling the residual and Jacobian? > > 5. Additionally, is the Jacobian matrix used in SNESNEWTONAL the original system Jacobian, or is it augmented to include the constraint surface function? Similarly, is the input vector expanded to ( n+1 ) dimensions to account for ( \lambda ), or does it remain the original size ( n ) as in the standard Newton-Raphson implementation? It is the original Jacobian ? we avoid augmenting for efficiency and symmetry. The full process is described in the documentation as well as in the source code. Essentially, we factor the total SNES update into two parts, one which is determined by the the full residual at lambda, F(x, lambda), (this is \delta x^F ), and the other based on the variation in F with respect to lambda Q(x, lambda) (this is \delta x^Q). Both parts are computed once per inner Newton iteration right after the Jacobian is assembled. The residual and tangent load vectors are technically computed at the end of each inner Newton iteration, but that is mainly an implementation detail. > 6. In general, I would like to understand more about the internal iteration details of `SNESSetType(snes, SNESNEWTONAL);` compared to `SNESSetType(snes, SNESNEWTONLS);` so that I can more accurately replicate and improve upon the arc-length algorithm I have implemented in the attached code using SNES. I would recommend again referring to the documentation and source for easier comparison. If you have additional specific questions about the implementation, please feel free to ask! Best, Zach Atkins ________________________________ From: Jed Brown Sent: Tuesday, March 18, 2025 11:34 AM To: David Jiawei LUO LIANG <12431140 at mail.sustech.edu.cn>; petsc-dev Cc: Zach Atkins Subject: Re: [petsc-dev] Inquiry Regarding Arc-Length Method Implementation in SNESNEWTONAL Solver [jed at jedbrown.org appears similar to someone who previously sent you email, but may not be that person. Learn why this could be a risk at https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!G_uCfscf7eWS!fkLQY6YXo3t6v6Di1MslMhnd9IaaagxBJ2eJStyMTIsHbXqM_XF9fAyqs0nggXxm9xDT2C63tge0xCpoFzV8wiwz13ACMQ$ ] [External email - use caution] Hi, David. I'm copying Zach, who developed this implementation and will be able to more directly answer your questions. "David Jiawei LUO LIANG" <12431140 at mail.sustech.edu.cn> writes: > Dear PETSc Developers, > > > I am currently using the SNESNEWTONAL nonlinear solver and its arc-length method module. I noticed from the tutorial that, besides the standard residual and Jacobian definitions:   > > > SNESSetFunction(snes, r, FormFunction2nd, &user);   > SNESSetJacobian(snes, J, J, FormJacobian2nd, &user);   > > > it also requires:   > > > SNESNewtonALSetFunction(snes, ComputeTangentLoad, &user);   > > > which is used to define the arc-length constraint function. > > > I have several questions regarding the arc-length implementation, and I would greatly appreciate your clarification: > > > 1. According to the tutorial, the arc-length constraint function `ComputeTangentLoad` is used to compute ( Q = dF^{ext}/d\lambda ), the derivative of the external load with respect to lambda. In the case of a linear load, i.e., ( F^{ext} = \lambda F^{ext} ), ( Q = F^{ext} ). In this scenario, is it correct to simply return ( F^{ext} ) inside `ComputeTangentLoad`? > > > 2. From my experiments, I observed that the `ComputeTangentLoad` function is called once before assembling the residual at every iteration. Interestingly, it seems that during the first iteration, ( Q ) contributes to the residual calculation, but from the second iteration onward, it no longer does. Could you help me understand why this happens? > > > 3. I have attached my own buckling example of a Lee Frame structure where I implemented the arc-length method as the nonlinear solver. In my implementation, I divided the arc-length method into two steps:   >    (1) A predictor step, which predicts the intersection of the constraint surface and the tangent;   >    (2) A corrector step, which uses Newton-Raphson iterations to refine the intersection point between the constraint surface and the actual equilibrium path.   >    This is the standard arc-length algorithm principle. I would like to know if `SNESNEWTONAL` follows a similar predictor-corrector procedure internally, or if I need to implement an outer load step loop and predictor step myself? > > > 4. I remember that the tutorial describes solving two linear systems during each corrector step to obtain ( \Delta x^F ) and ( \Delta x^Q ) separately. Where in the SNESNEWTONAL workflow are these two solves performed? Do they happen right after assembling the residual and Jacobian? > > > 5. Additionally, is the Jacobian matrix used in SNESNEWTONAL the original system Jacobian, or is it augmented to include the constraint surface function? Similarly, is the input vector expanded to ( n+1 ) dimensions to account for ( \lambda ), or does it remain the original size ( n ) as in the standard Newton-Raphson implementation? > > > 6. In general, I would like to understand more about the internal iteration details of `SNESSetType(snes, SNESNEWTONAL);` compared to `SNESSetType(snes, SNESNEWTONLS);` so that I can more accurately replicate and improve upon the arc-length algorithm I have implemented in the attached code using SNES. > > > Thank you very much for your time and assistance! > > > Best regards,   > > > > David > > > > > > David Jiawei LUO LIANG > > > > ??????/??/???/2024 > > > > ?????????????1088? > > > > >   -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.diehl at kuleuven.be Mon Mar 24 06:07:10 2025 From: martin.diehl at kuleuven.be (Martin Diehl) Date: Mon, 24 Mar 2025 11:07:10 +0000 Subject: [petsc-dev] Fortran interface definitions Message-ID: <44295d553b66344f6019e5e8e76e9f8fa2f90ce6.camel@kuleuven.be> Hello, as a preparation for the Google Summer of Code, Tapashree and I started to work on https://gitlab.com/petsc/petsc/-/issues/194 (interfaces for PetscViewerHDF5Write/ReadAttribute()). Preliminary work is in https://gitlab.com/petsc/petsc/-/commits/MarDiehl/194-add-f90-bindings-for-petscviewerhdf5write-readattribute When working on it, I realized that my understanding how Fortran interfaces are defined in PETSc faded, so I would need some clarifications on the different components. Is our understanding about the content of the ftn-custom folders correct: Do they only exist in the repository, C-code for functions that are not 1-1 translated to Fortran are defined. This includes for example functions having arrays or strings in their arguments. What are the purposes of the files in the ftn-mod folders? Some seem to combine autogenerated modules (e.g. ksp/ftn-mod/petsckspmod.F90), others make overloaded functions available under a common name (e.g. sys/ftn-mod/petscviewer.h90). But what is "/ksp/ftn-mod/petscksp.h90" doing? best regards, Martin and Tapashree -- KU Leuven Department of Computer Science Department of Materials Engineering Celestijnenlaan 200a 3001 Leuven, Belgium -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From bsmith at petsc.dev Mon Mar 24 13:24:19 2025 From: bsmith at petsc.dev (Barry Smith) Date: Mon, 24 Mar 2025 14:24:19 -0400 Subject: [petsc-dev] Fortran interface definitions In-Reply-To: <44295d553b66344f6019e5e8e76e9f8fa2f90ce6.camel@kuleuven.be> References: <44295d553b66344f6019e5e8e76e9f8fa2f90ce6.camel@kuleuven.be> Message-ID: <0D308B31-7B23-4024-ADFA-028918FE1A84@petsc.dev> Fortran bindings for functions generally consist of two parts: * An Fortran interface definition that is contained inside a module. - these provide the compile-time type checking of Fortran code that calls PETSc - the vast majority of these interfaces are generated automatically. + the automatic ones are stored in $PETSC_ARCH/ftn/src/MANSEC/* + The small number of manual ones are put in src/MANSEC/ftn-mod/* * A C stub, which is a C routine that is callable directly from Fortran. - most of these stubs are generated automatically, but not ones that, for example, return a pointer to an array or functions that have function arguments. + the automatic ones for a function defined in src/MANSEC/somedirectory/*.c are are put in $PETSC_ARCH/ftn/src/MANSEC/somedirectory/*f.c + the manual ones are to be put in src/MANSEC/somedirectory/ftn-custom/z*f.c PETSc functions that return pointers to arrays (VecGetArray() for example) generally have a restore partner (VecRestoreArray()). But others, such as KSPGetConvergenceHistory() do not need a restore partner in C; but they do need a restore partner in Fortran. Hence we need to provide both the Fortran interface definition for KSPRestoreConvergenceHistory() and the C stub for it manually. When you need to provide interfaces or stubs manually I suggest first run make fortranbindings and check to see if it generates the interfaces and stubs you need. For those it generates (and assuming they are correct) you don't need to do anything more. For any it does not generate you need to make appropriate manual versions (generally I find something similar and copy it to get the starting code for the needed manual interfaces and stubs). Barry > On Mar 24, 2025, at 7:07?AM, Martin Diehl wrote: > > Hello, > > as a preparation for the Google Summer of Code, Tapashree and I started > to work on https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/issues/194__;!!G_uCfscf7eWS!fsu7KTFZDG8gA5i0b_mVGz5mDt-t-_5K-BhWbkxMqImoBxLt1kFuLeDwXhoLxA5wviD6Lv9EnMb-QMQDSARQSA$ (interfaces for > PetscViewerHDF5Write/ReadAttribute()). Preliminary work is in > https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commits/MarDiehl/194-add-f90-bindings-for-petscviewerhdf5write-readattribute__;!!G_uCfscf7eWS!fsu7KTFZDG8gA5i0b_mVGz5mDt-t-_5K-BhWbkxMqImoBxLt1kFuLeDwXhoLxA5wviD6Lv9EnMb-QMR_MkUJag$ > > When working on it, I realized that my understanding how Fortran > interfaces are defined in PETSc faded, so I would need some > clarifications on the different components. > > Is our understanding about the content of the ftn-custom folders > correct: Do they only exist in the repository, C-code for functions > that are not 1-1 translated to Fortran are defined. This includes for > example functions having arrays or strings in their arguments. > > What are the purposes of the files in the ftn-mod folders? Some seem to > combine autogenerated modules (e.g. ksp/ftn-mod/petsckspmod.F90), > others make overloaded functions available under a common name (e.g. > sys/ftn-mod/petscviewer.h90). But what is "/ksp/ftn-mod/petscksp.h90" > doing? > > best regards, > Martin and Tapashree > > -- > KU Leuven > Department of Computer Science > Department of Materials Engineering > Celestijnenlaan 200a > 3001 Leuven, Belgium >