Periodic boundary condition for L2_Lagrange variable?

[Daniel Wojtaszek]

Is there a way to have periodic boundary conditions on an L2_Lagrange variable? Using the following BC works for Lagrange variable but not L2_Lagrange:

[BCs]
 [./Periodic]
   [./top]
     variable = u
     primary = top
     secondary = bottom
     translation ='0  0  -15'
   [../]
 [../]
[]

Cheers.

Dan

[Daniel Wojtaszek]

Here is the full input in case more details are required to answer my question:

velc = 2.0

#vel = 1.0

[Mesh]

  type = FileMesh

    file = flow_test.e

    parallel_type = distributed

[]

[Variables]

    [./dnp_lo]

        #block = 'core up out'

        family = L2_LAGRANGE

        order = FIRST

    [../]

    

[]

[ICs]

    [./ic_up]

        type = ConstantIC

        variable = dnp_lo

        block = 'middle'

        value = 10

    [../]

    

    [./ic_out]

        type = ConstantIC

        variable = dnp_lo

        block = 'bottom top'

        value = 5.0

    [../]

[]

[BCs]

    [./Periodic]

        [./top]

            variable = dnp_lo

            primary = top

            secondary = bottom

            translation = '0 0 -15'

        [../]

    [../]

    

    

    [./bc_out]

        type = AdvectionBC

        variable = dnp_lo

        boundary = top

        velocity_vector = '0 0 ${velc}'

    [../]

#    

    [./bc_in]

        type = AdvectionBC

        variable = dnp_lo

        boundary = bottom

        velocity_vector = '0 0 ${velc}'

        outflow = False

    [../]

[]

[Kernels]

    [./dotlo]

        type = TimeDerivative

        variable = dnp_lo

        

    [../]

  [./dnp_flow]

    type = ConservativeAdvection

    variable = dnp_lo

    velocity = '0 0 ${velc}'

  [../]

  

[]

[DGKernels]

  [./DGdnp_flow]

    type = DGConvection

    variable = dnp_lo

    velocity = '0 0 ${velc}'

  [../]

[]

[Executioner]

  type = Transient

  start_time = 0.0

  end_time = 5.0

  #num_steps = 3

  dt = 0.1

  nl_abs_tol = 1e-6

  solve_type = NEWTON

#  petsc_options_iname = '-pc_type -pc_hypre_type -ksp_gmres_restart'

#  petsc_options_value = 'hypre boomeramg 100'

  l_tol = 1e-1

[]

[Outputs]

  exodus = true

  csv = true

  #perf_graph = true

[]

[Alexander Lindsay]

Daniel,

Please see the reply below.

If you really want to do this, then we may consider using mortar.

Alex

---------- Forwarded message ---------
From: Stogner, Roy H <roys...@ices.utexas.edu>
Date: Tue, May 28, 2019 at 3:45 PM
Subject: Re: [Libmesh-users] Fwd: Periodic boundary condition for L2_Lagrange variable?
To: Alexander Lindsay <alexlin...@gmail.com>
Cc: libmesh-users <libmes...@lists.sourceforge.net>

On Mon, 27 May 2019, Alexander Lindsay wrote:

> Does it make sense/do we have the machinery to do periodic boundary
> conditions with discontinuous variables like the user below is asking for?

We don't even do internal continuity with discontinuous variables;
naturally we're not going to do continuity across domain boundaries.

Typically if you're using a discontinuous variable you expect
discontinuities, right?  If you actually do try to pin the value of
the variable to be exactly equal from one side of an interface to the
other, you end up killing your convergence: at best you've created an
effective "element" of size 2h and at worst you've screwed up
consistency.

If you have a mesh that matches up across a periodic boundary (as you
have to for libMesh PeriodicBoundary stuff to make sense even in the
C0 case), then ideally what you want to do is add interface terms to
your formulation to give the same sort of weak continuity enforcement
across boundary sides that you'd normally use between interior
neighbors; basically instead of skipping boundary sides in that loop
you check to see if they're periodic boundary sides and you use the
periodic neighbor for whatever jump/flux/etc terms are in your weak
equations.

> Maybe this is a use case for a face-face type discretization like mortar...

If you don't have a mesh that matches up perfectly across the
boundary, then I think mortar methods may be the way to go.
---
Roy

[Daniel Wojtaszek]

Thanks for your reply.  So when you say mortar methods, do you mean constraints such as EqualValueConstraint? I had tried using this constraint, but moose gives an error that it is expecting the name of an interface, but there is no mention of this parameter in the Source or input file syntax pages.

Cheers.

[Alexander Lindsay]

How recent is your moose? Mortar just underwent a total overhaul in https://github.com/idaholab/moose/pull/13056

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/af4c3aa1-699a-44d7-a25c-c4a3a9262297%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Lindsay]

If you pull down a recent moose, you can find an example of using mortar of periodic boundary conditions (admittedly for a continuous variable) here.

[Daniel Wojtaszek]

Thanks.  I can now successfully run that example.  I'm now trying to apply the equalvalueconstraint in a 3D problem, but get  an error: "Invalid shape function index i = 2".  I've attached the mesh and model file.  Note that I adapted periodic.i from the example to read in a 3D mesh.

Any suggestions on how to get this working?

Cheers.

Dan

On Wednesday, May 29, 2019 at 12:18:14 PM UTC-4, Alexander Lindsay wrote:

If you pull down a recent moose, you can find an example of using mortar of periodic boundary conditions (admittedly for a continuous variable) here.

On Wed, May 29, 2019 at 10:11 AM Alexander Lindsay <alexlin...@gmail.com> wrote:

How recent is your moose? Mortar just underwent a total overhaul in https://github.com/idaholab/moose/pull/13056

To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

[Alexander Lindsay]

Sorry, I probably should have said up front that mortar cannot currently be done in 3D. I've made that a little more explicit in https://github.com/idaholab/moose/pull/13761. Hopefully in the not too distant future we will get around to making 3D work.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/7163b62d-0436-475f-baa8-896a26115acf%40googlegroups.com.