You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First noticed in #3339canCreate() in TopologicalMapping calls findLinkDest() which checks the link at creation and if not found, the search continues in parent nodes.
if no MeshTopology is present in ./ for the output mesh, it can return a "valid" pointer to a mesh in the parent Node. Therefor you end up with the same topology in Input and Output.
Do you think it is a behavior error of findLinkDestClass or a bad usage in this case ?
In general I think that explicit link is the way to go.
Automatic deduction in the current node is acceptable but searching in the full hierarchy is going far too much.
I would recommend to deprecate that feature, and progressively remove it.
EDIT: I was thinking to make a small PR to fix that...and well...after having looked at the code it is, as often, going to be a noodle untangling task.
First noticed in #3339
canCreate()
in TopologicalMapping callsfindLinkDest()
which checks the link at creation and if not found, the search continues in parent nodes.is looking for the class in the given path and if not found is looking in the parent Node.
So for example in this code:
if no MeshTopology is present in
./
for the output mesh, it can return a "valid" pointer to a mesh in the parent Node. Therefor you end up with the same topology in Input and Output.Do you think it is a behavior error of findLinkDestClass or a bad usage in this case ?
@epernod @damienmarchal @fredroy
The text was updated successfully, but these errors were encountered: