[petsc-users] Regarding P4est

Thu Jun 18 13:13:23 CDT 2020

I agree with your points. 

It could be the case there might be some mapping error. Although I am not quite sure how to narrow down the problem. 

In any case, thank you for your valuable suggestions. 

>>>> 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). 

Unfortunately, my first question still remains a mystery. Hopefully, someone could take a few moments to point me in the right direction. 

Regards, 

Mukkund 

> On 18 Jun 2020, at 08:19, Dave May <dave.mayhem23 at gmail.com> wrote:
> 
> 
> 
> On Thu 18. Jun 2020 at 01:20, Mark Adams <mfadams at lbl.gov <mailto:mfadams at lbl.gov>> wrote:
> PETSc does take pains to keep it clean in Valgrind, to make it more useful ...
> 
> Yes of course!
> 
> As I understood, the code being discussed was derived / based on ex11, and not identical to ex11 (eg flux definitions have changed). Hence there’s some user code in the mix which is not guaranteed to be valgrind clean.
> 
> 
> 
> 
> 
> And yes there is tree structure to this error, and p4est is a tree code.
> 
> Try with uniform bathymetry, maybe your mapping is messed up by some recording by p4est.
> 
> 
> On Wed, Jun 17, 2020 at 6:47 PM MUKKUND SUNJII <mukkundsunjii at gmail.com <mailto:mukkundsunjii at gmail.com>> wrote:
> No, I have not checked it using Valgrind. Perhaps it will help me trace the problem. 
> 
> Regards, 
> 
> Mukkund
> 
>> On 18 Jun 2020, at 00:43, Dave May <dave.mayhem23 at gmail.com <mailto:dave.mayhem23 at gmail.com>> wrote:
>> 
>> Is the code valgrind clean?
>> 
>> On Wed, 17 Jun 2020 at 23:25, MUKKUND SUNJII <mukkundsunjii at gmail.com <mailto:mukkundsunjii at gmail.com>> wrote:
>> 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. 
>> 
>> Nevertheless it is indeed strange that the problem disappears when I use a PLEX dm.
>> 
>> Regards, 
>> 
>> Mukkund  
>> 
>>> On 17 Jun 2020, at 22:53, Dave May <dave.mayhem23 at gmail.com <mailto:dave.mayhem23 at gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> On Wed 17. Jun 2020 at 21:21, MUKKUND SUNJII <mukkundsunjii at gmail.com <mailto:mukkundsunjii at gmail.com>> wrote:
>>> 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>
>>> 
>>> 
>>> 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.
>>> 
>>> Thanks,
>>> Dave
>>> 
>>> 
>>> 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 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200618/28cde56d/attachment.html>