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

Questions on the subroutine fluxsv #166

Closed
xinshengqin opened this issue Aug 7, 2016 · 8 comments
Closed

Questions on the subroutine fluxsv #166

xinshengqin opened this issue Aug 7, 2016 · 8 comments

Comments

@xinshengqin
Copy link
Contributor

Can anybody tell me what fluxsv(mptr, xfluxm, xfluxp, yfluxm, yfluxp, ...listbc, ...) do?
This is how I interpret it:
Suppose a grid mptr is a level L grid. For all cells of the grid mptr that are adjacent to the border of all level L+1 grids encompassed by the grid mptr, we assign a block of memory (part of the alloc() array), index information of which is stored in the array listbc(), to store the conservation fix-up that will be applied to these cells later in upbnd() subroutine. In fluxsv(), xfluxm, xfluxp, yfluxm, yfluxp are fluxes at the edges of the grid mptr and they are added to the block of memory described above for later conservation fix-up.
My question is:
These fluxes have already been used to update solution q in all cells of the grid mptr in stepgrid.f(), including cells that needs conservation fix-up later. Why do we store them in alloc() for conservation fix-up? Doesn't this apply the flux to those cells for twice?
Thanks!

@mjberger
Copy link
Contributor

mjberger commented Aug 7, 2016

Shawn,

The coarse fluxes are saved to subtract them, and the fine fluxes are added, to change the solution on level L cells that border level L+! grids.

On Aug 6, 2016, at 10:30 PM, Shawn Qin notifications@github.com wrote:

Can anybody tell me what fluxsv(mptr, xfluxm, xfluxp, yfluxm, yfluxp, ...listbc, ...) do?
This is how I interpret it:
Suppose a grid mptr is a level L grid. For all cells of the grid mptr that are adjacent to the border of all level L+1 grids encompassed by the grid mptr, we assign a block of memory (part of the alloc() array), index information of which is stored in the array listbc(), to store the conservation fix-up that will be applied to these cells later in upbnd() subroutine. In fluxsv(), xfluxm, xfluxp, yfluxm, yfluxp are fluxes at the edges of the grid mptr and they are added to the block of memory described above for later conservation fix-up.
My question is:
These fluxes have already been used to update solution q in all cells of the grid mptr in stepgrid.f(), including cells that needs conservation fix-up later. Why do we store them in alloc() for conservation fix-up? Doesn't this apply the flux to those cells for twice?
Thanks!


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #166, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1DC8H4DgG8nwn3SNAJ_4lwXpNHgwR3ks5qdW2IgaJpZM4Jebkx.

@xinshengqin
Copy link
Contributor Author

I see. Now that make sense to me. Thank you, Marsha.
I have another question based on this:
Suppose we are working with grid mptr of level L. fluxad() is called to add fluxes at the interface between grid mptr and a level L-1 grid that encompass grid mptr. These correction fluxes are stored at alloc(node(ffluxptr, mptr)). But as I understand, qad() has also added correction fluxes at these interfaces at alloc(node(ffluxptr,mptr)). Are qad() and fluxad() doing the same job? To me, they are both adding fine fluxes.

@xinshengqin
Copy link
Contributor Author

UPDATE:
I just found that in the qad.f file, there is a comment saying:
"for GeoClaw we skip this routine --- need to fix someday"
But I think qad() is still called in par_advance()?

@mandli
Copy link
Member

mandli commented Aug 8, 2016

I don't think qad() is skipped but the src1d routine might be. That routine deals with conservative fixups at the boundaries of different level grids.

@mandli
Copy link
Member

mandli commented Aug 8, 2016

Also see [1] for explanation of what it is doing and why it is needed.

  1. Berger, M. J. & LeVeque, R. J. Adaptive Mesh Refinement Using Wave-Propagation Algorithms for Hyperbolic Systems. SIAM Journal on Numerical Analysis 35, 2298–2316 (1998).

@xinshengqin
Copy link
Contributor Author

I have read that paper before. The general idea in the paper is that a Riemman problem between coarse cell value and fine cell value at the boundary of different level grids should be solved to obtain "fluctuation" at the boundary, which is added to the coarse cell adjacent to the boundary as a conservation fix-up.
Another way of doing the conservation fix-up should be subtracting coarse fluxes and adding fine fluxes near the interface, which is done by fluxsv() and fluxad().
But as I understand, the conservation fix-up can be done using either (not both) way above?

@mandli
Copy link
Member

mandli commented Aug 8, 2016

My memory is that qad performs the additional Riemann solves required by the jump in resolution while the other fluxes are used around all of the grids. What is saved should only be leaving (entering the grids) from fluxsv() and fluxad() while qad performs the extra operations.

@xinshengqin
Copy link
Contributor Author

I see. Thanks, Kyle! I will try to dig deeper to see how they work exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants