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
> 

Reply via email to