Sort out applying different physics to subsets of an MFEM mesh

[trevilo]

As an example, start with single mesh that contains both flow-only and EM-only domains and reproduce flow-only and EM-only standalone resuls

[trevilo]

A few notes/thoughts as we start to look into this functionality...

1. Seems that there is not direct support for this in MFEM, at least as of two years ago, meaning that definining a GridFunction on a subdomain of a mesh is not possible. See discussion on MFEM #1124. Not immediately clear if subsequent developments have changed this situation.
2. One approach would be to create separate meshes for different physics from a single input mesh. An example of how to do this is provided by the trimmer miniapp. See discussion on MFEM #1551 and code at trimmer.cpp
3. If we take this approach (i.e., separate meshes for separate physics) we'll need to be able to interpolate or project fields between meshes (which is probably a capability we'll need eventually anyway).

[marc-85]

Have we considered creating Vectors from elements sharing the same attribute? We could build meshes with different "physical attributes" and then create different vectors pointing to the elements of certain attributes. Or just apply different sets of equations to elements with different attributes.

We can get the attribute of an element from the GridFunction through the FiniteElementSpace, i.e.

Up->FESpace()->GetAttribute(elemID)

[trevilo]

Have we considered creating Vectors from elements sharing the same attribute? We could build meshes with different "physical attributes" and then create different vectors pointing to the elements of certain attributes. Or just apply different sets of equations to elements with different attributes.

We can get the attribute of an element from the GridFunction through the FiniteElementSpace, i.e.

Up->FESpace()->GetAttribute(elemID)

Yes, I think anything we might do on a single mesh would have to be based on the element attribute. But, I'm not following the specifics of your idea. Tzanio contemplated three approaches in the discussion here (in MFEM #1124):

1. Allocate all variables over the whole mesh, with some variables being ignored in regions where they shouldn't be present.
2. Allocate variables only on the subdomains where the phyiscs dictates they live.
3. Define separate meshes for different physics and interpolate or project as necessary.

Item 1 seems easy to implement with existing MFEM capabilities, but is inefficient. Item 2 is what I was thinking we would do, but isn't (or at least wasn't) directly supported by MFEM. If it requires significant changes in MFEM or a lot of extra code on our part, maybe it is less attractive. Item 3 seems like a reasonable approach, particularly given that we've contemplated using different mesh resolutions for different physics anyway, but would require an interpolation capability to come online immediately.

Does your idea sit in one of these categories or is it something different?

[marc-85]

I guess I was thinking along the lines of item 2. Since generating two grid functions for two domains isn't supported I'd allocate the variables in two independent vectors and operate over the data in those vectors. The drawback would be that we'd need to create functions for the different operators in a way similar to what I've done with the GPU version, i.e., computing gradients wouldn't be as easy as calling GridFunction.ComputeGradient()

[trevilo]

@marc-85: ok, I got it. Thanks.

[koomie]

Comment for testing: expect to add additional bats test which runs a current flow and EM (parallel) test at the same time and verifies the solutions against running each independently.

[trevilo]

For an example implementation of the "separate meshes + interpolation" approach in MFEM using gslib, see the overlapping grids miniapps, specificially the conjugate heat transfer example.

[trevilo]

Noting a couple recent mfem developments...

1) MFEM PR 315 offers a potential alternative to GSLIB-based solution transfer between meshes 2) Improved GSLIB support, including support for mixed meshes, appears to be on the horizon (see MFEM PR 2948)