Thank you all for the help :). This is always a bit of a lesson in humility where I realise there is just so much I don't know, and how much out there there is still to learn :)!.
On Monday, December 7, 2020 at 11:52:51 a.m. UTC-5 Wolfgang Bangerth wrote: > On 12/7/20 6:19 AM, blais...@gmail.com wrote: > > > > How come you get away with only assembling the matrix every 3-5 time > steps? > > Are you treating advection explicitly? > > > > We get off by assembling the matrix every N time-steps for two main > reasons: > > - We use SDIRK which has a constant diagonal for all stages, hence this > part > > of the matrix does not change significantly > > - We are willing to sacrifice one non-linear iteration there and there, > at the > > cost of less assembly. The idea is that we use an exact jacobian when we > > assemble the matrix, but then we let it become innacurate as we continue > > iterating, while just updating the rhs. This is not a good approach when > the > > time-step is large, but when the time-step is small (say CFL<1), it > really > > does not affect significantly the number of newton iterations. > Consequently, > > we can update the jacobian matrix every 3 to 5 time-steps or so. This is > just > > an indication, generally we update it as soon as a non-linear step has > not > > lead to a decrease of more than 10x of the residual, meaning that our > Newton > > method is becoming inefficient. > > Nice approach! > > > > I'm also curious about what the matrix you use looks like. It must be > > something like > > A B > > B^T C > > What terms are in A,B,C? > > > > It has exactly this shape. The full weak form and some results are > detailed in > > : https://www.sciencedirect.com/science/article/pii/S2352711020302922 > > A is momentum + SUPG > > C is the PSPG block. In essence it looks very much like a stiffness > matrix > > weighted by the stabilization parameter. Hence, I really don't think it > is > > "well conditioned". > > Timo and Martin have already answered the question that underlaid why I > asked > about the block structure. In practice, you can't get good preconditioners > if > you don't exploit what a matrix corresponds to. ILU doesn't work well for > this > reason, but if you can decompose a matrix into its blocks, you can get > optimal > preconditioners for each block (say, the top left A block, given what it > represents -- if you resolve the length scales of advection, i.e., if your > cell Peclet number is less than 1, then it's essentially an elliptic > operator > for which you can apply multigrid methods). Then you build your overall > preconditioner from preconditioners for each block separately. > > I second the suggestion of the book by Elman, Silvester, and Wathen. I > would > also point you to step-22. The implementation in the actual program is > more > for illustrative purposes of what one can do, but I would suggest you > specifically read the section in the "Possibilities for extensions" that > discusses the Silvester/Wathen preconditioner which is probably close to > optimal. (It uses a mass matrix for the Schur complement, and that can be > done > better using the BTFB method, but I think it points you in the right > direction). > > Completely separately, one of the things Timo and I played around with in > ASPECT a long time ago is whether to make some terms in the equation > explicit > or implicit. We had originally made advection explicit, because that then > leads to a symmetric system matrix and we thought that that would be a > more > efficient way to solve the linear system. And that's true, symmetric > systems > are faster to solve. But it required us to have a substantially smaller > time > step, and in the end we realized that the overall time spent is (time per > time > step) * (number of time steps) and that by doing everything implicit, we > could > increase the time step size by 10x whereas the cost for solving the linear > systems only increased by 2x, so the made the whole simulation cheaper by > 5x. > > I think that from your description you're already doing everything > implicitly, > but it's worth thinking about these kinds of trade-offs anyway if you > currently have anything that limits your time step size. > > Best > W. > > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/eeb056b4-d87a-4d96-8c08-5f83931047fdn%40googlegroups.com.
