Because of the difficulty of maintaining a nonzero matrix for such problems aren't these problems often done "matrix-free"?
So you provide a routine that computes the action of the operator but doesn't form the operator explicitly (and you hope that you don't need a preconditioner). There are simple ways (but less optimal) to do this as well as more sophisticated (such as multipole methods). If the convergence of the linear solver is too slow (due to lack of preconditioner) you might consider continuing with matrix free but at each new Newton solve (or several Newton solves) construct a very sparse matrix that captures just the very local coupling in the problem. Once particles have moved around a bit you would throw away the old matrix and construct a new one. For example the matrix might just captures interactions between particles that are less than some radius away from themselves. You could use a direct solver or iterative solver to solve this very sparse system. Barry This is why KSPSetOperators and SNESSetJacobian and TSSetRHS/IJacobain take two Jacobian matrices, the first holds the matrix free Jacobian and the second holds the approximation used inside the preconditioner. > On Oct 15, 2019, at 3:29 PM, Ellen M. Price <[email protected]> > wrote: > > Thanks for the reply, Barry! Unfortunately, this is a particle code > (SPH, specifically), so the particle neighbors, which influence the > properties, change over time; the degrees of freedom is a constant, as > is the particle number. Any thoughts, given the new info? Or should I > stick with explicit integration? I've seen explicit used most commonly, > but, as I mentioned before, the optimal timestep that gives the error > bounds I need is just too small for my application, and the only other > thing I can think to try is to throw a lot more cores at the problem and > wait. > > Ellen > > > On 10/15/19 4:14 PM, Smith, Barry F. wrote: >> >> So you have a fixed "mesh" and fixed number of degrees of freedom for the >> entire time but the dependency on the function value at each particular >> point on the neighbor points changes over time? >> >> For example, if you are doing upwinding and the direction changes when you >> used to use values from the right you now use values from the left? >> >> Independent of the coloring, just changing the locations in the matrix >> where the entries are nonzero is expensive and painful. So what I would do >> is build the initial Jacobian nonzero structure to contain all possible >> connections, color that and then use that for the entire computation. At >> each time step you will be working with some zero entries in the Jacobian >> but that is ok, it is simpler and ultimately probably faster than trying to >> keep changing the nonzero structure to "optimize" and only treat truly >> nonzero values. >> >> For "stencil" type discretizations (finite difference, finite value) what >> I describe should be fine. But if you problem is completely different (I >> can't imagine how) and the Jacobian changes truly dramatically in structure >> then what I suggest may not be appropriate but you'll need to tell us your >> problem in that case so we can make suggestions. >> >> Barry >> >> >> >>> On Oct 15, 2019, at 2:56 PM, Ellen M. Price via petsc-users >>> <[email protected]> wrote: >>> >>> Hi PETSc users! >>> >>> I have a problem that I am integrating with TS, and I think an implicit >>> method would let me take larger timesteps. The Jacobian is difficult to >>> compute, but, more importantly, the nonzero structure is changing with >>> time, so even if I use coloring and finite differences to compute the >>> actual values, I will have to update the coloring every time the >>> Jacobian recomputes. >>> >>> Has anyone done this before, and/or is there a correct way to tell TS to >>> re-compute the coloring of the matrix before SNES actually computes the >>> entries? Is this even a good idea, or is the coloring so expensive that >>> this is foolish (in general -- I know the answer depends on the problem, >>> but there may be a rule of thumb)? >>> >>> Thanks, >>> Ellen Price >>
