Skip to content
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

Closed
vincentlaboure opened this issue Feb 21, 2019 · 6 comments
Closed

Conservative transfers #12948

vincentlaboure opened this issue Feb 21, 2019 · 6 comments
Labels
C: Framework T: task An enhancement to the software.

Comments

@vincentlaboure
Copy link
Contributor

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.

@permcody permcody added C: Framework P: critical T: task An enhancement to the software. labels Feb 21, 2019
@YaqiWang
Copy link
Contributor

My understanding: what @vincentlaboure wants are two more parameters in the transfer base class

postprocessor_to_be_preserved_on_master_side = 'pp_on_master'
postprocessor_to_be_preserved_on_subapp_side = 'pp_on_subapp'

When a transfer is done, on the to transfer side, do a postprocessor evaluation, get one scalar value v2, then use the ratio between the from transfer side postprocessor value v1 and v2 as a scaling factor to redo the transfer (assuming v2 is linear). This sounds simple but can be quite complicated.

@fdkong
Copy link
Contributor

fdkong commented Mar 12, 2019

Looks like we need to execute postprocessor twice. But we only trigger this when users speficy to use the conservative transfer.

fdkong added a commit to fdkong/moose that referenced this issue Mar 13, 2019
fdkong added a commit to fdkong/moose that referenced this issue Mar 13, 2019
that uses MultiAppCopyTransfer. But the code should work for other field transferes

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Mar 21, 2019
fdkong added a commit to fdkong/moose that referenced this issue Mar 21, 2019
that uses MultiAppCopyTransfer. But the code should work for other field transferes

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Mar 21, 2019
fdkong added a commit to fdkong/moose that referenced this issue Mar 21, 2019
the caculations can be reused for several interpolation transfers

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Mar 21, 2019
the caculations can be reused for several interpolation transfers

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Mar 22, 2019
fdkong added a commit to fdkong/moose that referenced this issue Mar 22, 2019
that uses MultiAppCopyTransfer. But the code should work for other field transferes

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Mar 22, 2019
fdkong added a commit to fdkong/moose that referenced this issue Mar 22, 2019
the caculations can be reused for several interpolation transfers

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Mar 22, 2019
@vincentlaboure
Copy link
Contributor Author

@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
Sub app defined for 0 < x < 0.5, 0 < y < 1; block 10 for 0.2 < x < 0.3 and 0.2 < y < 0.8, block 11 otherwise
Two sub abbs: positions = '0 0 0 0.5 0 0'

The goal would be to:

  • Transfer power density field p from master app block 0 to sub app 0, block 10 such that \int_{master, block 0} p dx = \int_{sub0, block 10} p dx

  • Transfer power density field p from master app block 1 to sub app 1, block 10 such that \int_{master, block 1} p dx = \int_{sub1, block 10} p dx

  • Transfer power density field q from sub app 0, block 10 to master app block 0 such that \int_{master, block 0} q dx = \int_{sub0, block 10} q dx

  • Transfer power density field p from sub app 1, block 10 to master app block 1 such that \int_{master, block 1} q dx = \int_{sub1, block 10} q dx

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.

@fdkong
Copy link
Contributor

fdkong commented Apr 1, 2019

@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
Sub app defined for 0 < x < 0.5, 0 < y < 1; block 10 for 0.2 < x < 0.3 and 0.2 < y < 0.8, block 11 otherwise
Two sub abbs: positions = '0 0 0 0.5 0 0'

The goal would be to:

  • Transfer power density field p from master app block 0 to sub app 0, block 10 such that \int_{master, block 0} p dx = \int_{sub0, block 10} p dx
  • Transfer power density field p from master app block 1 to sub app 1, block 10 such that \int_{master, block 1} p dx = \int_{sub1, block 10} p dx
  • Transfer power density field q from sub app 0, block 10 to master app block 0 such that \int_{master, block 0} q dx = \int_{sub0, block 10} q dx
  • Transfer power density field p from sub app 1, block 10 to master app block 1 such that \int_{master, block 1} q dx = \int_{sub1, block 10} q dx

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.

@vincentlaboure
Copy link
Contributor Author

@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.

@vincentlaboure
Copy link
Contributor Author

The input files are here

fdkong added a commit to fdkong/moose that referenced this issue Apr 10, 2019
fdkong added a commit to fdkong/moose that referenced this issue Apr 10, 2019
that uses MultiAppCopyTransfer. But the code should work for other field transferes

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Apr 10, 2019
fdkong added a commit to fdkong/moose that referenced this issue Apr 10, 2019
the caculations can be reused for several interpolation transfers

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue Apr 10, 2019
fdkong added a commit to fdkong/moose that referenced this issue Apr 18, 2019
fdkong added a commit to fdkong/moose that referenced this issue Apr 18, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
The pps works for the conservative transfer now

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
its value is right with updated solution

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
the master mesh so that the test is more meaningful

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
instead of from_postprocessor_to_be_preserved

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 16, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
that uses MultiAppCopyTransfer. But the code should work for other field transferes

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
the caculations can be reused for several interpolation transfers

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
The pps works for the conservative transfer now

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
its value is right with updated solution

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
the master mesh so that the test is more meaningful

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
instead of from_postprocessor_to_be_preserved

Refs idaholab#12948
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 17, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 20, 2019
fdkong added a commit to fdkong/moose that referenced this issue May 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework T: task An enhancement to the software.
Projects
None yet
Development

No branches or pull requests

4 participants