Re: [petsc-users] Setting a custom predictor in the generalized-alpha time stepper

[Matthew Knepley]

If you want to make a PR with your hack, we can help build out the
infrastructure for what Jed is recommending.

  Thanks,

 Matt

On Fri, Aug 4, 2023 at 2:56 PM Jed Brown  wrote:

> Yeah, we'd like the implementation to stay in alpha2.c. There could be a
> new interface TSAlpha2SetPredictorType (with -ts_alpha2_predictor_type
> [none,same_velocity,...]) or TSAlpha2SetPredictorFunction.
>
> David Kamensky  writes:
>
> > Hi Jed,
> >
> > The current workaround I'm using is very minimal and basically just moves
> > the definition of `TS_Alpha` from `alpha2.c` up to
> `petsc/private/tsimpl.h`
> > (and renames it to avoid a conflict with `TS_Alpha` in `alpha1.c`), but I
> > gather that we're really still not "supposed to" include that header in
> > applications.  So, I don't know whether something like that would be
> > welcomed upstream.  The actual computation of the predictor is done on
> the
> > application side.
> >
> > Having options like `-ts_alpha_same_velocity` and
> > `-ts_alpha_same_acceleration` could probably be implemented by analogy to
> > `-ts_theta_initial_guess_extrapolate`, although they wouldn't quite cover
> > my specific use-case, where I'm only setting the predictor on part of the
> > solution vector.  So, maybe something more general, like providing a
> > generalized-$\alpha$-specific option for a custom predictor callback that
> > takes `X0`, `V0`, and `A0` arguments would be the cleanest solution (and
> > some convenient shortcuts for full-solution same-velocity and
> > same-acceleration predictors could subsequently make use of that
> > infrastructure).  I've been working quickly over the past week, but I
> might
> > be able to take some time to implement a more sustainable solution soon.
> >
> > Thanks again,
> > David
> >
> > On Fri, Aug 4, 2023 at 9:23 AM Jed Brown  wrote:
> >
> >> Some other TS implementations have a concept of extrapolation as an
> >> initial guess. Such method-specific initial guesses sound like they fit
> >> that pattern and would be welcome to be included in alpha2.c. Would you
> be
> >> willing to make a merge request to bring your work upstream?
> >>
> >> David Kamensky  writes:
> >>
> >> > Hi Jed,
> >> >
> >> > What I'm trying to compute is basically a standard same-velocity or
> >> > same-acceleration predictor (although slightly more complicated, since
> >> I'm
> >> > restricting it to a sub-system).  I hadn't looked into
> >> > `SNESSetComputeInitialGuess` yet, although one difficulty is that it
> >> would
> >> > need access to the `X0`, `V0`, and `A0` members of the `TS_Alpha`
> struct,
> >> > which is only defined in `alpha2.c`, and thus not available through
> the
> >> > API.
> >> >
> >> > For now, we just worked around this by patching PETSc to move the
> >> > definition of `TS_Alpha` up into a header to make it accessible.
> >> > (Modifying the library obviously introduces a maintenance headache; I
> >> also
> >> > considered just casting the `ts->data` pointer to `(char*)`,
> calculating
> >> > memory offsets based on `sizeof` the struct members, and casting back
> to
> >> > `Vec`, but that relies on compiler-specific assumptions, and could
> also
> >> > break if the PETSc source code was updated.)  We also shuffled the
> order
> >> of
> >> > some calls to `VecCopy` and `TSPreStage` in the routine
> >> `TSAlpha_Restart`,
> >> > so that `TSPreStage` can set the initial guess, although that sounds
> like
> >> > it would be unnecessary if we instead used a callback in
> >> > `SNESSetComputeInitialGuess` that had access to the internals of
> >> > `TS_Alpha`.
> >> >
> >> > Thanks, David
> >> >
> >> > On Thu, Aug 3, 2023 at 11:28 PM Jed Brown  wrote:
> >> >
> >> >> I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to
> >> modify
> >> >> the initial guess for SNES. Would that serve your needs? Is there
> >> anything
> >> >> else you can say about how you'd like to compute this initial guess?
> Is
> >> >> there a paper or something?
> >> >>
> >> >> David Kamensky  writes:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > My understanding is that the second-order generalized-alpha time
> >> stepper
> >> >> in
> >> >> > PETSc uses a same-displacement predictor as the initial guess for
> the
> >> >> > nonlinear solver that executes in each time step.  I'd like to be
> >> able to
> >> >> > set this to something else, to improve convergence.  However, my
> >> >> > (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage`
> >> >> haven't
> >> >> > worked out.  Is there any way to set a custom predictor?
> >> >> >
> >> >> > Thanks,
> >> >> > David Kamensky
> >> >>
> >>
>


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

Re: [petsc-users] Setting a custom predictor in the generalized-alpha time stepper

[Jed Brown]

Yeah, we'd like the implementation to stay in alpha2.c. There could be a new 
interface TSAlpha2SetPredictorType (with -ts_alpha2_predictor_type 
[none,same_velocity,...]) or TSAlpha2SetPredictorFunction.

David Kamensky  writes:

> Hi Jed,
>
> The current workaround I'm using is very minimal and basically just moves
> the definition of `TS_Alpha` from `alpha2.c` up to `petsc/private/tsimpl.h`
> (and renames it to avoid a conflict with `TS_Alpha` in `alpha1.c`), but I
> gather that we're really still not "supposed to" include that header in
> applications.  So, I don't know whether something like that would be
> welcomed upstream.  The actual computation of the predictor is done on the
> application side.
>
> Having options like `-ts_alpha_same_velocity` and
> `-ts_alpha_same_acceleration` could probably be implemented by analogy to
> `-ts_theta_initial_guess_extrapolate`, although they wouldn't quite cover
> my specific use-case, where I'm only setting the predictor on part of the
> solution vector.  So, maybe something more general, like providing a
> generalized-$\alpha$-specific option for a custom predictor callback that
> takes `X0`, `V0`, and `A0` arguments would be the cleanest solution (and
> some convenient shortcuts for full-solution same-velocity and
> same-acceleration predictors could subsequently make use of that
> infrastructure).  I've been working quickly over the past week, but I might
> be able to take some time to implement a more sustainable solution soon.
>
> Thanks again,
> David
>
> On Fri, Aug 4, 2023 at 9:23 AM Jed Brown  wrote:
>
>> Some other TS implementations have a concept of extrapolation as an
>> initial guess. Such method-specific initial guesses sound like they fit
>> that pattern and would be welcome to be included in alpha2.c. Would you be
>> willing to make a merge request to bring your work upstream?
>>
>> David Kamensky  writes:
>>
>> > Hi Jed,
>> >
>> > What I'm trying to compute is basically a standard same-velocity or
>> > same-acceleration predictor (although slightly more complicated, since
>> I'm
>> > restricting it to a sub-system).  I hadn't looked into
>> > `SNESSetComputeInitialGuess` yet, although one difficulty is that it
>> would
>> > need access to the `X0`, `V0`, and `A0` members of the `TS_Alpha` struct,
>> > which is only defined in `alpha2.c`, and thus not available through the
>> > API.
>> >
>> > For now, we just worked around this by patching PETSc to move the
>> > definition of `TS_Alpha` up into a header to make it accessible.
>> > (Modifying the library obviously introduces a maintenance headache; I
>> also
>> > considered just casting the `ts->data` pointer to `(char*)`, calculating
>> > memory offsets based on `sizeof` the struct members, and casting back to
>> > `Vec`, but that relies on compiler-specific assumptions, and could also
>> > break if the PETSc source code was updated.)  We also shuffled the order
>> of
>> > some calls to `VecCopy` and `TSPreStage` in the routine
>> `TSAlpha_Restart`,
>> > so that `TSPreStage` can set the initial guess, although that sounds like
>> > it would be unnecessary if we instead used a callback in
>> > `SNESSetComputeInitialGuess` that had access to the internals of
>> > `TS_Alpha`.
>> >
>> > Thanks, David
>> >
>> > On Thu, Aug 3, 2023 at 11:28 PM Jed Brown  wrote:
>> >
>> >> I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to
>> modify
>> >> the initial guess for SNES. Would that serve your needs? Is there
>> anything
>> >> else you can say about how you'd like to compute this initial guess? Is
>> >> there a paper or something?
>> >>
>> >> David Kamensky  writes:
>> >>
>> >> > Hi,
>> >> >
>> >> > My understanding is that the second-order generalized-alpha time
>> stepper
>> >> in
>> >> > PETSc uses a same-displacement predictor as the initial guess for the
>> >> > nonlinear solver that executes in each time step.  I'd like to be
>> able to
>> >> > set this to something else, to improve convergence.  However, my
>> >> > (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage`
>> >> haven't
>> >> > worked out.  Is there any way to set a custom predictor?
>> >> >
>> >> > Thanks,
>> >> > David Kamensky
>> >>
>>

Re: [petsc-users] Setting a custom predictor in the generalized-alpha time stepper

[David Kamensky]

Hi Jed,

The current workaround I'm using is very minimal and basically just moves
the definition of `TS_Alpha` from `alpha2.c` up to `petsc/private/tsimpl.h`
(and renames it to avoid a conflict with `TS_Alpha` in `alpha1.c`), but I
gather that we're really still not "supposed to" include that header in
applications.  So, I don't know whether something like that would be
welcomed upstream.  The actual computation of the predictor is done on the
application side.

Having options like `-ts_alpha_same_velocity` and
`-ts_alpha_same_acceleration` could probably be implemented by analogy to
`-ts_theta_initial_guess_extrapolate`, although they wouldn't quite cover
my specific use-case, where I'm only setting the predictor on part of the
solution vector.  So, maybe something more general, like providing a
generalized-$\alpha$-specific option for a custom predictor callback that
takes `X0`, `V0`, and `A0` arguments would be the cleanest solution (and
some convenient shortcuts for full-solution same-velocity and
same-acceleration predictors could subsequently make use of that
infrastructure).  I've been working quickly over the past week, but I might
be able to take some time to implement a more sustainable solution soon.

Thanks again,
David

On Fri, Aug 4, 2023 at 9:23 AM Jed Brown  wrote:

> Some other TS implementations have a concept of extrapolation as an
> initial guess. Such method-specific initial guesses sound like they fit
> that pattern and would be welcome to be included in alpha2.c. Would you be
> willing to make a merge request to bring your work upstream?
>
> David Kamensky  writes:
>
> > Hi Jed,
> >
> > What I'm trying to compute is basically a standard same-velocity or
> > same-acceleration predictor (although slightly more complicated, since
> I'm
> > restricting it to a sub-system).  I hadn't looked into
> > `SNESSetComputeInitialGuess` yet, although one difficulty is that it
> would
> > need access to the `X0`, `V0`, and `A0` members of the `TS_Alpha` struct,
> > which is only defined in `alpha2.c`, and thus not available through the
> > API.
> >
> > For now, we just worked around this by patching PETSc to move the
> > definition of `TS_Alpha` up into a header to make it accessible.
> > (Modifying the library obviously introduces a maintenance headache; I
> also
> > considered just casting the `ts->data` pointer to `(char*)`, calculating
> > memory offsets based on `sizeof` the struct members, and casting back to
> > `Vec`, but that relies on compiler-specific assumptions, and could also
> > break if the PETSc source code was updated.)  We also shuffled the order
> of
> > some calls to `VecCopy` and `TSPreStage` in the routine
> `TSAlpha_Restart`,
> > so that `TSPreStage` can set the initial guess, although that sounds like
> > it would be unnecessary if we instead used a callback in
> > `SNESSetComputeInitialGuess` that had access to the internals of
> > `TS_Alpha`.
> >
> > Thanks, David
> >
> > On Thu, Aug 3, 2023 at 11:28 PM Jed Brown  wrote:
> >
> >> I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to
> modify
> >> the initial guess for SNES. Would that serve your needs? Is there
> anything
> >> else you can say about how you'd like to compute this initial guess? Is
> >> there a paper or something?
> >>
> >> David Kamensky  writes:
> >>
> >> > Hi,
> >> >
> >> > My understanding is that the second-order generalized-alpha time
> stepper
> >> in
> >> > PETSc uses a same-displacement predictor as the initial guess for the
> >> > nonlinear solver that executes in each time step.  I'd like to be
> able to
> >> > set this to something else, to improve convergence.  However, my
> >> > (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage`
> >> haven't
> >> > worked out.  Is there any way to set a custom predictor?
> >> >
> >> > Thanks,
> >> > David Kamensky
> >>
>

Re: [petsc-users] PETSc :: FEM Help

[Matthew Knepley]

On Fri, Aug 4, 2023 at 10:31 AM Brandon Denton  wrote:

> Good Morning Prof. Knepley,
>
> Thank you for the update. I am now able to run the code. However, it does
> not appear to solve the problem correctly. The only results available are
> the initial conditions (temp = 100). In the problem, one face is set to
> 1400 and another face is set to 100. Since the faces are at opposite ends
> of the geometry, we would expect a roughly linear temperature profile from
> 1400 to 100. What am I missing to get the output to show this proper result.
>

1) The inlet/outlet labels where being constructed on dmSurface. I fixed
this.

2) The 14/7 faceIDs do not appear to be the ones you want. Here is
corrected source. Can you look at the labels?

  Thanks,

 Matt


> Thank you.
> Brandon
>
>
> --
> *From:* Matthew Knepley 
> *Sent:* Tuesday, August 1, 2023 10:23 AM
> *To:* Brandon Denton 
> *Cc:* petsc-users@mcs.anl.gov 
> *Subject:* Re: [petsc-users] PETSc :: FEM Help
>
> Sorry about this. I signed up for a conference without the work done, with
> predictable results. I have just returned home.
>
> There were just a few small problems. First, the labels were attached to
> dmSurface, but you wanted them on dm. They got destroyed with dmSurface
> before setting the BC. Second, the declarations of the point function were
> missing the constant arguments. Third, the PetscFEDestroy() was missing and
> extra DM creations were there. I have fixed these and am attaching the new
> source. It runs for me but I have not checked the answer.
>
>   Thanks,
>
>  Matt
>
> On Wed, Jun 7, 2023 at 11:05 AM Brandon Denton via petsc-users <
> petsc-users@mcs.anl.gov> wrote:
>
> Good Morning,
>
> I'm trying to verify that the CAD -> PETSc/DMPlex methods I've developed
> can be used for FEM analyses using PETSc. Attached is my current attempt
> where I import a CAD STEP file to create a volumetric tetrahedral
> discretization (DMPlex),  designate boundary condition points using
> DMLabels, and solve the Laplace problem (heat) with Dirichlet conditions on
> each end. At command line I indicate the STEP file with the -filename
> option and the dual space degree with -petscspace_degree 2. The run ends
> with either a SEGV Fault or a General MPI Communication Error.
>
> Could you please look over the attached file to tell me if what I'm doing
> to set up the FEM problem is wrong?
>
> Thank you in advance for your time and help.
> -Brandon
>
> TYPICAL ERROR MESSAGE
> [0]PETSC ERROR: - Error Message
> --
> [0]PETSC ERROR: General MPI error
> [0]PETSC ERROR: MPI error 605109765 Invalid communicator, error stack:
> PMPI_Comm_get_attr(344): MPI_Comm_get_attr(comm=0x0,
> comm_keyval=-1539309568, attribute_val=0x7ffe75a58848, flag=0x7ffe75a58844)
> failed
> MPII_Comm_get_attr(257): MPIR_Comm_get_attr(comm=0x0,
> comm_keyval=-1539309568, attribute_val=0x7ffe75a58848, flag=0x7ffe75a58844)
> failed
> MPII_Comm_get_attr(53).: Invalid communicator
> [0]PETSC ERROR: WARNING! There are option(s) set that were not used! Could
> be the program crashed before they were used or a spelling mistake, etc!
> [0]PETSC ERROR:   Option left: name:-dm_plex_refine_without_snap_to_geom
> value: 0 source: command line
> [0]PETSC ERROR:   Option left: name:-dm_refine value: 1 source: command
> line
> [0]PETSC ERROR:   Option left: name:-snes_monitor (no value) source:
> command line
> [0]PETSC ERROR: See https://petsc.org/release/faq/ for trouble shooting.
> [0]PETSC ERROR: Petsc Development GIT revision: v3.18.5-1817-gd2497b8de4c
> GIT Date: 2023-05-22 18:44:03 +
> [0]PETSC ERROR: ./thermal on a  named XPS. by bdenton Wed Jun  7 11:03:43
> 2023
> [0]PETSC ERROR: Configure options --with-make-np=16
> --prefix=/mnt/c/Users/Brandon/software/libs/petsc/3.19.1-gitlab/gcc/11.2.0/mpich/3.4.2/openblas/0.3.17/opt
> --with-debugging=false --COPTFLAGS="-O3 -mavx" --CXXOPTFLAGS="-O3 -mavx"
> --FOPTFLAGS=-O3 --with-shared-libraries=1
> --with-mpi-dir=/mnt/c/Users/Brandon/software/libs/mpich/3.4.2/gcc/11.2.0
> --with-mumps=true --download-mumps=1 --with-metis=true --download-metis=1
> --with-parmetis=true --download-parmetis=1 --with-superlu=true
> --download-superlu=1 --with-superludir=true --download-superlu_dist=1
> --with-blacs=true --download-blacs=1 --with-scalapack=true
> --download-scalapack=1 --with-hypre=true --download-hypre=1
> --with-hdf5-dir=/mnt/c/Users/Brandon/software/libs/hdf5/1.12.1/gcc/11.2.0
> --with-valgrind-dir=/mnt/c/Users/Brandon/software/apps/valgrind/3.14.0
> --with-blas-lib="[/mnt/c/Users/Brandon/software/libs/openblas/0.3.17/gcc/11.2.0/lib/libopenblas.so]"
> --with-lapack-lib="[/mnt/c/Users/Brandon/software/libs/openblas/0.3.17/gcc/11.2.0/lib/libopenblas.so]"
> --LDFLAGS= --with-tetgen=true --download-tetgen=1 --download-ctetgen=1
> --download-opencascade=1 --download-egads
> [0]PETSC ERROR: 

Re: [petsc-users] DMPlex edge/vertex orientation

[Matthew Knepley]

On Fri, Aug 4, 2023 at 12:06 PM onur.notonur via petsc-users <
petsc-users@mcs.anl.gov> wrote:

> Hi,
>
> I'm currently working with 3D DMPlex and performing crucial calculations
> involving face normals and edge tangents. I've noticed that face normals
> are directed from support[0] to support[1].
>

That is an accident of implementation and not enforced.


> However, I'm uncertain about the conventions for edges and vertices in
> relation to faces. Specifically, I need to determine the order of vertices
> that create a surface and whether they are stored in a counter-clockwise
> (CCW) or clockwise (CW) manner. As DMPlex follows a hierarchy of
> cell-face-edge-vertex, my main question becomes about the orientation of
> edges. Any clarification on this aspect would be immensely helpful!
>

1) All computed quantities follow the closure ordering, namely that the
order that vertices come out in the DMPlexGetTransitiveClosure() call is
the one used for computing.

2) Closures are always ordered to produce outward normals

3) Since we build k-cells out of k-1 cells, the k-1 cells _already_ have an
ordering before I make my k-cell. Thus I have to tell you how to order the
k-1 cell, with respect to its closure ordering, when you are building your
k-cell. This is what an "orientation" is, namely a representation of the
dihedral group for that k-1 cell.

Example: A segment has two orientations, which we label 0 and -1. When we
build a triangle out of segments, we order them counter-clockwise, so that
the normals are all outward. The same thing is done
for quads.

Triangles have 6 orientations, all the permutations of the edges. We pick
one when making tetrahedra such that the normals are outward _and_ the
vertices are in the closure order.


> Additionally, I'm unfamiliar with most of the terms used in DMPlex. For
> example "orientation" in DMPlexGetConeOrientation. If you could suggest
> some readings or resources that explain these concepts, I would greatly
> appreciate it.
>

I am finishing up my book on it, which I will post. To start, here is a
paper

  https://arxiv.org/abs/2004.08729

  Thanks,

  Matt


> Thx,
> Onur
> Sent with Proton Mail  secure email.
>


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

Re: [petsc-users] Setting a custom predictor in the generalized-alpha time stepper

[Jed Brown]

Some other TS implementations have a concept of extrapolation as an initial 
guess. Such method-specific initial guesses sound like they fit that pattern 
and would be welcome to be included in alpha2.c. Would you be willing to make a 
merge request to bring your work upstream? 

David Kamensky  writes:

> Hi Jed,
>
> What I'm trying to compute is basically a standard same-velocity or
> same-acceleration predictor (although slightly more complicated, since I'm
> restricting it to a sub-system).  I hadn't looked into
> `SNESSetComputeInitialGuess` yet, although one difficulty is that it would
> need access to the `X0`, `V0`, and `A0` members of the `TS_Alpha` struct,
> which is only defined in `alpha2.c`, and thus not available through the
> API.
>
> For now, we just worked around this by patching PETSc to move the
> definition of `TS_Alpha` up into a header to make it accessible.
> (Modifying the library obviously introduces a maintenance headache; I also
> considered just casting the `ts->data` pointer to `(char*)`, calculating
> memory offsets based on `sizeof` the struct members, and casting back to
> `Vec`, but that relies on compiler-specific assumptions, and could also
> break if the PETSc source code was updated.)  We also shuffled the order of
> some calls to `VecCopy` and `TSPreStage` in the routine `TSAlpha_Restart`,
> so that `TSPreStage` can set the initial guess, although that sounds like
> it would be unnecessary if we instead used a callback in
> `SNESSetComputeInitialGuess` that had access to the internals of
> `TS_Alpha`.
>
> Thanks, David
>
> On Thu, Aug 3, 2023 at 11:28 PM Jed Brown  wrote:
>
>> I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to modify
>> the initial guess for SNES. Would that serve your needs? Is there anything
>> else you can say about how you'd like to compute this initial guess? Is
>> there a paper or something?
>>
>> David Kamensky  writes:
>>
>> > Hi,
>> >
>> > My understanding is that the second-order generalized-alpha time stepper
>> in
>> > PETSc uses a same-displacement predictor as the initial guess for the
>> > nonlinear solver that executes in each time step.  I'd like to be able to
>> > set this to something else, to improve convergence.  However, my
>> > (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage`
>> haven't
>> > worked out.  Is there any way to set a custom predictor?
>> >
>> > Thanks,
>> > David Kamensky
>>

[petsc-users] DMPlex edge/vertex orientation

[onur.notonur via petsc-users]

Hi,

I'm currently working with 3D DMPlex and performing crucial calculations 
involving face normals and edge tangents. I've noticed that face normals are 
directed from support[0] to support[1]. However, I'm uncertain about the 
conventions for edges and vertices in relation to faces. Specifically, I need 
to determine the order of vertices that create a surface and whether they are 
stored in a counter-clockwise (CCW) or clockwise (CW) manner. As DMPlex follows 
a hierarchy of cell-face-edge-vertex, my main question becomes about the 
orientation of edges. Any clarification on this aspect would be immensely 
helpful!

Additionally, I'm unfamiliar with most of the terms used in DMPlex. For example 
"orientation" in DMPlexGetConeOrientation. If you could suggest some readings 
or resources that explain these concepts, I would greatly appreciate it.

Thx,
Onur

Sent with [Proton Mail](https://proton.me/) secure email.

Re: [petsc-users] Setting a custom predictor in the generalized-alpha time stepper

[David Kamensky]

Hi Jed,

What I'm trying to compute is basically a standard same-velocity or
same-acceleration predictor (although slightly more complicated, since I'm
restricting it to a sub-system).  I hadn't looked into
`SNESSetComputeInitialGuess` yet, although one difficulty is that it would
need access to the `X0`, `V0`, and `A0` members of the `TS_Alpha` struct,
which is only defined in `alpha2.c`, and thus not available through the
API.

For now, we just worked around this by patching PETSc to move the
definition of `TS_Alpha` up into a header to make it accessible.
(Modifying the library obviously introduces a maintenance headache; I also
considered just casting the `ts->data` pointer to `(char*)`, calculating
memory offsets based on `sizeof` the struct members, and casting back to
`Vec`, but that relies on compiler-specific assumptions, and could also
break if the PETSc source code was updated.)  We also shuffled the order of
some calls to `VecCopy` and `TSPreStage` in the routine `TSAlpha_Restart`,
so that `TSPreStage` can set the initial guess, although that sounds like
it would be unnecessary if we instead used a callback in
`SNESSetComputeInitialGuess` that had access to the internals of
`TS_Alpha`.

Thanks, David

On Thu, Aug 3, 2023 at 11:28 PM Jed Brown  wrote:

> I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to modify
> the initial guess for SNES. Would that serve your needs? Is there anything
> else you can say about how you'd like to compute this initial guess? Is
> there a paper or something?
>
> David Kamensky  writes:
>
> > Hi,
> >
> > My understanding is that the second-order generalized-alpha time stepper
> in
> > PETSc uses a same-displacement predictor as the initial guess for the
> > nonlinear solver that executes in each time step.  I'd like to be able to
> > set this to something else, to improve convergence.  However, my
> > (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage`
> haven't
> > worked out.  Is there any way to set a custom predictor?
> >
> > Thanks,
> > David Kamensky
>

Re: [petsc-users] PETSc :: FEM Help

[Brandon Denton via petsc-users]

Good Morning Prof. Knepley,

Thank you for the update. I am now able to run the code. However, it does not 
appear to solve the problem correctly. The only results available are the 
initial conditions (temp = 100). In the problem, one face is set to 1400 and 
another face is set to 100. Since the faces are at opposite ends of the 
geometry, we would expect a roughly linear temperature profile from 1400 to 
100. What am I missing to get the output to show this proper result.

Thank you.
Brandon



From: Matthew Knepley 
Sent: Tuesday, August 1, 2023 10:23 AM
To: Brandon Denton 
Cc: petsc-users@mcs.anl.gov 
Subject: Re: [petsc-users] PETSc :: FEM Help

Sorry about this. I signed up for a conference without the work done, with 
predictable results. I have just returned home.

There were just a few small problems. First, the labels were attached to 
dmSurface, but you wanted them on dm. They got destroyed with dmSurface before 
setting the BC. Second, the declarations of the point function were missing the 
constant arguments. Third, the PetscFEDestroy() was missing and extra DM 
creations were there. I have fixed these and am attaching the new source. It 
runs for me but I have not checked the answer.

  Thanks,

 Matt

On Wed, Jun 7, 2023 at 11:05 AM Brandon Denton via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
Good Morning,

I'm trying to verify that the CAD -> PETSc/DMPlex methods I've developed can be 
used for FEM analyses using PETSc. Attached is my current attempt where I 
import a CAD STEP file to create a volumetric tetrahedral discretization 
(DMPlex),  designate boundary condition points using DMLabels, and solve the 
Laplace problem (heat) with Dirichlet conditions on each end. At command line I 
indicate the STEP file with the -filename option and the dual space degree with 
-petscspace_degree 2. The run ends with either a SEGV Fault or a General MPI 
Communication Error.

Could you please look over the attached file to tell me if what I'm doing to 
set up the FEM problem is wrong?

Thank you in advance for your time and help.
-Brandon

TYPICAL ERROR MESSAGE
[0]PETSC ERROR: - Error Message 
--
[0]PETSC ERROR: General MPI error
[0]PETSC ERROR: MPI error 605109765 Invalid communicator, error stack:
PMPI_Comm_get_attr(344): MPI_Comm_get_attr(comm=0x0, 
comm_keyval=-1539309568, attribute_val=0x7ffe75a58848, flag=0x7ffe75a58844) 
failed
MPII_Comm_get_attr(257): MPIR_Comm_get_attr(comm=0x0, 
comm_keyval=-1539309568, attribute_val=0x7ffe75a58848, flag=0x7ffe75a58844) 
failed
MPII_Comm_get_attr(53).: Invalid communicator
[0]PETSC ERROR: WARNING! There are option(s) set that were not used! Could be 
the program crashed before they were used or a spelling mistake, etc!
[0]PETSC ERROR:   Option left: name:-dm_plex_refine_without_snap_to_geom value: 
0 source: command line
[0]PETSC ERROR:   Option left: name:-dm_refine value: 1 source: command line
[0]PETSC ERROR:   Option left: name:-snes_monitor (no value) source: command 
line
[0]PETSC ERROR: See https://petsc.org/release/faq/ for trouble shooting.
[0]PETSC ERROR: Petsc Development GIT revision: v3.18.5-1817-gd2497b8de4c  GIT 
Date: 2023-05-22 18:44:03 +
[0]PETSC ERROR: ./thermal on a  named XPS. by bdenton Wed Jun  7 11:03:43 2023
[0]PETSC ERROR: Configure options --with-make-np=16 
--prefix=/mnt/c/Users/Brandon/software/libs/petsc/3.19.1-gitlab/gcc/11.2.0/mpich/3.4.2/openblas/0.3.17/opt
 --with-debugging=false --COPTFLAGS="-O3 -mavx" --CXXOPTFLAGS="-O3 -mavx" 
--FOPTFLAGS=-O3 --with-shared-libraries=1 
--with-mpi-dir=/mnt/c/Users/Brandon/software/libs/mpich/3.4.2/gcc/11.2.0 
--with-mumps=true --download-mumps=1 --with-metis=true --download-metis=1 
--with-parmetis=true --download-parmetis=1 --with-superlu=true 
--download-superlu=1 --with-superludir=true --download-superlu_dist=1 
--with-blacs=true --download-blacs=1 --with-scalapack=true 
--download-scalapack=1 --with-hypre=true --download-hypre=1 
--with-hdf5-dir=/mnt/c/Users/Brandon/software/libs/hdf5/1.12.1/gcc/11.2.0 
--with-valgrind-dir=/mnt/c/Users/Brandon/software/apps/valgrind/3.14.0 
--with-blas-lib="[/mnt/c/Users/Brandon/software/libs/openblas/0.3.17/gcc/11.2.0/lib/libopenblas.so]"
 
--with-lapack-lib="[/mnt/c/Users/Brandon/software/libs/openblas/0.3.17/gcc/11.2.0/lib/libopenblas.so]"
 --LDFLAGS= --with-tetgen=true --download-tetgen=1 --download-ctetgen=1 
--download-opencascade=1 --download-egads
[0]PETSC ERROR: #1 PetscObjectName() at 
/mnt/c/Users/Brandon/software/builddir/petsc-3.19.1-gitlab/src/sys/objects/pname.c:119
[0]PETSC ERROR: #2 PetscObjectGetName() at 
/mnt/c/Users/Brandon/software/builddir/petsc-3.19.1-gitlab/src/sys/objects/pgname.c:27
[0]PETSC ERROR: #3 PetscDSAddBoundary() at 
/mnt/c/Users/Brandon/software/builddir/petsc-3.19.1-gitlab/src/dm/dt/interface/dtds.c:3404
[0]PETSC ERROR: #4 

Re: [petsc-users] Setting a custom predictor in the generalized-alpha time stepper

[Jed Brown]

I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to modify the 
initial guess for SNES. Would that serve your needs? Is there anything else you 
can say about how you'd like to compute this initial guess? Is there a paper or 
something?

David Kamensky  writes:

> Hi,
>
> My understanding is that the second-order generalized-alpha time stepper in
> PETSc uses a same-displacement predictor as the initial guess for the
> nonlinear solver that executes in each time step.  I'd like to be able to
> set this to something else, to improve convergence.  However, my
> (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage` haven't
> worked out.  Is there any way to set a custom predictor?
>
> Thanks,
> David Kamensky