[Ffc] Status
We've come pretty far on the rewrite of FFC and only a few functions remain. As far as I can see, it remains to implement code generation for the following functions: Kristian: code["evaluate_basis_all"] = not_implemented code["evaluate_basis_derivatives"] = not_implemented code["evaluate_basis_derivatives_all"] = not_implemented Marie: code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what this function should do code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in this function Marie or Kristian: code["interpolate_vertex_values"] = not_implemented In addition, we need to get the code generation for the integral classes working. It's sort of working for the tensor representation but not at all (?) for the quadrature representation. I'll be working on getting the tensor representation completely in place. -- 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] Status
2010/1/6 Anders Logg : We've come pretty far on the rewrite of FFC and only a few functions remain. As far as I can see, it remains to implement code generation for the following functions: Kristian: code["evaluate_basis_all"] = not_implemented This should be easy to implement. Would it be an idea to let evaluate_basis() call evaluate_basis_all() and then pick the correct value? This will remove a lot of redundant code at the cost of some overhead introduced by the function call. However, I don't see why one would call evaluate_basis() if evaluate_basis_all() works, I imagine that the assembler will call evaluate_basis_all() in the future for efficiency? code["evaluate_basis_derivatives"] = not_implemented code["evaluate_basis_derivatives_all"] = not_implemented Marie: code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what this function should do code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in this function Marie or Kristian: code["interpolate_vertex_values"] = not_implemented In addition, we need to get the code generation for the integral classes working. It's sort of working for the tensor representation but not at all (?) for the quadrature representation. I'll be working on getting the tensor representation completely in place. I don't think the quadrature code for integrals work at all, but I haven't checked. If you set up the infrastructure for combining code from different integrals, I'll take care of the quadrature part. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktEYmQACgkQTuwUCDsYZdHCvgCcDbc6GpfqnJGi5iUJqxj+1uRq WTEAnivVMK4Kw1tW7jxdqH+zO8oAJH/j =HEMl -END PGP 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 signature.asc Description: OpenPGP 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] Status
On Wed, Jan 06, 2010 at 11:24:04AM +0100, Kristian Oelgaard wrote: > > > 2010/1/6 Anders Logg : > >We've come pretty far on the rewrite of FFC and only a few functions > >remain. As far as I can see, it remains to implement code generation > >for the following functions: > > > >Kristian: > > > > code["evaluate_basis_all"] = not_implemented > > This should be easy to implement. > Would it be an idea to let evaluate_basis() call evaluate_basis_all() and > then pick the correct value? > This will remove a lot of redundant code at the cost of some overhead > introduced by the function call. > However, I don't see why one would call evaluate_basis() if > evaluate_basis_all() works, I imagine that the assembler will call > evaluate_basis_all() in the future for efficiency? I don't think the assembler calls evaluate_basis_all. It's only used in special cases for people that write their own assemblers (Nitsche on overlapping meshes, crack propagation, partition of unity etc). But having evaluate_basis call evaluate_basis_all sounds like it would result in very much overhead. It would evaluate all basis functions even if just one is needed. Wouldn't it be more natural to do the opposite? > > code["evaluate_basis_derivatives"] = not_implemented > > code["evaluate_basis_derivatives_all"] = not_implemented > > > >Marie: > > > > code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what > >this function should do > > code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in > >this function > > > >Marie or Kristian: > > > > code["interpolate_vertex_values"] = not_implemented > > > >In addition, we need to get the code generation for the integral > >classes working. It's sort of working for the tensor representation > >but not at all (?) for the quadrature representation. I'll be working > >on getting the tensor representation completely in place. > > I don't think the quadrature code for integrals work at all, but I haven't > checked. If you set up the infrastructure for combining code from different > integrals, I'll take care of the quadrature part. ok. I will look at it. But you can also experiment with just changing one line in codegeneration.py. Change from code = generate_tensor_integrals(ir, options) to code = generate_quadrature_integrals(ir, options) Note that in the new approach, all code needs to be generated as a string, not a list of declarations but maybe that was only used by the tensor representation before anyway. -- 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] Status
2010/1/6 Anders Logg : On Wed, Jan 06, 2010 at 11:24:04AM +0100, Kristian Oelgaard wrote: 2010/1/6 Anders Logg : >We've come pretty far on the rewrite of FFC and only a few functions >remain. As far as I can see, it remains to implement code generation >for the following functions: > >Kristian: > > code["evaluate_basis_all"] = not_implemented This should be easy to implement. Would it be an idea to let evaluate_basis() call evaluate_basis_all() and then pick the correct value? This will remove a lot of redundant code at the cost of some overhead introduced by the function call. However, I don't see why one would call evaluate_basis() if evaluate_basis_all() works, I imagine that the assembler will call evaluate_basis_all() in the future for efficiency? I don't think the assembler calls evaluate_basis_all. It's only used in special cases for people that write their own assemblers (Nitsche on overlapping meshes, crack propagation, partition of unity etc). I think I tracked a call from the assembler to evaluate_basis, but that was in a very old DOLFIN I guess. Now evaluate_basis() is just called from one of the Function::eval() functions. But having evaluate_basis call evaluate_basis_all sounds like it would result in very much overhead. It would evaluate all basis functions even if just one is needed. Wouldn't it be more natural to do the opposite? But if users will use evaluate_basis_all() (if available) rather than evaluate_basis() it is better to call evaluate_basis from evaluate_basis_all than the other way around. The fastest will be to just include all the code in both functions. Getting the value of all basis functions is not that demanding once the values of the expansion polynomial basis are computed (which is the same for all basis functions). Then it is just a matrix vector multiply of the coefficients (tabulated) and the basis values (computed at run-time). > code["evaluate_basis_derivatives"] = not_implemented > code["evaluate_basis_derivatives_all"] = not_implemented > >Marie: > > code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what this function should do > code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in this function > >Marie or Kristian: > > code["interpolate_vertex_values"] = not_implemented > >In addition, we need to get the code generation for the integral >classes working. It's sort of working for the tensor representation >but not at all (?) for the quadrature representation. I'll be working >on getting the tensor representation completely in place. I don't think the quadrature code for integrals work at all, but I haven't checked. If you set up the infrastructure for combining code from different integrals, I'll take care of the quadrature part. ok. I will look at it. But you can also experiment with just changing one line in codegeneration.py. Change from code = generate_tensor_integrals(ir, options) to code = generate_quadrature_integrals(ir, options) Note that in the new approach, all code needs to be generated as a string, not a list of declarations but maybe that was only used by the tensor representation before anyway. OK Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktEbJQACgkQTuwUCDsYZdE6JwCePzSA6iEP1Pw9ODwYyN+wc+e7 kukAoIem9SAzancyFMvKlJn//PWVWTdi =vZ7I -END PGP SIGNATURE- signature.asc Description: OpenPGP 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] Status
Anders Logg wrote:
We've come pretty far on the rewrite of FFC and only a few functions
remain. As far as I can see, it remains to implement code generation
for the following functions:
Kristian:
code["evaluate_basis_all"] = not_implemented
code["evaluate_basis_derivatives"] = not_implemented
code["evaluate_basis_derivatives_all"] = not_implemented
Marie:
code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what this
function should do
Evidently, my comment was unclear ;)
Should it look like this for CG_1?
/// Tabulate the local-to-local mapping of dofs on entity (d, i)
virtual void tabulate_entity_dofs(unsigned int* dofs,
unsigned int d, unsigned int i) const
{
dofs[0] = i
}
code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in
this function
What should this function do for the integral moment dofs, where there
are more than one point per dof?
Marie or Kristian:
code["interpolate_vertex_values"] = not_implemented
Can fix.
--
Marie
In addition, we need to get the code generation for the integral
classes working. It's sort of working for the tensor representation
but not at all (?) for the quadrature representation. I'll be working
on getting the tensor representation completely in place.
--
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] Status
Kristian Oelgaard wrote: 2010/1/6 Anders Logg : On Wed, Jan 06, 2010 at 11:24:04AM +0100, Kristian Oelgaard wrote: 2010/1/6 Anders Logg : >We've come pretty far on the rewrite of FFC and only a few functions >remain. As far as I can see, it remains to implement code generation >for the following functions: > >Kristian: > > code["evaluate_basis_all"] = not_implemented This should be easy to implement. Would it be an idea to let evaluate_basis() call evaluate_basis_all() and then pick the correct value? This will remove a lot of redundant code at the cost of some overhead introduced by the function call. However, I don't see why one would call evaluate_basis() if evaluate_basis_all() works, I imagine that the assembler will call evaluate_basis_all() in the future for efficiency? I don't think the assembler calls evaluate_basis_all. It's only used in special cases for people that write their own assemblers (Nitsche on overlapping meshes, crack propagation, partition of unity etc). I think I tracked a call from the assembler to evaluate_basis, but that was in a very old DOLFIN I guess. Now evaluate_basis() is just called from one of the Function::eval() functions. But having evaluate_basis call evaluate_basis_all sounds like it would result in very much overhead. It would evaluate all basis functions even if just one is needed. Wouldn't it be more natural to do the opposite? But if users will use evaluate_basis_all() (if available) rather than evaluate_basis() it is better to call evaluate_basis from evaluate_basis_all than the other way around. The fastest will be to just include all the code in both functions. Getting the value of all basis functions is not that demanding once the values of the expansion polynomial basis are computed (which is the same for all basis functions). Then it is just a matrix vector multiply of the coefficients (tabulated) and the basis values (computed at run-time). The same applies for evaluate_dof and evaluate_dofs. I thought that I'd implement these two differently, so that evaluate_dof is as fast as possible for a single dof and evaluate_dofs is as fast as possible for all the dofs. -- Marie > code["evaluate_basis_derivatives"] = not_implemented > code["evaluate_basis_derivatives_all"] = not_implemented > >Marie: > > code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what this function should do > code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in this function > >Marie or Kristian: > > code["interpolate_vertex_values"] = not_implemented > >In addition, we need to get the code generation for the integral >classes working. It's sort of working for the tensor representation >but not at all (?) for the quadrature representation. I'll be working >on getting the tensor representation completely in place. I don't think the quadrature code for integrals work at all, but I haven't checked. If you set up the infrastructure for combining code from different integrals, I'll take care of the quadrature part. ok. I will look at it. But you can also experiment with just changing one line in codegeneration.py. Change from code = generate_tensor_integrals(ir, options) to code = generate_quadrature_integrals(ir, options) Note that in the new approach, all code needs to be generated as a string, not a list of declarations but maybe that was only used by the tensor representation before anyway. OK Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktEbJQACgkQTuwUCDsYZdE6JwCePzSA6iEP1Pw9ODwYyN+wc+e7 kukAoIem9SAzancyFMvKlJn//PWVWTdi =vZ7I -END PGP 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 ___ 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] Status
Marie Rognes wrote:
> Anders Logg wrote:
>> We've come pretty far on the rewrite of FFC and only a few functions
>> remain. As far as I can see, it remains to implement code generation
>> for the following functions:
>>
>> Kristian:
>>
>> code["evaluate_basis_all"] = not_implemented
>> code["evaluate_basis_derivatives"] = not_implemented
>> code["evaluate_basis_derivatives_all"] = not_implemented
>>
>> Marie:
>>
>> code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know
>> what this function should do
>>
>
>
> Evidently, my comment was unclear ;)
> Should it look like this for CG_1?
>
> /// Tabulate the local-to-local mapping of dofs on entity (d, i)
> virtual void tabulate_entity_dofs(unsigned int* dofs,
>unsigned int d, unsigned int i) const
> {
> dofs[0] = i }
>
>
>
>
>> code["tabulate_coordinates"] = not_implemented # Marie doesn't
>> believe in this function
>>
>>
>
>
> What should this function do for the integral moment dofs, where there
> are more than one point per dof?
>
An error?
It is useful to know the dof location for some problems. A simple
example is for visualising higher-order Lagrange functions, which is
something that some libraries do support.
Garth
>> Marie or Kristian:
>>
>> code["interpolate_vertex_values"] = not_implemented
>>
>>
>
> Can fix.
>
>
> --
> Marie
>
>
>> In addition, we need to get the code generation for the integral
>> classes working. It's sort of working for the tensor representation
>> but not at all (?) for the quadrature representation. I'll be working
>> on getting the tensor representation completely in place.
>>
>> --
>> 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
