idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.71k stars 1.04k forks source link

Add capability to forward mesh property data #23352

Open loganharbour opened 1 year ago

loganharbour commented 1 year ago

Reason

The mesh property data is not retained when executing multiple mesh generators. There exist cases when we actually want to keep some of this data.

Design

Add an interface to explicitly specify mesh property data to forward.

Impact

New capability.

loganharbour commented 1 year ago

Here's the interface we're thinking so far. Instead of "forward", we preferred the concept of "pulling". That is, the next generator in the line can describe what it wants to pull.

We're thinking a few ways to do this. Take the simple generators:

[A]
  ...
[]

[B]
  ...
[]

[C]
  inputs = 'A B'
  ...
[]

[D]
  inputs = 'C'
  ...
[]

By default, you are allowed to getMeshProperty for only mesh generators that you directly depend on. That is, C can access props from A and B and D can access properties from C. If you want to "pull" properties in C, you could do the following:

Looking for input from @permcody, @GiudGiud, and @miaoyinb. Specifically Yinbin - is this enough?

miaoyinb commented 1 year ago

Thanks for the summary, @loganharbour. I think this should be enough for my application. Just some questions.

Just to confirm. So "pull" here means get the mesh metadata from input mesh(es) and then declare the corresponding mesh metadata and set the values based on the "pulled" data values for the current MG, right?

Also, for multiple input meshes (e.g., inputs = 'A B' in your example), what would happen if A and B has a metadata with the same name?

loganharbour commented 1 year ago

Just to confirm. So "pull" here means get the mesh metadata from input mesh(es) and then declare the corresponding mesh metadata and set the values based on the "pulled" data values for the current MG, right?

Yes, something like that. What a pull basically does is just clones that data into the data for the current generator. That is, if we pull A:foo into the generator C, we clone the data and now C:foo exists. Which, in the case above, would make C:foo then available to D, but not A:foo (because you should only get data from your direct dependencies.

Also, for multiple input meshes (e.g., inputs = 'A B' in your example), what would happen if A and B has a metadata with the same name?

There can be checking for ambiguity. For inputs with the same name or data with the same name, you'll just get an error telling you that you need to be more explicit.

miaoyinb commented 1 year ago

Sounds great. This should be enough for my applications.

GiudGiud commented 1 year ago
[C]
  inputs = 'A B'
  pull_all_mesh_properties = true
[]

this is not the typical case. I think pulling mesh properties is more meant for single input MGs, like a TransformMeshGenerator. A "C" like an assembly generator does not need to pull mesh properties. It just needs to use them.

While this will be supported, I think situations such as: "A and B have the same property name" should lead to an error

GiudGiud commented 1 year ago

We should rename from pull to copy btw. It feels like an AssemblyMG which uses PinMG data would pull it, when in reality it does not need to pull or copy it, just use it.

Similarly a pull for a transformMG feels too active. It's really just a copy

miaoyinb commented 1 year ago

I think in some applications of XYDelaunayGenerator, we may need to "pull" boundary's metadata not the holes's metadata.

GiudGiud commented 1 year ago

Good point. Ok then we should support copying from multiple MGs

eshemon commented 1 year ago

Following :)

GiudGiud commented 1 year ago

@loganharbour

loganharbour commented 1 year ago

@loganharbour

Yes?

eshemon commented 1 year ago

@loganharbour @miaoyinb just wanted to follow this issue and see where we are. Now that our training is over we will get focused on some work that depends on this PR. Should we have a meeting on the status and implications soon?

miaoyinb commented 1 year ago

@loganharbour Just want to check if this will be ready soon. Thanks.