<div dir="ltr"><div dir="ltr">On Tue, Jul 14, 2020 at 5:47 AM MUKKUND SUNJII <<a href="mailto:mukkundsunjii@gmail.com">mukkundsunjii@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Greetings, </div><div><br></div><div>This message is again in relation to the previous series of exchanges I had with the PETSc development team and professors. </div><div><br></div><div>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 <span style="color:rgb(0,0,0)">*fluxR[]</span>) 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. </div><div><br></div><div>I might have accidentally found the solution while trying to figure out the origin of the problem. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Thank you very much in advance. </div></div></blockquote><div><br></div><div>That is a very clear description. That will really help us figure out what is happening.</div><div><br></div><div>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</div><div>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</div><div>it is the same flux when viewed from either side.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Regards, </div><div><br></div><div>Mukkund</div><div><br></div><br><blockquote type="cite"><div>Begin forwarded message:</div><br><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>From: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">MUKKUND SUNJII <<a href="mailto:mukkundsunjii@gmail.com" target="_blank">mukkundsunjii@gmail.com</a>><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>Subject: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif"><b>Re: [petsc-users] Regarding P4est</b><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>Date: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">17 June 2020 at 21:20:29 CEST<br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>To: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Mark Adams <<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>Cc: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>>, Domenico Lahaye <<a href="mailto:D.J.P.Lahaye@tudelft.nl" target="_blank">D.J.P.Lahaye@tudelft.nl</a>><br></span></div><br><div><div style="overflow-wrap: break-word;">Yes, precisely! I am not sure how I can replicate using the original version of ex11.c because it does not support bathymetry. <div><br></div><div>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 </div><div><br></div><div>1) Bathymetry.png : It shows you the bathymetry profile (z(x)) and the water surface height (H = h+z(x)) at t = 0.</div><div><img id="gmail-m_-9154686824536798956B4B044BF-9005-4C27-B700-6B6BBF9D4682" src="cid:1734cd3d31ee98675d81"></div><div><br></div><div>2) Plex.png : This is the water surface height after 1 time step (<span style="color:rgb(12,255,0);font-family:"Andale Mono";background-color:rgba(255,255,255,0.9)">0.007055 sec</span>)  and the dm type is Plex. As you can see, the water surface height is undisturbed as expected.</div><div><img id="gmail-m_-91546868245367989564966DB14-E920-468E-9F7B-DF370908BF29" src="cid:1734cd3d31e7a8a1b8a2"></div><div><br></div><div>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. <span style="white-space:pre-wrap">      </span><br><div><img id="gmail-m_-9154686824536798956E5271AAD-474F-42A5-A8F1-76B1C3BEF792" src="cid:1734cd3d31ea1399f7d3"></div><div><br></div><div>Maybe this paints a better picture. </div><div><br></div><div>Regards, </div><div><br></div><div>Mukkund </div><div><br></div><div>For your reference, the Riemann Solver is a modified version of the HLL solver: <span><b>A simple well-balanced and positive numerical scheme for the shallow-water system by </b></span><b>Emmanuel Audusse, Christophe Chalons, Philippe Ung. </b></div><div>(<a href="https://www.intlpress.com/site/pub/files/_fulltext/journals/cms/2015/0013/0005/CMS-2015-0013-0005-a011.pdf" target="_blank">https://www.intlpress.com/site/pub/files/_fulltext/journals/cms/2015/0013/0005/CMS-2015-0013-0005-a011.pdf</a>)</div><span><br><blockquote type="cite">On 17 Jun 2020, at 20:47, Mark Adams <<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>> wrote:<br><br>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.<br><br>I don't know of any difference from p4est on a non-adapted grid. Can you reproduce this with ex11?<br><br>Matt and Toby could answer this better.<br><br><br>On Wed, Jun 17, 2020 at 1:33 PM MUKKUND SUNJII <<a href="mailto:mukkundsunjii@gmail.com" target="_blank">mukkundsunjii@gmail.com</a>> wrote:<br>Greetings, <br><br>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. <br><br>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 <br><br>(forest->transfervec)(dmIn,vecIn,dmOut,vecOut,useBCs,time). <br><br>Any information on this particular routine is highly appreciated.<br><br>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. <br><br>Thank you for all of your suggestions! <br><br>Regards, <br><br>Mukkund </blockquote></span></div></div></div></blockquote></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>