Understanding MeshWorker::mesh_loop order with adaptive refinement

[Corbin Foucart]

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

[Timo Heister]

Corbin,

Do you know if this problem is only present in 1d?

-- https://www.math.clemson.edu/~heister/

On Mon, Apr 3, 2023, 18:36 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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

Use caution when opening links or attachments if you do not recognize the sender.

 

ZjQcmQRYFpfptBannerEnd

--
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.

[Corbin Foucart]

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. 

--

[Timo Heister]

> 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

> 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/

[Corbin Foucart]

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 

[Timo Heister]

I think this is just a typo in the documentation exactly like you pointed out. It would be great to see that fixed. Are you willing to do that?

I am not sure I understand your problem you had to work around. If you go into detail we might be able to figure out the issue (if there is one inside deal.II)

-- https://www.math.clemson.edu/~heister/

On Wed, May 3, 2023, 20:52 Corbin Foucart <corbin....@gmail.com> wrote:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/a0269629-0dc7-447f-8785-718a760d05f9n%40googlegroups.com.