dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On 7/9/07, Anders Logg <logg@xxxxxxxxx> wrote:
> Matthew Knepley wrote:
> > On 7/9/07, Anders Logg <logg@xxxxxxxxx> wrote:
> >> It looks to me like the (quad) cell which first has vertices 1-2-5-4
> >> after the surgery has vertices 1-(0)-(2)-3. What are then the
> >
> > Yes.
> >
> >> coordinates of vertices (0) and (2)? Same as for 0 and 2, or same as
> >> original 2 and 5?
> >
> > Same as (0) and (2) since no other vertices actually exist in the mesh.
> > Those are vertices 0 and 2. I put them in parens to emphasize that I
> > was writing them twice, but they exist only once. Next time I will just
> > write the Sieves. Much clearer :)
> >
> >   Matt
>
> It still doesn't make sense to me, but maybe I'm just getting tired...
>
> If the coordinates of (0) and (2) are the same as those of 0 and 2,
> won't we get the wrong geometry for the cells on the boundary? Imagine
> having a much finer grid. Then the cells on the right boundary will
> stretch all the way back to touch the left boundary.

Yes, but that is why I put in the explanation for calculation of J. With the
exception of coordinate functions (which we can talk about after this),
you only need J or functions of it. Now, the Jacobian only depends on
coordinate differences. So you just need something like

 dx = (x_1 - x_0) mod L

where L is the periodic length.

 Matt

> /Anders
>
>
> >> /Anders
> >>
> >>
> >> Matthew Knepley wrote:
> >> > Not quite. I am suggesting changing the grid. For instance, lets use
> >> > the 3-lines mesh as an example. You start with
> >> >
> >> >  6--7--8
> >> >  |    |    |
> >> >  3--4--5
> >> >  |    |    |
> >> >  0--1--2
> >> >
> >> > and I suggest doing surgery to produce
> >> >
> >> >  4--5--(4)
> >> >  |    |     |
> >> >  2--3--(2)
> >> >  |    |     |
> >> >  0--1--(0)
> >> >
> >> > Notice that the edges on the far right are being shown twice. Thus,
> >> in the
> >> > second mesh there are 6 vertices, 10 edges, and 8 triangles. Then we
> >> > discretize on that mesh with my prescription for J.
> >> >
> >> >  Matt
> >> >
> >> > On 7/9/07, Anders Logg <logg@xxxxxxxxx> wrote:
> >> >> Matthew Knepley wrote:
> >> >> > On 7/9/07, Anders Logg <logg@xxxxxxxxx> wrote:
> >> >> >> Matthew Knepley wrote:
> >> >> >> > On 7/9/07, Anders Logg <logg@xxxxxxxxx> wrote:
> >> >> >> >> Good point, but I don't see how to do this in DOLFIN without
> >> a few
> >> >> >> major
> >> >> >> >> changes. For example, we assume that each vertex is
> >> associated to
> >> >> >> >> exactly one coordinate and the local-to-global mappings that FFC
> >> >> >> >> generate are computed in terms of the global number of vertices,
> >> >> edges
> >> >> >> >> etc.
> >> >> >> >
> >> >> >> > I think we can preserve those. Imagine discretizing a
> >> cylinder, but
> >> >> >> with
> >> >> >> > Cartesian coordinates.The connectivity will give the correct
> >> >> assembly.
> >> >> >>
> >> >> >> ok so far...
> >> >> >>
> >> >> >> > Our only problem is calculation of the Jacobian (I will ignore
> >> >> >> coordinate
> >> >> >> > functions for now). Since J only depends on coordinate
> >> >> differences, it
> >> >> >> > is enough to take differences mod L = \pi d. I have
> >> implemented this
> >> >> >> > for my thesis. It works well and I think its simpler to think
> >> about.
> >> >> >>
> >> >> >> But what about when it's not a cylinder? Say a mesh of the unit
> >> square
> >> >> >> and its not embedded in 3D.
> >> >> >
> >> >> > Not sure what you mean here. Everything I said goes through for a
> >> >> > discretization of
> >> >> >
> >> >> >   R^k \times S^{n-k}
> >> >> >
> >> >> > So basically the product of a box and a torus. Do you have something
> >> >> > more complicated?
> >> >> >
> >> >> >   Matt
> >> >>
> >> >> I'm just thinking of the very simple case of the unit square and you
> >> >> want u(0, y) = u(1, y). Then I think what you suggest is to let's
> >> number
> >> >> the vertices vertices (and edges) at x = 0 with the same indices as
> >> the
> >> >> vertices and edges at x = 1. Is this what you suggest?
> >> >>
> >> >> /Anders
> >> >>
> >> >>
> >> >> >> /Anders
> >> >> >>
> >> >> >>
> >> >> >> >  Matt
> >> >> >> >
> >> >> >> >> Perhaps one could postprocess the system to remove the rows
> >> with a
> >> >> >> >> single 1 on the diagonal (Dirichlet BCs) and the rows with a 1
> >> >> and -1
> >> >> >> >> (periodic BCs)?
> >> >> >> >>
> >> >> >> >> /Anders
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Matthew Knepley wrote:
> >> >> >> >> > This seems weird to me. When I want periodic boundary
> >> conditions,
> >> >> >> >> > I just make a periodic mesh. Anything else messes with the
> >> system
> >> >> >> >> > too much. Making a periodic mesh from a flat one is simple
> >> >> surgery.
> >> >> >> >> > I agree that you have to modify the computation of element
> >> >> geometry,
> >> >> >> >> > but that seems to right place to me to account for the
> >> embedding.
> >> >> >> >> >
> >> >> >> >> >  Matt
> >> >> >> >> >
> >> >> >> >> > On 7/9/07, Garth N. Wells <g.n.wells@xxxxxxxxxx> wrote:
> >> >> >> >> >>
> >> >> >> >> >> Quoting DOLFIN <dolfin@xxxxxxxxxx>:
> >> >> >> >> >>
> >> >> >> >> >> > One or more new changesets pushed to the primary dolfin
> >> >> >> repository.
> >> >> >> >> >> > A short summary of the last three changesets is included
> >> >> below.
> >> >> >> >> >> >
> >> >> >> >> >> > changeset:   3306:c70033cb881cb98ef8f177ebf0cb95348de96aa7
> >> >> >> >> >> > tag:         tip
> >> >> >> >> >> > user:        "Anders Logg <logg@xxxxxxxxx>"
> >> >> >> >> >> > date:        Mon Jul 09 19:24:50 2007 +0200
> >> >> >> >> >> > files:       Makefile.in aclocal.m4 configure
> >> src/Makefile.in
> >> >> >> >> >> > src/bench/Makefile.in src/bench/fem/Makefile.in
> >> >> >> >> >> src/bench/la/Makefile.in
> >> >> >> >> >> > src/bench/ode/Makefile.in src/demo/Makefile.in
> >> >> >> >> src/greeting/Makefile.in
> >> >> >> >> >> > src/kernel/Makefile.in src/kernel/common/Makefile.in
> >> >> >> >> >> > src/kernel/common/dolfin/Makefile.in
> >> >> >> src/kernel/elements/Makefile.in
> >> >> >> >> >> > src/kernel/elements/dolfin/Makefile.in
> >> >> >> >> >> src/kernel/fem/BoundaryCondition.cpp
> >> >> >> >> >> > src/kernel/fem/Makefile.am src/kernel/fem/Makefile.in
> >> >> >> >> >> > src/kernel/fem/PeriodicBoundaryCondition.cpp
> >> >> >> >> >> > src/kernel/fem/dolfin/BoundaryCondition.h
> >> >> >> >> >> src/kernel/fem/dolfin/Makefile.am
> >> >> >> >> >> > src/kernel/fem/dolfin/Makefile.in
> >> >> >> >> >> > src/kernel/fem/dolfin/PeriodicBoundaryCondition.h
> >> >> >> >> >> > src/kernel/fem/dolfin/dolfin_fem.h
> >> >> >> src/kernel/function/Makefile.in
> >> >> >> >> >> > src/kernel/function/dolfin/Makefile.in
> >> >> >> src/kernel/graph/Makefile.in
> >> >> >> >> >> > src/kernel/graph/dolfin/Makefile.in
> >> src/kernel/io/Makefile.in
> >> >> >> >> >> > src/kernel/io/dolfin/Makefile.in src/kernel/la/Makefile.in
> >> >> >> >> >> > src/kernel/la/dolfin/Makefile.in src/kernel/log/Makefile.in
> >> >> >> >> src/kernel
> >> >> >> >> >> >  /log/dolfin/Makefile.in src/kernel/main/Makefile.in
> >> >> >> >> >> > src/kernel/main/dolfin/Makefile.in
> >> src/kernel/math/Makefile.in
> >> >> >> >> >> > src/kernel/math/dolfin/Makefile.in
> >> src/kernel/mesh/Makefile.in
> >> >> >> >> >> > src/kernel/mesh/SubDomain.cpp
> >> >> src/kernel/mesh/dolfin/Makefile.in
> >> >> >> >> >> > src/kernel/mesh/dolfin/SubDomain.h
> >> src/kernel/mf/Makefile.in
> >> >> >> >> >> > src/kernel/mf/dolfin/Makefile.in src/kernel/nls/Makefile.in
> >> >> >> >> >> > src/kernel/nls/dolfin/Makefile.in
> >> src/kernel/ode/Makefile.in
> >> >> >> >> >> > src/kernel/ode/dolfin/Makefile.in
> >> >> >> src/kernel/parameter/Makefile.in
> >> >> >> >> >> > src/kernel/parameter/dolfin/Makefile.in
> >> >> >> src/kernel/pde/Makefile.in
> >> >> >> >> >> > src/kernel/pde/dolfin/Makefile.in
> >> src/kernel/plot/Makefile.in
> >> >> >> >> >> > src/kernel/plot/dolfin/Makefile.in
> >> >> >> src/kernel/quadrature/Makefile.in
> >> >> >> >> >> > src/kernel/quadrature/dolfin/Makefile.in
> >> src/lib/Makefile.in
> >> >> >> >> >> > src/pydolfin/Makefile.in src/test/Makefile.in
> >> >> >> src/utils/Makefile.in
> >> >> >> >> >> > src/utils/convert/Makefile.in src/utils/inp2dx/Makefile.in
> >> >> >> >> >> > src/utils/swig/Makefile.in
> >> >> >> >> >> > description:
> >> >> >> >> >> > Add support for setting periodic boundary conditions.
> >> >> >> >> >> >
> >> >> >> >> >> > To set a periodic boundary condition, specify a pair of
> >> >> domains
> >> >> >> >> >> > G and H by a SubDomain. The inside() function should
> >> >> specify the
> >> >> >> >> >> > points of G and the map() function should specify a mapping
> >> >> F : H
> >> >> >> >> >> --> G.
> >> >> >> >> >> >
> >> >> >> >> >> > Then create a PeriodicBoundaryCondition and apply() it
> >> to the
> >> >> >> linear
> >> >> >> >> >> system.
> >> >> >> >> >> >
> >> >> >> >> >> > Bugs/features:
> >> >> >> >> >> >
> >> >> >> >> >> >   1. Only works for scalar subsystems, so it needs to be
> >> done
> >> >> >> >> once for
> >> >> >> >> >> >   each subsystem of a vector function.
> >> >> >> >> >> >
> >> >> >> >> >> >   2. Setting the entries in the matrix can perhaps be
> >> >> optimized.
> >> >> >> >> >> >
> >> >> >> >> >> >   3. PeriodicBoundaryCondition is not a subclass of
> >> >> >> >> BoundaryCondition,
> >> >> >> >> >> >   so it does not work to give a
> >> PeriodicBoundaryCondition as
> >> >> >> >> argument
> >> >> >> >> >> >   to LinearPDE.
> >> >> >> >> >> >
> >> >> >> >> >> > To fix 3, should we rename BoundaryCondition -->
> >> DirichletBC
> >> >> >> >> >> > and have PeriodicBC and DirichletBC as subclasses of
> >> >> >> >> BoundaryCondition?
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> Yes, sounds good.
> >> >> >> >> >>
> >> >> >> >> >> Garth
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > changeset:   3305:4564fa57c9159e7dbe287ba121324ec84afd4d00
> >> >> >> >> >> > user:        "Garth N. Wells <g.n.wells@xxxxxxxxxx>"
> >> >> >> >> >> > date:        Thu Jul 05 22:24:27 2007 +0200
> >> >> >> >> >> > files:       src/kernel/la/PETScLUSolver.cpp
> >> >> >> >> >> src/kernel/nls/NewtonSolver.cpp
> >> >> >> >> >> > src/kernel/nls/dolfin/NewtonSolver.h
> >> >> src/kernel/pde/LinearPDE.cpp
> >> >> >> >> >> > description:
> >> >> >> >> >> > Fix use of PETSc with UMFPACK.
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > changeset:   3304:1a95bb6095dd1b91e462f62a630035defd37c8c6
> >> >> >> >> >> > parent:      3303:a324e9cb2c73b27ecd636fcee5b1a08cc01a0da8
> >> >> >> >> >> > parent:      3302:cd19d9eeddaa68d14d8c6fafe4de490ff17c1f5a
> >> >> >> >> >> > user:        "Garth N. Wells <g.n.wells@xxxxxxxxxx>"
> >> >> >> >> >> > date:        Wed Jul 04 14:38:37 2007 +0200
> >> >> >> >> >> > files:
> >> >> >> >> >> > description:
> >> >> >> >> >> > merge.
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >>
> >> >> ----------------------------------------------------------------------
> >> >> >> >> >> > For more details, visit http://www.fenics.org/hg/dolfin
> >> >> >> >> >> > _______________________________________________
> >> >> >> >> >> > DOLFIN-dev mailing list
> >> >> >> >> >> > DOLFIN-dev@xxxxxxxxxx
> >> >> >> >> >> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> >> >> >> >> >> >
> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> DOLFIN-dev mailing list
> >> >> >> >> >> DOLFIN-dev@xxxxxxxxxx
> >> >> >> >> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> _______________________________________________
> >> >> >> DOLFIN-dev mailing list
> >> >> >> DOLFIN-dev@xxxxxxxxxx
> >> >> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >> >> >>
> >> >> >
> >> >> >
> >> >> _______________________________________________
> >> >> DOLFIN-dev mailing list
> >> >> DOLFIN-dev@xxxxxxxxxx
> >> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >> >>
> >> >
> >> >
> >>
> >
> >


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