[petsc-users] Regarding P4est

[Mark Adams]

PETSc does take pains to keep it clean in Valgrind, to make it more
useful ...

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>
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> wrote:
>
> Is the code valgrind clean?
>
> On Wed, 17 Jun 2020 at 23:25, MUKKUND SUNJII <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> wrote:
>>
>>
>>
>> On Wed 17. Jun 2020 at 21:21, MUKKUND SUNJII <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
>>> )
>>>
>>> On 17 Jun 2020, at 20:47, Mark Adams <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>
>>> 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/20200617/4d947d30/attachment.html>