[petsc-users] 2 Dirichlet conditions for one Element in PetscFE

Yann Jobic yann.jobic at univ-amu.fr
Fri Nov 24 09:13:34 CST 2017


Hello,

I tried the "next" branch  from the git repository.
The function PetscDSAddBoundary correctly set the boundary values, but 
there is still the bug of the boundary applied to the whole element.
I'll dig a little in DMPlexVecSetFieldClosure_Internal() of 
knepley/fix-plex-bc-multiple where the possible bug should be.

I now use a simple Poisson FE test case in order to check the boundaries.

I hope these details helps a little...

Regards,

Yann


Le 24/11/2017 à 11:34, Yann Jobic a écrit :
> Le 23/11/2017 à 13:45, Matthew Knepley a écrit :
>> On Thu, Nov 23, 2017 at 3:39 AM, Yann Jobic <yann.jobic at univ-amu.fr 
>> <mailto:yann.jobic at univ-amu.fr>> wrote:
>>
>>     Hello,
>>
>>     I checked out  the branch knepley/fix-plex-bc-multiple, but i now
>>     have a strange problem.
>>     I splited my labels as in ex69.c of snes. It may be the right way
>>     to do it.
>>     In petsc 3.8.2, i have the same behavior as before, the element
>>     containing the face is called by PetscDSAddBoundary.
>>     In the git version, PetscDSAddBoundary does not call my boundary
>>     function at all.
>>     The call :
>>       ierr = PetscDSAddBoundary(prob, DM_BC_ESSENTIAL, "wallL",
>>     "markerLeft",   0, Ncomp, components, (void (*)(void)) uIn,  1,
>>     &id, ctx);CHKERRQ(ierr);
>>
>>     I checked that my labels are correct :
>>       markerLeft: 1 strata with value/size (1 (11))
>>       markerTop: 1 strata with value/size (1 (11))
>>       markerRight: 1 strata with value/size (1 (11))
>>       markerBottom: 1 strata with value/size (1 (11))
>>
>>     What am i doing wrong ?
>>
>>
>> So you call AddBoundary() and then the boundary values are never 
>> inserted? The call looks correct. Can you send me an example to check?
>> Obviously this works for my simple examples in the repo. I can't see 
>> by looking what might be wrong for you.
> Hello,
> I may have the wrong git directory.
> I've got the message when i'm compiling :
> The version of PETSc you are using is out-of-date, we recommend 
> updating to the new release
>  Available Version: 3.8.2   Installed Version: 3.8
>
> As i'm not familiar with git, I've done :
> git clone https://bitbucket.org/petsc/petsc
> git checkout knepley/fix-plex-bc-multiple
>
> With this petsc version, ex46 and ex47 are not working (from TS), and 
> after calling PetscDSAddBoundary, it seems that the boundary values 
> are never inserted, as in my own code.
>
> Do i have the right petsc development version ?
>
> Thanks,
>
> Regards,
>
> Yann
>
> PS : In my old code, i've tried to mix ex56 and ex69 for marking 
> boundary values.
> I first set labels for "Faces", and using this label, i create new 
> separated ones (North, South, ...).
> It worked in sequential, but in parallel, the program hang at 
> DMPlexCreateClosureIndex.
> So i just kept "Faces", as in ex56, and it worked in parallel.
>
>>
>>   Thanks,
>>
>>     Matt
>>
>>     Thanks,
>>
>>     Regards,
>>
>>     Yann
>>
>>     Le 22/11/2017 à 18:51, Matthew Knepley a écrit :
>>>     On Wed, Nov 22, 2017 at 12:39 PM, Yann Jobic
>>>     <yann.jobic at univ-amu.fr <mailto:yann.jobic at univ-amu.fr>> wrote:
>>>
>>>         Hello,
>>>
>>>         I've found a strange behavior when looking into a bug for
>>>         the pressure convergence of a simple Navier-Stokes problem
>>>         using PetscFE.
>>>
>>>         I followed many examples for labeling boundary faces. I
>>>         first use DMPlexMarkBoundaryFaces, (label=1 to the faces).
>>>         I find those faces using DMGetStratumIS and searching 1 as
>>>         it is the value of the marked boundary faces.
>>>         Finally i use DMPlexLabelComplete over the new label.
>>>         I then use :
>>>           ierr = PetscDSAddBoundary(prob, DM_BC_ESSENTIAL, "in",
>>>         "Faces", 0, Ncomp, components, (void (*)(void)) uIn, NWest,
>>>         west, NULL);CHKERRQ(ierr);
>>>         in order to impose a dirichlet condition for the faces
>>>         labeled by the correct value (west=1, south=3,...).
>>>
>>>         However, the function "uIn()" is called in all the Elements
>>>         containing the boundary faces, and thus impose the values at
>>>         nodes that are not in the labeled faces.
>>>         Is it a normal behavior ? I then have to test the position
>>>         of the node calling uIn, in order to impose the good value.
>>>         I have this problem for a Poiseuille flow, where at 2 corner
>>>         Elements i have a zero velocity dirichlet condition (wall)
>>>         and a In flow velocity one.
>>>
>>>
>>>     I believe I have fixed this in knepley/fix-plex-bc-multiple
>>>     which should be merged soon. Do you know how to merge that
>>>     branch and try?
>>>
>>>       Thanks,
>>>
>>>          Matt
>>>
>>>         The pressure is then very high at the corner nodes of those
>>>         2 Elements.
>>>         Do you think my pressure problem comes from there ? (The
>>>         velocity field is correct)
>>>
>>>         Many thanks,
>>>
>>>         Regards,
>>>
>>>         Yann
>>>
>>>         PS : i'm using those runtime options :
>>>         -vel_petscspace_order 2 -pres_petscspace_order 1 \
>>>         -ksp_type fgmres -pc_type fieldsplit -pc_fieldsplit_type
>>>         schur -pc_fieldsplit_schur_fact_type full  \
>>>         -fieldsplit_velocity_pc_type lu
>>>         -fieldsplit_pressure_ksp_rtol 1.0e-10
>>>         -fieldsplit_pressure_pc_type jacobi
>>>
>>>
>>>         ---
>>>         L'absence de virus dans ce courrier électronique a été
>>>         vérifiée par le logiciel antivirus Avast.
>>>         https://www.avast.com/antivirus
>>>         <https://www.avast.com/antivirus>
>>>
>>>
>>>
>>>
>>>     -- 
>>>     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.caam.rice.edu/%7Emk51/>
>>
>>
>>
>>
>>
>> -- 
>> 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.caam.rice.edu/%7Emk51/>
>
>

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


More information about the petsc-users mailing list