[petsc-users] Regarding Mapping

Tue Jul 14 14:30:24 CDT 2020

Greetings, 

Thank you for your reply. 

You are right in your intuition about the Finite Volume Method. In the case of no bathymetry, this is not required as the fluxes stay the same on both the sides of the interface. However, with the bathymetry terms, the bed slope terms are also accounted into the Riemann Solver. However, in order to keep the model well-balanced, the left and right flux differ by the wave speeds as indicated by the equations in the diagram (see attachment). 

Perhaps, this is more of a localised requirement for my problem but other models might feature the same formulation. 

Regards, 

Mukkund 

> On 14 Jul 2020, at 12:19, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Tue, Jul 14, 2020 at 5:47 AM MUKKUND SUNJII <mukkundsunjii at gmail.com <mailto:mukkundsunjii at gmail.com>> wrote:
> Greetings, 
> 
> This message is again in relation to the previous series of exchanges I had with the PETSc development team and professors. 
> 
> To not be repetitive I will provide a concise description for those unaware. I have built a well-balanced shallow water solver based on ts/tutorials/ex11.c. However, the Riemann Solver that I have written includes the topography terms. To be well-balanced, I have made a change in the Riemann Solver interface in fv.c: Before the change it computes only one flux vector (*flux[]). But now with my modification, it computes 2 flux terms (*fluxL[] and *fluxR[]) and it is assigned to the left and right side of the interface respectively. The exact description of the problem itself is mentioned in the thread below. 
> 
> I might have accidentally found the solution while trying to figure out the origin of the problem. 
> 
> I noticed that the solver is no longer well-balanced (when running the adaptive mesh refinement case) when I use -dm_refine to prescribe the refinement level of the initial grid. I understand now, that the ‘noise' all across the domain is indeed caused by the wrong mapping of the left and right fluxes at the interface by my modification in fv.c. 
> 
> However, interestingly, the solver becomes well-balanced (i.e., the mapping is correct again) when I use -dm_forest_initial_refinement instead. I have tested various cases with water completely at rest to verify the well-balancedness of the solver while using DM of type p4est. 
> 
> I thought this observation might be interesting to you as I see some of the AMR test cases in ex11.c use -dm_refine and some others use -dm_forest_initial_refinement. My knowledge on P4est and DMPlex is lacking to explain the discrepancy between the two. Perhaps, someone else can shine light on this matter. 
> 
> Thank you very much in advance. 
> 
> That is a very clear description. That will really help us figure out what is happening.
> 
> For people like me who do not really understand FV methods, can you briefly explain why we would have 2 fluxes? The simple way I think
> about things, in FV you consider the state in 2 adjacent cells and then determine a flux between them, which can be positive or negative, but
> it is the same flux when viewed from either side.
> 
>   Thanks,
> 
>      Matt
>  
> Regards, 
> 
> Mukkund
> 
> 
>> Begin forwarded message:
>> 
>> From: MUKKUND SUNJII <mukkundsunjii at gmail.com <mailto:mukkundsunjii at gmail.com>>
>> Subject: Re: [petsc-users] Regarding P4est
>> Date: 17 June 2020 at 21:20:29 CEST
>> To: Mark Adams <mfadams at lbl.gov <mailto:mfadams at lbl.gov>>
>> Cc: petsc-users <petsc-users at mcs.anl.gov <mailto:petsc-users at mcs.anl.gov>>, Domenico Lahaye <D.J.P.Lahaye at tudelft.nl <mailto:D.J.P.Lahaye at tudelft.nl>>
>> 
>> Yes, precisely! I am not sure how I can replicate using the original version of ex11.c because it does not support bathymetry. 
>> 
>> Regardless, to demonstrate the discrepancy, I have uploaded three plots. The scenario is a lake at rest. Essentially, you have a varying bathymetry but a level water surface. If the model is well balanced, then the water surface height must not change. The description of the files are below 
>> 
>> 1) Bathymetry.png : It shows you the bathymetry profile (z(x)) and the water surface height (H = h+z(x)) at t = 0.
>> <Bathymetry.png>
>> 
>> 2) Plex.png : This is the water surface height after 1 time step (0.007055 sec)  and the dm type is Plex. As you can see, the water surface height is undisturbed as expected.
>> <Plex.png>
>> 
>> 3) P4est.png : This is the result after 1 time step (same final time) if I set the dm type as p4est. The noise is in the order of 1e-3 to be a little more specific. Since its not specifically at the boundaries and more or less spread throughout, it could indeed be noise introduced. But of course I could be wrong. 	
>> <p4est.png>
>> 
>> Maybe this paints a better picture. 
>> 
>> Regards, 
>> 
>> Mukkund 
>> 
>> For your reference, the Riemann Solver is a modified version of the HLL solver: A simple well-balanced and positive numerical scheme for the shallow-water system by Emmanuel Audusse, Christophe Chalons, Philippe Ung. 
>> (https://www.intlpress.com/site/pub/files/_fulltext/journals/cms/2015/0013/0005/CMS-2015-0013-0005-a011.pdf <https://www.intlpress.com/site/pub/files/_fulltext/journals/cms/2015/0013/0005/CMS-2015-0013-0005-a011.pdf>)
>> 
>>> On 17 Jun 2020, at 20:47, Mark Adams <mfadams at lbl.gov <mailto:mfadams at lbl.gov>> wrote:
>>> 
>>> So you get this noise with a regular grid in p4est. So the same grid as will Plex, and you are not getting the same results.
>>> 
>>> I don't know of any difference from p4est on a non-adapted grid. Can you reproduce this with ex11?
>>> 
>>> Matt and Toby could answer this better.
>>> 
>>> 
>>> On Wed, Jun 17, 2020 at 1:33 PM MUKKUND SUNJII <mukkundsunjii at gmail.com <mailto:mukkundsunjii at gmail.com>> wrote:
>>> Greetings, 
>>> 
>>> I am a master’s student working on the shallow water model of the TS example 'ex11.c' as part of my thesis. Therefore, I am working with DMForest for the implementation of adaptive grids. I have a question and an observation. 
>>> 
>>> I am trying to find relevant information about interpolation that takes place through the routine DMForestTransferVec. Perhaps it could be my inability to find it, but I am unable to locate the implementation of the routine 
>>> 
>>> (forest->transfervec)(dmIn,vecIn,dmOut,vecOut,useBCs,time). 
>>> 
>>> Any information on this particular routine is highly appreciated.
>>> 
>>> Furthermore, I have developed a well balanced Riemann Solver that includes topography in the model. In the process of testing both the non-adaptive and adaptive version, I found that my results differed when I changed the type of DM. For instance, when I run a scenario in a fixed, non-adaptive grid  with a DM of type 'P4est', I find that the well balanced nature is lost due to small perturbations all across the domain. However, this does not occur when I use a DM of type ‘plex’. Is there a radical change in the routines between the two DM’s? This is not as much of a question as it is an observation. 
>>> 
>>> Thank you for all of your suggestions! 
>>> 
>>> Regards, 
>>> 
>>> Mukkund 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200714/e613a2c8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2020-07-14 at 20.55.11.png
Type: image/png
Size: 128664 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200714/e613a2c8/attachment-0001.png>