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

FV: add support for higher-order solution reconstruction #15066

Closed
rwcarlsen opened this issue Apr 14, 2020 · 3 comments · Fixed by #15825
Closed

FV: add support for higher-order solution reconstruction #15066

rwcarlsen opened this issue Apr 14, 2020 · 3 comments · Fixed by #15825
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@rwcarlsen
Copy link
Contributor

Reason

Various numerical flux methods and other FV bells-and-whistles benefit from or require having gradient approximations for mesh cells (i.e. _grad_u_left and _grad_u_right in fv kernels).

Design

Computing these gradients requires values from a cell's neighbors. This calculation should probably be initiated on-demand for FV variables when they are computing/setting the rest of the solution, gradient, etc. values. Then the variable could provide these values to kernels, bcs, etc. transparently just like objects usually get gradients. The FV variable could cash this value for the next time it is needed (since each cell's gradient info will be needed for every visit to a face of that cell). We will need to create a new "reconstruction" object that users can write custom versions of and enable/swap from input file syntax.

Impact

Should not affect existing APIs

@rwcarlsen rwcarlsen added T: task An enhancement to the software. P: normal A defect affecting operation with a low possibility of significantly affects. labels Apr 14, 2020
@YaqiWang
Copy link
Contributor

You may just use higher order variable to store this instead of cache. While FV may just work on the low order part and you can have a posprocessing function to recover the high order part. Just suggesting you an option. Cache is typically hard to manage and not transparent to users.

rwcarlsen added a commit to rwcarlsen/moose that referenced this issue May 5, 2020
@lindsayad lindsayad linked a pull request Oct 19, 2020 that will close this issue
1 task
@lindsayad
Copy link
Member

lindsayad commented Oct 21, 2020

@rwcarlsen to me there are couple different concepts here. There's the ability to (re)construct a gradient and then there's also the ability to construct a higher-order (e.g. non-constant) representation of the solution within a cell. #15825 has the gradient (re)construction but it does not do anything to construct a higher-order representation of the solution within a cell. That higher-order cell representation would be really useful I think at things like outflow boundaries where I do not simply want to use the cell center value as the face value, which would be implying a potentially inaccurate zero-gradient condition.

@rwcarlsen
Copy link
Contributor Author

Yeah - my description here really is about gradient reconstruction - even though the title is about solution reconstruction. They are related - obviously a higher order solution needs a reconstructed gradient. I'm just not sure that an explicit higher order solution reconstruction is the right angle to attack this from. With FV - everything revolves around numerical fluxes - so I would expect the numerical flux methods to incorporate the reconstructed gradient to compute whatever equivalent higher-order solution they might need. I think it might be better to have some helper utils/functions that make it easy for objects to get a "higher order" solution - utils that just use the reconstructed gradient. I think trying to do things through the variable objects would be a bit premature perhaps - at least until we have multiple concrete uses of this in the wild that could benefit from more than just some utils/funcs.

FY 21 NEAMS TH Pronghorn automation moved this from To do to Done Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.
Development

Successfully merging a pull request may close this issue.

4 participants