Improve MultiAppGeneralFieldNearestLocationTransfer
Reason
Design
Impact
hello
please fill the pull request template you ll want to add "refs #28065" to one of the commit messages so it passes the pre-check
We'll need a test. Please note that parallel support is going to be complicated here, since if we are seeking 3 nearest nodes (=locations, using nodes as an example) for example, these two cases will return different results:
- 3 nearest nodes on the same process domain
- 2 nearest nodes on one process domain and 1 on another process domain
I think there is a way to remediate to this, but it's a little involved and likely modifies routines from the base class a bit. We would need each process to return the 3 nearest nodes and distances, then the requestor process can make the decision as to which nodes to use to get a value
This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
Job Precheck, step Clang format on 0447650 wanted to post the following:
Your code requires style changes.
A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:
curl -s https://mooseframework.inl.gov/docs/PRs/28065/clang_format/style.patch | git apply -v
Alternatively, with your repository up to date and in the top level of your repository:
git clang-format 2790049cfcdb14dfbbddec0841caf92abd6e7be3
Hi @GiudGiud
Thanks for the helpful comments. I was under the impression that greedy_search=true would handle the issue of nodes on different processes. But you are right, I made a small test and it does not seem to do that.
This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.