friedmud
commented
5 years ago - Is not a bug. This transfer is not at all meant to be conservative. It is a sampling transfer. It samples the source domain at the destination domain's nodes / elements (depending on if you're transferring to an elemental or nodal field).
On Wed, Oct 3, 2018 at 5:07 PM vincentlaboure notifications@github.com wrote:
Rationale
Two defects are being reported in this issue. It looks like:
1.
MultiAppMeshFunctionTransfer does not work appropriately with CONSTANT MONOMIAL if the master mesh is more refined than the subapp mesh (even if the latter is strictly included in the former). More specifically, it seems that the transfer is not conservative which is surprising since the projection should be pretty straightforward. 2.
MultiAppNearestNodeTransfer does not work appropriately with CONSTANT MONOMIAL (regardless of the refinement). In that case, the transferred field is zero everywhere... Yet, the source code seems to cover the !is_nodal case.
Description
To reproduce the errors:
1.
Go here https://github.com/vincentlaboure/moose/tree/multiapp_transfer_problems/test/tests/transfers/transfer_pb and run the master file (may need to change MultiApps/sub_app/app_type). The subapp postprocessor pwr_density_avg returns 4.75 while it should be 5 (not conservative). If Mesh/uniform_refine is set to 1, the expected value is obtained. 2.
Run the same input files as before but change Transfers/to_sub_power_density/type to MultiAppNearestNodeTransfer. Both subapp postprocessors (power_density_max and pwr_density_avg) return zero. The same result is obtained regarless of Mesh/uniform_refine.
Impact
Both of these are problematic because some multiphysics applications require to transfer CONSTANT MONOMIAL variables.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/12245, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1JMUhQf21B32az024NWyBEwtilPg3Uks5uhTULgaJpZM4XHCDd .
vincentlaboure
permcody
Rationale
Two defects are being reported in this issue. It looks like: 1)
MultiAppMeshFunctionTransferdoes not work appropriately with CONSTANT MONOMIAL if the master mesh is more refined than the subapp mesh (even if the latter is strictly included in the former). More specifically, it seems that the transfer is not conservative which is surprising since the projection should be pretty straightforward.2)
MultiAppNearestNodeTransferdoes not work appropriately with CONSTANT MONOMIAL (regardless of the refinement). In that case, the transferred field is zero everywhere... Yet, the source code seems to cover the!is_nodalcase.Description
To reproduce the errors:
1) Go here and run the master file (may need to change
MultiApps/sub_app/app_type). The subapp postprocessorpwr_density_avgreturns 4.75 while it should be 5 (not conservative). IfMesh/uniform_refineis set to 1, the expected value is obtained.2) Run the same input files as before but change
Transfers/to_sub_power_density/typetoMultiAppNearestNodeTransfer. Both subapp postprocessors (power_density_maxandpwr_density_avg) return zero. The same result is obtained regarless ofMesh/uniform_refine.Impact
Both of these are problematic because some multiphysics applications require to transfer CONSTANT MONOMIAL variables.