dolfin team mailing list archive

[jhoffman@xxxxxxxxxxx]

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

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
>>
>
> --
> Anders Logg
> Research Assistant Professor
> Toyota Technological Institute at Chicago
> http://www.tti-c.org/logg/
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>