[Ffc] evaluate_integrand
We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. For this reason, we would like to generate code for evaluating the integrand of a form at an arbitrary point within the cell. I would propose adding something like this to each of the *_integral classes in the UFC interface: /// Evaluate integrand at given point virtual void evaluate_integrand(double* A, const double * const * w, const cell& c, const double* coordinates) const = 0; I suspect/hope this should be easy to add to FFC since the current quadrature code must do something like this, but in addition iterate over the points and compute the weighted sum. This would let a user handle the quadrature manually in cases where that is necessary. Would it be possible to add? -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On 12/04/10 20:47, Anders Logg wrote: We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. We (Mehdi and I) do this already (using UFC), so I don't see why a new function is required. Can you explain why evaluate_tensor is not enough? Garth For this reason, we would like to generate code for evaluating the integrand of a form at an arbitrary point within the cell. I would propose adding something like this to each of the *_integral classes in the UFC interface: /// Evaluate integrand at given point virtual void evaluate_integrand(double* A, const double * const * w, const cell& c, const double* coordinates) const = 0; I suspect/hope this should be easy to add to FFC since the current quadrature code must do something like this, but in addition iterate over the points and compute the weighted sum. This would let a user handle the quadrature manually in cases where that is necessary. Would it be possible to add? -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On 12/04/10 21:19, Garth N. Wells wrote: On 12/04/10 20:47, Anders Logg wrote: We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. We (Mehdi and I) do this already (using UFC), so I don't see why a new function is required. Can you explain why evaluate_tensor is not enough? I meant 'tabulate_tensor'. Garth Garth For this reason, we would like to generate code for evaluating the integrand of a form at an arbitrary point within the cell. I would propose adding something like this to each of the *_integral classes in the UFC interface: /// Evaluate integrand at given point virtual void evaluate_integrand(double* A, const double * const * w, const cell& c, const double* coordinates) const = 0; I suspect/hope this should be easy to add to FFC since the current quadrature code must do something like this, but in addition iterate over the points and compute the weighted sum. This would let a user handle the quadrature manually in cases where that is necessary. Would it be possible to add? -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: > > > On 12/04/10 21:19, Garth N. Wells wrote: > > > > > >On 12/04/10 20:47, Anders Logg wrote: > >>We are doing some work where we need to do run-time quadrature over > >>arbitrary polyhedra. > > > >We (Mehdi and I) do this already (using UFC), so I don't see why a new > >function is required. Can you explain why evaluate_tensor is not enough? > > > > I meant 'tabulate_tensor'. Which function do you call for evaluating the integrand? -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On 12/04/10 21:29, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: On 12/04/10 21:19, Garth N. Wells wrote: On 12/04/10 20:47, Anders Logg wrote: We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. We (Mehdi and I) do this already (using UFC), so I don't see why a new function is required. Can you explain why evaluate_tensor is not enough? I meant 'tabulate_tensor'. Which function do you call for evaluating the integrand? We evaluate it inside ufc::tabulate_tensor. We construct our forms with an extra argument, say an object "CutCellIntegrator", which can provide quadrature schemes which depend on the considered cell. Garth -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote: > > > On 12/04/10 21:29, Anders Logg wrote: > >On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: > >> > >> > >>On 12/04/10 21:19, Garth N. Wells wrote: > >>> > >>> > >>>On 12/04/10 20:47, Anders Logg wrote: > We are doing some work where we need to do run-time quadrature over > arbitrary polyhedra. > >>> > >>>We (Mehdi and I) do this already (using UFC), so I don't see why a new > >>>function is required. Can you explain why evaluate_tensor is not enough? > >>> > >> > >>I meant 'tabulate_tensor'. > > > >Which function do you call for evaluating the integrand? > > > > We evaluate it inside ufc::tabulate_tensor. We construct our forms > with an extra argument, say an object "CutCellIntegrator", which can > provide quadrature schemes which depend on the considered cell. That would require a special purpose code generator. Having evaluate_integrand would allow more flexibility for users to implement their own special quadrature scheme. I also don't understand how it can work at all since the quadrature points are not known at compile-time. Or do you a fixed set of reference polyhedra that you map to? -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On 12/04/10 21:49, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote: On 12/04/10 21:29, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: On 12/04/10 21:19, Garth N. Wells wrote: On 12/04/10 20:47, Anders Logg wrote: We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. We (Mehdi and I) do this already (using UFC), so I don't see why a new function is required. Can you explain why evaluate_tensor is not enough? I meant 'tabulate_tensor'. Which function do you call for evaluating the integrand? We evaluate it inside ufc::tabulate_tensor. We construct our forms with an extra argument, say an object "CutCellIntegrator", which can provide quadrature schemes which depend on the considered cell. That would require a special purpose code generator. What's wrong with that? FFC won't (and shouldn't) be able to do everything. Just adding a function to UFC won't make FFC do what we do now. We reuse FFC (import modules) and add special purpose extensions. Having evaluate_integrand would allow more flexibility for users to implement their own special quadrature scheme. We make "CutCellIntegrator" an abstract base class, so the user has *complete* freedom to define the quadrature scheme and the generated code does not depend on the scheme, since the scheme may depend on things like how the cell 'cut' is represented. I also don't understand how it can work at all since the quadrature points are not known at compile-time. Or do you a fixed set of reference polyhedra that you map to? The "CutCellIntegrator" object is asked for the quadrature points, and it returns them. One way to do it is to sub-triangulate polyhedra (I think that CGAL can do this). "CutCellIntegrator" would usually be aware of intersecting surfaces, etc. It can also return schemes on surfaces. I would like a quadrature generator on polyhedra to eventually be part of DOLFIN. Garth -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] Bubble function
On Mon, Apr 12, 2010 at 1:51 AM, Marie Rognes wrote: > Andy Ray Terrel wrote: >> >> Okay so Brezzi Fortin have just a bubble function with one node. >> Perhaps they meant P3 but their notation is ambiguous. >> ArnoldBrezziFortin1984 does call for the P3 in the original paper but >> then they mention using 2 P4 bubble functions for the next velocity >> order. If I do enrich with 2 P4 bubbles with ffc will the bubble >> functions be any different. It just seems like it will give exactly >> the same evaluation points as enriching with 1 bubble function. >> > > I'm not quite sure what you mean by enriching with 2 P4 bubble functions. Do > you mean 2 as in 2 components? Note that the bubble space of degree 4 has > local dimension 3. Hmm perhaps they just mean 2 components, funny they stress 2 function for P4 but not for P3. What do you mean by local dimension 3? Do you mean the spatial dimension or 3 basis functions? > > Are you sure that you have the latest ffc? Yeah. But I can put anything 3 and above as the order and it looks to work. I just want to make sure I have some vague notion of what I am doing. > > -- > Marie > ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On Mon, Apr 12, 2010 at 10:20:13PM +0800, Garth N. Wells wrote: > > > On 12/04/10 21:49, Anders Logg wrote: > >On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote: > >> > >> > >>On 12/04/10 21:29, Anders Logg wrote: > >>>On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: > > > On 12/04/10 21:19, Garth N. Wells wrote: > > > > > >On 12/04/10 20:47, Anders Logg wrote: > >>We are doing some work where we need to do run-time quadrature over > >>arbitrary polyhedra. > > > >We (Mehdi and I) do this already (using UFC), so I don't see why a new > >function is required. Can you explain why evaluate_tensor is not enough? > > > > I meant 'tabulate_tensor'. > >>> > >>>Which function do you call for evaluating the integrand? > >>> > >> > >>We evaluate it inside ufc::tabulate_tensor. We construct our forms > >>with an extra argument, say an object "CutCellIntegrator", which can > >>provide quadrature schemes which depend on the considered cell. > > > >That would require a special purpose code generator. > > What's wrong with that? FFC won't (and shouldn't) be able to do > everything. Just adding a function to UFC won't make FFC do what we > do now. We reuse FFC (import modules) and add special purpose > extensions. Exactly, it won't make FFC do what we need, but we could *use* FFC to do what we need (without adding a special-purpose code generator). > >Having > >evaluate_integrand would allow more flexibility for users to implement > >their own special quadrature scheme. > > > > We make "CutCellIntegrator" an abstract base class, so the user has > *complete* freedom to define the quadrature scheme and the generated > code does not depend on the scheme, since the scheme may depend on > things like how the cell 'cut' is represented. Then it sounds to me like that generated code is not at all special, but instead general purpose and should be added to UFC/FFC. And the most general interface would (I think) be an interface for evaluating the integrand at a given point. We already have the same for basis functions (evaluate_basis_function) so it is a natural extension. > >I also don't understand how it can work at all since the quadrature > >points are not known at compile-time. Or do you a fixed set of reference > >polyhedra that you map to? > > > > The "CutCellIntegrator" object is asked for the quadrature points, > and it returns them. One way to do it is to sub-triangulate > polyhedra (I think that CGAL can do this). "CutCellIntegrator" would > usually be aware of intersecting surfaces, etc. It can also return > schemes on surfaces. > > I would like a quadrature generator on polyhedra to eventually be > part of DOLFIN. It is already. See the BarycenterQuadrature class in the Nitsche repository. I'm currently merging it. It computes the simplest possible quadrature (exact for linear polynomials) for arbitrary polyhedra. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
Hi! Anders and I are working on an implementation for Nitsche's method, where the question of integration on cut cell and facets also (beside XFEM for you) came up. On Monday 12. April 2010 16.20.13 Garth N. Wells wrote: > On 12/04/10 21:49, Anders Logg wrote: > > On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote: > >> On 12/04/10 21:29, Anders Logg wrote: > >>> On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: > On 12/04/10 21:19, Garth N. Wells wrote: > > On 12/04/10 20:47, Anders Logg wrote: > >> We are doing some work where we need to do run-time quadrature over > >> arbitrary polyhedra. > > > > We (Mehdi and I) do this already (using UFC), so I don't see why a > > new function is required. Can you explain why evaluate_tensor is not > > enough? > > I meant 'tabulate_tensor'. > >>> > >>> Which function do you call for evaluating the integrand? > >> > >> We evaluate it inside ufc::tabulate_tensor. We construct our forms > >> with an extra argument, say an object "CutCellIntegrator", which can > >> provide quadrature schemes which depend on the considered cell. > > > > That would require a special purpose code generator. > > What's wrong with that? FFC won't (and shouldn't) be able to do > everything. Just adding a function to UFC won't make FFC do what we do > now. We reuse FFC (import modules) and add special purpose extensions. I think code generator is cool :) But in this case and maybe also other use- cases for DOLFIN it presents a high barrier to try out new FEM schemes. And for example adding an evaluate integrand function would *DOLFIN* make to do what we want to to with Nitsche (see below). > > > Having > > evaluate_integrand would allow more flexibility for users to implement > > their own special quadrature scheme. > > We make "CutCellIntegrator" an abstract base class, so the user has > *complete* freedom to define the quadrature scheme and the generated > code does not depend on the scheme, since the scheme may depend on > things like how the cell 'cut' is represented. That's sounds like a pretty cool and sophisticated framework but to me it is not clear how our implementation would easily fit into this framework. Although there are quite a lot similiarities as integration on cut cells and facets my understanding of the pum code is not deep enough to see how we could *easily* reuse your code in our case. Maybe you could give a hint of how it would possible? For example how tight is your ffc code generation implementation for XFEM connected with the use of the CutCellIntegrator class? Since Nitsche methods can be understand as a kind of domain decompositon we have *several* (overlapping) meshes. Then we want is to integrate forms (possibly different equation) on each (not covered part of the) mesh and some additonal interface integrals along the interfaces. Basically we have almost everything in place. We have an intersection map, mapping each cell/facet to the covering cells/facets and we have at least a barycenter quadrature rule for arbitrary cut cells and facet at hand. So for trying out another FEM scheme in DOLFIN all we need is to assemble it and merging the domain specific matrices. Everything can already be done in DOLFIN with resonable effort except the actual calculation of the integrals. To summarize, this only one evaluate_integrand function would help to make DOLFIN/FENICS flexible enough for an average programmer like me to implement new, semi-automated :) FEM schemes with a reasonable amount of time. > > > I also don't understand how it can work at all since the quadrature > > points are not known at compile-time. Or do you a fixed set of reference > > polyhedra that you map to? > > The "CutCellIntegrator" object is asked for the quadrature points, and > it returns them. One way to do it is to sub-triangulate polyhedra (I > think that CGAL can do this). "CutCellIntegrator" would usually be aware > of intersecting surfaces, etc. It can also return schemes on surfaces. > > I would like a quadrature generator on polyhedra to eventually be part > of DOLFIN. > > Garth > > > -- > > Anders > > ___ > Mailing list: https://launchpad.net/~ffc > Post to : ffc@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On 12/04/10 23:35, Anders Logg wrote: On Mon, Apr 12, 2010 at 10:20:13PM +0800, Garth N. Wells wrote: On 12/04/10 21:49, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote: On 12/04/10 21:29, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: On 12/04/10 21:19, Garth N. Wells wrote: On 12/04/10 20:47, Anders Logg wrote: We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. We (Mehdi and I) do this already (using UFC), so I don't see why a new function is required. Can you explain why evaluate_tensor is not enough? I meant 'tabulate_tensor'. Which function do you call for evaluating the integrand? We evaluate it inside ufc::tabulate_tensor. We construct our forms with an extra argument, say an object "CutCellIntegrator", which can provide quadrature schemes which depend on the considered cell. That would require a special purpose code generator. What's wrong with that? FFC won't (and shouldn't) be able to do everything. Just adding a function to UFC won't make FFC do what we do now. We reuse FFC (import modules) and add special purpose extensions. Exactly, it won't make FFC do what we need, but we could *use* FFC to do what we need (without adding a special-purpose code generator). Having evaluate_integrand would allow more flexibility for users to implement their own special quadrature scheme. We make "CutCellIntegrator" an abstract base class, so the user has *complete* freedom to define the quadrature scheme and the generated code does not depend on the scheme, since the scheme may depend on things like how the cell 'cut' is represented. Then it sounds to me like that generated code is not at all special, but instead general purpose and should be added to UFC/FFC. And the most general interface would (I think) be an interface for evaluating the integrand at a given point. We already have the same for basis functions (evaluate_basis_function) so it is a natural extension. I still don't see the need for 'evaluate_integrand' unless you plan to call it directly from the assembler side (i.e. DOLFIN). Is that the case? Perhaps you can give me a concrete example of how you plan to use it. I also don't understand how it can work at all since the quadrature points are not known at compile-time. Or do you a fixed set of reference polyhedra that you map to? The "CutCellIntegrator" object is asked for the quadrature points, and it returns them. One way to do it is to sub-triangulate polyhedra (I think that CGAL can do this). "CutCellIntegrator" would usually be aware of intersecting surfaces, etc. It can also return schemes on surfaces. I would like a quadrature generator on polyhedra to eventually be part of DOLFIN. It is already. See the BarycenterQuadrature class in the Nitsche repository. I'm currently merging it. It computes the simplest possible quadrature (exact for linear polynomials) for arbitrary polyhedra. Nice. We'll take a look. Garth -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] evaluate_integrand
On 13/04/10 00:16, Andre Massing wrote: Hi! Anders and I are working on an implementation for Nitsche's method, where the question of integration on cut cell and facets also (beside XFEM for you) came up. On Monday 12. April 2010 16.20.13 Garth N. Wells wrote: On 12/04/10 21:49, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote: On 12/04/10 21:29, Anders Logg wrote: On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote: On 12/04/10 21:19, Garth N. Wells wrote: On 12/04/10 20:47, Anders Logg wrote: We are doing some work where we need to do run-time quadrature over arbitrary polyhedra. We (Mehdi and I) do this already (using UFC), so I don't see why a new function is required. Can you explain why evaluate_tensor is not enough? I meant 'tabulate_tensor'. Which function do you call for evaluating the integrand? We evaluate it inside ufc::tabulate_tensor. We construct our forms with an extra argument, say an object "CutCellIntegrator", which can provide quadrature schemes which depend on the considered cell. That would require a special purpose code generator. What's wrong with that? FFC won't (and shouldn't) be able to do everything. Just adding a function to UFC won't make FFC do what we do now. We reuse FFC (import modules) and add special purpose extensions. I think code generator is cool :) But in this case and maybe also other use- cases for DOLFIN it presents a high barrier to try out new FEM schemes. And for example adding an evaluate integrand function would *DOLFIN* make to do what we want to to with Nitsche (see below). Having evaluate_integrand would allow more flexibility for users to implement their own special quadrature scheme. We make "CutCellIntegrator" an abstract base class, so the user has *complete* freedom to define the quadrature scheme and the generated code does not depend on the scheme, since the scheme may depend on things like how the cell 'cut' is represented. That's sounds like a pretty cool and sophisticated framework but to me it is not clear how our implementation would easily fit into this framework. Although there are quite a lot similiarities as integration on cut cells and facets my understanding of the pum code is not deep enough to see how we could *easily* reuse your code in our case. Maybe you could give a hint of how it would possible? For example how tight is your ffc code generation implementation for XFEM connected with the use of the CutCellIntegrator class? You wouldn't be able to re-use all the code, but we could share some common base classes, for example for locating quadrature points, which in turn would depend on how the surface is represented, and for integrating on surfaces. Since Nitsche methods can be understand as a kind of domain decompositon we have *several* (overlapping) meshes. Then we want is to integrate forms (possibly different equation) on each (not covered part of the) mesh and some additonal interface integrals along the interfaces. Basically we have almost everything in place. We have an intersection map, mapping each cell/facet to the covering cells/facets and we have at least a barycenter quadrature rule for arbitrary cut cells and facet at hand. So for trying out another FEM scheme in DOLFIN all we need is to assemble it and merging the domain specific matrices. Everything can already be done in DOLFIN with resonable effort except the actual calculation of the integrals. We do this now more-or-less in tabulate_tensor with our PUM object providing the necessary data for taking care of the merging. Garth To summarize, this only one evaluate_integrand function would help to make DOLFIN/FENICS flexible enough for an average programmer like me to implement new, semi-automated :) FEM schemes with a reasonable amount of time. I also don't understand how it can work at all since the quadrature points are not known at compile-time. Or do you a fixed set of reference polyhedra that you map to? The "CutCellIntegrator" object is asked for the quadrature points, and it returns them. One way to do it is to sub-triangulate polyhedra (I think that CGAL can do this). "CutCellIntegrator" would usually be aware of intersecting surfaces, etc. It can also return schemes on surfaces. I would like a quadrature generator on polyhedra to eventually be part of DOLFIN. Garth -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
