Hello Vachan, What you are describing is very similar to Hesthaven's framework of build matrix operators and apply them to your degrees of freedom. The main advantage of this operator form is to have a common mass (if linear elements), differentiation, flux, and boundary operators for all your elements since the operators are defined on the reference element. Therefore, using MeshWorker loop to go through every single element to build those matrices would result in building redundant local matrices and storing them in a global matrix. Can be very expensive memory wise.
Yes, you could use MeshWorker to compute only your normal fluxes. So, it's feasible, but I wouldn't use the MeshWorker loop to build those matrices . You are welcome to look at step-33 to see how you can loop through your elements, and then build your different mass matrices. Then use a similar loop to apply your, interpolation, differentiation, lifting matrices on the local solution to assemble your right-hand side. Yes, if you build those operators, you will save a significant amount of time *for explicit time stepping* since you will basically have concatenated multiple operators together. Interpolation, differentiation, integration, etc. into a single matrix-vector product. I think know what you are referring to with that sparse flux matrix. If it's a local matrix, you would want to store the lifting operator, which is the mass inverse times your sparse flux matrix, which is not necessarily a sparse matrix (unless mass is diagonal). Either way, I wouldn't worry too much about that operation taking a long time. Your other operations on the volume take much longer, and if you decide to go with nonlinear fluxes, the time it takes to apply this lifted flux vector is meaningless. deal.II has a SparseMatrix class, in case you want to use it, and you can provide the set the SparsityPattern if you want. If you were planning on building multiple global matrices, then yes, your approach makes sense using SparseMatrix; be careful about memory. If you only plan on doing linear advection, your problems should be simple enough that you wouldn't care about memory nor computational time. I haven't seen people build those global matrices, but it should be faster than assembling every loop. It's the old trade-off between memory and computation. Doug On Tuesday, September 17, 2019 at 3:03:52 AM UTC-4, vachan potluri wrote: > > Hello all, > > > I am a beginner in dealii. I want to solve a linear, transient advection > equation explicitly in two dimensions using DG. The resulting discrete > equation will have a mass matrix as the system matrix and a sum of terms > which depend on previous solution (multiplied by mass, differentiation, > flux and boundary matrix) as the rhs. > > [image: linearAdvection2D.png] > > Instead of using MeshWorker::loop for every single time step, I think the > following approach would be better. I am using a ghost cell approach to > specify the boundary condition: the boundary condition can be specified by > an appropriately calculated normal numerical flux. > > > 1. Before the any time steps, use a MeshWorker::loop each for each of > the four matrices: mass, differentiation, flux and boundary > 2. During each update > 1. Again use MeshWorker::loop, but this time only to calculate the > normal numerical flux. > 2. Use the normal numerical flux and the previous solution to > obtain the RHS using appropriate matrix-vector products > 3. Solve the system > > I have few question regarding this approach. > > 1. Is it feasible > 2. Can it give significant improvement in performance over the case > when assembling is done for every time step > 3. (Assuming answers to above questions are positive) For higher > orders, the flux and boundary matrices will be very sparse. The normal > numerical flux (which will be a vector) will also be sparse. Can the > matrix-vector product involving these combinations be optimised by using > appropriate sparsity pattern? Can a sparsity pattern be specified for a > vector too? > > -- 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/39f7baf9-e7c7-4a4a-b50e-b54ab5af0d7f%40googlegroups.com.
