<div dir="ltr">PETSc does take pains to keep it clean in Valgrind, to make it more useful ...<div><br></div><div>And yes there is tree structure to this error, and p4est is a tree code.</div><div><br></div><div>Try with uniform bathymetry, maybe your mapping is messed up by some recording by p4est.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 6:47 PM MUKKUND SUNJII <<a href="mailto:mukkundsunjii@gmail.com">mukkundsunjii@gmail.com</a>> wrote:<br></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;">No, I have not checked it using Valgrind. Perhaps it will help me trace the problem. <div><br></div><div>Regards, </div><div><br></div><div>Mukkund<br><div><br><blockquote type="cite"><div>On 18 Jun 2020, at 00:43, Dave May <<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Is the code valgrind clean?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Jun 2020 at 23:25, MUKKUND SUNJII <<a href="mailto:mukkundsunjii@gmail.com" target="_blank">mukkundsunjii@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I agree with the structured nature of the noise. I did play around with the PetscFV implementation a bit to allow for the computation of different fluxes left and right side of every interface. <div><br></div><div>Nevertheless it is indeed strange that the problem disappears when I use a PLEX dm.</div><div><br></div><div>Regards, </div><div><br></div><div>Mukkund  <br><div><br><blockquote type="cite"><div>On 17 Jun 2020, at 22:53, Dave May <<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="ltr">On Wed 17. Jun 2020 at 21:21, MUKKUND SUNJII <<a href="mailto:mukkundsunjii@gmail.com" target="_blank">mukkundsunjii@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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><span id="gmail-m_-7976693154586197784gmail-m_160952809414734522cid:172c40d64737c2455aa1"><Bathymetry.png></span></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><span id="gmail-m_-7976693154586197784gmail-m_160952809414734522cid:172c40d6473c036c0142"><Plex.png></span></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><span id="gmail-m_-7976693154586197784gmail-m_160952809414734522cid:172c40d6473f0fb5d6c3"><p4est.png></span></div><div><br></div><div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">The (wrong) result has seemingly a lot of structure. Have you verified your code using p4est is valgrind clean? This looks too much like a weird indexing bug for me to not ask this question.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Dave</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><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></div></div><div><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></blockquote></div></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>