To be sure, my needs are much simpler, and I can probably use Martin's
suggestion. But it seems nice and complete to have some robust way to
get to this information. Maybe the string idea ("L2") could be
combined with David's idea, by having a non-ufc utility method on
element, f.x. is_contained_in(string) or subspace_of(string).-j. On 12 September 2012 09:31, Anders Logg <[email protected]> wrote: > I'm not sure we need such classes/objects. Wouldn't it be enough to add a new > function to the element class to return a string like "L2", "H1" etc? > > UFC is up for extension in the near future so this should be added as a UFC > blueprint. > > -- > Anders > > 11 sep 2012 kl. 21:07 skrev David Ham <[email protected]>: > >> FWIW I agree with Martin that the element class needs to be able to >> report this. For instance, if someone were to add non-equispaced >> Lagrange polynomials which are typically used for higher order >> computations, these need to show up as continuous, which would not >> safely happen if you just check the element family. >> >> A suggestion, if I may, which seems sort of mathematically nice to me >> would be to define a SobolevSpace class. Instances of that class would >> be comparable with each other and with element objects so one could >> inquire whether an element has continuity in a given sense. >> >> For instance there might be SobolevSpace objects H1, H1_div, H1_curl, >> L_2. These would compare H1>H1_div>L_2, H1>H1_curl>L_2. >> >> A DG element object d would compare d<L_2 but false for any other inclusion >> A CG element would compare true for all the spaces. >> RT1 would compare true for H1_div and L2 but not for H1_curl or H1 and so on. >> >> Thought would need to be given to whether it is necessary to enforce >> dimension matching properly or not. >> >> In the Python level it might be more natural to make the inclusion >> operator "in" rather than <. >> >> Regards, >> >> David >> >> >> >> On 11 September 2012 18:20, Martin Sandve Alnæs <[email protected]> wrote: >>> This is maybe cumbersome, but you can identify DG elements by checking >>> the number of dofs per mesh entity through ufc::dof_map, with the function >>> /// Return the number of dofs associated with each cell entity of >>> dimension d >>> virtual unsigned int num_entity_dofs(unsigned int d) const = 0; >>> if >>> dm->num_entity_dofs(0) == dm->max_local_dimension() >>> then no dofs are shared between elements. >>> >>> However this does not cover elements where dofs are shared but >>> the functions are still discontinuous in certain senses. >>> I guess more information will be needed in the ufc element classes. >>> >>> Martin >>> >>> >>> On 11 September 2012 16:13, Garth N. Wells <[email protected]> wrote: >>>> On Tue, Sep 11, 2012 at 11:36 AM, Joachim Berdal Haga <[email protected]> >>>> wrote: >>>>> Ok! I'll just check the element family then. Is there a more robust >>>>> way to query it (in C++) than parsing >>>>> f->function_space()->element()->signature()? >>>>> >>>> >>>> The signature should not be used. It's not robust. Using the signature >>>> has caused problems in the past. >>>> >>>> Garth >>>> >>>>> -j. >>>>> >>>>> On 11 September 2012 12:09, Kent-Andre Mardal <[email protected]> wrote: >>>>>> I guess it is only the Lagrange/CG element that is continuous. The others >>>>>> are only continuous >>>>>> in certain senses or directions. I don't think there is any meta data >>>>>> that >>>>>> contains this >>>>>> info. >>>>>> >>>>>> Kent >>>>>> >>>>>> On 11 September 2012 11:56, Joachim Berdal Haga <[email protected]> wrote: >>>>>>> >>>>>>> Is there a simple way to find out whether an arbitrary Function (or >>>>>>> FunctionSpace) is continuous across cells in C++? >>>>>>> >>>>>>> -j. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~dolfin >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~dolfin >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dolfin >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~dolfin >>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~dolfin >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~dolfin >>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dolfin >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~dolfin >>> More help : https://help.launchpad.net/ListHelp >> >> >> >> -- >> Dr David Ham >> Department of Computing >> Imperial College London >> >> http://www.imperial.ac.uk/people/david.ham >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dolfin >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~dolfin >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
