dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jul 07, 2005 at 08:03:36PM +0200, jhoffman@xxxxxxxxxxx wrote:

> I agree that we should support both, although 2 would be the only one
> avoiding checking (for Karin & Johan) as far as I understand.

It depends on what the user wants. If someone calls

   FEM::applyBC(..., mesh, ...)

then we have to iterate over the entire boundary. On the other hand,
if someone calls

   FEM::applyBC(..., boundary, ...)

then we only have to loop over that portion of the boundary.

> Also, I
> think we should support some argument to create parts of the boundary (or
> more general any subset of the domain (volume/surface/curve/point)) to use
> for applying boundary conditions, since we cannot assume that we have all
> information in the XML-file.

Yes, this is what the BoundarySpecification stuff does.

Anyone wants to implement this?

/Anders

> Also, e.g. for postprocessing it would be useful to be able to create
> subsets of the domain (to integrate over for example).

> /Johan
> 
> > There is some partial support for portions of boundaries. The DOLFIN
> > XML format accepts specification of boundary IDs for vertices, and
> > each vertex has a list of boundary IDs listing the boundaries to which
> > the vertex belongs.
> >
> > There are two alternatives, and I think we should support both:
> >
> > 1. Creating the full boundary using
> >
> >        Boundary boundary(mesh);
> >
> >    When iterating over a boundary created this way, it should be
> >    possible to check for each mesh entity which boundary it belongs
> >    to. The boundary ID can then be passed as an extra argument to
> >
> >        const BoundaryCondition::BoundaryValue operator() (const Point& p)
> >
> >    during assembly.
> >
> > 2. Creating a piece of a boundary by specifying the boundary ID:
> >
> >        Boundary boundary(mesh, id)
> >
> >    Perhaps one could also be allowed to pass an argument that can be
> >    called during the creation of the boundary to ask which entities
> >    belong on the boundary. This might solve Garth's problem.
> >
> > By the way, we use the name "node" for vertices, but we should
> > probably use "vertex". Then "node" is free to use for finite element
> > nodes (degrees for freedom) which can be associated with vertices,
> > edges, faces etc.
> >
> > /Anders
> >
> > On Thu, Jul 07, 2005 at 06:25:56PM +0200, jhoffman@xxxxxxxxxxx wrote:
> >> Yes, I agree. This is what I meant, the ability to create portions of
> >> the
> >> boundary, possibly by providing some rule of how to choose this portion;
> >> simple bounds for the coordinates, being close to a defined
> >> curve/surface
> >> (up to a tolerance), etc.
> >>
> >> /Johan
> >>
> >> > While we're at it, it makes sense also to be able to select portions
> >> > of the boundary -- for example in calculating drag on a box.  Perhaps
> >> > this should be considered along with boundary conditions.
> >> >
> >> >
> >> > On Jul 7, 2005, at 10:18 AM, jhoffman@xxxxxxxxxxx wrote:
> >> >
> >> >> Maybe it would be a good idea to be able to create several Boundary
> >> >> objects.? As it is now, the default is to create one Boundary (in
> >> >> InitBoundary) which is the total Boundary. Instead maybe one would
> >> >> like to
> >> >> be able to create different Boundary objects for different boundary
> >> >> conditions. The iteration would then be over the different Boundary
> >> >> objects individually.
> >> >>
> >> >> /Johan
> >> >>
> >> >>
> >> >>> On Thu, Jul 07, 2005 at 04:30:35PM +0200, Karin Kraft wrote:
> >> >>>
> >> >>>> Hello!
> >> >>>>
> >> >>>> We have made some progress. We have made a simple implementation
> >> >>>> of the
> >> >>>> general boundary conditions. As a start we have assumed homogeneous
> >> >>>> dirichlet with a constant penalty factor and this works reasonably
> >> >>>> well.
> >> >>>>
> >> >>>
> >> >>> Excellent!
> >> >>>
> >> >>>
> >> >>>> Some issues we have discovered:
> >> >>>> 1. We need to compute the local edge numbers. At the moment we do
> >> >>>> this
> >> >>>> by comparing to all the edges in the cell like so:
> >> >>>>
> >> >>>>   // Iterate over all edges in the boundary
> >> >>>>   for (EdgeIterator edge(boundary); !edge.end(); ++edge)
> >> >>>>   {
> >> >>>>       ...
> >> >>>>       for(int i = 0; i < cell.noEdges(); i++)
> >> >>>>       {
> >> >>>>       if(cell.edgeID(i) == edge->id())
> >> >>>>       {
> >> >>>>           segment = i;
> >> >>>>       }
> >> >>>>       }
> >> >>>>
> >> >>>>
> >> >>>> However, this is inefficient. Perhaps the mesh should be extended
> >> to
> >> >>>> store this information?
> >> >>>>
> >> >>>
> >> >>> Matt Knepley is working on a new parallel mesh component for FEniCS
> >> >>> and the plan is that we will wrap this in DOLFIN (same as with
> >> PETSc)
> >> >>> once it is ready, so maybe we should not invest too much time in
> >> >>> extending the mesh data structures with new data.
> >> >>>
> >> >>> I suggest that we use your temporary implementation (looping over
> >> >>> edges locally to find the local edge number), but create it as a
> >> >>> function in Cell (put it close to the functions for computing edge
> >> >>> and
> >> >>> face alignments). Something like
> >> >>>
> >> >>>     uint Cell::edgeNumber(const Edge& edge) const;
> >> >>>
> >> >>> We will also need
> >> >>>
> >> >>>     uint Cell::faceNumber(const Face& edge) const;
> >> >>>
> >> >>> By putting this as a member function in Cell, you can use the local
> >> >>> data structures directly instead of iterators (the array ce) which
> >> >>> should be a little faster.
> >> >>>
> >> >>>
> >> >>>> 2. Our eval looks something like this and we want to avoid the
> >> >>>> conditional evaluation. Any ideas?
> >> >>>>
> >> >>>>  void eval(real block[], const AffineMap& map, uint boundary) const
> >> >>>>   {
> >> >>>>     // Compute geometry tensors
> >> >>>>     real G0_ = map.scale*1e6;
> >> >>>>
> >> >>>>     // Compute element tensor
> >> >>>>
> >> >>>>     if( boundary == 0 ) {
> >> >>>>     block[0] = 0.0;
> >> >>>>     block[1] = 0.0;
> >> >>>>     block[2] = 0.0;
> >> >>>>
> >> >>>>     block[3] = 0.0;
> >> >>>>     block[4] = 3.333333333333318e-01*G0_;
> >> >>>>     block[5] = 3.333333333333318e-01*G0_;
> >> >>>>
> >> >>>>     block[6] = 0.0;
> >> >>>>     block[7] = 3.333333333333318e-01*G0_;
> >> >>>>     block[8] = 3.333333333333318e-01*G0_;
> >> >>>>     }
> >> >>>>
> >> >>>> Regards,
> >> >>>> Karin and Johan
> >> >>>>
> >> >>>
> >> >>> I managed to avoid conditionals when building the dofmap()
> >> >>> function by
> >> >>> creating arrays. Maybe there is some solution where the segment
> >> >>> (boundary) argument is used to index an array to get the values, but
> >> >>> it doesn't look like that would be easy to do here.
> >> >>>
> >> >>> One solution would be to create three different eval functions
> >> >>> (eval_segment_0, eval_segment_1. eval_segment_2) and then have an
> >> >>> array of function pointers to these functions and use the argument
> >> >>> segment (boundary) to index into this array, get the correct
> >> function
> >> >>> and then call it. I'm not sure how this compares to having a
> >> >>> switch or
> >> >>> a series of if statements inside eval.
> >> >>>
> >> >>> It bugs me that we first have to search for the edge number, and
> >> then
> >> >>> when we have the number go through a switch statement. Are we doing
> >> >>> something wrong? Maybe there is a shortcut that avoids both the
> >> >>> searching and the switch?
> >> >>>
> >> >>> /Anders
> >> >>>
> >> >>> _______________________________________________
> >> >>> DOLFIN-dev mailing list
> >> >>> DOLFIN-dev@xxxxxxxxxx
> >> >>> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> DOLFIN-dev mailing list
> >> >> DOLFIN-dev@xxxxxxxxxx
> >> >> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > DOLFIN-dev mailing list
> >> > DOLFIN-dev@xxxxxxxxxx
> >> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >> >
> >>
> >>
> >>
> >> _______________________________________________
> >> DOLFIN-dev mailing list
> >> DOLFIN-dev@xxxxxxxxxx
> >> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >>
> >
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >
> 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/