New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conservative transfers #12948
Comments
My understanding: what @vincentlaboure wants are two more parameters in the transfer base class
When a transfer is done, on the to transfer side, do a postprocessor evaluation, get one scalar value |
Looks like we need to execute |
that uses MultiAppCopyTransfer. But the code should work for other field transferes Refs idaholab#12948
that uses MultiAppCopyTransfer. But the code should work for other field transferes Refs idaholab#12948
the caculations can be reused for several interpolation transfers Refs idaholab#12948
the caculations can be reused for several interpolation transfers Refs idaholab#12948
that uses MultiAppCopyTransfer. But the code should work for other field transferes Refs idaholab#12948
the caculations can be reused for several interpolation transfers Refs idaholab#12948
@fdkong Thanks for looking at this! @YaqiWang's summary seems accurate. I think a good test problem could be as follows: Master app defined for 0 < x < 1, 0 < y < 1; block 0 for 0 < x < 0.5, block 1 for 0.5 < x < 1 The goal would be to:
A first step might be to do that same problem without block restriction on the sub apps. Does this make more sense? If you want, I can create some input files for that proposed test problem. |
Sounds good for me. @vincentlaboure, please create some input files, and added to my PR #13060. I will take care of them. |
@fdkong I created a branch showing input files that should make a really good test. I am aware that this might not be a trivial task but it would extremely useful for us and our customers. Please let me know if you have any questions about it. |
The input files are here |
that uses MultiAppCopyTransfer. But the code should work for other field transferes Refs idaholab#12948
the caculations can be reused for several interpolation transfers Refs idaholab#12948
The pps works for the conservative transfer now Refs idaholab#12948
its value is right with updated solution Refs idaholab#12948
the master mesh so that the test is more meaningful Refs idaholab#12948
instead of from_postprocessor_to_be_preserved Refs idaholab#12948
that uses MultiAppCopyTransfer. But the code should work for other field transferes Refs idaholab#12948
the caculations can be reused for several interpolation transfers Refs idaholab#12948
The pps works for the conservative transfer now Refs idaholab#12948
its value is right with updated solution Refs idaholab#12948
the master mesh so that the test is more meaningful Refs idaholab#12948
instead of from_postprocessor_to_be_preserved Refs idaholab#12948
Rationale
Some customers are increasingly requesting conservative transfers.
Description
A (scalable and transfer-agnostic) option could perhaps be to specify - in the
Transfers
block - the postprocessors on both the master and sub app that should match. The target fields could then be scaled using the ratio of these postprocessors.Impact
Key quantities of interest could be preserved during transfers.
The text was updated successfully, but these errors were encountered: