[petsc-dev] Petsc 19 user meeting June 5-7, 2019: sign up for talks and posters
Hi all, I would really appreciate it if all PETSc developers who are planning on attending the user meeting would - submit their proposed talks/posters soon on easychair https://easychair.org/cfp/petsc19 - register on eventbrite https://www.eventbrite.com/e/petsc-19-user-meeting-tickets-59465955273 - Convince friends and colleagues to do the same! Thanks, Toby
Re: [petsc-dev] MPI_UB is deprecated in MPI-2.0
Pushed a fix that just uses MPI_Type_contiguous(MPI_BYTE, sizeof(),
...), which is not great but I'm only creating the type to work with
PetscSF, so it does the job. Satish, do you want this as a pull
request, or can you just merge it into next
(`tisaac/feature-remove-mpi-ub`)?
Thanks,
Toby
On Tue, Mar 12, 2019 at 10:21:42PM -0600, Jed Brown wrote:
> MPI_Type_create_resized (if needed).
>
> "Balay, Satish via petsc-dev" writes:
>
> > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2019/03/01/make_master_arch-linux-pkgs-64idx_thrash.log
> > has the following [but for some reason - its filtered out from the warning
> > count]
> >
>
> > In file included from
> > /sandbox/petsc/petsc.master-3/src/dm/impls/forest/p4est/dmp4est.c:13:0:
> > /sandbox/petsc/petsc.master-3/src/dm/impls/forest/p4est/pforest.c: In
> > function ‘DMPforestGetTransferSF_Point’:
> > /sandbox/petsc/petsc.master-3/src/dm/impls/forest/p4est/pforest.c:2518:7:
> > warning: ‘ompi_mpi_ub’ is deprecated (declared at
> > /sandbox/petsc/petsc.master-3/arch-linux-pkgs-64idx/include/mpi.h:928):
> > MPI_UB is deprecated in MPI-2.0 [-Wdeprecated-declarations]
> >MPI_Datatype blockTypes[5] =
> > {MPI_INT32_T,MPI_INT8_T,MPI_INT16_T,MPI_INT32_T,MPI_UB};
> > <<
> >
> > Any idea how to fix this?
> >
> > Thanks,
> > Satish
Re: [petsc-dev] MATCOMPOSITE as fallback for matrix-matrix multiplication
Okay, but do you have an opinion on the original issue: should we always return a matrix from various matrix-matrix routines, even if it has limited functionality? On Mon, Mar 11, 2019 at 06:09:55PM +, Smith, Barry F. wrote: > >Sounds like overkill on the complexity meter. > >Barry > > > > On Mar 11, 2019, at 6:15 AM, Isaac, Tobin G via petsc-dev > > wrote: > > > > One thought: we could extend MatReuse with MAT_INITIAL_MATRIX_GET_VALUES to > > indicate that a matrix that implements MatGetValues() is desired, to allow > > some user intent. > > > > > > On March 9, 2019 7:44:06 PM EST, Matthew Knepley wrote: > >> On Sat, Mar 9, 2019 at 4:42 PM Isaac, Tobin G via petsc-dev < > >> petsc-dev@mcs.anl.gov> wrote: > >> > >>> > >>> Let's say I want to do Newton-Krylov on some DAG of computations. > >>> Building the Jacobian is programmatic from the chain rule, requiring > >>> just a lot of matrix-matrix multiplications in the correct sequence. > >>> > >>> If it really is more efficient for two Jacobians to be contracted > >> into > >>> a matrix with random access, that's great, but if it's not, or if > >>> the appropriate implementation of MatMatMult_X_Y does not exist, > >>> having a MATCOMPOSITE is better than nothing. > >>> > >>> So why not make MATCOMPOSITE something that our matrix-matrix > >>> multiplication routines return when a specialization isn't found? > >>> It moves the "Not Implemented" warning from MatMatMult() to > >>> whenever I try to do something other than multiply with the output, > >>> but in some situations that's desirable. > >>> > >>> I'd be interested to hear what people think. > >>> > >> > >> I think this is a good idea. The most important thing is to maintain > >> transparency, so that the output > >> makes this clear in -ksp_view and we are easily able to see what > >> someone > >> has produced. > >> > >> Matt > >> > >> > >>> Thanks, > >>> Toby > >>> > >>> > >>> >
Re: [petsc-dev] MATCOMPOSITE as fallback for matrix-matrix multiplication
One thought: we could extend MatReuse with MAT_INITIAL_MATRIX_GET_VALUES to indicate that a matrix that implements MatGetValues() is desired, to allow some user intent. On March 9, 2019 7:44:06 PM EST, Matthew Knepley wrote: >On Sat, Mar 9, 2019 at 4:42 PM Isaac, Tobin G via petsc-dev < >petsc-dev@mcs.anl.gov> wrote: > >> >> Let's say I want to do Newton-Krylov on some DAG of computations. >> Building the Jacobian is programmatic from the chain rule, requiring >> just a lot of matrix-matrix multiplications in the correct sequence. >> >> If it really is more efficient for two Jacobians to be contracted >into >> a matrix with random access, that's great, but if it's not, or if >> the appropriate implementation of MatMatMult_X_Y does not exist, >> having a MATCOMPOSITE is better than nothing. >> >> So why not make MATCOMPOSITE something that our matrix-matrix >> multiplication routines return when a specialization isn't found? >> It moves the "Not Implemented" warning from MatMatMult() to >> whenever I try to do something other than multiply with the output, >> but in some situations that's desirable. >> >> I'd be interested to hear what people think. >> > >I think this is a good idea. The most important thing is to maintain >transparency, so that the output >makes this clear in -ksp_view and we are easily able to see what >someone >has produced. > > Matt > > >> Thanks, >> Toby >> >> >>
[petsc-dev] MATCOMPOSITE as fallback for matrix-matrix multiplication
Let's say I want to do Newton-Krylov on some DAG of computations. Building the Jacobian is programmatic from the chain rule, requiring just a lot of matrix-matrix multiplications in the correct sequence. If it really is more efficient for two Jacobians to be contracted into a matrix with random access, that's great, but if it's not, or if the appropriate implementation of MatMatMult_X_Y does not exist, having a MATCOMPOSITE is better than nothing. So why not make MATCOMPOSITE something that our matrix-matrix multiplication routines return when a specialization isn't found? It moves the "Not Implemented" warning from MatMatMult() to whenever I try to do something other than multiply with the output, but in some situations that's desirable. I'd be interested to hear what people think. Thanks, Toby
Re: [petsc-dev] Why do we use void* instead of PetscObject in PETSc?
I've been working on a nonlinear map object: it would wrap
up the function/derivative/second-derivative callbacks
for SNES/Tao/maybe TS in an object.
It doesn't do what Dave is asking: at the moment, the user still
passes a (void *) as ctx to that object. Rather, I'm interested in
use cases where there is more structure to the nonlinear map than is
expressed in the callbacks (such as for operator split methods).
Toby
On Mon, Mar 04, 2019 at 08:55:42PM +, Smith, Barry F. via petsc-dev wrote:
>
>
> > On Mar 4, 2019, at 5:54 AM, Dave May wrote:
> >
> > Hi Barry,
> >
> >
> > On Mon, 4 Mar 2019 at 03:26, Smith, Barry F. wrote:
> >
> >There is a lot of merit for this alternative approach.
> >
> >This suggestion is also closely related to the (I think it's Toby's)
> > proposal to replace the (function), ctx pairs that manage call backs in
> > PETSc with objects.
> >
> > Are you referring to this issue?
>
>No. I am not sure the suggestion I was referring to has popped up in any
> textual form yet.
>
>Barry
>
> >
> > https://bitbucket.org/petsc/petsc/issues/245/developer-api-for-replacing-petsc-objects
> >
> > I didn't find anything else but probably I looked in the wrong place.
> >
> >
> >
> > There will be a bit of an issue with dealing with the Fortran code but
> > presumably it will be manageable.
> >
> > Barry
> >
> > So my question is, what would be the major win to devoting the
> > resources to make this change now versus putting it off indefinitely?
> >
> >
> > For "basic" usage of SNES, or KSP with KSPSetComputeOperators() there is no
> > obvious win I can see. Hence my proposal is disruptive for (probably) a
> > large fraction of PETSc users.
> >
> > However for "advanced" usage of KSP, SNES-DM, specifically FAS or anything
> > involving DMCoarsenHookAdd() I think there is a benefit due to the improved
> > type safety and debugability of the resulting solver. I asked myself the
> > question I posted after having to think about how to safely define a user
> > contexts on KSPs, DMs living on sub-communicators with the PCTelescope
> > setup. Determining if a user context is valid for use on a sub-communicator
> > obviously complicated by the fact we cannot extract / query a void* user
> > context for a communicator.
> >
> > Given that the percentage of basic usage mentioned above likely represents
> > the largest fraction of petsc users, my proposal seems unnecessarily
> > disruptive given the little gain it would likely yield to a typical end
> > user. Hence I have two alternative proposals which are less invasive (for
> > the user).
> >
> > [option 1]
> > * Keep void* in all the PETSc APIs
> > * All PETSc objects currently storing, managing void* data are changed to
> > internally store a PetscObject.
> >
> > If the user context provided is not a valid PETSc object, we create a
> > PetscContainer, shove in the user context and set the internal PetscObject
> > to point to the container. This does make a call back in which the user
> > data is returned somewhat clunky as you have to first query if the internal
> > PetscObject was created internally, and if so check it is of type
> > PetscContainer and then return the pointer (to allow for a user context
> > which is itself a PetscContainer). Yuck.
> >
> > Option 1 asserts the following: "the user does not have to concern
> > themselves with any object model, but internal to the PETSc library we
> > refuse to use void* for user contexts as they are inherently unsafe and
> > hard to debug"
> >
> > This would require a suitable method to query pointers for a consistent
> > PETSc header (a function variant of PetscValidHeader() which does not throw
> > errors) and PETSc objects. Below is one such method:
> >
> > typedef enum { PETSCHEADER_NULL_PTR = 0 , PETSCHEADER_INVALID_PTR,
> > PETSCHEADER_OBJECT_FREED, PETSCHEADER_INVALID_TYPE } PetscHeaderErrorType;
> >
> > const char *PetscHeaderErrorTypeNames[] = { "null pointer", "invalid
> > pointer", "object already freed", "invalid (unknown) PETSc type" };
> >
> > PetscErrorCode PetscHasValidHeader(void *h,PetscBool
> > *valid_header,PetscHeaderErrorType *err)
> > {
> > *valid_header = PETSC_TRUE;
> > if (!h) { /* "Null Object: Parameter # %d" */
> > *valid_header = PETSC_FALSE;
> > if (err) *err = PETSCHEADER_NULL_PTR;
> > PetscFunctionReturn(0);
> > }
> > if (!PetscCheckPointer(h,PETSC_OBJECT)) { /* "Invalid Pointer to Object:
> > Parameter # %d" */
> > *valid_header = PETSC_FALSE;
> > if (err) *err = PETSCHEADER_INVALID_PTR;
> > PetscFunctionReturn(0);
> > }
> > if (((PetscObject)(h))->classid == PETSCFREEDHEADER){ /* "Object already
> > free: Parameter # %d" */
> > *valid_header = PETSC_FALSE;
> > if (err) *err = PETSCHEADER_OBJECT_FREED;
> > } else if (((PetscObject)(h))->classid < PETSC_SMALLEST_CLASSID ||
> > ((PetscObject)(h))->classid > PETSC_LARGEST_CL
Re: [petsc-dev] Tao Separable Objective deprecated
That's for the explanation, Alp. On January 4, 2019 4:45:34 PM EST, "Dener, Alp" wrote: >Hi Isaac, > >On Jan 4, 2019, at 8:41 AM, Isaac, Tobin G via petsc-dev >mailto:petsc-dev@mcs.anl.gov>> wrote: > > >I'm interested in exploring various method of multipliers approaches >to optimization for separable objectives. With the separable >objective interface recently deprecated, how do you think I should go >about doing this? > >The separable objective interface isn’t gone. We just changed >terminology because “separable objective” was not an accurate >description of what the function was doing. It was being used to define >the residual for a nonlinear least-squares problem, so we’ve changed >the function name to TaoSetResidualRoutine(). Otherwise the function >signature is the same as before. > >In line with this change, we’ve also converted >TaoSetSeparableObjectiveWeights() to TaoSetResidualWeights(). We’ve >also added a TaoSetResidualJacobianRoutine() in order to support the >regularized Gauss-Newton algorithm that has been added to TAO recently >(Pounders never needed the least-squares Jacobian to be provided). > >If you were using Pounders before with the separable objective API, you >can continue to do so still using the new function names. The >functionality underneath hasn’t changed. > > >In general, because on objective function is not an object, just a >routine, how should we go about conveying structure in the objective? >Do we prefer that data to be composed onto the Tao object? > > >There is no support in TAO at the moment for actual separable objective >functions. None of the algorithms in TAO have any understanding of >structure in the objective, or try to do special things to take >advantage of that structure. That is actually the main reason why we >wanted to change the separable objective interface because it is >misleading to the user, and suggests the existence of a TAO >functionality that is not actually available. > >Thanks, > Toby > > > >I hope this answers your questions! > >Best, >—— >Alp Dener >Argonne National Laboratory >https://www.anl.gov/profile/alp-dener
Re: [petsc-dev] Tao Separable Objective deprecated
On Fri, Jan 04, 2019 at 09:41:21AM -0500, Tobin Isaac wrote: > > I'm interested in exploring various method of multipliers approaches > to optimization for separable objectives. With the separable > objective interface recently deprecated, how do you think I should go > about doing this? > > In general, because on objective function is not an object, just a > routine, how should we go about conveying structure in the objective? > Do we prefer that data to be composed onto the Tao object? Just to throw it out there, but as several approaches to separable objectives rely on sub-optimization problems, a good approach for extensibility might be to have each process PetscObjectCompose() a list of sub-Tao's that it participates in. A separable Tao implementation could then query for the list. I think this would work will for O(1) or O(P) separable components, but might be cumbersome for more components. > > Thanks, > Toby > >
[petsc-dev] Tao Separable Objective deprecated
I'm interested in exploring various method of multipliers approaches to optimization for separable objectives. With the separable objective interface recently deprecated, how do you think I should go about doing this? In general, because on objective function is not an object, just a routine, how should we go about conveying structure in the objective? Do we prefer that data to be composed onto the Tao object? Thanks, Toby
