Hi Timo, I replied to this from a different email address, and it doesn't seem to have made it to the mailing list; most likely an error on my end. Here's what I wrote a few weeks ago:
> Do you mean a pull request to the documentation? Or a pull request for mesh_loop? I ask because I'm unsure if what I'm seeing with AssembleFlags::assemble_own_interior_faces_both is a bug or not. > I've since re-written my code to assemble all the face data using AssembleFlags::assemble_own_interior_faces_once, then computing and applying the residuals in a separate mesh_loop call, and I'm once again recovering the correct residual in the global refinement and adaptive refinement cases; no unexpected behavior there. Thank you, Corbin On Friday, April 7, 2023 at 2:49:48 PM UTC-4 Timo Heister wrote: > > to my eye, in both cases, the work on the face is done, followed by the > work on the cell. I think, however, the default behavior is to work on the > cells first, followed by work on the faces. > > That is correct. Would you be able to submit a pull request to fix this? > > On Thu, Apr 6, 2023 at 8:30 AM Corbin Foucart <corbin....@gmail.com> > wrote: > > > > I also think there may be a small typo in the documentation; "If the > flag AssembleFlags: : assemble_own_cells is passed, then the default > behavior is to first loop over faces and do the work there, and then > compute the actual work on the > > ZjQcmQRYFpfptBannerStart > > This Message Is From an External Sender > > Use caution when opening links or attachments if you do not recognize > the sender. > > > > ZjQcmQRYFpfptBannerEnd > > I also think there may be a small typo in the documentation; > > > > "If the flag AssembleFlags::assemble_own_cells is passed, then the > default behavior is to first loop over faces and do the work there, and > then compute the actual work on the cell. It is possible to perform the > integration on the cells after working on faces, by adding the flag > AssembleFlags::cells_after_faces." > > > > to my eye, in both cases, the work on the face is done, followed by the > work on the cell. I think, however, the default behavior is to work on the > cells first, followed by work on the faces. > > > > On Mon, Apr 3, 2023 at 6:35 PM Corbin Foucart <corbin....@gmail.com> > wrote: > >> > >> Hello everyone, > >> > >> I'm solving a 1D explicit DG-FEM problem and I've encountered behavior > that I don't understand using MeshWorker::mesh_loop. > >> > >> I'm using the MeshWorker::assemble_own_interior_faces_both flag since I > want to do work on each face corresponding to the same cell interior > >> If the grid is created using typical GridGenerator calls, the order is > exactly as I'd expect: first, work is done on the cell, then the faces > (boundary or interior), followed by the next cell (further, all mass > matrices are the same) > >> However, if I manually adapt the mesh by refining some cells, the order > seems to change; the face work is done without respect to the cell interior > last worked on > >> > >> I've attached a stripped-down program that illustrates this behavior on > a toy mesh in 1D, as well as the output. > >> > >> Ultimately, my goal is to assemble an inverse mass matrix on each cell, > and apply it to a residual vector containing interior and face > contributions (which can be done element-wise since the elements are FE_DGQ) > >> I was attempting to store the inverse via CopyData and then apply it in > the copy worker. > >> However, I'm finding that due to the order of execution, I can't rely > on the face work being done immediately after the cell work, and the > inverse mass matrix stored to CopyData is often from another cell than the > faces being worked on. > >> I could do the assembly and application of the inverse mass matrices > separately, or store the inverse mass matrices in a map to the cell > iterators, but I'm curious why this ordering occurs. > >> > >> Am I misunderstanding how mesh_loop is supposed to work? Any guidance > would be appreciated! > >> > >> Corbin > >> > >> -- > >> 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+un...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/ac4d4550-b014-4440-b2c2-227dba71fffen%40googlegroups.com > . > > > > -- > > 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+un...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/CAE%2BMPodXQ5tZWiOkhq1j-p4uuvQiWOg3n57R2z7cWCKMz1pKFQ%40mail.gmail.com > . > > > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ > -- 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/a0269629-0dc7-447f-8785-718a760d05f9n%40googlegroups.com.
