Open loganharbour opened 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:
[C]
inputs = 'A B'
pull_all_mesh_properties = true
[]
[C]
inputs = 'A B'
pull_mesh_properties = 'A B:propname'
[]
getPulledMeshProperty<T>(_input_names[0], "propname")
Looking for input from @permcody, @GiudGiud, and @miaoyinb. Specifically Yinbin - is this enough?
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?
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.
Sounds great. This should be enough for my applications.
[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
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
I think in some applications of XYDelaunayGenerator
, we may need to "pull" boundary
's metadata not the holes
's metadata.
Good point. Ok then we should support copying from multiple MGs
Following :)
@loganharbour
@loganharbour
Yes?
@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?
@loganharbour Just want to check if this will be ready soon. Thanks.
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.