[petsc-dev] MATLMVM

[Jed Brown]

I'm a bit concerned that these LMVM variants are packing
optimization-specific structure into the Mat even if the algebraic
operations like MatMult are equivalent.  Compare the two Broydens, for
example.

  ierr = MatLMVMApplyJ0Fwd(B, X, Z);CHKERRQ(ierr);
  for (i = 0; i <= lmvm->k-1; ++i) {
    ierr = VecDot(lmvm->S[i], X, &stx);CHKERRQ(ierr);
    ierr = VecAXPBYPCZ(Z, PetscRealPart(stx)/lbrdn->sts[i], -PetscRealPart(stx)/lbrdn->sts[i], 1.0, lmvm->Y[i], lbrdn->P[i]);CHKERRQ(ierr);
  }

  ierr = MatLMVMApplyJ0Fwd(B, X, Z);CHKERRQ(ierr);
  for (i = 0; i <= lmvm->k-1; ++i) {
    ierr = VecDot(lmvm->Y[i], X, &ytx);CHKERRQ(ierr);
    ierr = VecAXPBYPCZ(Z, PetscRealPart(ytx)/lbb->yts[i], -PetscRealPart(ytx)/lbb->yts[i], 1.0, lmvm->Y[i], lbb->P[i]);CHKERRQ(ierr);
  }

These aren't algebraically different beasts, they just access different
fields from the optimization problem.  I think they shouldn't be
different as Mats.

Also, this can surely be rewritten to use VecMDot for significantly
improve parallel performance.


Note that we also have MatCreateLRC which implements similar
algebraic structures.


"Munson, Todd" <tmunson at mcs.anl.gov> writes:

> I would be happy with one matrix type and removing the convenience functions
> from the code.  I am surprised that the dark lord did not mention it when
> he approved the pull request...
>
> Matt: the difference in the subtypes is that they are using different formulas 
> that result in different approximations.  BFGS is for symmetric problems and 
> is a rank-2 update that maintains positive definiteness, SR1 is for 
> symmetric problems and is a rank-1 update that can be indefinite.
>
> The nonsymmetric equivalents (BadBroyden and GoodBroyden) are also different 
> and bad Broyden is typically better than good Broyden.
>
> Performance on a particular problem varies greatly depending on both the
> specific problem and the approximation type selected.
>
> Recall to get performance, you can either make the computational kernels
> run faster, change the algorithm, or both.  Changing the matrix 
> approximations changes the algorithm.
>
> Todd.
>
>> On Sep 11, 2018, at 10:12 AM, Matthew Knepley <knepley at gmail.com> wrote:
>> 
>> On Tue, Sep 11, 2018 at 9:47 AM Dener, Alp <adener at anl.gov> wrote:
>> 1 base type and 8 subtypes. If there’s a better convention/structure to do this in PETSc, I’d be happy to get a refactoring done ASAP this week so that it’s cleaner in the release.
>> 
>> I guess what Lisandro is asking is, what backend differences are there to make so many type necessary.
>> 
>> Looking at the few I recognize, it seems like they encode the sum of rank 1 matrices (BFGS, SR1). Why
>> would we have separate types for this two things?
>> 
>>   Thanks,
>> 
>>      Matt
>>  
>> —
>> Alp Dener
>> Argonne National Laboratory
>> https://mcs.anl.gov/person/alp-Dener
>> 
>> On Sep 11, 2018, at 5:10 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> 
>>> So now we have 9 new, top-level, public matrix types for LMVM... Really?
>>> 
>>> #define MATLMVM            "lmvm"
>>> #define MATLMVMDFP         "lmvmdfp"
>>> #define MATLMVMBFGS        "lmvmbfgs"
>>> #define MATLMVMSR1         "lmvmsr1"
>>> #define MATLMVMBRDN        "lmvmbrdn"
>>> #define MATLMVMBADBRDN     "lmvmbadbrdn"
>>> #define MATLMVMSYMBRDN     "lmvmsymbrdn"
>>> #define MATLMVMSYMBADBRDN  "lmvmsymbadbrdn"
>>> #define MATLMVMDIAGBRDN    "lmvmdiagbrdn"
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Lisandro Dalcin
>>> ============
>>> Research Scientist
>>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>>> Extreme Computing Research Center (ECRC)
>>> King Abdullah University of Science and Technology (KAUST)
>>> http://ecrc.kaust.edu.sa/
>>> 
>>> 4700 King Abdullah University of Science and Technology
>>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>>> http://www.kaust.edu.sa
>>> 
>>> Office Phone: +966 12 808-0459
>> 
>> 
>> -- 
>> 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/