[petsc-dev] Proposed changes to TS API

[Smith, Barry F.]

> On May 11, 2018, at 1:01 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> 
> On Fri, 11 May 2018 at 19:34, Jed Brown <jed at jedbrown.org> wrote:
> 
>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> 
>>>>> 
>>>>> I assemble the combined system directly.
>>>> 
>>>>  How, two sets of calls to MatSetValues(), One for the scaled mass
> matrix and one for the Jacobian entries? For a constant mass matrix does
> this mean you are recomputing the mass matrix entries each call? Or are you
> storing the mass matrix entries somewhere?  Or is your mass matrix diagonal
> only?
>>> 
>>>  Or do you build element by element the M*shift + J element stiffness
> and then insert it with a single MatSetValues() call?
> 
>> It isn't even built separately at the element scale, just summed
>> contributions at quadrature points.
> 
> That's exactly the way I do it in PetIGA, and the way I would do it in any
> other general-purpose FEM-like code. In high-order FEM, Jacobian assembly
> may very well account from 50% to 80% of runtime (at least that's my
> experience with PetIGA). IMHO, forcing users to have to do TWO global
> matrix assemblies per time step is simply unacceptable, both in terms of
> memory and runtime.
> 
> TS used to be an unusable pile of crap until Jed proposed the marvelous
> IJacobian interface. Suddenly COMPLEX fully-implicit DAE problems become
> SIMPLE to express, and a single IFunction/IJacobian pair reusable for
> different timestepper implementations a reality. And we got an added
> bounus: this was efficient, it involved a SINGLE global matrix assembly. If
> the issue is in supporting simpler problems, then we should go for an
> alternative interface with broken Jacobians, just as Stefano propossed in a
> previous email. I'm totally in favor of an additional broken Jacobians API,
> and totally againt the removal of the single-matrix IJacobian interface.

   Ok, thanks.

> 
> I don't buy the argument that IJacobian with shift is ugly,

   Not ugly, hard for most users to understand.

> and that such
> API drives users away from TS. At best, this is a documentation problem.
> Come on, this is just chain rule, should be kindergarden-level stuff for
> PETSc users. If we simplify things for the sake of making things simple for
> newcomers and beginners and make them annoyingly slow for power users
> solving complex problems, we will do a very bad business. This is not
> politically correct, but I'm much worried about loosing power users, you
> know, those that can eventually make a meaningful contributions to science
> and software projects. Beginners and newcomers eventually learn and benefit
> for common-sense software design, and will eventually appreciate it. I
> really hope populism to not win this battle :-)
> 
> -- 
> 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