Dear Dr. Bangerth, Thank you very much for your quick reply. In theta scheme that I currently use, I do limit refinement frequency to each n-th layer, normally n=10.
I can see that there is an implementation of IRK method in deal.ii. If you do not mind, may I ask what was the reason that that particular method was chosen in your software? I am aware that IRK and BDF schemes have overall similar efficiency, so that might have been just some personal preference of the developer(s). I am wondering how deal.ii solves the issue when the dimension of the problem is large and then it is impossible to store the matrix (I-tau*AxJ)^(-1) of the simplified Newton iteration in IRK (where x is the Kronecker product; from Hairer & Wanner). I believe you use some modification that leads to the use of simply (I-tau*J)^(-1) as it is seen from the name *id_minus_tau_J_inverse* of one of the variables in the code. Is it recomputed for each Newton iteration? Regards, Aslan Kosakian Graduate Student Energy Systems Design Laboratory Department of Mechanical Engineering University of Alberta Edmonton, AB, Canada T6G2G8 On Wednesday, November 16, 2016 at 8:03:52 AM UTC-7, Wolfgang Bangerth wrote: > > > Aslan, > > > There is, however, one important drawback of the multistep methods > (including > > BDF of order 2<k<6 that I am looking at): they require solution transfer > from > > more than one previous steps compared to just one in one-step methods > > (Runge-Kutta, theta scheme). Therefore, if the mesh is continuously > > refined/coarsened during the simulation, this will lead to increase in > > computational expenses due to necessity of interpolation of several > solutions > > onto the new grid. > > The way you would implement this is that every time you change the mesh, > you > transfer all solution vectors from the previous to the new mesh. The old > mesh, > and all solution vectors defined on it, then cease to exist. Everything > only > exists on the new mesh. For all practical purposes, at any given time of > the > time stepping method, you only ever work on one mesh and it looks like > there > has never been another mesh. The only time when you deal with two meshes > is > during the brief period where you use SolutionTransfer. > > Now, transferring solution vectors is not cheap, but it's also not > expensive > compared to, for example, assembling and solving a linear system. That's > particularly true because you don't typically adapt the mesh very > frequently. > For most problems, I would assume that adapting the mesh every 10 or 20 > time > steps is perfectly fine. For example, in our "big" code, ASPECT, the > default > is every 15 time steps, and I don't know that anyone would have ever > changed > that default in their applications. In any case, if you amortize the cost > of > solution transfer over 10 or 20 time steps, then it's pretty much > negligible. > I would say that's true regardless of whether you transfer one, or ten > solution vectors. > > Best > Wolfgang > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > <javascript:> > 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. For more options, visit https://groups.google.com/d/optout.
