ffc team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

Without having thought this through in any way, I think this should
rather be additions to the ufc::cell struct than adding a new struct.

-- 
Martin



2008/8/14 Shawn Walker <walker@xxxxxxxxxxxxxxx>:
> I'm not against changing the xml format.  Actually, it would be nice to
> have a format that is backwards compatible; that way you could ignore the
> curved information and just use the mesh as straight if you want.  That
> seems do-able.
>
> And then add a local struct to the UFC format that is accessible by the
> tabulate_tensor routine.  This local struct would have the local nonlinear
> map for each cell and facet in place.  I need to look at the UFC manual
> some more and see how this might work...
>
> - Shawn
>
> On Thu, 14 Aug 2008, Johan Hoffman wrote:
>
>>>
>>> On Wed, 13 Aug 2008, Jed Brown wrote:
>>>
>>>> On Wed 2008-08-13 17:37, Shawn Walker wrote:
>>>>> ok, but how would you adjust the xml mesh format?  That should be
>>>>> figured
>>>>> out first.  I was thinking one could just add extra data for each cell
>>>>> that specifies the location of the other control points for the
>>>>> triangle
>>>>> sides.  Or maybe it would be better to just supply a finite element
>>>>> function (2nd order or higher) for the x,y,z coordinates of the mesh
>>>>> and
>>>>> do it that way?
>>>>
>>>> I'm a fan of storing coordinates just like any other function, but you
>>>> probably want variable order (p-adaptivity) for this since you would
>>>> like most elements to have an affine mapping (for efficiency and to
>>>> improve the accuracy of the quadrature).
>>>
>>> Well, if DOLFIN has p-adaptive functions built into it, then this would
>>> not be a problem.  If it doesn't have it yet, then it could wait.  In the
>>> meantime, I would just have a full P2, or P3 (2nd or 3rd order) function
>>> for all triangles.  And, in addition, provide a boolean function on each
>>> cell that says whether it is straight or not.
>>
>> I am also interested in curved boundaries. If we do not want to change the
>> xml format, maybe it would be enough to use a boolean MeshFunction over
>> the boundary to achieve what you describe?
>>
>> /Johan
>>
>>
>>
>>
>>
>>
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>