Re: [Ffc] Selection of element degree
Anders Logg wrote: On Mon, Nov 30, 2009 at 11:01:59PM +, Garth N. Wells wrote: Anders Logg wrote: We still haven't decided on the correct strategy for choosing the degree of an unspecified element. What we have now looks at the total degree of the form and then sets the degree accordingly. This doesn't really work weoull and the reason is quite simple: We can't figure out the total degree correctly if we don't know the degree of the coefficient. So my new suggestion is the following. We simply scan all elements in the form with specified degrees and set the degree to the maximum degree among the elements. Or should it be the maximum degree of the test and trial functions? Yes, that's basically what happens now. It looks at everything that has a degree so it looks at the test and trial functions but also at any coefficients that may happen to have a degree. That's useful for say v*f*g*dx if one of f and g happen to have a degree specified. Then the degree for the other needs to be the same. Why? -- Marie Do you take into accout derivatives, e.g. for w*dot(grad(v), grad(u))*dx would w be of the same order as v and u, or one order lower? Yes, derivatives are taken into account, but that's maybe not what we want. In the above case, the results will be q = 1 for w coming from max((1, 0, 0)) The 1 comes from the default degree q = 1 used when estimating the max degree for a form with an unknown coefficient. Perhaps we should not look at derivatives at all when selecting the quadrature degree? -- Anders Garth Here are some use cases: 1. v*f*dx If v is an element of degree q, then the degree for the approximation of f is set to q. For quadrature elements, this means thatd we get a quadrature error in the integral of order q + 1 which in many cases is the same as the convergence of the finite element method. For Lagrange elements, we get an interpolation error when approximating f of degree q + 1 so the situation is the same. 2. v*f*g*dx Same as above here if f and g have unspecified degrees. But if f or g should happen to have a degree higher than q, than that degree will be used for the other coefficient if unspecified. I'll go ahead and make this change in FFC. It's rather easy to change the strategy and FFC is being very verbose about the choices it makes, at least until we have settled on an acceptable strategy. ___ 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] Selection of element degree
Anders Logg wrote: On Tue, Dec 01, 2009 at 09:15:53AM +0100, Marie Rognes wrote: Anders Logg wrote: On Mon, Nov 30, 2009 at 11:01:59PM +, Garth N. Wells wrote: Anders Logg wrote: We still haven't decided on the correct strategy for choosing the degree of an unspecified element. What we have now looks at the total degree of the form and then sets the degree accordingly. This doesn't really work weoull and the reason is quite simple: We can't figure out the total degree correctly if we don't know the degree of the coefficient. So my new suggestion is the following. We simply scan all elements in the form with specified degrees and set the degree to the maximum degree among the elements. Or should it be the maximum degree of the test and trial functions? Yes, that's basically what happens now. It looks at everything that has a degree so it looks at the test and trial functions but also at any coefficients that may happen to have a degree. That's useful for say v*f*g*dx if one of f and g happen to have a degree specified. Then the degree for the other needs to be the same. Why? Since that's how the generated quadrature code works. It loops over quadrature points for an integrand and then it's useful if everything in the integrand is evaluated at those points. Ok. -- 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] [Branch ~ffc-core/ffc/dev] Rev 1348: Simple functionality now in place in compute_dof_ir. Missing tabulate_* and
Anders Logg wrote:
On Thu, Dec 17, 2009 at 02:32:19PM -, nore...@launchpad.net wrote:
revno: 1348
committer: m...@simula.no
branch nick: ffc-dev
timestamp: Thu 2009-12-17 15:29:05 +0100
message:
Simple functionality now in place in compute_dof_ir. Missing tabulate_* and
create_sub_dof_map.
What is init_cell and init_cell_finalize used for?
It was added to UFC to allow a form compiler to precompute the dofmap
by iterating over the mesh. If you look at DofMap.cpp in DOLFIN you
will see this:
// Initialize UFC dof map
const bool init_cells = dofmap.init_mesh(ufc_mesh);
if (init_cells)
{
UFCCell ufc_cell(dolfin_mesh);
for (CellIterator cell(dolfin_mesh); !cell.end(); ++cell)
{
ufc_cell.update(*cell);
dofmap.init_cell(ufc_mesh, ufc_cell);
}
dofmap.init_cell_finalize();
}
init_cell and init_cell_finalize are not used by FFC only SyFi so
init_mesh should return false and the other two should be empty.
I copied the previous, so init_mesh initializes the global_dimension
(and returns false)
We probably need something like
format["do_nothing"] --> "// Do nothing"
in the format dictionary.
Check (from previous).
--
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
___
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
Anders Logg wrote:
On Wed, Jan 06, 2010 at 04:25:30PM +0100, 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 }
Yes, this function should return an array of the dofs (dof indices) for
the dofs associated with entity number i of dimension d.
But perhaps we should check the d and the i as well to make sure that
d == 0 and i <= d + 1?
Here's another example of what should happen for P3 in 2D.
switch (d)
{
case 0:
if (i > 2)
throw std::runtime_error("Sensible error message.");
dofs[0] = i;
case 1:
if (i > 2)
throw std::runtime_error("Sensible error message.");
dofs[0] = 3 + 2*i;
dofs[1] = 3 + 2*i + 1;
case 2:
if (i > 0)
throw std::runtime_error("Sensible error message.");
dofs[0] = 10;
default:
throw std::runtime_error("Sensible error message.");
}
Ok!
The corresponding function num_entity_dofs should return the size of
the dofs array for each dimension so it should return 0, 2 and 1 in
the above case for d = 0, 1, 2.
Fixed already.
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?
I guess we need to throw an exception and think about possibly extending the
UFC interface with this extra information.
Will throw.
--
Marie
--
Anders
Marie or Kristian:
code["interpolate_vertex_values"] = not_implemented
Can fix.
___
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] [nore...@launchpad.net: [Branch ~ffc-core/ffc/dev] Rev 1412: Implemented interpolate_vertex_values for scalar CG_1.]
Anders Logg wrote: Which ones need to be cleaned up? I'll be working on getting tabulate_tensor working. Let me know if I should help with the cleaning up. I'm boldly throwing away anything that seems obsolete -- Marie -- Anders Subject: [Branch ~ffc-core/ffc/dev] Rev 1412: Implemented interpolate_vertex_values for scalar CG_1. From: nore...@launchpad.net Date: Thu, 07 Jan 2010 13:19:14 - To: Anders Logg To: Anders Logg revno: 1412 committer: Marie E. Rognes branch nick: ffc-unstable timestamp: Thu 2010-01-07 14:16:49 +0100 message: Implemented interpolate_vertex_values for scalar CG_1. Time to do some clean-ups with regard to code generation utilities before continuing. modified: ffc/codegeneration.py ffc/fiatinterface.py ffc/representation.py -- lp:~ffc-core/ffc/dev https://code.launchpad.net/~ffc-core/ffc/dev You are subscribed to branch lp:~ffc-core/ffc/dev. To unsubscribe from this branch go to https://code.launchpad.net/~ffc-core/ffc/dev/+edit-subscription. ___ 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] [Branch ~ffc-core/ffc/dev] Rev 1429: Finished support for 3D Lagrange in evaluate_basis.
Kristian Oelgaard wrote: 2010/1/8 : revno: 1429 committer: Kristian B. Ølgaard branch nick: dev timestamp: Fri 2010-01-08 16:54:41 +0100 message: Finished support for 3D Lagrange in evaluate_basis. modified: ffc/evaluatebasis.py 2D and 3D works now for Lagrange elements, 1D is not implemented because of a bug in FIAT. Before fixing BDM, Nedelec and MixedElements we should fix the following bugs: In FIAT.FiniteElement: set the correct mapping (self._mapping) for all elements I will fix. I'm pretty much done with my todo-list, so I'll start going through the demos and checking the generated code (for the functions that should be in place). -- 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] 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 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. How are things going? I'm have a bug or two to fix in evaluate_dof for integral moments and will then fix evaluate_dofs. Need to sort out FIAT normal directions before correct code is generated for RT/BDM though. Otherwise good. Can we move the prefetching of the various format["..."] into the global scope of codegeneration.py or is that evil? -- 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] Status
Kristian Oelgaard wrote: 2010/1/12 Marie Rognes : 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 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. How are things going? I'm have a bug or two to fix in evaluate_dof for integral moments and will then fix evaluate_dofs. Need to sort out FIAT normal directions before correct code is generated for RT/BDM though. Otherwise good. Can we move the prefetching of the various format["..."] into the global scope of codegeneration.py or is that evil? We need to do something different with the way we handle the formatting. At the moment we just import format from cpp in codegeneration.py, but that is clearly not an option if one wants to generate different code. Do we have any examples of different code that we want to generate? -- Marie Kristian -- 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 ___ 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] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats
nore...@launchpad.net wrote: revno: 1443 committer: Anders Logg branch nick: ffc-dev timestamp: Wed 2010-01-13 17:00:13 +0100 message: Remove \n in formats modified: ffc/cpp.py I like the \n in formats. Makes more sense to me to have a line break after for instance "each assignment" than explicitly stating breaks in the code generation functions. -- 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] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats
Anders Logg wrote:
On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
nore...@launchpad.net wrote:
revno: 1443
committer: Anders Logg
branch nick: ffc-dev
timestamp: Wed 2010-01-13 17:00:13 +0100
message:
Remove \n in formats
modified:
ffc/cpp.py
I like the \n in formats. Makes more sense to me to have a line break
after for instance "each assignment" than explicitly stating breaks
in the code generation functions.
I agree, but it becomes problematic in some cases. For example when we
insert things into the UFC format strings in the formatting stage:
/// Return the dimension of the finite element function space
virtual unsigned int space_dimension() const
{
%(space_dimension)s
}
Then we get things like
virtual unsigned int space_dimension() const
{
return 3;
}
Remove the "\n" in the format["return", "comment"] then ... and keep
"iadd" and "assign" then?
--
Marie
It's better with \n since \n can easily be added where needed but not
(so) easily removed where not needed.
___
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] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats
Anders Logg wrote:
On Wed, Jan 13, 2010 at 08:27:33PM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
nore...@launchpad.net wrote:
revno: 1443
committer: Anders Logg
branch nick: ffc-dev
timestamp: Wed 2010-01-13 17:00:13 +0100
message:
Remove \n in formats
modified:
ffc/cpp.py
I like the \n in formats. Makes more sense to me to have a line break
after for instance "each assignment" than explicitly stating breaks
in the code generation functions.
I agree, but it becomes problematic in some cases. For example when we
insert things into the UFC format strings in the formatting stage:
/// Return the dimension of the finite element function space
virtual unsigned int space_dimension() const
{
%(space_dimension)s
}
Then we get things like
virtual unsigned int space_dimension() const
{
return 3;
}
Remove the "\n" in the format["return", "comment"] then ... and keep
"iadd" and "assign" then?
I thought this was ok, but just found out it wasn't. It will lead to
things like
// Compute element tensor
A[0] += 0;
A[1] += 0;
A[2] += 0;
A[3] += 0;
A[4] += 0;
A[5] += 0;
A[6] += 0;
A[7] += 0;
A[8] += 0;
}
Could you remind me why that last spare line is so evil?
--
Marie
Since we can't avoid the last \n.
So the general rule needs to be no \n in formatting rules and we add
it where we need it.
--
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] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats
Anders Logg wrote:
On Wed, Jan 13, 2010 at 09:26:25PM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 08:27:33PM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
nore...@launchpad.net wrote:
revno: 1443
committer: Anders Logg
branch nick: ffc-dev
timestamp: Wed 2010-01-13 17:00:13 +0100
message:
Remove \n in formats
modified:
ffc/cpp.py
I like the \n in formats. Makes more sense to me to have a line break
after for instance "each assignment" than explicitly stating breaks
in the code generation functions.
I agree, but it becomes problematic in some cases. For example when we
insert things into the UFC format strings in the formatting stage:
/// Return the dimension of the finite element function space
virtual unsigned int space_dimension() const
{
%(space_dimension)s
}
Then we get things like
virtual unsigned int space_dimension() const
{
return 3;
}
Remove the "\n" in the format["return", "comment"] then ... and keep
"iadd" and "assign" then?
I thought this was ok, but just found out it wasn't. It will lead to
things like
// Compute element tensor
A[0] += 0;
A[1] += 0;
A[2] += 0;
A[3] += 0;
A[4] += 0;
A[5] += 0;
A[6] += 0;
A[7] += 0;
A[8] += 0;
}
Could you remind me why that last spare line is so evil?
Yes, it looks ugly.
We should generate code that not only runs faster than hand-written
code, but also looks better than hand-written code. :-)
Ah. I'll add this to my list of "obviously logical things" along with the
ordering of the ufc functions ;)
--
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] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats
Anders Logg wrote:
On Wed, Jan 13, 2010 at 12:35:35PM -0800, Johan Hake wrote:
On Wednesday 13 January 2010 12:26:25 Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 08:27:33PM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
nore...@launchpad.net wrote:
revno: 1443
committer: Anders Logg
branch nick: ffc-dev
timestamp: Wed 2010-01-13 17:00:13 +0100
message:
Remove \n in formats
modified:
ffc/cpp.py
I like the \n in formats. Makes more sense to me to have a line break
after for instance "each assignment" than explicitly stating breaks
in the code generation functions.
I agree, but it becomes problematic in some cases. For example when we
insert things into the UFC format strings in the formatting stage:
/// Return the dimension of the finite element function space
virtual unsigned int space_dimension() const
{
%(space_dimension)s
}
Then we get things like
virtual unsigned int space_dimension() const
{
return 3;
}
Remove the "\n" in the format["return", "comment"] then ... and keep
"iadd" and "assign" then?
Sorry for bumping into the discussion with a potentially irrelevant comment.
Have you considered collecting code snippets in a list by
code_snippets.append(code_snippet)
and then last you do a
code = "\n".join(code_snippets)
This might also be faster (if this snippeting is ever going to be a bottle
neck?), as string is immutable in Python which means that
code_snippet += some_code
always creates a new string.
Good point. This makes good sense in some places but not in others.
I think this is what we did before, and I can happily revert to that.
--
Marie
I've used it now in one more place.
Note that we are currently pushing to ffc/dev instead of ffc/main so
changes will appear there.
--
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] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats
Johan Hake wrote:
On Wednesday 13 January 2010 12:26:25 Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 08:27:33PM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
nore...@launchpad.net wrote:
revno: 1443
committer: Anders Logg
branch nick: ffc-dev
timestamp: Wed 2010-01-13 17:00:13 +0100
message:
Remove \n in formats
modified:
ffc/cpp.py
I like the \n in formats. Makes more sense to me to have a line break
after for instance "each assignment" than explicitly stating breaks
in the code generation functions.
I agree, but it becomes problematic in some cases. For example when we
insert things into the UFC format strings in the formatting stage:
/// Return the dimension of the finite element function space
virtual unsigned int space_dimension() const
{
%(space_dimension)s
}
Then we get things like
virtual unsigned int space_dimension() const
{
return 3;
}
Remove the "\n" in the format["return", "comment"] then ... and keep
"iadd" and "assign" then?
Sorry for bumping into the discussion with a potentially irrelevant comment.
Have you considered collecting code snippets in a list by
code_snippets.append(code_snippet)
and then last you do a
code = "\n".join(code_snippets)
This might also be faster (if this snippeting is ever going to be a bottle
neck?),
On a related subject, do we have some fancy timing functionality to time
the different
compiler stages and different functions? (In the spirit of: time first,
optimize afterwards ;) )
--
Marie
as string is immutable in Python which means that
code_snippet += some_code
always creates a new string.
Johan
___
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_basis
Kristian Oelgaard wrote: 2010/1/14 Anders Logg : On Thu, Jan 14, 2010 at 06:16:00PM +0100, Kristian Oelgaard wrote: 2010/1/14 Anders Logg : >Some indentation and newlines seem to need fixing in evaluate_basis. Sure, evaluate_basis is using the old format, once _derivatives is working I'll move to the new format and fix the code that looks ugly. Kristian ok. I think we're getting pretty close to having something that sort of works. Have you started thinking about getting the quadrature representation working again? Will you have time to fix it so we can make a new release before the end of January? I was hoping that I could finish the evaluate stuff this week or Monday at the latest, then I'll start looking at the quadrature code. I don't expect too many changes but I might be wrong. One problem with the January deadline is that it doesn't leave much time for testing. There is currently no unit test available for evaluate_basis and evaluate_basis_derivatives which I think is a big problem since it is quite impossible (for me) to check by simply looking at the code if the correct thing is computed. What I would like to have is something simple like the simple_verify_tensor, which will evaluate all the dofs on an element at some arbitrary coordinate on some random cell (NOT the reference cell). The derivatives should be evaluated up to the element degree. We don't have to use the forms in the demo directory, instead we should just compile single elements of different type (including mixed) and degree. It might also be a good idea to have similar tests for other functions of e.g., dof_map which have changed a lot? The tests should be implemented in the 'old' FFC and verified by ffc/dev before we can release a new FFC. FYI: I'm working on something like this. -- Marie We should also add references for simple_verify_tensors for the new forms you added and update the reference for the one you changed. (in the old FFC). Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktPVAEACgkQTuwUCDsYZdFQBQCfWDrYUR+GoegD/bK8zmp6eOIM 6ogAni7HNO4J2l7XGfmf9L8r9NqJK0Rn =GusQ -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] [nore...@launchpad.net: [Branch ~ffc-core/ffc/dev] Rev 1484: Lots of fixes in many places. DOLFIN Poisson demo now compiles. But an assertion]
Anders Logg wrote: Marie, could you have a look at init_mesh? There seems to be a small bug. For P1 elements, it generates _global_dimension = m.num_entities[1]; It should be _global_dimension = m.num_entities[0]; Fixed. -- Marie -- Anders Subject: [Branch ~ffc-core/ffc/dev] Rev 1484: Lots of fixes in many places. DOLFIN Poisson demo now compiles. But an assertion From: nore...@launchpad.net Date: Mon, 18 Jan 2010 20:27:15 - To: Anders Logg To: Anders Logg revno: 1484 committer: Anders Logg branch nick: ffc-dev timestamp: Mon 2010-01-18 21:24:30 +0100 message: Lots of fixes in many places. DOLFIN Poisson demo now compiles. But an assertion fails: demo: ./dolfin/fem/DofMap.h:78: unsigned int dolfin::DofMap::global_dimension() const: Assertion `_ufc_dofmap->global_dimension() > 0' failed. modified: ffc/analysis.py ffc/codegeneration.py ffc/compiler.py ffc/cpp.py ffc/evaluatedof.py ffc/tensor/tensorgenerator.py ffc/wrappers.py scripts/ffc -- lp:~ffc-core/ffc/dev https://code.launchpad.net/~ffc-core/ffc/dev You are subscribed to branch lp:~ffc-core/ffc/dev. To unsubscribe from this branch go to https://code.launchpad.net/~ffc-core/ffc/dev/+edit-subscription. ___ 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] [nore...@launchpad.net: [Branch ~ffc-core/ffc/dev] Rev 1484: Lots of fixes in many places. DOLFIN Poisson demo now compiles. But an assertion]
Anders Logg wrote: On Mon, Jan 18, 2010 at 09:42:34PM +0100, Marie Rognes wrote: Anders Logg wrote: Marie, could you have a look at init_mesh? There seems to be a small bug. For P1 elements, it generates _global_dimension = m.num_entities[1]; It should be _global_dimension = m.num_entities[0]; Fixed. Great! Now the Poisson demo runs but the solution looks wrong. There seems to be some coefficients missing in the generated tabulate_tensor for the right-hand side? -- 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] Unit test for RT2
Anders Logg wrote: Any idea why the RT2 unit test is failing? Two ideas coming up: (i) The interior moments for RT might have changed (ii) There might be a bug in interior moments in FIAT. -- Marie AssertionError: -0.082755579782240435 != -0.21220022923833148 -- 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] [Branch ~ffc-core/ffc/dev] Rev 1494: Somewhat evil and dead-slow (but very useful!) testing of generated
Kristian Oelgaard wrote: 2010/1/20 : revno: 1494 committer: Marie E. Rognes branch nick: ffc-unstable timestamp: Wed 2010-01-20 21:43:48 +0100 message: Somewhat evil and dead-slow (but very useful!) testing of generated element and dofmap code. A lot of stuff fails, including: (a) element_map fails for mixed elements (-> AL) (b) generated evaluate_basis_derivatives code does not compile (-> KBO) I just pushed a bug fix that should? fix this. When I try to run the tests in verify_element_code I get: Traceback (most recent call last): File "test.py", line 16, in from REFERENCE import references ImportError: No module named REFERENCE Did you forget to add the file? Yes (on purpose ;) ) The testing is not quite done yet. But, running generate_reference.py should generate the REFERENCE.py. -- 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] [Branch ~ffc-core/ffc/dev] Rev 1494: Somewhat evil and dead-slow (but very useful!) testing of generated
Kristian Oelgaard wrote: 2010/1/20 : revno: 1494 committer: Marie E. Rognes branch nick: ffc-unstable timestamp: Wed 2010-01-20 21:43:48 +0100 message: Somewhat evil and dead-slow (but very useful!) testing of generated element and dofmap code. A lot of stuff fails, including: (a) element_map fails for mixed elements (-> AL) (b) generated evaluate_basis_derivatives code does not compile (-> KBO) I just pushed a bug fix that should? fix this. Still fails for BDM/RT. Note that for the piola mapped elements it might be easier to use format["J"] and format ["inv(J)"] directly than the format["transform"]. (The latter constantly confuses me with regard to indices for dx/dX and dX/dx). Also detJ has been given an extra_ (by someone?) There is a doc-string in _change_variables in evaluatedof.py on how the Piolas should work in case reminding is useful. -- 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] [Branch ~ffc-core/ffc/dev] Rev 1494: Somewhat evil and dead-slow (but very useful!) testing of generated
Marie Rognes wrote: There is a doc-string in _change_variables in evaluatedof.py on how the Piolas should work in case reminding is useful. Actually, the one in interpolatevertex values is probably the relevant one. -- 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] [Branch ~ffc-core/ffc/dev] Rev 1502: Fixes for covariant piola. Marie finally remembered why it should be
Harish Narayanan wrote: On 21/01/2010 14:19, Kristian Oelgaard wrote: 2010/1/21 : revno: 1502 committer: Marie E. Rognes branch nick: ffc-unstable timestamp: Thu 2010-01-21 15:13:40 +0100 message: Fixes for covariant piola. Marie finally remembered why it should be (j, i) instead of (i, j). Cool, I guess this means that the indices is based on some theory after all :) Would the reason why the covariant Piola map doesn't contain a det(J) but the contravariant Piola does be clarified on reading RognesKirbyEtAl2009? Yes. -- 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] [Branch ~ffc-core/ffc/dev] Rev 1518: Make symbolics work with new format.
Kristian Oelgaard wrote: I'm moving to the new format in cpp.py. A few remarks: 'format' is a builtin function, so we should probably call it something else. I made some changes such that 'add' -> ' + ', 'mul' -> '*'. If one wants something more intelligent 'addition' and 'multiply' maps to the functions _add and _multiply. Have you replaced add/mul with addition/multiply elsewhere? -- Marie Is 'float' meant to replace the old 'floating point'? If it is, we need to handle the precision somehow, this is crucial for the regression tests. Kristian 2010/1/22 : Merge authors: Anders Logg (logg) revno: 1518 [merge] committer: Kristian B. Ølgaard branch nick: dev timestamp: Fri 2010-01-22 14:20:36 +0100 message: Make symbolics work with new format. removed: test/unit/test_symbolics.py added: test/unit/symbolics/ test/unit/symbolics/testdgelastodyn.py test/unit/symbolics/testelasticity2d.py test/unit/symbolics/testelasticityterm.py test/unit/symbolics/testelasweighted.py test/unit/symbolics/testelasweighted2.py test/unit/symbolics/testexpandoperations.py test/unit/symbolics/testfloat.py test/unit/symbolics/testfloatoperators.py test/unit/symbolics/testfraction.py test/unit/symbolics/testfractionoperators.py test/unit/symbolics/testmixedsymbols.py test/unit/symbolics/testnotfinished.py test/unit/symbolics/testpoisson.py test/unit/symbolics/testproduct.py test/unit/symbolics/testproductoperators.py test/unit/symbolics/testrealexamples.py test/unit/symbolics/testreducegip.py test/unit/symbolics/testreduceoperations.py test/unit/symbolics/testreducevartype.py test/unit/symbolics/testsum.py test/unit/symbolics/testsumoperators.py test/unit/symbolics/testsymbol.py test/unit/symbolics/testsymbolics.py test/unit/symbolics/testsymboloperators.py modified: ffc/codegeneration.py ffc/compiler.py ffc/cpp.py ffc/evaluatebasis.py ffc/evaluatedof.py ffc/log.py ffc/quadrature/floatvalue.py ffc/quadrature/fraction.py ffc/quadrature/optimisedquadraturetransformer.py ffc/quadrature/product.py ffc/quadrature/reduce_operations.py ffc/quadrature/sumobj.py ffc/quadrature/symbol.py ffc/quadrature/symbolics.py ffc/tensor/tensorgenerator.py The size of the diff (6327 lines) is larger than your specified limit of 1000 lines -- lp:~ffc-core/ffc/dev https://code.launchpad.net/~ffc-core/ffc/dev You are subscribed to branch lp:~ffc-core/ffc/dev. To unsubscribe from this branch go to https://code.launchpad.net/~ffc-core/ffc/dev/+edit-subscription. ___ 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
[Ffc] Current ffc-dev status element/dofmap
Summary of current status for non-mixed elements:
- CG matches old results for (at least) k = 1, ..., 4, which is good :)
Errors:
(1) The generated code for evaluate_basis_derivatives_all for DG_0 does
not compile.
Changes in output:
(i) num_sub_elements is 0 instead of 1 for all non-mixed elements
(ii) The ordering of the degrees of freedom for DG has changed. This
affects evaluate_dof, interpolate_vertex_value and tabulate_coordinates.
Hence, the output from these functions will not match reference. The
results look correct in the eye-norm though.
(iii) There is a bug in the ffc-stable codegenerator_utils.py
'inner_product' (-1*1 = 1)! This affects interpolate_vertex_values
for H(div/curl) elements (at least). The old values are wrong. The new
values look right.
(iv) FIAT has changed the dofs for interior moments for H(div/curl)
elements. This affects evaluate_dof, tabulate_coordinates etc.
Bottom-line: Things look good. I'll go through the higher-order
H(div/curl) elements in FIAT and add suitable unit tests.
For mixed elements such as
element = MixedElement([VectorElement('CG', 'triangle', 3),
FiniteElement('DG', 'triangle', 2)])
I'm still getting errors like:
This is FFC, the FEniCS Form Compiler, version 0.7.1.
For further information, visit http://www.fenics.org/ffc/.
Compiler stage 1: Analyzing form(s)
---
Compiler stage 1 finished in 0.000413179 seconds.
Compiler stage 2: Computing intermediate representation
---
Computing representation of 3 elements
Reusing element from cache
Reusing element from cache
Reusing element from cache
Reusing element from cache
Traceback (most recent call last):
File "/home/meg/local/bin/ffc", line 167, in
sys.exit(main(sys.argv[1:]))
File "/home/meg/local/bin/ffc", line 151, in main
compile_element(ufd.elements, ufd.object_names, prefix, options)
File "/home/meg/local/lib64/python2.6/site-packages/ffc/compiler.py",
line 181, in compile_element
ir = compute_ir(analysis, options)
File
"/home/meg/local/lib64/python2.6/site-packages/ffc/representation.py",
line 52, in compute_ir
ir_elements = [_compute_element_ir(e, i, element_map) for (i, e) in
enumerate(elements)]
File
"/home/meg/local/lib64/python2.6/site-packages/ffc/representation.py",
line 92, in _compute_element_ir
ir["create_sub_element"] = _create_sub_foo(ufl_element, element_map)
File
"/home/meg/local/lib64/python2.6/site-packages/ffc/representation.py",
line 316, in _create_sub_foo
return [element_map[e] for e in ufl_element.sub_elements()]
KeyError: FiniteElement('Lagrange', Cell('triangle', 1, Space(2)), 3)
--
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] [Branch ~ffc-core/ffc/dev] Rev 1518: Make symbolics work with new format.
Kristian Oelgaard wrote: 2010/1/22 Marie Rognes : Kristian Oelgaard wrote: I'm moving to the new format in cpp.py. A few remarks: 'format' is a builtin function, so we should probably call it something else. I made some changes such that 'add' -> ' + ', 'mul' -> '*'. If one wants something more intelligent 'addition' and 'multiply' maps to the functions _add and _multiply. Have you replaced add/mul with addition/multiply elsewhere? Yes, and Poisson and Elasticity compiles but I might have missed some. It should be an easy fix if it breaks something. I did this such that 'add' does the same as __add__ in Python etc. Ok, great :) -- Marie Kristian -- Marie Is 'float' meant to replace the old 'floating point'? If it is, we need to handle the precision somehow, this is crucial for the regression tests. Kristian 2010/1/22 : Merge authors: Anders Logg (logg) revno: 1518 [merge] committer: Kristian B. Ølgaard branch nick: dev timestamp: Fri 2010-01-22 14:20:36 +0100 message: Make symbolics work with new format. removed: test/unit/test_symbolics.py added: test/unit/symbolics/ test/unit/symbolics/testdgelastodyn.py test/unit/symbolics/testelasticity2d.py test/unit/symbolics/testelasticityterm.py test/unit/symbolics/testelasweighted.py test/unit/symbolics/testelasweighted2.py test/unit/symbolics/testexpandoperations.py test/unit/symbolics/testfloat.py test/unit/symbolics/testfloatoperators.py test/unit/symbolics/testfraction.py test/unit/symbolics/testfractionoperators.py test/unit/symbolics/testmixedsymbols.py test/unit/symbolics/testnotfinished.py test/unit/symbolics/testpoisson.py test/unit/symbolics/testproduct.py test/unit/symbolics/testproductoperators.py test/unit/symbolics/testrealexamples.py test/unit/symbolics/testreducegip.py test/unit/symbolics/testreduceoperations.py test/unit/symbolics/testreducevartype.py test/unit/symbolics/testsum.py test/unit/symbolics/testsumoperators.py test/unit/symbolics/testsymbol.py test/unit/symbolics/testsymbolics.py test/unit/symbolics/testsymboloperators.py modified: ffc/codegeneration.py ffc/compiler.py ffc/cpp.py ffc/evaluatebasis.py ffc/evaluatedof.py ffc/log.py ffc/quadrature/floatvalue.py ffc/quadrature/fraction.py ffc/quadrature/optimisedquadraturetransformer.py ffc/quadrature/product.py ffc/quadrature/reduce_operations.py ffc/quadrature/sumobj.py ffc/quadrature/symbol.py ffc/quadrature/symbolics.py ffc/tensor/tensorgenerator.py The size of the diff (6327 lines) is larger than your specified limit of 1000 lines -- lp:~ffc-core/ffc/dev https://code.launchpad.net/~ffc-core/ffc/dev You are subscribed to branch lp:~ffc-core/ffc/dev. To unsubscribe from this branch go to https://code.launchpad.net/~ffc-core/ffc/dev/+edit-subscription. ___ 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] New handling of integrals
Anders Logg wrote: I have pushed a changeset that simplifies the handling of integrals of different types and domains. This unfortunately breaks the quadrature but the changes should lead to large simplifications. I hope you're up for it Kristian... Tensor is broken too. Try MixedPoisson. -- Marie For the tensor representation, I was able to remove large portions of code for extracting integrals of various types (domain_type) and on different sub domains (domain_id). This now happens in UFL and form_data has a new member called integral_data, that just lists all the data associated with different (UFC) integrals: [(domain_type, domain_id, integrals, metadata), (domain_type, domain_id, integrals, metadata), ...] We then iterate over all integral tuples in representation.py and call the appropriate backend depending on metadata["representation"]. I have also updated analysis.py so that it makes sure metadata is common for all UFL integrals that should go into the same UFC integral. Let me know if you have any questions on the new format. -- 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
[Ffc] Jacobi code in codesnippets
Would anyone object if I removed jacobian_nD in codesnippets and moved only_jacobian_nD to jacobian_nD? Also can we remove all the _FIAT_ stuff from codesnippets? -- 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] Jacobi code in codesnippets
Anders Logg wrote: On Mon, Jan 25, 2010 at 12:47:36PM +0100, Marie Rognes wrote: Would anyone object if I removed jacobian_nD in codesnippets and moved only_jacobian_nD to jacobian_nD? Could you make sure to make the corresponding changes in tensorgenerator.py, lines 66, 82, 99? I'll do my best ;) Also can we remove all the _FIAT_ stuff from codesnippets? Yes. Ok. There seems to be one occurance of 'fiat_coordinate_map' in evaluatebasis.py Kristian? -- 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] Jacobi code in codesnippets
Kristian Oelgaard wrote: 2010/1/25 Anders Logg : On Mon, Jan 25, 2010 at 12:47:36PM +0100, Marie Rognes wrote: Would anyone object if I removed jacobian_nD in codesnippets and moved only_jacobian_nD to jacobian_nD? Could you make sure to make the corresponding changes in tensorgenerator.py, lines 66, 82, 99? Also can we remove all the _FIAT_ stuff from codesnippets? Yes. No, I use that in evaluate_basis* Isn't everything in FIAT now parameterized over the given reference element? -- Marie Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktdhsoACgkQTuwUCDsYZdH0HQCdEXO5aE4L/oYxeuxNfa/MwaLR mWsAnitr9OPn2iHTYKYxUAqMoO39/8DT =HebG -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] Jacobi code in codesnippets
Kristian Oelgaard wrote: 2010/1/25 Marie Rognes : Kristian Oelgaard wrote: 2010/1/25 Anders Logg : On Mon, Jan 25, 2010 at 12:47:36PM +0100, Marie Rognes wrote: Would anyone object if I removed jacobian_nD in codesnippets and moved only_jacobian_nD to jacobian_nD? Could you make sure to make the corresponding changes in tensorgenerator.py, lines 66, 82, 99? Also can we remove all the _FIAT_ stuff from codesnippets? Yes. No, I use that in evaluate_basis* Isn't everything in FIAT now parameterized over the given reference element? In expansions.py, the points are mapped to the reference element (where the expansion functions are defined i.e., FIAT), and since I'm generating a cpp version of FIAT code it is the easiest thing to do. Maybe it is possible to use points defined on the UFC elements, but I wouldn't know what to change and where. Ok. I'll leave the snippet used then. -- Marie Kristian -- Marie Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktdhsoACgkQTuwUCDsYZdH0HQCdEXO5aE4L/oYxeuxNfa/MwaLR mWsAnitr9OPn2iHTYKYxUAqMoO39/8DT =HebG -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 update
Let me know if I should do anything else than adding unit tests for RT/BDM/NED. (Aaargh, btw). Is the jit compilation working? -- Marie Anders Logg wrote: It's starting to look better. The following 8 tests are currently failing: Generating code --- 1. ElementRestriction.ufl failed *** FFC: Sorry, finite element of type "ElementRestriction" are not supported by FIAT. I assume Kristian knows what to do. 2. QuadratureElement.ufl failed *** FFC: Sorry, finite element of type "Quadrature" are not supported by FIAT. I assume Kristian knows what to do. 3. TensorWeightedPoisson.ufl failed *** FFC: Can only handle rank 0 or rank 1 tensors. This is a bug in the selection of representation. The tensor representation should realize earlier that it can't handle tensors so quadrature should be selected. Building test programs -- 4. Constant failed Constant.h:1044: error: unused variable ‘x’ Bug in evaluate_basis or removed_unused? 5. FacetIntegrals failed Same problem in evaluate_basis 6. MixedMixedElement failed Same problem in evaluate_basis 7. VectorLaplaceGradCurl failed VectorLaplaceGradCurl.h:3650: error: ‘K_00’ was not declared in this scope Another problem in evaluate_basis Validating generated programs - 8. P5tet.bin failed Segmentation fault when calling evaluate_basis_derivatives -- 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 update
Anders Logg wrote: On Mon, Jan 25, 2010 at 08:16:06PM +0100, Marie Rognes wrote: Let me know if I should do anything else than adding unit tests for RT/BDM/NED. (Aaargh, btw). I hope to add more a selection of elements to the regression tests later. Then you can feel very free to help with the debugging. :-) Hurray ;) Is the jit compilation working? I hope so. It worked last week but it might have broken since then. Looks slightly suboptimal, cf below. (Also, something goes awry in the generation of the dolfin wrapper code for mixed elements. Try compiling the dolfin Elasticity demo for instance.) m...@localhost ~/local/src/fenics/dolfin/demo/pde/poisson/python $ python demo.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "demo.py", line 24, in V = FunctionSpace(mesh, "CG", 1) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py", line 226, in __init__ FunctionSpaceBase.__init__(self, mesh, element) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py", line 44, in __init__ ufc_element, ufc_dofmap = jit(self._ufl_element) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py", line 44, in mpi_jit return local_jit(*args, **kwargs) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py", line 108, in jit return jit_compile(form, options) File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 59, in jit return jit_element(object, options) File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 150, in jit_element return extract_element_and_dofmap(module) File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 182, in extract_element_and_dofmap return (getattr(module, module.__name__ + "_0_finite_element_0")(), AttributeError: 'module' object has no attribute 'form_20a60ceb7c37f811570413455597a3abad2819b8_0_finite_element_0' ___ 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] Misc bugs
Anders Logg wrote: A list of misc bugs detected by the regression tests: 1. global_dimension old = 10003 new = 10001 2. num_entity_dofs_2 old = 0 new = 1 (related to global_dimension error?) 3. interpolate_vertex_values old = 0 0 0 new = 0.306 0.4256 0.7644 (strange) Will look and fix above, unless you have already done so. -- Marie 4. evaluate_basis[_derivatives][_all] Lots of errors One thing to consider might be if the points are chosen in a bad way in the regression tests (like outside the cell) -- 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] Misc bugs
Anders Logg wrote: On Tue, Jan 26, 2010 at 11:34:49AM +0100, Marie Rognes wrote: Anders Logg wrote: A list of misc bugs detected by the regression tests: 1. global_dimension old = 10003 new = 10001 2. num_entity_dofs_2 old = 0 new = 1 (related to global_dimension error?) This one seems slightly unfair: num_entity_dofs with modded ffc-0.7.1 always returns zero. -- Marie 3. interpolate_vertex_values old = 0 0 0 new = 0.306 0.4256 0.7644 (strange) Will look and fix above, unless you have already done so. No, I was hoping you would fix it. I'll just sit back now and watch the changesets roll in. :-) -- 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] Misc bugs
Anders Logg wrote: On Tue, Jan 26, 2010 at 11:34:49AM +0100, Marie Rognes wrote: Anders Logg wrote: A list of misc bugs detected by the regression tests: 1. global_dimension old = 10003 new = 10001 2. num_entity_dofs_2 old = 0 new = 1 (related to global_dimension error?) 3. interpolate_vertex_values old = 0 0 0 new = 0.306 0.4256 0.7644 (strange) This one is caused by the very clever reuse of 'values' in ufctest.h. The argument 'values' is filled by evaluate_dofs, which (wildly guessing) probably returns zero in the modded 0.7.1 ffc. Hence the interpolated values are also zero. -- Marie Will look and fix above, unless you have already done so. No, I was hoping you would fix it. I'll just sit back now and watch the changesets roll in. :-) -- 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] Status update
Anders Logg wrote: On Mon, Jan 25, 2010 at 08:46:47PM +0100, Marie Rognes wrote: Anders Logg wrote: On Mon, Jan 25, 2010 at 08:16:06PM +0100, Marie Rognes wrote: Let me know if I should do anything else than adding unit tests for RT/BDM/NED. (Aaargh, btw). I hope to add more a selection of elements to the regression tests later. Then you can feel very free to help with the debugging. :-) Hurray ;) Is the jit compilation working? I hope so. It worked last week but it might have broken since then. Looks slightly suboptimal, cf below. JIT compiler seems to work again. Definite improvement :) Could you take a look at what goes wrong with dolfin/demo/pde/mixed-poisson/python/demo.py ? -- Anders (Also, something goes awry in the generation of the dolfin wrapper code for mixed elements. Try compiling the dolfin Elasticity demo for instance.) m...@localhost ~/local/src/fenics/dolfin/demo/pde/poisson/python $ python demo.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "demo.py", line 24, in V = FunctionSpace(mesh, "CG", 1) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py", line 226, in __init__ FunctionSpaceBase.__init__(self, mesh, element) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py", line 44, in __init__ ufc_element, ufc_dofmap = jit(self._ufl_element) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py", line 44, in mpi_jit return local_jit(*args, **kwargs) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py", line 108, in jit return jit_compile(form, options) File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 59, in jit return jit_element(object, options) File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 150, in jit_element return extract_element_and_dofmap(module) File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 182, in extract_element_and_dofmap return (getattr(module, module.__name__ + "_0_finite_element_0")(), AttributeError: 'module' object has no attribute 'form_20a60ceb7c37f811570413455597a3abad2819b8_0_finite_element_0' ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] Status (again)
FFC compilation fails for ElementRestriction.ufl QuadratureElement.ufl TensorWeightedPoisson.ufl Running test programs fails for P5tet.bin(Segmentation faults after evaluate_basis(0, ...) Differences in output evaluate_basis* FacetIntegrals.out (missing value in generated code (many)) SubDomain.out(missing value in generated code (tabulate_tensor)) Others: tabulate_entity_dofs (errors thrown are all wrong. Marie will fix) -- 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] Status (again)
Medhi Nikbakht wrote: On Wed, 2010-01-27 at 15:50 +0100, Marie Rognes wrote: FFC compilation fails for ElementRestriction.ufl The error message says that "ElementRestriction" is not supported by FIAT. How will the restricted elements be implemented? Wouldn't it be better to support them inside FFC? They will be supported inside FFC. This is just one of items that remains for the FFC development branch. -- Marie Mehdi QuadratureElement.ufl TensorWeightedPoisson.ufl Running test programs fails for P5tet.bin(Segmentation faults after evaluate_basis(0, ...) Differences in output evaluate_basis* FacetIntegrals.out (missing value in generated code (many)) SubDomain.out(missing value in generated code (tabulate_tensor)) Others: tabulate_entity_dofs (errors thrown are all wrong. Marie will fix) -- 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 ___ 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] Bug in evaluate_dofs
Anders Logg wrote: There's a bug in evaluate_dofs for tensor-valued elements. For TensorWeightedPoisson, we get a segmentation fault because the array named vals declared on line 1319 has length 2 when the value_size is 4 (=2*2) for the mixed element. The vals array is used as input to the evaluate call which will assign to all for components. Not surprising, I haven't really taken care of tensor-valued elements at all. I can fix tomorrow. How are we handling tensor-valued elements btw? Flattening them? -- 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] Status (again)
Anders Logg wrote: On Wed, Jan 27, 2010 at 08:48:10PM +0100, Anders Logg wrote: Update: FFC compilation fails for ElementRestriction.ufl QuadratureElement.ufl GCC compilation works for all forms Running test programs fails for P5tet.bin Output test fails for all forms evaluate_basis_* 3048 errors tabulate_tensor 34 errors interpolate_vertex_values 12 errors value_dimension 2 errors num_coefficients 1 error Good job with evaluate_basis Kristian. Update: evaluate_basis_derivatives* 1517 tabulate_tensor 45 (worse than before?) interpolate_vertex_values 12 I think these can be ignored as well. evaluate_basis 4 value_dimension2 num_coefficients 1 The following can be ignored (not implemented before): evaluate_basis_all evaluate_dofs I made a quick fix in ffc-0.7.1-reference implementing evaluate_dofs, so you shouldn't get any errors for this one. -- Marie num_entity_dofs -- 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_basis update
k.b.oelga...@gmail.com wrote:
Hi,
I'm running some tests on evaluate_basis with different elements and
here are some results.
The following elements are no longer supported by FIAT:
Crouzeix-Raviart and Brezzi-Douglas-Fortin-Marini, will they be
supported again?
I would say that BDFM is not important, but that CR is.
The following elements could not be compiled by gcc because of a
problem with and undefined variable 'copy' in evaluate_dof() and
evaluate_dofs():
FiniteElement('Brezzi-Douglas-Marini', Cell('triangle', 1, Space(2)), 2)
FiniteElement('Brezzi-Douglas-Marini', Cell('triangle', 1, Space(2)), 3)
FiniteElement('Brezzi-Douglas-Marini', Cell('tetrahedron', 1,
Space(3)), 2)
FiniteElement('Brezzi-Douglas-Marini', Cell('tetrahedron', 1,
Space(3)), 3)
FiniteElement('Nedelec 1st kind H(curl)', Cell('triangle', 1,
Space(2)), 2)
FiniteElement('Nedelec 1st kind H(curl)', Cell('triangle', 1,
Space(2)), 3)
FiniteElement('Nedelec 1st kind H(curl)', Cell('tetrahedron', 1,
Space(3)), 3)
Known potential issue. Will fix.
A funny thing to note is that
FiniteElement('Nedelec 1st kind H(curl)', Cell('tetrahedron', 1,
Space(3)), 2)
compiles fine.
Values differ for the following DG element:
FiniteElement('Discontinuous Lagrange', Cell('interval', 1,
Space(1)), 2)
FiniteElement('Discontinuous Lagrange', Cell('interval', 1,
Space(1)), 3)
FiniteElement('Discontinuous Lagrange', Cell('interval', 1,
Space(1)), 4)
FiniteElement('Discontinuous Lagrange', Cell('tetrahedron', 1,
Space(3)), 2)
FiniteElement('Discontinuous Lagrange', Cell('tetrahedron', 1,
Space(3)), 3)
FiniteElement('Discontinuous Lagrange', Cell('tetrahedron', 1,
Space(3)), 4)
FiniteElement('Discontinuous Lagrange', Cell('triangle', 1,
Space(2)), 2)
FiniteElement('Discontinuous Lagrange', Cell('triangle', 1,
Space(2)), 3)
FiniteElement('Discontinuous Lagrange', Cell('triangle', 1,
Space(2)), 4)
but Marie changed the ordering of dofs, so that is not big mystery.
I refuse to take the blame for changing the ordering of the dofs! ;)
I checked some values manually and it looks like the values has just
been shifted around so the result should be OK.
Good!
Values also differ for the following elements:
FiniteElement('Nedelec 1st kind H(curl)', Cell('tetrahedron', 1,
Space(3)), 2)
FiniteElement('Raviart-Thomas', Cell('tetrahedron', 1, Space(3)), 2)
FiniteElement('Raviart-Thomas', Cell('tetrahedron', 1, Space(3)), 3)
FiniteElement('Raviart-Thomas', Cell('triangle', 1, Space(2)), 2)
FiniteElement('Raviart-Thomas', Cell('triangle', 1, Space(2)), 3)
For the Nedelec element values look the same, but they appear in
different places.
If I call tabulate on the FIAT element (reference) I get matching
results as when I call evaluate_basis(), so I guess it is OK. Marie,
has the ordering of dofs changed for Nedelec?
Don't know actually. I can check evaluate_dof.
For the Raviart-Thomas elements the story is almost the same. The only
difference is that for e.g.,
FiniteElement('Raviart-Thomas', Cell('triangle', 1, Space(2)), 2)
I get values like '0.4 0.6 0.2 -0.2 -0.3' in the
'old' version of FFC and FIAT, but in the new FFC (and the new FIAT) I
get values like:
0.7 0.3 -0.0 -0.0 -0.3' when I tabulate the basis
at the same point. Marie, has something changed for RT elements?
Yes. Rob changed the interior degrees of freedom for polynomial degrees
> 1 from integral moments to point values. Hence the basis
functions have changed.
(Note that there is a unit test for RT2 on a triangle that passes :) )
--
Marie
For both old and new FFC FIAT.tabulate() and evaluate_basis() agrees
so I guess the values are OK.
If the above issues can be confirmed and addressed It looks like
evaluate_basis can be trusted.
Kristian
___
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 (again)
Kristian Oelgaard wrote: 2010/1/27 Medhi Nikbakht : On Wed, 2010-01-27 at 15:50 +0100, Marie Rognes wrote: FFC compilation fails for ElementRestriction.ufl The error message says that "ElementRestriction" is not supported by FIAT. How will the restricted elements be implemented? Wouldn't it be better to support them inside FFC? There are two types of restrictions supported in UFL (and the old FFC). 1) Restriction onto Measure (like 'dc'), which is what you want. 2) Restriction onto Cell, as for instance restricting a Lagrange element defined on a 'triangle' to its facets. The third restriction that we might want in the future is restriction onto subdomains possible in UFL but not in FFC. To implement 1) I think it is enough to just attach the Measure as a member to the fiat_element and the simply look for it in appropriate places when generating the code. That means handle it in FFC.fiatinterface, could that work? To implement 2) I modified the return value of entity_dofs() and tabulate() accordingly. To do it this way again we will need to make changes in FIAT_NEW.FiniteElement and FFC.MixedElement. I'm not sure it is a good idea to make FIAT_NEW.PolynomialSet aware of restrictions, but I don't know enough about the FIAT internals to back up this claim. How about adding a class RestrictedElement that contains an element and (based on the restriction) a list of relevant basis function indices, and overrides the methods as FiniteElement/MixedElement? No need to make FIAT aware of this. -- Marie I'm not really sure how to handle the restriction onto subdomains, but it should most likely be implemented in FFC. Kristian Mehdi QuadratureElement.ufl TensorWeightedPoisson.ufl Running test programs fails for P5tet.bin(Segmentation faults after evaluate_basis(0, ...) Differences in output evaluate_basis* FacetIntegrals.out (missing value in generated code (many)) SubDomain.out(missing value in generated code (tabulate_tensor)) Others: tabulate_entity_dofs (errors thrown are all wrong. Marie will fix) -- 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 ___ 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 (again)
Garth N. Wells wrote: Anders Logg wrote: On Thu, Jan 28, 2010 at 09:14:36PM +0100, Marie Rognes wrote: Kristian Oelgaard wrote: 2010/1/27 Medhi Nikbakht : On Wed, 2010-01-27 at 15:50 +0100, Marie Rognes wrote: FFC compilation fails for ElementRestriction.ufl The error message says that "ElementRestriction" is not supported by FIAT. How will the restricted elements be implemented? Wouldn't it be better to support them inside FFC? There are two types of restrictions supported in UFL (and the old FFC). 1) Restriction onto Measure (like 'dc'), which is what you want. 2) Restriction onto Cell, as for instance restricting a Lagrange element defined on a 'triangle' to its facets. The third restriction that we might want in the future is restriction onto subdomains possible in UFL but not in FFC. To implement 1) I think it is enough to just attach the Measure as a member to the fiat_element and the simply look for it in appropriate places when generating the code. That means handle it in FFC.fiatinterface, could that work? To implement 2) I modified the return value of entity_dofs() and tabulate() accordingly. To do it this way again we will need to make changes in FIAT_NEW.FiniteElement and FFC.MixedElement. I'm not sure it is a good idea to make FIAT_NEW.PolynomialSet aware of restrictions, but I don't know enough about the FIAT internals to back up this claim. How about adding a class RestrictedElement that contains an element and (based on the restriction) a list of relevant basis function indices, and overrides the methods as FiniteElement/MixedElement? No need to make FIAT aware of this. This sounds good. I think I understand (somewhat) what (2) is supposed to do, but not (1). And as Garth suggests, I think a better name is FacetElement. Does a FacetElement know that it can only be integrated over facets, not the interior, or can it? It's possible that it could be integrated over the interior, but probably not very sensible. I think that FacetElement is a bit misleading, since what it does is just take the dofs of a cell that live on the facets. With FacetElement I think of an element of topological dim 2 embedded in 3D. Agree. Besides, the concept is more general than just for facets. The idea is simply to take the span of a subset of the basis functions, right. Maybe calling it a restriction is misleading in the first place... -- Marie 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] Status (again)
Kristian Oelgaard wrote: On 28 January 2010 22:12, Garth N. Wells wrote: Kristian Oelgaard wrote: On 28 January 2010 21:16, Garth N. Wells wrote: Anders Logg wrote: On Thu, Jan 28, 2010 at 07:51:52PM +0100, Kristian Oelgaard wrote: On 28 January 2010 19:18, Anders Logg wrote: Update: ElementRestriction.ufl Could you have a look at and comment on the discussion about element restrictions? It was posted a couple of days ago on the list. It would be nice to get right the first time. Kristian I can't find the discussion about element restrictions. What is the status of getting ElementRestriction working? I haven't looked at restrictions at all so I don't know how it should be handled. And shouldn't the name of the element be RestrictedElement rather than ElementRestriction? I should probably be 'FacetRestriction'. No, because we can restrict elements to Cell, Measure and possibly SubDomain. 'Can' or 'would like to'? ;) OK, so it is 'could' in the old FFC for restrictions onto facets and to Measure (the *dc that Mehdi uses), the sub-domains business is easy to switch on i UFL, but harder to implement in FFC and it is currently unsupported in both old and new FFC. And it wouldn't like to be able to restrict elements to SubDomains and the moment :) Could somebody fill me in on precisely what the "Restrictions to Measure" and "Restrictions to SubDomains" mean? (Math wanted ;) ) -- 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] Release plans
Kristian Oelgaard wrote: On 29 January 2010 01:23, Anders Logg wrote: There seem to be just a couple of issues remaining in order of importance: 1. QuadratureElement 2. DOLFIN fem unit test 3. evaluate_basis_derivatives 4. RestrictedElement Among these, I would say 1-2 are crucial to fix before 0.9.0, but 3-4 are less crucial. It would be good to have evaluate_basis_derivatives working, but I don't know how much work is involved. First my apologies for the late reply, Internet was down again all morning and it pisses me off. Now that BDM elements also compiles for gcc it looks like everything is in place for evaluate_basis. CG and CR elements work, and so does all linear elements and DG constants. 2nd and 3rd order elements of BDM, RT, and DG type does not give the same result but there are explanations for this and at least it looks like they agree with the values you would get from FIAT if you tabulate on the reference element. evaluate_basis_derivatives works for CG elements and for most elements of degree 1. I'm working on some kind of unit testing framework for evaluate_basis and evaluate_basis_derivatives, such that we can make sure that at least cpp code and FIAT agrees on the reference element. If this test works, then the only bug can be in the transformation back to the physical element, but since this works for CG elements I don't see why it shouldn't for other elements too. However, I'll put this development on hold until Quadrature and Restricted elements work. RestrictedElement is also good to have, but I would say it is less important, especially since it's unclear what exactly it should do and how it should be implemented. It should be implemented like I did it in the old FFC :) w.r.t. the demo, it should test if restrictions on a MixedElement are propagated to the sub elements and that a restricted element can appear in a MixedElement. I'm taking care of RestrictedElement (onto facets/cells etc) at ze moment. -- Marie We should also have the following in mind: (i) The number of users relying on restricted elements is most likely very small and they are very likely using the development version anyway so if a fix for restricted elements comes next week, that will be ok. (ii) If we make a release of 0.9.0 now and package it for Debian/Ubuntu, it is still possible to request Ubuntu to pull bug fixes for some time. So we can release 0.9.0 now and then 0.9.1 in a couple of weeks. I think this sounds like a good plan. I'll work on getting QuadratureElement up and running and the RestrictedElement. If there are any bugs in evaluate_basis_derivatives we'll release it in 0.9.1. The code really needs some cleaning up, and we should also rearrange some of the utility functions, but that can wait until 0.9.1. Kristian One of the reasons I'm pressing on with the release is the interface changes that we have made in both FFC and DOLFIN. It would be good to introduce these as early as possible to avoid confusion about how to write a form file (Coefficient, not Function) and how to implement Expressions (Array, not std::vector). -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktiKnAACgkQTuwUCDsYZdHEmgCcD3jSWQfDtVnNktS2+XMgQMhg FkQAoJL6rELvZTzC+8fea5uMIYohDwUV =aMac -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 ___ 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] Release plans
Marie Rognes wrote: Kristian Oelgaard wrote: On 29 January 2010 01:23, Anders Logg wrote: There seem to be just a couple of issues remaining in order of importance: 1. QuadratureElement 2. DOLFIN fem unit test 3. evaluate_basis_derivatives 4. RestrictedElement Among these, I would say 1-2 are crucial to fix before 0.9.0, but 3-4 are less crucial. It would be good to have evaluate_basis_derivatives working, but I don't know how much work is involved. First my apologies for the late reply, Internet was down again all morning and it pisses me off. Now that BDM elements also compiles for gcc it looks like everything is in place for evaluate_basis. CG and CR elements work, and so does all linear elements and DG constants. 2nd and 3rd order elements of BDM, RT, and DG type does not give the same result but there are explanations for this and at least it looks like they agree with the values you would get from FIAT if you tabulate on the reference element. evaluate_basis_derivatives works for CG elements and for most elements of degree 1. I'm working on some kind of unit testing framework for evaluate_basis and evaluate_basis_derivatives, such that we can make sure that at least cpp code and FIAT agrees on the reference element. If this test works, then the only bug can be in the transformation back to the physical element, but since this works for CG elements I don't see why it shouldn't for other elements too. However, I'll put this development on hold until Quadrature and Restricted elements work. RestrictedElement is also good to have, but I would say it is less important, especially since it's unclear what exactly it should do and how it should be implemented. It should be implemented like I did it in the old FFC :) w.r.t. the demo, it should test if restrictions on a MixedElement are propagated to the sub elements and that a restricted element can appear in a MixedElement. I'm taking care of RestrictedElement (onto facets/cells etc) at ze moment. This was actually slightly more mind-boggling than planned. I ended up letting FFC convert restricted mixed elements to mixed restricted elements. That kept the codegeneration complexity low and my head from exploding. I'll clean up and push tomorrow, unless that is too late ;) Also, question for Kristian: About the IR for evaluate_basis for mixed elements: You want a (non-nested) list of sub-elements, right? -- 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] Release plans
Kristian Oelgaard wrote: On 29 January 2010 16:55, Marie Rognes wrote: Marie Rognes wrote: Kristian Oelgaard wrote: On 29 January 2010 01:23, Anders Logg wrote: There seem to be just a couple of issues remaining in order of importance: 1. QuadratureElement 2. DOLFIN fem unit test 3. evaluate_basis_derivatives 4. RestrictedElement Among these, I would say 1-2 are crucial to fix before 0.9.0, but 3-4 are less crucial. It would be good to have evaluate_basis_derivatives working, but I don't know how much work is involved. First my apologies for the late reply, Internet was down again all morning and it pisses me off. Now that BDM elements also compiles for gcc it looks like everything is in place for evaluate_basis. CG and CR elements work, and so does all linear elements and DG constants. 2nd and 3rd order elements of BDM, RT, and DG type does not give the same result but there are explanations for this and at least it looks like they agree with the values you would get from FIAT if you tabulate on the reference element. evaluate_basis_derivatives works for CG elements and for most elements of degree 1. I'm working on some kind of unit testing framework for evaluate_basis and evaluate_basis_derivatives, such that we can make sure that at least cpp code and FIAT agrees on the reference element. If this test works, then the only bug can be in the transformation back to the physical element, but since this works for CG elements I don't see why it shouldn't for other elements too. However, I'll put this development on hold until Quadrature and Restricted elements work. RestrictedElement is also good to have, but I would say it is less important, especially since it's unclear what exactly it should do and how it should be implemented. It should be implemented like I did it in the old FFC :) w.r.t. the demo, it should test if restrictions on a MixedElement are propagated to the sub elements and that a restricted element can appear in a MixedElement. I'm taking care of RestrictedElement (onto facets/cells etc) at ze moment. This was actually slightly more mind-boggling than planned. I ended up letting FFC convert restricted mixed elements to mixed restricted elements. That kept the codegeneration complexity low and my head from exploding. I'll clean up and push tomorrow, unless that is too late ;) Also, question for Kristian: About the IR for evaluate_basis for mixed elements: You want a (non-nested) list of sub-elements, right? Yes, I think that should work. But why do you need to bother if you create a 'normal' MixedElement? Then nothing should change with respect to the functions in representation.py The IR for evaluate_basis for mixed element iterate[s|d] over the ufl_element. I don't want to do that (since that would be an ufl.ElementRestriction.) -- Marie Kristian -- 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] Release plans
Kristian Oelgaard wrote: On 29 January 2010 18:46, Marie Rognes wrote: Kristian Oelgaard wrote: On 29 January 2010 16:55, Marie Rognes wrote: Marie Rognes wrote: Kristian Oelgaard wrote: On 29 January 2010 01:23, Anders Logg wrote: There seem to be just a couple of issues remaining in order of importance: 1. QuadratureElement 2. DOLFIN fem unit test 3. evaluate_basis_derivatives 4. RestrictedElement Among these, I would say 1-2 are crucial to fix before 0.9.0, but 3-4 are less crucial. It would be good to have evaluate_basis_derivatives working, but I don't know how much work is involved. First my apologies for the late reply, Internet was down again all morning and it pisses me off. Now that BDM elements also compiles for gcc it looks like everything is in place for evaluate_basis. CG and CR elements work, and so does all linear elements and DG constants. 2nd and 3rd order elements of BDM, RT, and DG type does not give the same result but there are explanations for this and at least it looks like they agree with the values you would get from FIAT if you tabulate on the reference element. evaluate_basis_derivatives works for CG elements and for most elements of degree 1. I'm working on some kind of unit testing framework for evaluate_basis and evaluate_basis_derivatives, such that we can make sure that at least cpp code and FIAT agrees on the reference element. If this test works, then the only bug can be in the transformation back to the physical element, but since this works for CG elements I don't see why it shouldn't for other elements too. However, I'll put this development on hold until Quadrature and Restricted elements work. RestrictedElement is also good to have, but I would say it is less important, especially since it's unclear what exactly it should do and how it should be implemented. It should be implemented like I did it in the old FFC :) w.r.t. the demo, it should test if restrictions on a MixedElement are propagated to the sub elements and that a restricted element can appear in a MixedElement. I'm taking care of RestrictedElement (onto facets/cells etc) at ze moment. This was actually slightly more mind-boggling than planned. I ended up letting FFC convert restricted mixed elements to mixed restricted elements. That kept the codegeneration complexity low and my head from exploding. I'll clean up and push tomorrow, unless that is too late ;) Also, question for Kristian: About the IR for evaluate_basis for mixed elements: You want a (non-nested) list of sub-elements, right? Yes, I think that should work. But why do you need to bother if you create a 'normal' MixedElement? Then nothing should change with respect to the functions in representation.py The IR for evaluate_basis for mixed element iterate[s|d] over the ufl_element. I don't want to do that (since that would be an ufl.ElementRestriction.) I don't follow. If you have a mixed element mixed_element = elem0 + elem1 and then restrict it to facets: element = mixed_element["facet"] which is now a RestrictedElement. on the UFL side, yes. Then, as I understand it, you create a new MixedElement equivalent to: element = elem0["facet"] + eleme1["facet"] on the FFC side, yes in this case the evaluate_basis IR (and all other IRs) will only see a 'normal' MixedElement and we can proceed without problems. Exactly. That is the bonus of this approach :) But I did not want to tamper with the UFL representation of the element. Hence, it is way easier to iterate over the FFC element rather than the UFL element in the IR of evaluate_basis. Just wanted to check with you that the way I planned doing that was correct. For the other IRs I know what the correct way of doing this is ;) -- Marie Kristian -- Marie Kristian -- 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] Regression test update
Anders Logg wrote: On Fri, Jan 29, 2010 at 10:11:19PM +0100, Kristian Oelgaard wrote: On 29 January 2010 21:47, Anders Logg wrote: On Fri, Jan 29, 2010 at 07:26:46PM +0100, Kristian Oelgaard wrote: On 29 January 2010 18:56, Anders Logg wrote: It keeps getting better. Here are the current tests that fail. Generating code (33 form files found) - ElementRestriction.ufl failed QuadratureElement.ufl I fixed QuadratureElement, but it won't work until we figure out how to handle the degrees of forms and elements. I've fixed the representation selection now so that quadrature is selected. It now fails with another error: Not with the latest FFC :) Yes, sorry my fault. I didn't notice you had pushed. It works perfectly now! :-) Looks like it's just the restriction thing that is missing now. The ElementRestriction demo is now running. Don't know if it is correct. Need reference. Constructing restricted elements should work for wild combinations of mixed elements etc, but something seems to go wrong in the monomialtransformation for the commented part of the ElementRestriction demo. -- Marie -- 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] Quadrature optimisation bug
Garth N. Wells wrote: There seems to be a nasty bug in the quadrature optimisation. I can compute a result, but it's wrong. I can try to look into it in more detail later, but I'm using a combination of BDM and P0 functions which might be enough of a hint for someone. Could you give a test script? -- 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] Quadrature optimisation bug
Garth N. Wells wrote:
Marie Rognes wrote:
Garth N. Wells wrote:
There seems to be a nasty bug in the quadrature optimisation. I can
compute a result, but it's wrong. I can try to look into it in more
detail later, but I'm using a combination of BDM and P0 functions which
might be enough of a hint for someone.
Could you give a test script?
Below is a script which reproduces a bug when the quadrature
optimisation is turned on. The norm of vectors assembled with and
without using optimisation dffer.
Same problem arises with CG.
This looks like Harish's old bug where:
un = dot(u0, n)/2.0
does not work, but
un = 0.5*dot(u0, n)
does.
(Just as a sidenote.)
--
Marie
Garth
from dolfin import *
mesh = UnitSquare(3, 3)
n = FacetNormal(mesh)
BDM = FunctionSpace(mesh, "Brezzi-Douglas-Marini", 1)
P0 = FunctionSpace(mesh, "Discontinuous Lagrange", 0)
mixed_space = MixedFunctionSpace([BDM, P0])
# Function spaces and functions
r = TestFunction(P0)
U0 = Function(mixed_space)
u0, s0 = split(U0)
U0.vector()[:] = 1.0
un = dot(u0, n)/2.0
F= 1.0/(s0**2 + 1.0)
L = r*F*un*ds
param0 = {"representation": "quadrature", "optimize": False}
param1 = {"representation": "quadrature", "optimize": True}
print "Vec norm (no opt): ", assemble(L,
form_compiler_parameters=param0).norm("l2")
print "Vec norm (with opt): ", assemble(L,
form_compiler_parameters=param1).norm("l2")
--
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] JIT compile strangeness
Anders Logg wrote: On Mon, Feb 01, 2010 at 05:03:45PM +, Harish Narayanan wrote: On 01/02/2010 16:41, Anders Logg wrote: Works for me. Maybe instant-clean might help? I've tried an instant-clean. I also wiped out my .py files from site-packages and installed everything from scratch. Harish Very strange. I ran the exact same script as you pasted in your email. Is anyone else able to run the test? Works fine here. -- Marie -- 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] [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem.
Anders Logg wrote: Impressive! :-) Is it release time or are we waiting for Kristian to do some magic with evaluate_derivatives for Hdiv/curl? Who the heck needs evaluate_derivatives for Hdiv/curl ;) ? Throw error? -- Marie -- Anders On Mon, Feb 01, 2010 at 08:30:28PM -, nore...@launchpad.net wrote: revno: 1369 committer: Marie E. Rognes branch nick: ffc timestamp: Mon 2010-02-01 21:27:04 +0100 message: Fixed Garth's optimised quadrature problem. modified: ffc/quadrature/fraction.py === modified file 'ffc/quadrature/fraction.py' --- ffc/quadrature/fraction.py 2010-01-30 19:50:03 + +++ ffc/quadrature/fraction.py 2010-02-01 20:27:04 + @@ -5,7 +5,7 @@ __copyright__ = "Copyright (C) 2009-2010 Kristian B. Oelgaard" __license__ = "GNU GPL version 3 or any later version" -# Last changed: 2010-01-21 +# Last changed: 2010-02-01 # FFC modules. from ffc.log import error @@ -241,9 +241,14 @@ self = found*remain.""" # Reduce the numerator by the var type. -# Handle case where numerator is a sum. if self.num._prec == 3: -num_found, num_remain = self.num.reduce_vartype(var_type)[0] +foo = self.num.reduce_vartype(var_type) +if len(foo) == 1: +num_found, num_remain = self.num.reduce_vartype(var_type)[0] +else: +# meg: I have only a marginal idea of what I'm doing here! +return create_sum([create_fraction(create_product([num_found, num_remain]), self.denom) + for (num_found, num_remain) in foo]).expand().reduce_vartype(var_type) else: num_found, num_remain = self.num.reduce_vartype(var_type) @@ -259,7 +264,7 @@ denom_found, denom_remain = self.denom.reduce_vartype(var_type) # If we have a Sum in the denominator, all terms must be reduced by -# the same terms to make sense. +# the same terms to make sense else: remain = [] for m in self.denom.vrs: @@ -294,6 +299,7 @@ # TODO: Add more checks to avoid expansion. found = None # There is always a remainder. + remain = create_fraction(num_remain, denom_remain).expand() if num_found: @@ -306,6 +312,7 @@ found = create_fraction(create_float(1), denom_found) else: found = () + return (found, remain) # FFC quadrature modules. ___ 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] [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem.
Kristian Oelgaard wrote: On 1 February 2010 21:37, Anders Logg wrote: Impressive! :-) It sure is, many things could be handled in a much simpler way if it wasn't for memory and runtime considerations of the optimisations. If I get around to implementing the other optimisation strategy, we could make life simpler in these classes and only let the symbolics stuff work on moderately complex forms. Sorry if I messed something up. I just thought it was better to have something working (but suboptimal) than something broken (and optimal ;) ) Is it release time or are we waiting for Kristian to do some magic with evaluate_derivatives for Hdiv/curl? Actually, I'm waiting for Marie to fix this one too :) I'm taking a look, but it is not likely to happen within the next couple of hours. I'm lost in the vectors: What is 'derivatives' and 'values' supposed to be holding? (Math, please ;)) -- Marie I'm having problems with the transformation back to the physical element, at least that's where I think the problem is. On the other hand, when I'm computing values on the reference element (for the tests) should it really matter for these elements? I don't see any transformation in FIAT for Hdiv/curl elements. Kristian -- Anders On Mon, Feb 01, 2010 at 08:30:28PM -, nore...@launchpad.net wrote: revno: 1369 committer: Marie E. Rognes branch nick: ffc timestamp: Mon 2010-02-01 21:27:04 +0100 message: Fixed Garth's optimised quadrature problem. modified: ffc/quadrature/fraction.py === modified file 'ffc/quadrature/fraction.py' --- ffc/quadrature/fraction.py2010-01-30 19:50:03 + +++ ffc/quadrature/fraction.py2010-02-01 20:27:04 + @@ -5,7 +5,7 @@ __copyright__ = "Copyright (C) 2009-2010 Kristian B. Oelgaard" __license__ = "GNU GPL version 3 or any later version" -# Last changed: 2010-01-21 +# Last changed: 2010-02-01 # FFC modules. from ffc.log import error @@ -241,9 +241,14 @@ self = found*remain.""" # Reduce the numerator by the var type. -# Handle case where numerator is a sum. if self.num._prec == 3: -num_found, num_remain = self.num.reduce_vartype(var_type)[0] +foo = self.num.reduce_vartype(var_type) +if len(foo) == 1: +num_found, num_remain = self.num.reduce_vartype(var_type)[0] +else: +# meg: I have only a marginal idea of what I'm doing here! +return create_sum([create_fraction(create_product([num_found, num_remain]), self.denom) + for (num_found, num_remain) in foo]).expand().reduce_vartype(var_type) else: num_found, num_remain = self.num.reduce_vartype(var_type) @@ -259,7 +264,7 @@ denom_found, denom_remain = self.denom.reduce_vartype(var_type) # If we have a Sum in the denominator, all terms must be reduced by -# the same terms to make sense. +# the same terms to make sense else: remain = [] for m in self.denom.vrs: @@ -294,6 +299,7 @@ # TODO: Add more checks to avoid expansion. found = None # There is always a remainder. + remain = create_fraction(num_remain, denom_remain).expand() if num_found: @@ -306,6 +312,7 @@ found = create_fraction(create_float(1), denom_found) else: found = () + return (found, remain) # FFC quadrature modules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktnO54ACgkQTuwUCDsYZdEMIgCfQj7hbvwXKDVzP72ykidr29E9 3s8An1xmHf6nfXJUbnwkwCeZ7dDq5cO0 =9wkW -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 ___ 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] [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem.
Kristian Oelgaard wrote: On 1 February 2010 22:02, Marie Rognes wrote: Kristian Oelgaard wrote: On 1 February 2010 21:37, Anders Logg wrote: Impressive! :-) It sure is, many things could be handled in a much simpler way if it wasn't for memory and runtime considerations of the optimisations. If I get around to implementing the other optimisation strategy, we could make life simpler in these classes and only let the symbolics stuff work on moderately complex forms. Sorry if I messed something up. I just thought it was better to have something working (but suboptimal) than something broken (and optimal ;) ) Agree, the code looks OK. Is it release time or are we waiting for Kristian to do some magic with evaluate_derivatives for Hdiv/curl? Actually, I'm waiting for Marie to fix this one too :) I'm taking a look, but it is not likely to happen within the next couple of hours. I'm lost in the vectors: What is 'derivatives' and 'values' supposed to be holding? (Math, please ;) 'values' is the argument to evaluate_basis_derivatives that will hold the return values (derivatives on the physical cell) from the function. It is the users responsibility to make sure it has the correct size. 'derivatives' is the derivatives on the reference element, which is computed like it is done inside FIAT (multiplication of coefficients, dmats and basis values of the expansion). Ok. And the values are ordered so that first all derivatives for value dimension 0, then all derivatives for value dimension 1, etc.? Currently only the first two (out of four?) 'derivatives' are mapped for BDM _1on triangle? derivatives[0] = (1.0/detJ)*((J_00*tmp_ref0 + J_01*tmp_ref1)); derivatives[1] = (1.0/detJ)*((J_10*tmp_ref0 + J_11*tmp_ref1)); but you use higher indices later: values[row] += transform[row][col]*derivatives[col]; values[num_derivatives + row] += transform[row][col]*(derivatives[num_derivatives + col]); Is this intentional? -- Marie Kristian -- Marie I'm having problems with the transformation back to the physical element, at least that's where I think the problem is. On the other hand, when I'm computing values on the reference element (for the tests) should it really matter for these elements? I don't see any transformation in FIAT for Hdiv/curl elements. Kristian -- Anders On Mon, Feb 01, 2010 at 08:30:28PM -, nore...@launchpad.net wrote: revno: 1369 committer: Marie E. Rognes branch nick: ffc timestamp: Mon 2010-02-01 21:27:04 +0100 message: Fixed Garth's optimised quadrature problem. modified: ffc/quadrature/fraction.py === modified file 'ffc/quadrature/fraction.py' --- ffc/quadrature/fraction.py2010-01-30 19:50:03 + +++ ffc/quadrature/fraction.py2010-02-01 20:27:04 + @@ -5,7 +5,7 @@ __copyright__ = "Copyright (C) 2009-2010 Kristian B. Oelgaard" __license__ = "GNU GPL version 3 or any later version" -# Last changed: 2010-01-21 +# Last changed: 2010-02-01 # FFC modules. from ffc.log import error @@ -241,9 +241,14 @@ self = found*remain.""" # Reduce the numerator by the var type. -# Handle case where numerator is a sum. if self.num._prec == 3: -num_found, num_remain = self.num.reduce_vartype(var_type)[0] +foo = self.num.reduce_vartype(var_type) +if len(foo) == 1: +num_found, num_remain = self.num.reduce_vartype(var_type)[0] +else: +# meg: I have only a marginal idea of what I'm doing here! +return create_sum([create_fraction(create_product([num_found, num_remain]), self.denom) + for (num_found, num_remain) in foo]).expand().reduce_vartype(var_type) else: num_found, num_remain = self.num.reduce_vartype(var_type) @@ -259,7 +264,7 @@ denom_found, denom_remain = self.denom.reduce_vartype(var_type) # If we have a Sum in the denominator, all terms must be reduced by -# the same terms to make sense. +# the same terms to make sense else: remain = [] for m in self.denom.vrs: @@ -294,6 +299,7 @@ # TODO: Add more checks to avoid expansion. found = None # There is always a remainder. + remain = create_fraction(num_remain, denom_remain).expand() if num_found: @@ -306,6 +312,7 @@ found = create_fraction(create_float(1), denom_found) else: found = () + return (found, remain) # FFC quadrature modules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktnO54ACgkQTuwUCDsYZdEMIgCfQj7hbvwXKDVzP72ykidr29E9 3s8An1xmHf6nfXJUbnw
Re: [Ffc] [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem.
Kristian Oelgaard wrote: On 1 February 2010 22:32, Marie Rognes wrote: Kristian Oelgaard wrote: On 1 February 2010 22:02, Marie Rognes wrote: Kristian Oelgaard wrote: On 1 February 2010 21:37, Anders Logg wrote: Impressive! :-) It sure is, many things could be handled in a much simpler way if it wasn't for memory and runtime considerations of the optimisations. If I get around to implementing the other optimisation strategy, we could make life simpler in these classes and only let the symbolics stuff work on moderately complex forms. Sorry if I messed something up. I just thought it was better to have something working (but suboptimal) than something broken (and optimal ;) ) Agree, the code looks OK. Is it release time or are we waiting for Kristian to do some magic with evaluate_derivatives for Hdiv/curl? Actually, I'm waiting for Marie to fix this one too :) I'm taking a look, but it is not likely to happen within the next couple of hours. I'm lost in the vectors: What is 'derivatives' and 'values' supposed to be holding? (Math, please ;) 'values' is the argument to evaluate_basis_derivatives that will hold the return values (derivatives on the physical cell) from the function. It is the users responsibility to make sure it has the correct size. 'derivatives' is the derivatives on the reference element, which is computed like it is done inside FIAT (multiplication of coefficients, dmats and basis values of the expansion). Ok. And the values are ordered so that first all derivatives for value dimension 0, then all derivatives for value dimension 1, etc.? Yes. There is a comment at the top of evaluatebasisderivatives.py, but it might be a good idea to put in the generated code too? Currently only the first two (out of four?) 'derivatives' are mapped for BDM _1on triangle? derivatives[0] = (1.0/detJ)*((J_00*tmp_ref0 + J_01*tmp_ref1)); derivatives[1] = (1.0/detJ)*((J_10*tmp_ref0 + J_11*tmp_ref1)); I pushed a fix for this a while back, I was hoping that was the error, but I still get wrong results. Sorry, my bad -- something strange happened. And I guess you have checked the indices a couple of hundred times? How about the famous UFC/FIAT reference element difference? -- Marie It should be like below of course. Kristian but you use higher indices later: values[row] += transform[row][col]*derivatives[col]; values[num_derivatives + row] += transform[row][col]*(derivatives[num_derivatives + col]); Is this intentional? -- Marie Kristian -- Marie I'm having problems with the transformation back to the physical element, at least that's where I think the problem is. On the other hand, when I'm computing values on the reference element (for the tests) should it really matter for these elements? I don't see any transformation in FIAT for Hdiv/curl elements. Kristian -- Anders On Mon, Feb 01, 2010 at 08:30:28PM -, nore...@launchpad.net wrote: revno: 1369 committer: Marie E. Rognes branch nick: ffc timestamp: Mon 2010-02-01 21:27:04 +0100 message: Fixed Garth's optimised quadrature problem. modified: ffc/quadrature/fraction.py === modified file 'ffc/quadrature/fraction.py' --- ffc/quadrature/fraction.py2010-01-30 19:50:03 + +++ ffc/quadrature/fraction.py2010-02-01 20:27:04 + @@ -5,7 +5,7 @@ __copyright__ = "Copyright (C) 2009-2010 Kristian B. Oelgaard" __license__ = "GNU GPL version 3 or any later version" -# Last changed: 2010-01-21 +# Last changed: 2010-02-01 # FFC modules. from ffc.log import error @@ -241,9 +241,14 @@ self = found*remain.""" # Reduce the numerator by the var type. -# Handle case where numerator is a sum. if self.num._prec == 3: -num_found, num_remain = self.num.reduce_vartype(var_type)[0] +foo = self.num.reduce_vartype(var_type) +if len(foo) == 1: +num_found, num_remain = self.num.reduce_vartype(var_type)[0] +else: +# meg: I have only a marginal idea of what I'm doing here! +return create_sum([create_fraction(create_product([num_found, num_remain]), self.denom) + for (num_found, num_remain) in foo]).expand().reduce_vartype(var_type) else: num_found, num_remain = self.num.reduce_vartype(var_type) @@ -259,7 +264,7 @@ denom_found, denom_remain = self.denom.reduce_vartype(var_type) # If we have a Sum in the denominator, all terms must be reduced by -# the same terms to make sense. +# the same terms to make sense else: remain = [] for m in self.denom.vrs: @@ -294,6 +299,7 @@ #
Re: [Ffc] [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem.
Kristian Oelgaard wrote: On 1 February 2010 22:57, Marie Rognes wrote: Kristian Oelgaard wrote: On 1 February 2010 22:32, Marie Rognes wrote: Kristian Oelgaard wrote: On 1 February 2010 22:02, Marie Rognes wrote: Kristian Oelgaard wrote: On 1 February 2010 21:37, Anders Logg wrote: Impressive! :-) It sure is, many things could be handled in a much simpler way if it wasn't for memory and runtime considerations of the optimisations. If I get around to implementing the other optimisation strategy, we could make life simpler in these classes and only let the symbolics stuff work on moderately complex forms. Sorry if I messed something up. I just thought it was better to have something working (but suboptimal) than something broken (and optimal ;) ) Agree, the code looks OK. Is it release time or are we waiting for Kristian to do some magic with evaluate_derivatives for Hdiv/curl? Actually, I'm waiting for Marie to fix this one too :) I'm taking a look, but it is not likely to happen within the next couple of hours. I'm lost in the vectors: What is 'derivatives' and 'values' supposed to be holding? (Math, please ;) 'values' is the argument to evaluate_basis_derivatives that will hold the return values (derivatives on the physical cell) from the function. It is the users responsibility to make sure it has the correct size. 'derivatives' is the derivatives on the reference element, which is computed like it is done inside FIAT (multiplication of coefficients, dmats and basis values of the expansion). Ok. And the values are ordered so that first all derivatives for value dimension 0, then all derivatives for value dimension 1, etc.? Yes. There is a comment at the top of evaluatebasisderivatives.py, but it might be a good idea to put in the generated code too? Currently only the first two (out of four?) 'derivatives' are mapped for BDM _1on triangle? derivatives[0] = (1.0/detJ)*((J_00*tmp_ref0 + J_01*tmp_ref1)); derivatives[1] = (1.0/detJ)*((J_10*tmp_ref0 + J_11*tmp_ref1)); I pushed a fix for this a while back, I was hoping that was the error, but I still get wrong results. Sorry, my bad -- something strange happened. And I guess you have checked the indices a couple of hundred times? How about the famous UFC/FIAT reference element difference? I think I found it, I was mapping values from FIAT incorrectly. Hurray! *crossing fingers* -- Marie Stupid, stupid me. I'll just clean things up then Anders can make a release. Kristian -- Marie It should be like below of course. Kristian but you use higher indices later: values[row] += transform[row][col]*derivatives[col]; values[num_derivatives + row] += transform[row][col]*(derivatives[num_derivatives + col]); Is this intentional? -- Marie Kristian -- Marie I'm having problems with the transformation back to the physical element, at least that's where I think the problem is. On the other hand, when I'm computing values on the reference element (for the tests) should it really matter for these elements? I don't see any transformation in FIAT for Hdiv/curl elements. Kristian -- Anders On Mon, Feb 01, 2010 at 08:30:28PM -, nore...@launchpad.net wrote: revno: 1369 committer: Marie E. Rognes branch nick: ffc timestamp: Mon 2010-02-01 21:27:04 +0100 message: Fixed Garth's optimised quadrature problem. modified: ffc/quadrature/fraction.py === modified file 'ffc/quadrature/fraction.py' --- ffc/quadrature/fraction.py2010-01-30 19:50:03 + +++ ffc/quadrature/fraction.py2010-02-01 20:27:04 + @@ -5,7 +5,7 @@ __copyright__ = "Copyright (C) 2009-2010 Kristian B. Oelgaard" __license__ = "GNU GPL version 3 or any later version" -# Last changed: 2010-01-21 +# Last changed: 2010-02-01 # FFC modules. from ffc.log import error @@ -241,9 +241,14 @@ self = found*remain.""" # Reduce the numerator by the var type. -# Handle case where numerator is a sum. if self.num._prec == 3: -num_found, num_remain = self.num.reduce_vartype(var_type)[0] +foo = self.num.reduce_vartype(var_type) +if len(foo) == 1: +num_found, num_remain = self.num.reduce_vartype(var_type)[0] +else: +# meg: I have only a marginal idea of what I'm doing here! +return create_sum([create_fraction(create_product([num_found, num_remain]), self.denom) + for (num_found, num_remain) in foo]).expand().reduce_vartype(var_type) else: num_found, num_remain = self.num.reduce_vartype(var_type) @@ -259,7 +264,7 @@ denom_found, denom_remain = self.denom.reduce_vartype(var_
Re: [Ffc] JIT compile strangeness
More compile strangeness: Clean cache, error at first run, things running at second run: m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean Instant cache is empty m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "test.py", line 6, in L = assemble(v*dx) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", line 88, in assemble dolfin_form = Form(form, function_spaces, coefficients, form_compiler_parameters) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 39, in __init__ function_spaces) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 60, in _extract_function_spaces if not isinstance(func.function_space(), cpp.FunctionSpace): AttributeError: 'Argument' object has no attribute 'function_space' m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py L = Anyone else experience this? from dolfin import * mesh = UnitSquare(2,2) V_h = FunctionSpace(mesh, "DG", 1) v = TestFunction(V_h) L = assemble(v*dx) print "L = ", L ___ 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] JIT compile strangeness
Anders Logg wrote: On Tue, Feb 02, 2010 at 12:08:51PM +, Harish Narayanan wrote: On 02/02/2010 11:29, Marie Rognes wrote: More compile strangeness: Clean cache, error at first run, things running at second run: m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean Instant cache is empty m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "test.py", line 6, in L = assemble(v*dx) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", line 88, in assemble dolfin_form = Form(form, function_spaces, coefficients, form_compiler_parameters) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 39, in __init__ function_spaces) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 60, in _extract_function_spaces if not isinstance(func.function_space(), cpp.FunctionSpace): AttributeError: 'Argument' object has no attribute 'function_space' m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py L = Anyone else experience this? from dolfin import * mesh = UnitSquare(2,2) V_h = FunctionSpace(mesh, "DG", 1) v = TestFunction(V_h) L = assemble(v*dx) print "L = ", L Me, me, me! :) Harish ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp This is fixed now. Hurray! -- Marie It was an intricate caching problem relating to reuse of the dummy form v*dx that FFC creates when JIT compiling elements (for use in DOLFIN FunctionSpace). I fixed it by making sure FormData is not cached when compiling elements but a proper solution (removal of the FFC dummy form) should be implemented instead. I've added a FIXME in jit.py. -- 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] [Branch ~ffc-core/ffc/main] Rev 1438: Added support for Bubble elements, using ElementRestriction of a
Garth N. Wells wrote: nore...@launchpad.net wrote: revno: 1438 committer: Marie E. Rognes branch nick: ffc timestamp: Sun 2010-03-07 19:15:05 +0100 message: Added support for Bubble elements, using ElementRestriction of a Lagrange element of degree (geometric_dimension + 1) to interior. Nice. Any thoughts on how to solve for the internal dof? Within ffc? No, not really. Static condensation is on the DOLFIN Blueprint list. Well, that sounds like a good plan to carry out then ;) What is static condensation exactly? (Beyond being an algorithm for eliminating internal dofs.) -- Marie Garth Example: For triangles, the bubble element is the span of the single CG_3 interior basis function. modified: ffc/fiatinterface.py -- lp:ffc https://code.launchpad.net/~ffc-core/ffc/main Your team FFC Core Team is subscribed to branch lp:ffc. To unsubscribe from this branch go to https://code.launchpad.net/~ffc-core/ffc/main/+edit-subscription. ___ 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
[Ffc] ElementUnion
nore...@launchpad.net wrote: revno: 1440 committer: Marie E. Rognes branch nick: ffc timestamp: Sun 2010-03-07 21:32:00 +0100 message: Bug fixes in logic wrt unions of mixed elements. Human-readable code generated for Mini looks correct now :) (Don't know about evaluate_basis* and tabulate_tensor*) FFC is now able to compile ElementUnions. An ElementUnion of a set of elements represents the span of the union of the finite element bases. A classic example of its use would be to augment some element space by the bubble element (cf ffc/demo/Mini.ufl). Note that it is not really a finite element in the Ciarlet sense, because the combined basis does not form a nodal basis. In short, the effect is that one can assemble forms, but interpolation onto such spaces is not safe. Some comments: (a) I'm not convinced that ElementUnion is the perfect name. (b) Some additions are required for pydolfin to recognize ElementUnions. Hake? (c) It is not fully tested -> hangs on (b) -- 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] New syntax for mixed and enriched spaces
Anders Logg wrote:
On Mon, Mar 22, 2010 at 06:20:00PM +0800, Garth N. Wells wrote:
On 22/03/10 16:42, Kristian Oelgaard wrote:
On 21 March 2010 21:32, Anders Logg wrote:
After Marie's latest addition of enriched spaces (and some discussion
with Doug Arnold), it seems clear that our current notation V + W for
mixed spaces is not optimal.
Even though one may think of the operation of creating a "mixed
function space" as a direct sum,
X = {(v, 0) : v in V} \oplus {(0, w) : w in W},
it is more natural (and common) to think of it as a Cartesian product,
X = V \times W = {(v, w) : v in V, w in W}
It would therefore be more natural to use '*' instead of '+' as the
operation for creating mixed elements/function spaces.
That would free up '+' to be used for enriched spaces (which have
recently been added),
X = {v + w : v in V, w in W}
The typical example would be to take V piecewise linears and W scaled
P3 bubbles.
In summary, the suggestion is to use the following notation:
+ <--> +
* <--> \times
It's obvious this is better than what we have now which is
+ <--> \oplus
? <--> +
Thoughts?
Agree.
Me too.
Garth
ok. Let's change then.
It will require changes in both UFL and FFC. Anyone up for it?
I can fix ffc. (Have no permission for ufl)
--
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] New syntax for mixed and enriched spaces
Anders Logg wrote:
On Mon, Mar 22, 2010 at 11:41:42AM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Mon, Mar 22, 2010 at 06:20:00PM +0800, Garth N. Wells wrote:
On 22/03/10 16:42, Kristian Oelgaard wrote:
On 21 March 2010 21:32, Anders Logg wrote:
After Marie's latest addition of enriched spaces (and some discussion
with Doug Arnold), it seems clear that our current notation V + W for
mixed spaces is not optimal.
Even though one may think of the operation of creating a "mixed
function space" as a direct sum,
X = {(v, 0) : v in V} \oplus {(0, w) : w in W},
it is more natural (and common) to think of it as a Cartesian product,
X = V \times W = {(v, w) : v in V, w in W}
It would therefore be more natural to use '*' instead of '+' as the
operation for creating mixed elements/function spaces.
That would free up '+' to be used for enriched spaces (which have
recently been added),
X = {v + w : v in V, w in W}
The typical example would be to take V piecewise linears and W scaled
P3 bubbles.
In summary, the suggestion is to use the following notation:
+ <--> +
* <--> \times
It's obvious this is better than what we have now which is
+ <--> \oplus
? <--> +
Thoughts?
Agree.
Me too.
Garth
ok. Let's change then.
It will require changes in both UFL and FFC. Anyone up for it?
I can fix ffc.
I was hoping for that. :-)
(Have no permission for ufl)
You do now. ;-)
Aka, I'll fix that too.
--
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] New syntax for mixed and enriched spaces
Marie Rognes wrote:
Anders Logg wrote:
On Mon, Mar 22, 2010 at 11:41:42AM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Mon, Mar 22, 2010 at 06:20:00PM +0800, Garth N. Wells wrote:
On 22/03/10 16:42, Kristian Oelgaard wrote:
On 21 March 2010 21:32, Anders Logg wrote:
After Marie's latest addition of enriched spaces (and some
discussion
with Doug Arnold), it seems clear that our current notation V +
W for
mixed spaces is not optimal.
Even though one may think of the operation of creating a "mixed
function space" as a direct sum,
X = {(v, 0) : v in V} \oplus {(0, w) : w in W},
it is more natural (and common) to think of it as a Cartesian
product,
X = V \times W = {(v, w) : v in V, w in W}
It would therefore be more natural to use '*' instead of '+' as the
operation for creating mixed elements/function spaces.
That would free up '+' to be used for enriched spaces (which have
recently been added),
X = {v + w : v in V, w in W}
The typical example would be to take V piecewise linears and W
scaled
P3 bubbles.
In summary, the suggestion is to use the following notation:
+ <--> +
* <--> \times
It's obvious this is better than what we have now which is
+ <--> \oplus
? <--> +
Thoughts?
Agree.
Me too.
Garth
ok. Let's change then.
It will require changes in both UFL and FFC. Anyone up for it?
I can fix ffc.
I was hoping for that. :-)
(Have no permission for ufl)
You do now. ;-)
Aka, I'll fix that too.
Fixed:
(a) ElementUnion is now called EnrichedElement.
(b) (Old) V + Q --> (New) V * Q
(c) V + Q = EnrichedElement(V, Q)
Now, PYDOLFIN needs updating...
--
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
[Ffc] Tests for Projection.ufl fails
The regression testing of Projection.ufl is failing for me (and has been so for a while). Could it be that the references have not been updated for this form? The first part of the diff is as follows: -// This code conforms with the UFC specification version 1.2 -// and was automatically generated by FFC version 0.9.0-beta. +// This code conforms with the UFC specification version 1.4 +// and was automatically generated by FFC version 0.9.2+. +// +// This code was generated with the following parameters: +// +// cache_dir: '' +// convert_exceptions_to_warnings: True +// cpp_optimize: False +// epsilon:1e-14 +// form_postfix: True +// format: 'ufc' +// log_level: 10 +// log_prefix: '' +// optimize: False +// output_dir: '.' +// precision: '8' +// quadrature_degree: 'auto' +// quadrature_rule:'auto' +// representation: 'auto' +// split: False -- 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] Tests for Projection.ufl fails
Kristian Oelgaard wrote: Works fine here, Ah, pulled fresh branch -- and now I see. Projection.ufl has been removed from the demos directory, but the reference is still hovering around. but I get: Missing reference for Mini.out Yes, will add once I've checked that the generated code gives meaningful results. -- Marie Kristian On 22 March 2010 13:49, Marie Rognes wrote: The regression testing of Projection.ufl is failing for me (and has been so for a while). Could it be that the references have not been updated for this form? The first part of the diff is as follows: -// This code conforms with the UFC specification version 1.2 -// and was automatically generated by FFC version 0.9.0-beta. +// This code conforms with the UFC specification version 1.4 +// and was automatically generated by FFC version 0.9.2+. +// +// This code was generated with the following parameters: +// +// cache_dir: '' +// convert_exceptions_to_warnings: True +// cpp_optimize: False +// epsilon:1e-14 +// form_postfix: True +// format: 'ufc' +// log_level: 10 +// log_prefix: '' +// optimize: False +// output_dir: '.' +// precision: '8' +// quadrature_degree: 'auto' +// quadrature_rule:'auto' +// representation: 'auto' +// split: False -- 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 ___ 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] New syntax for mixed and enriched spaces
Anders Logg wrote:
On Mon, Mar 22, 2010 at 01:43:41PM +0100, Marie Rognes wrote:
Marie Rognes wrote:
Anders Logg wrote:
On Mon, Mar 22, 2010 at 11:41:42AM +0100, Marie Rognes wrote:
Anders Logg wrote:
On Mon, Mar 22, 2010 at 06:20:00PM +0800, Garth N. Wells wrote:
On 22/03/10 16:42, Kristian Oelgaard wrote:
On 21 March 2010 21:32, Anders Logg wrote:
After Marie's latest addition of enriched spaces (and
some discussion
with Doug Arnold), it seems clear that our current
notation V + W for
mixed spaces is not optimal.
Even though one may think of the operation of creating a "mixed
function space" as a direct sum,
X = {(v, 0) : v in V} \oplus {(0, w) : w in W},
it is more natural (and common) to think of it as a
Cartesian product,
X = V \times W = {(v, w) : v in V, w in W}
It would therefore be more natural to use '*' instead of '+' as the
operation for creating mixed elements/function spaces.
That would free up '+' to be used for enriched spaces (which have
recently been added),
X = {v + w : v in V, w in W}
The typical example would be to take V piecewise
linears and W scaled
P3 bubbles.
In summary, the suggestion is to use the following notation:
+ <--> +
* <--> \times
It's obvious this is better than what we have now which is
+ <--> \oplus
? <--> +
Thoughts?
Agree.
Me too.
Garth
ok. Let's change then.
It will require changes in both UFL and FFC. Anyone up for it?
I can fix ffc.
I was hoping for that. :-)
(Have no permission for ufl)
You do now. ;-)
Aka, I'll fix that too.
Fixed:
(a) ElementUnion is now called EnrichedElement.
(b) (Old) V + Q --> (New) V * Q
(c) V + Q = EnrichedElement(V, Q)
Now, PYDOLFIN needs updating...
Done.
Great! (I'm off to do some Mini debugging.)
--
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] [Branch ~ffc-core/ffc/main] Rev 1450: Bug fixes for tabulate_tensor for Enriched Mixed elements.
nore...@launchpad.net wrote: revno: 1450 committer: Marie E. Rognes branch nick: ffc timestamp: Tue 2010-03-23 23:08:17 +0100 message: Bug fixes for tabulate_tensor for Enriched Mixed elements. That was supposed to be tabulate_dofs (in case anyone is overly interested.) -- 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
[Ffc] Some various questions
(1) ffc does not expose ufl. Is this intentional? For instance, the
following gives a "FiniteElement not defined error"
from ffc import *
element = FiniteElement("CG", "triangle", 1)
(2) What is the purpose of the argument 'object_names' to
'compile_element'? It does not seem to be used anywhere.
(3) Where is the output argument 'forms' of 'compile_form' used? I
thought it was used by the jitcompiler, but that does not seem to be
the case.
--
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] Some various questions
Anders Logg wrote:
On Wed, Mar 24, 2010 at 07:36:33PM +0100, Kristian Oelgaard wrote:
On 24 March 2010 17:31, Marie Rognes wrote:
(1) ffc does not expose ufl. Is this intentional? For instance, the
following gives a "FiniteElement not defined error"
from ffc import *
element = FiniteElement("CG", "triangle", 1)
I don't think we should make FiniteElement part of ffc. It belongs in UFL and
when you need it, import it.
Agree.
(2) What is the purpose of the argument 'object_names' to
'compile_element'? It does not seem to be used anywhere.
I think it only makes sense in compile_form, to get correct names for
Coefficients (like f, g) and stuff, so that can be deleted.
Agree.
(3) Where is the output argument 'forms' of 'compile_form' used? I
thought it was used by the jitcompiler, but that does not seem to be
the case.
Don't know.
It was used before, but not since we changed the JIT compiler so that
it calls preprocess itself before calling compile_form.
So it can be removed.
Ok!
--
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] EnrichedElement
Mehdi Nikbakht wrote:
Hello,
I am trying to use new syntax for the enriched elements. I don't see
the reason why we can not enrich an scaler element. Assume this form
file,
P1 = FiniteElement("Lagrange", triangle, 1)
Mini = P1 + P1
v = TestFunction(Mini)
u = TrialFunction(Mini)
a = inner(v, u)*dx
this file can't be compiled. But if we use VectorElement instead of
FiniteElement, it works fine. Is it a bug?
Most definitely. I'll fix tomorrow unless anyone beats me to it. (It is
just a matter of fixing some indicing in EnrichedElement.tabulate, I think.)
In addition, is it possible to have access to the dof maps of underling
elements, independently?
I don't quite understand what you mean here. Do you mean that you want
code generated for each of the underlying elements as well?
--
Marie
Yours,
Mehdi
___
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] EnrichedElement
Marie Rognes wrote:
Mehdi Nikbakht wrote:
Hello,
I am trying to use new syntax for the enriched elements. I don't see
the reason why we can not enrich an scaler element. Assume this form
file,
P1 = FiniteElement("Lagrange", triangle, 1)
Mini = P1 + P1
v = TestFunction(Mini)
u = TrialFunction(Mini)
a = inner(v, u)*dx
this file can't be compiled. But if we use VectorElement instead of
FiniteElement, it works fine. Is it a bug?
Most definitely. I'll fix tomorrow unless anyone beats me to it. (It
is just a matter of fixing some indicing in EnrichedElement.tabulate,
I think.)
This should be fixed now.
--
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] Bubble function
Andy Ray Terrel wrote:
Okay I see. Its just a third order bubble, sometimes I send mail
before I think. The mini element is a first order bubble or at least
that's what Brezzi Fortin say.
That depends on your definition of the word "is".
The "velocity" part of the (lowest order) Mini element is, in FFC:
P1 = VectorElement("Lagrange", triangle, 1)
B = VectorElement("Bubble", triangle, 3)
V = P1 + B
The logic here is that the degree should be such that any element
of degree k is included in P_k. Hence, for triangles, the numbering for the
bubbles start at 3.
--
Marie
-- Andy
On Fri, Apr 9, 2010 at 8:43 PM, wrote:
Is there anything telling how the bubble functions are defined?
For example with the Mini example:
P1 = VectorElement("Lagrange", "triangle", 1)
B = VectorElement("Bubble", "triangle", 3)
Q = FiniteElement("Lagrange", "triangle", 1)
Mini = (P1 + B) * Q
Does B consist of 3 bubble functions in some symmetric pattern in the
element?
The bubble functions are the bubble functions ;)
In the above example, B is the span of the piecewise continuous
cubic functions that are zero on the boundary of each triangle.
(1 per triangle for a FiniteElement and hence 2 per triangle for a
VectorElement of value dimension 2.)
In general, the bubble finite element of degree k is the span of the interior
basis functions of CG_k.
--
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] Bubble function
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. Are you sure that you have the latest ffc? -- 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] buildbot failure in FEniCS Buildbot on ffc-jaunty-amd64
On 04. juni 2010 15:23, build...@fenics.org wrote: > The Buildbot has detected a new failure of ffc-jaunty-amd64 on FEniCS > Buildbot. > Full details are available at: > http://fenics.org:8080/builders/ffc-jaunty-amd64/builds/372 > > Buildbot URL: http://fenics.org:8080/ > > Buildslave for this Build: jaunty-amd64 > > Build Reason: > Build Source Stamp: HEAD > Blamelist: Marie E. Rognes > > BUILD FAILED: failed ffc check > > sincerely, > -The Buildbot > > This is the usual 0.5 vs 1/2 ufl bug. Will fix the bug in ufl instead of tweaking the demo. -- 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
[Ffc] Fwd: Re: function on EnrichedElement
Original Message
Subject:Re: function on EnrichedElement
Date: Tue, 15 Jun 2010 15:27:44 +0200
From: Marie Rognes
To: Mehdi
CC: gn...@cam.ac.uk, Anders Logg
On 15. juni 2010 15:12, Mehdi wrote:
> On Tue, 2010-06-15 at 14:26 +0200, Marie Rognes wrote:
>
>> On 14. juni 2010 19:57, Marie Rognes wrote:
>>
>>> On 14. juni 2010 19:37, Mehdi wrote:
>>>
>>>
>>>> On Mon, 2010-06-14 at 19:18 +0200, Marie Rognes wrote:
>>>>
>>>>
>>>>
>>>>> On 14. juni 2010 18:10, Mehdi wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Marie,
>>>>>>
>>>>>> I have a function defined on Enriched Element. I want to have access to
>>>>>> the subfunctions defined on this space. How ffc/ufl can be extended to
>>>>>> handle this issue?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Could you give me a piece of sample code?
>>>>>
>>>>>
>>>>>
>>>> The input is something like this,
>>>>
>>>> Elem1 = VectorElement("Lagrange", triangle, 2)
>>>> Elem2 = VectorElement("Lagrange", triangle, 1)
>>>>
>>>> Element = Elem1 + Elem2
>>>>
>>>> u = Coefficient(Element)
>>>>
>>>> # I want to have this functionality
>>>> u1, u2 = split(u)
>>>>
>>>> Thank you in advance.
>>>>
>>>>
>>>>
>>>>
>>> Will see what I can do tomorrow.
>>>
>>> Note that functions on enriched spaces can be a bit treacherous since
>>> the basis is not a nodal basis.
>>>
>>>
>> I've been thinking some about this. Let me try to explain why this is
>> nontrivial.
>>
>> Say, we have two element spaces
>>
>> V = span ( {v_i} )
>> Q = span ( {q_j})
>>
>> and create an "enriched space"
>>
>> W = V + Q
>>
>> so that
>>
>> W = span ( {v_i, q_j})
>>
>> We also define the degrees of freedom on W by taking the set of
>> all degrees of freedom on V (L_i) and all degrees of freedom on Q (K_j)
>>
>> ( {L_i}, {K_j} )
>>
>> At this point, we are starting to tweak the ffc element framework a bit,
>> because the basis for W is _not_ a nodal basis with respect to the
>> degrees of freedom: it might be (actually, quite often is) that
>>
>> L_i (q_j) \not = 0
>>
>> for all i, j and vice versa for K_j (v_i).)
>>
>> A function f in W can be represented as
>>
>> f = \alpha_i v_i + beta_j q_j
>>
>> However, note that for some degree of freedom L_k,
>>
>> L_k(f) = \alpha_k + \beta_j L_k(q_j)
>>
>> Hence, the coefficients in the vector do _not_ directly correspond to
>> the degrees of freedom, unless L_k(q_j) = 0 for all k, j. This means
>> that most kinds of function manipulation on enriched elements give you
>> something different than what you might think you get.
>>
>> There are however exceptions where things are good: Take for instance
>> continuous linears plus bubble:
>>
>> V = FiniteElement("CG", "triangle", 1)
>> Q = FiniteElement("B", "triangle", 3)
>> W = V + Q
>>
>> Since the bubble basis functions are zero on the boundary of each
>> element, with the above notation
>>
>> L_k (q_j) = 0
>>
>> for all k, j. This means that you can do
>>
>> f = Function(W)
>> g = interpolate(f, V)
>>
>> Then g will be what I think you want from
>>
>> (g, h) = split(f)
>>
>> In order to get h, you could do
>>
>> h = f - g
>>
>>
>> It would be possible to extract the vectors {\alpha_i} and {\beta_j}
>> from a Function on an enriched elements, but this requires quite a bit
>> of work, and is mainly DOLFIN related (rather than FFC/UFL).
>>
> Actually we were handling this inside main file before, but we didn't
> like it. It makes code dirty especially for the nonlinear problems in
> which we need to obtain these functions in each iteration explicitly.
>
> We think that handling enriched elements inside FFC/UFL is not
> consistent with the rest. This causes problems while working with
> enriched elements.
>
So, let's take this discussion on a mailing list instead?
--
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] Fwd: Re: function on EnrichedElement
On 16. juni 2010 13:41, Mehdi wrote:
> On Tue, 2010-06-15 at 15:35 +0200, Marie Rognes wrote:
>
>>
>> Original Message
>> Subject:
>> Re: function on EnrichedElement
>> Date:
>> Tue, 15 Jun 2010 15:27:44 +0200
>> From:
>> Marie Rognes
>>To:
>> Mehdi
>>CC:
>> gn...@cam.ac.uk, Anders Logg
>>
>>
>>
>> On 15. juni 2010 15:12, Mehdi wrote:
>>
>>> On Tue, 2010-06-15 at 14:26 +0200, Marie Rognes wrote:
>>>
>>>
>>>> On 14. juni 2010 19:57, Marie Rognes wrote:
>>>>
>>>>
>>>>> On 14. juni 2010 19:37, Mehdi wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, 2010-06-14 at 19:18 +0200, Marie Rognes wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 14. juni 2010 18:10, Mehdi wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Marie,
>>>>>>>>
>>>>>>>> I have a function defined on Enriched Element. I want to have access to
>>>>>>>> the subfunctions defined on this space. How ffc/ufl can be extended to
>>>>>>>> handle this issue?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Could you give me a piece of sample code?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> The input is something like this,
>>>>>>
>>>>>> Elem1 = VectorElement("Lagrange", triangle, 2)
>>>>>> Elem2 = VectorElement("Lagrange", triangle, 1)
>>>>>>
>>>>>> Element = Elem1 + Elem2
>>>>>>
>>>>>> u = Coefficient(Element)
>>>>>>
>>>>>> # I want to have this functionality
>>>>>> u1, u2 = split(u)
>>>>>>
>>>>>> Thank you in advance.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Will see what I can do tomorrow.
>>>>>
>>>>> Note that functions on enriched spaces can be a bit treacherous since
>>>>> the basis is not a nodal basis.
>>>>>
>>>>>
>>>>>
>>>> I've been thinking some about this. Let me try to explain why this is
>>>> nontrivial.
>>>>
>>>> Say, we have two element spaces
>>>>
>>>> V = span ( {v_i} )
>>>> Q = span ( {q_j})
>>>>
>>>> and create an "enriched space"
>>>>
>>>> W = V + Q
>>>>
>>>> so that
>>>>
>>>> W = span ( {v_i, q_j})
>>>>
>>>> We also define the degrees of freedom on W by taking the set of
>>>> all degrees of freedom on V (L_i) and all degrees of freedom on Q (K_j)
>>>>
>>>> ( {L_i}, {K_j} )
>>>>
>>>> At this point, we are starting to tweak the ffc element framework a bit,
>>>> because the basis for W is _not_ a nodal basis with respect to the
>>>> degrees of freedom: it might be (actually, quite often is) that
>>>>
>>>> L_i (q_j) \not = 0
>>>>
>>>> for all i, j and vice versa for K_j (v_i).)
>>>>
>>>> A function f in W can be represented as
>>>>
>>>> f = \alpha_i v_i + beta_j q_j
>>>>
>>>> However, note that for some degree of freedom L_k,
>>>>
>>>> L_k(f) = \alpha_k + \beta_j L_k(q_j)
>>>>
>>>> Hence, the coefficients in the vector do _not_ directly correspond to
>>>> the degrees of freedom, unless L_k(q_j) = 0 for all k, j. This means
>>>> that most kinds of function manipulation on enrich
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 16. juni 2010 15:51, Mehdi wrote:
> On Wed, 2010-06-16 at 14:03 +0200, Marie Rognes wrote:
>
>> On 16. juni 2010 13:41, Mehdi wrote:
>>
>>> On Tue, 2010-06-15 at 15:35 +0200, Marie Rognes wrote:
>>>
>>>
>>>> Original Message
>>>> Subject:
>>>> Re: function on EnrichedElement
>>>> Date:
>>>> Tue, 15 Jun 2010 15:27:44 +0200
>>>> From:
>>>> Marie Rognes
>>>>To:
>>>> Mehdi
>>>> CC:
>>>> gn...@cam.ac.uk, Anders Logg
>>>>
>>>>
>>>>
>>>> On 15. juni 2010 15:12, Mehdi wrote:
>>>>
>>>>
>>>>> On Tue, 2010-06-15 at 14:26 +0200, Marie Rognes wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 14. juni 2010 19:57, Marie Rognes wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 14. juni 2010 19:37, Mehdi wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mon, 2010-06-14 at 19:18 +0200, Marie Rognes wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 14. juni 2010 18:10, Mehdi wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Marie,
>>>>>>>>>>
>>>>>>>>>> I have a function defined on Enriched Element. I want to have access
>>>>>>>>>> to
>>>>>>>>>> the subfunctions defined on this space. How ffc/ufl can be extended
>>>>>>>>>> to
>>>>>>>>>> handle this issue?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Could you give me a piece of sample code?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The input is something like this,
>>>>>>>>
>>>>>>>> Elem1 = VectorElement("Lagrange", triangle, 2)
>>>>>>>> Elem2 = VectorElement("Lagrange", triangle, 1)
>>>>>>>>
>>>>>>>> Element = Elem1 + Elem2
>>>>>>>>
>>>>>>>> u = Coefficient(Element)
>>>>>>>>
>>>>>>>> # I want to have this functionality
>>>>>>>> u1, u2 = split(u)
>>>>>>>>
>>>>>>>> Thank you in advance.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Will see what I can do tomorrow.
>>>>>>>
>>>>>>> Note that functions on enriched spaces can be a bit treacherous since
>>>>>>> the basis is not a nodal basis.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I've been thinking some about this. Let me try to explain why this is
>>>>>> nontrivial.
>>>>>>
>>>>>> Say, we have two element spaces
>>>>>>
>>>>>> V = span ( {v_i} )
>>>>>> Q = span ( {q_j})
>>>>>>
>>>>>> and create an &q
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 17. juni 2010 15:44, Mehdi wrote: > On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote: > >> On 16 June 2010 17:28, Garth N. Wells wrote: >> >>> >>> On 16/06/10 15:55, Kristian Oelgaard wrote: >>> >>>> On 16 June 2010 16:45, Garth N. Wells wrote: >>>> >>>>> >>>>> On 16/06/10 15:20, Marie Rognes wrote: >>>>> >>>>>> On 16. juni 2010 15:51, Mehdi wrote: >>>>>> >>>>>>> On Wed, 2010-06-16 at 14:03 +0200, Marie Rognes wrote: >>>>>>> >>>>>>> >>>>>>>> On 16. juni 2010 13:41, Mehdi wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Tue, 2010-06-15 at 15:35 +0200, Marie Rognes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Original Message >>>>>>>>>> Subject: >>>>>>>>>> Re: function on EnrichedElement >>>>>>>>>> Date: >>>>>>>>>> Tue, 15 Jun 2010 15:27:44 +0200 >>>>>>>>>> From: >>>>>>>>>> Marie Rognes >>>>>>>>>>To: >>>>>>>>>> Mehdi >>>>>>>>>> CC: >>>>>>>>>> gn...@cam.ac.uk, Anders Logg >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 15. juni 2010 15:12, Mehdi wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Tue, 2010-06-15 at 14:26 +0200, Marie Rognes wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 14. juni 2010 19:57, Marie Rognes wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 14. juni 2010 19:37, Mehdi wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, 2010-06-14 at 19:18 +0200, Marie Rognes wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 14. juni 2010 18:10, Mehdi wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Marie, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have a function defined on Enriched Element. I want to have >>>>>>>>>>>>>>>> access to >>>>>>>>>>>>>>>> the subfunctions defined on this space. How ffc/ufl can be >>>>>>>>>>>>>>>> extended to >>>>>>>>>>>>>>>> handle this issue? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 18. juni 2010 11:38, Kristian Oelgaard wrote:
> On 18 June 2010 01:44, Marie Rognes wrote:
>
>> On 17. juni 2010 15:44, Mehdi wrote:
>>
>> On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
>>
>>
>>
>> Mehdi and I discussed this a bit, one way to get around this in FFC is to
>> let
>> VectorElement accept a FiniteElement as argument, then you can do
>>
>> element = VectorElement(V + Q)
>>
>> and still be dimension independent.
>>
>> Or in UFL we can tweak the '+' operator, such that enriching a
>> VectorElement means enriching each of the components of 'self' with
>> the components of 'other'. For this to work the dimension of the two
>> vector elements must of course be identical but I guess that will
>> always be the case, otherwise we throw an error.
>>
>>
>> I will go for this option. This allows us to have simpler code and
>> preserves accessing to the sub-elements of enriched mixed element.
>>
>>
>>
>> How do you plan on handling elements such as the following (relevant in
>> connection with the PEERS element for linear elasticity) with this approach?
>>
>> V = FiniteElement("RT", "triangle", 1)
>> Q = VectorElement("B", "triangle", 3)
>> W = V + Q
>>
> I was planning on throwing an error :)
>
Please don't :)
> I did not know that one would ever want to enrich a scalar element
> with a vector bubble function,
Since RT is a vector-valued element, enriching it with a vector bubble
function
is well-defined.
Strictly speaking, my example is not the enrichment of one UFL VectorElement
with another VectorElement. So, I guess you could overload + for
VectorElement (and TensorElement) only. However, that would make
V = FiniteElement("CG", "triangle", 1)
V = V*V
B = VectorElement("B", "triangle", 3)
W = V + B
and
V2 = VectorElement("CG", "triangle", 1)
W = V2 + B
behave differently, which I imagine could be rather confusing.
> but since this appears to be the case
> the only two options, as I see it, are:
>
> 1) do nothing such that one will have to do
>
> P1 = FiniteElement("Lagrange", tetrahedron, 1)
> B = FiniteElement("Bubble", tetrahedron, 3)
> Q = FiniteElement("CG", triangle, 1)
> Mini = MixedElement([P1 + B], [P1 + B], [P1 + B])*Q
>
> manually.
>
> 2) have VectorElement accept FiniteElementBase as argument to allow
>
> Mini = VectorElement(P1 + B)*Q
>
> which will reduce the labour of defining elements and still be
> independent of dimensions.
>
>
Option 2) sounds neat and useful in other contexts too :)
> We could of course try to 'guess' what the user wants but I don't
> think that is a good idea.
>
>
Agree.
--
Marie
> Kristian
>
>
>> v = TestFunction(W)
>> u = TrialFunction(W)
>> a = dot(v, u)*dx
>>
>> --
>> Marie
>>
>>
>>
>>
>> Mehdi
>>
>>
>> Kristian
>>
>>
>>
>> Garth
>>
>>
>>
>> Kristian
>>
>>
>>
>> Garth
>>
>>
>>
>>
>>
>> --
>> Marie
>>
>>
>>
>> Mehdi
>>
>>
>>
>>
>> --
>> Marie
>>
>>
>>
>>
>>
>> Mehdi
>>
>>
>>
>>
>>
>> ___
>> 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
>>
>>
>> ___
>> 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] Fwd: Re: function on EnrichedElement
On 18. juni 2010 12:23, Kristian Oelgaard wrote:
> On 18 June 2010 12:05, Marie Rognes wrote:
>
>> On 18. juni 2010 11:38, Kristian Oelgaard wrote:
>>
>>> On 18 June 2010 01:44, Marie Rognes wrote:
>>>
>>>
>>>> On 17. juni 2010 15:44, Mehdi wrote:
>>>>
>>>> On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
>>>>
>>>>
>>>>
>>>> Mehdi and I discussed this a bit, one way to get around this in FFC is to
>>>> let
>>>> VectorElement accept a FiniteElement as argument, then you can do
>>>>
>>>> element = VectorElement(V + Q)
>>>>
>>>> and still be dimension independent.
>>>>
>>>> Or in UFL we can tweak the '+' operator, such that enriching a
>>>> VectorElement means enriching each of the components of 'self' with
>>>> the components of 'other'. For this to work the dimension of the two
>>>> vector elements must of course be identical but I guess that will
>>>> always be the case, otherwise we throw an error.
>>>>
>>>>
>>>> I will go for this option. This allows us to have simpler code and
>>>> preserves accessing to the sub-elements of enriched mixed element.
>>>>
>>>>
>>>>
>>>> How do you plan on handling elements such as the following (relevant in
>>>> connection with the PEERS element for linear elasticity) with this
>>>> approach?
>>>>
>>>> V = FiniteElement("RT", "triangle", 1)
>>>> Q = VectorElement("B", "triangle", 3)
>>>> W = V + Q
>>>>
>>>>
>>> I was planning on throwing an error :)
>>>
>>>
>>
>> Please don't :)
>>
>>
>>> I did not know that one would ever want to enrich a scalar element
>>> with a vector bubble function,
>>>
>> Since RT is a vector-valued element, enriching it with a vector bubble
>> function
>> is well-defined.
>>
> Ha, I completely missed the 'RT', that's what you get for working with
> 'CG' only :)
> Now it makes a lot more sense to me.
>
>
Ok :)
>> Strictly speaking, my example is not the enrichment of one UFL VectorElement
>> with another VectorElement. So, I guess you could overload + for
>> VectorElement (and TensorElement) only. However, that would make
>>
> Yes, that's what we had in mind, then instead of an error we just
> return an EnrichedElement, then it's up to the user to make sure that
> the enrichment makes sense. I haven't looked at the code in detail
> now, but maybe there are other things we need to check for.
>
>
>>V = FiniteElement("CG", "triangle", 1)
>>V = V*V
>>B = VectorElement("B", "triangle", 3)
>>W = V + B
>>
>> and
>>
>>V2 = VectorElement("CG", "triangle", 1)
>>W = V2 + B
>>
>> behave differently, which I imagine could be rather confusing.
>>
> They do?
>
Assumption A: If you only overload + for VectorElement and TensorElement.
Under A, yes.
> I would expect both instances to end up meaning
> W = MixedElement([FiniteElement('CG', 'triangle', 1) + B]*2)
>
> or can you spell it out for me?
>
>
Again, under A:
In the first case, V becomes a MixedElement, and then MixedElement +
VectorElement -> EnrichedElement
In the second case V is a VectorElement and then VectorElement +
VectorElement -> VectorElement
>>
>>> but since this appears to be the case
>>> the only two options, as I see it, are:
>>>
>>> 1) do nothing such that one will have to do
>>>
>>> P1 = FiniteElement("Lagrange", tetrahedron, 1)
>>> B = FiniteElement("Bubble", tetrahedron, 3)
>>> Q = FiniteElement("CG", triangle, 1)
>>> Mini = MixedElement([P1 + B], [P1 + B], [P1 + B])*Q
>>>
>>> manually.
>>>
>>> 2) have VectorElement accept FiniteElementBase as argument to allow
>>>
>>> Mini = VectorElement(P1 + B)*Q
>>>
>>> which will reduce the labour of defining elements and still be
>>> independent of dimensions.
>>>
>>>
>>>
>>
>> Option 2) sounds neat and useful in other contexts too :)
>>
> We of course still d
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 18. juni 2010 13:43, Kristian Oelgaard wrote:
> On 18 June 2010 13:20, Mehdi wrote:
>
>> On Fri, 2010-06-18 at 12:34 +0200, Marie Rognes wrote:
>>
>>> On 18. juni 2010 12:23, Kristian Oelgaard wrote:
>>>
>>>> On 18 June 2010 12:05, Marie Rognes wrote:
>>>>
>>>>
>>>>> On 18. juni 2010 11:38, Kristian Oelgaard wrote:
>>>>>
>>>>>
>>>>>> On 18 June 2010 01:44, Marie Rognes wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 17. juni 2010 15:44, Mehdi wrote:
>>>>>>>
>>>>>>> On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mehdi and I discussed this a bit, one way to get around this in FFC is
>>>>>>> to
>>>>>>> let
>>>>>>> VectorElement accept a FiniteElement as argument, then you can do
>>>>>>>
>>>>>>> element = VectorElement(V + Q)
>>>>>>>
>>>>>>> and still be dimension independent.
>>>>>>>
>>>>>>> Or in UFL we can tweak the '+' operator, such that enriching a
>>>>>>> VectorElement means enriching each of the components of 'self' with
>>>>>>> the components of 'other'. For this to work the dimension of the two
>>>>>>> vector elements must of course be identical but I guess that will
>>>>>>> always be the case, otherwise we throw an error.
>>>>>>>
>>>>>>>
>>>>>>> I will go for this option. This allows us to have simpler code and
>>>>>>> preserves accessing to the sub-elements of enriched mixed element.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> How do you plan on handling elements such as the following (relevant in
>>>>>>> connection with the PEERS element for linear elasticity) with this
>>>>>>> approach?
>>>>>>>
>>>>>>> V = FiniteElement("RT", "triangle", 1)
>>>>>>> Q = VectorElement("B", "triangle", 3)
>>>>>>> W = V + Q
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I was planning on throwing an error :)
>>>>>>
>>>>>>
>>>>>>
>>>>> Please don't :)
>>>>>
>>>>>
>>>>>
>>>>>> I did not know that one would ever want to enrich a scalar element
>>>>>> with a vector bubble function,
>>>>>>
>>>>>>
>>>>> Since RT is a vector-valued element, enriching it with a vector bubble
>>>>> function
>>>>> is well-defined.
>>>>>
>>>>>
>>>> Ha, I completely missed the 'RT', that's what you get for working with
>>>> 'CG' only :)
>>>> Now it makes a lot more sense to me.
>>>>
>>>>
>>>>
>>> Ok :)
>>>
>>>
>>>>> Strictly speaking, my example is not the enrichment of one UFL
>>>>> VectorElement
>>>>> with another VectorElement. So, I guess you could overload + for
>>>>> VectorElement (and TensorElement) only. However, that would make
>>>>>
>>>>>
>>>> Yes, that's what we had in mind, then instead of an error we just
>>>> return an EnrichedElement, then it's up to the user to make sure that
>>>> the enrichment makes sense. I haven't looked at the code in detail
>>>> now, but maybe there are other things we need to check for.
>>>>
>>>>
>>>>
>>>>>V = FiniteElement("CG", "triangle", 1)
>>>>>V = V*V
>>>>>B = VectorElement("B", "triangle", 3)
>>>>>W = V + B
>>>>>
>>>>> and
>>>>>
>>>>>V2 = VectorElement("CG", "triangle", 1)
>>>>>W = V2 + B
>>>>>
>>
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 18. juni 2010 15:08, Kristian Oelgaard wrote:
> On 18 June 2010 14:12, Marie Rognes wrote:
>
>> On 18. juni 2010 13:43, Kristian Oelgaard wrote:
>>
>> On 18 June 2010 13:20, Mehdi wrote:
>>
>>
>> On Fri, 2010-06-18 at 12:34 +0200, Marie Rognes wrote:
>>
>>
>> On 18. juni 2010 12:23, Kristian Oelgaard wrote:
>>
>>
>> On 18 June 2010 12:05, Marie Rognes wrote:
>>
>>
>>
>> On 18. juni 2010 11:38, Kristian Oelgaard wrote:
>>
>>
>>
>> On 18 June 2010 01:44, Marie Rognes wrote:
>>
>>
>>
>>
>> On 17. juni 2010 15:44, Mehdi wrote:
>>
>> On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
>>
>>
>>
>> Mehdi and I discussed this a bit, one way to get around this in FFC is to
>> let
>> VectorElement accept a FiniteElement as argument, then you can do
>>
>> element = VectorElement(V + Q)
>>
>> and still be dimension independent.
>>
>> Or in UFL we can tweak the '+' operator, such that enriching a
>> VectorElement means enriching each of the components of 'self' with
>> the components of 'other'. For this to work the dimension of the two
>> vector elements must of course be identical but I guess that will
>> always be the case, otherwise we throw an error.
>>
>>
>> I will go for this option. This allows us to have simpler code and
>> preserves accessing to the sub-elements of enriched mixed element.
>>
>>
>>
>> How do you plan on handling elements such as the following (relevant in
>> connection with the PEERS element for linear elasticity) with this approach?
>>
>> V = FiniteElement("RT", "triangle", 1)
>> Q = VectorElement("B", "triangle", 3)
>> W = V + Q
>>
>>
>>
>>
>> I was planning on throwing an error :)
>>
>>
>>
>>
>> Please don't :)
>>
>>
>>
>>
>> I did not know that one would ever want to enrich a scalar element
>> with a vector bubble function,
>>
>>
>>
>> Since RT is a vector-valued element, enriching it with a vector bubble
>> function
>> is well-defined.
>>
>>
>>
>> Ha, I completely missed the 'RT', that's what you get for working with
>> 'CG' only :)
>> Now it makes a lot more sense to me.
>>
>>
>>
>>
>> Ok :)
>>
>>
>>
>> Strictly speaking, my example is not the enrichment of one UFL VectorElement
>> with another VectorElement. So, I guess you could overload + for
>> VectorElement (and TensorElement) only. However, that would make
>>
>>
>>
>> Yes, that's what we had in mind, then instead of an error we just
>> return an EnrichedElement, then it's up to the user to make sure that
>> the enrichment makes sense. I haven't looked at the code in detail
>> now, but maybe there are other things we need to check for.
>>
>>
>>
>>
>>V = FiniteElement("CG", "triangle", 1)
>>V = V*V
>>B = VectorElement("B", "triangle", 3)
>>W = V + B
>>
>> and
>>
>>V2 = VectorElement("CG", "triangle", 1)
>>W = V2 + B
>>
>> behave differently, which I imagine could be rather confusing.
>>
>>
>>
>> They do?
>>
>>
>>
>> Assumption A: If you only overload + for VectorElement and TensorElement.
>>
>> Under A, yes.
>>
>>
>> I think if we want to overload +, by default we should treat these two
>> cases equally.
>>
>>
>> Well, I never intended to overload '+' for just Vector and Tensor elements,
>> I would overload the MixedElement class which is the base class for
>> the two special types.
>> Then the two cases will result in the same element, we should of
>> course check for equal length of the two mixed elements, and in case
>> of nested mixed elements, we let the '+' operator handle this on the
>> sub elements.
>>
>>
>>
>> Ok, then what will be the effect for a mixed/vector version of my previous
>> example? (which is even more relevant for the PEERS element ;) )
>>
>> V = FiniteElement("RT", "triangle", 1)
>> V = V * V
>> Q = VectorElement("B", "triangle", 3, 4)
>>
>> W = V + Q
>>
> This will (and should) crash for sure, len(V) = 2, len(Q) = 4; so it
>
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 18. juni 2010 16:16, Kristian Oelgaard wrote:
> On 18 June 2010 15:19, Marie Rognes wrote:
>
>> On 18. juni 2010 15:08, Kristian Oelgaard wrote:
>>
>>> On 18 June 2010 14:12, Marie Rognes wrote:
>>>
>>>
>>>> On 18. juni 2010 13:43, Kristian Oelgaard wrote:
>>>>
>>>> On 18 June 2010 13:20, Mehdi wrote:
>>>>
>>>>
>>>> On Fri, 2010-06-18 at 12:34 +0200, Marie Rognes wrote:
>>>>
>>>>
>>>> On 18. juni 2010 12:23, Kristian Oelgaard wrote:
>>>>
>>>>
>>>> On 18 June 2010 12:05, Marie Rognes wrote:
>>>>
>>>>
>>>>
>>>> On 18. juni 2010 11:38, Kristian Oelgaard wrote:
>>>>
>>>>
>>>>
>>>> On 18 June 2010 01:44, Marie Rognes wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 17. juni 2010 15:44, Mehdi wrote:
>>>>
>>>> On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
>>>>
>>>>
>>>>
>>>> Mehdi and I discussed this a bit, one way to get around this in FFC is to
>>>> let
>>>> VectorElement accept a FiniteElement as argument, then you can do
>>>>
>>>> element = VectorElement(V + Q)
>>>>
>>>> and still be dimension independent.
>>>>
>>>> Or in UFL we can tweak the '+' operator, such that enriching a
>>>> VectorElement means enriching each of the components of 'self' with
>>>> the components of 'other'. For this to work the dimension of the two
>>>> vector elements must of course be identical but I guess that will
>>>> always be the case, otherwise we throw an error.
>>>>
>>>>
>>>> I will go for this option. This allows us to have simpler code and
>>>> preserves accessing to the sub-elements of enriched mixed element.
>>>>
>>>>
>>>>
>>>> How do you plan on handling elements such as the following (relevant in
>>>> connection with the PEERS element for linear elasticity) with this
>>>> approach?
>>>>
>>>> V = FiniteElement("RT", "triangle", 1)
>>>> Q = VectorElement("B", "triangle", 3)
>>>> W = V + Q
>>>>
>>>>
>>>>
>>>>
>>>> I was planning on throwing an error :)
>>>>
>>>>
>>>>
>>>>
>>>> Please don't :)
>>>>
>>>>
>>>>
>>>>
>>>> I did not know that one would ever want to enrich a scalar element
>>>> with a vector bubble function,
>>>>
>>>>
>>>>
>>>> Since RT is a vector-valued element, enriching it with a vector bubble
>>>> function
>>>> is well-defined.
>>>>
>>>>
>>>>
>>>> Ha, I completely missed the 'RT', that's what you get for working with
>>>> 'CG' only :)
>>>> Now it makes a lot more sense to me.
>>>>
>>>>
>>>>
>>>>
>>>> Ok :)
>>>>
>>>>
>>>>
>>>> Strictly speaking, my example is not the enrichment of one UFL
>>>> VectorElement
>>>> with another VectorElement. So, I guess you could overload + for
>>>> VectorElement (and TensorElement) only. However, that would make
>>>>
>>>>
>>>>
>>>> Yes, that's what we had in mind, then instead of an error we just
>>>> return an EnrichedElement, then it's up to the user to make sure that
>>>> the enrichment makes sense. I haven't looked at the code in detail
>>>> now, but maybe there are other things we need to check for.
>>>>
>>>>
>>>>
>>>>
>>>>V = FiniteElement("CG", "triangle", 1)
>>>>V = V*V
>>>>B = VectorElement("B", "triangle", 3)
>>>>W = V + B
>>>>
>>>> and
>>>>
>>>>V2 = VectorElement("CG", "triangle", 1)
>>>>W = V2 + B
>>>>
>>>> behave differently, which I imagine could be rather confusing.
>>>>
>>>>
>>>>
>>>> They do?
>>>>
>>>>
>>>>
>
Re: [Ffc] Fwd: Re: function on EnrichedElement
On 18. juni 2010 16:23, Kristian Oelgaard wrote:
> On 18 June 2010 15:25, Mehdi wrote:
>
>>
>> If we want to address this issue, the same concept should be also
>> considered for ElementRestriction. What would we expect if we enrich a
>> vector element with a restricted vector element?
>>
>> V = VectorElement("CG", "triangle", 1)
>> B = ElementRestriction(V, dc)
>>
>> W = V + B
>>
>> Since this restricted element is not vector element anymore.
>>
> Can't we just check, inside the '+' operator, if an element is an
> ElementRestriction and then if the restricted element is a
> VectorElement
> BTW, shouldn't it be RestrictedElement (like EnrichedElement) rather
> than ElementRestriction?
>
>
Yes, that would be more consistent.
> Another possibility is to propagate the restriction to the subelements
> when creating the restricted element and then return a VectorElement
> with restricted sub elements. Did we try that and fail at some point?
> I forgot.
>
>
FFC does do this for its internal representation of restricted elements...
--
Marie
> Kristian
>
>
>> Yours,
>> Mehdi
>>
>>
>>
>>> Kristian
>>>
>>>
Another advantages of using this approach is we don't need to define
unnecessary scaler elements to just get mixed enriched element. The
approach of defining scaler elements can be annoying, if we want to use
both enriched and non-enriched vector elements(which is the case often
for me).
If we overload +, it is just enough to have:
V = VectorElement("CG", "triangle", 1)
B = VectorElement("B", "triangle", 3)
M = V + B
We can use M and V both to define our functions.
This is definitely and advantage.
If we want to extend VectorElement, this would be,
V1 = FiniteElement("CG", "triangle", 1)
B1 = FiniteElement("B", "triangle", 3)
M = VectorElemnet(V1 + B1)
But we can still extend the vector element to enable this it you think
it will be useful, that was the essence of my earlier and confusing
remark which should have been:
'We CAN of course still do this even if we decide on option 1)'
Ok, sentence makes sense now!
--
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] Fwd: Re: function on EnrichedElement
On 18. juni 2010 17:09, Kristian Oelgaard wrote:
> On 18 June 2010 16:28, Marie Rognes wrote:
>
>> On 18. juni 2010 16:16, Kristian Oelgaard wrote:
>>
>>> On 18 June 2010 15:19, Marie Rognes wrote:
>>>
>>>
>>>> On 18. juni 2010 15:08, Kristian Oelgaard wrote:
>>>>
>>>>
>>>>> On 18 June 2010 14:12, Marie Rognes wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 18. juni 2010 13:43, Kristian Oelgaard wrote:
>>>>>>
>>>>>> On 18 June 2010 13:20, Mehdi wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, 2010-06-18 at 12:34 +0200, Marie Rognes wrote:
>>>>>>
>>>>>>
>>>>>> On 18. juni 2010 12:23, Kristian Oelgaard wrote:
>>>>>>
>>>>>>
>>>>>> On 18 June 2010 12:05, Marie Rognes wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 18. juni 2010 11:38, Kristian Oelgaard wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 18 June 2010 01:44, Marie Rognes wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17. juni 2010 15:44, Mehdi wrote:
>>>>>>
>>>>>> On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mehdi and I discussed this a bit, one way to get around this in FFC is to
>>>>>> let
>>>>>> VectorElement accept a FiniteElement as argument, then you can do
>>>>>>
>>>>>> element = VectorElement(V + Q)
>>>>>>
>>>>>> and still be dimension independent.
>>>>>>
>>>>>> Or in UFL we can tweak the '+' operator, such that enriching a
>>>>>> VectorElement means enriching each of the components of 'self' with
>>>>>> the components of 'other'. For this to work the dimension of the two
>>>>>> vector elements must of course be identical but I guess that will
>>>>>> always be the case, otherwise we throw an error.
>>>>>>
>>>>>>
>>>>>> I will go for this option. This allows us to have simpler code and
>>>>>> preserves accessing to the sub-elements of enriched mixed element.
>>>>>>
>>>>>>
>>>>>>
>>>>>> How do you plan on handling elements such as the following (relevant in
>>>>>> connection with the PEERS element for linear elasticity) with this
>>>>>> approach?
>>>>>>
>>>>>> V = FiniteElement("RT", "triangle", 1)
>>>>>> Q = VectorElement("B", "triangle", 3)
>>>>>> W = V + Q
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was planning on throwing an error :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please don't :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I did not know that one would ever want to enrich a scalar element
>>>>>> with a vector bubble function,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Since RT is a vector-valued element, enriching it with a vector bubble
>>>>>> function
>>>>>> is well-defined.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ha, I completely missed the 'RT', that's what you get for working with
>>>>>> 'CG' only :)
>>>>>> Now it makes a lot more sense to me.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ok :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Strictly speaking, my example is not the enrichment of one UFL
>>>>>> VectorElement
>>>>>> with another VectorElement. So, I guess you could overload + for
>>>>>> VectorElement (and TensorElement) only. However, that would make
>>>>>>
>>>>>>
[Ffc] Forms with TrialFunctions (only)
Just checking: should this form L = u*dx be ok? -- 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] All components of a list tensor most provide same arguments?
On 17. nov. 2010 14:36, Patrick Riesen wrote: > hello, > i'm trying to update my code for the most recent fenics development > versions. > > compiling+demos for ffc/ufl/dolfin etc. is all ok. > > now my code has a problem, i have the following in the ufl-file: > > > e = as_matrix([[0.5*u.dx(0)**2, 0.5*u.dx(0)], >[0.5*u.dx(0) ,0.0]]) > > e_dev = e - 0.5*tr(e)*Identity(2) > > Ie = 0.5*tr(e_dev*e_dev) > beta = K*exp(-c*Ie) > > > > note: > the variable u is a coefficient from a mixed element as > uw = Coefficient(ME) > u, w = split(uw) > > > compiling with ffc now terminates after the compiler stage 1 and gives: > > All components of a list tensor most provide same arguments > > *** FFC: All components of a list tensor most provide same arguments > *** FFC: To get more information about this error, rerun FFC with > --verbose. > > what does this mean? how do i need to fix my syntax above? When compiling a given form 'a', FFC now checks that the form has a single rank; that is, that all terms in the form has the same rank. FFC does this (more or less) by extracting the ranks of all the terms appearing in the form and checking that there is only one rank. Problems can arise with list tensors (such as as_matrix(...)) where the components have different ranks. It is odd however, that the above example gives problems since if u is a coefficient, then 0.5*u.dx(0) and 0.0 should have the same rank. Could you provide a minimal runnable example that reproduces the error? -- 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] All components of a list tensor most provide same arguments?
On 17. nov. 2010 16:15, Patrick Riesen wrote:
> Nope, won't do differnt with Zero().
> Here is a simple complete program:
> -
> cell = interval
> FE = FiniteElement("CG", cell, 2)
>
> v = TestFunction(FE)
> U = TrialFunction(FE)
>
> u = Coefficient(FE)
>
> K = Constant(cell)
> c = Constant(cell)
>
> e = as_matrix([[0.5*u.dx(0)**2, 0.5*u.dx(0)],
>[0.5*u.dx(0) , Zero()]])
>
> e_dev = e - 0.5*tr(e)*Identity(2)
>
> Ie = 0.5*tr(e_dev*e_dev)
> beta = K*exp(-c*Ie)
>
> L = v.dx(0)*beta*0.5*u.dx(0)*dx# ok
> a = derivative(L, u, U)# it fails here
> -
>
>
Thanks. I see what is going on, but do not quite know how to fix it
immediately.
Please add a bug report (for UFL, which is where the problem is), and
I'll think about how to fix it.
Here is a simpler example btw:
from ufl.algorithms import compute_form_arities
cell = interval
FE = FiniteElement("CG", cell, 2)
u = Coefficient(FE)
e = as_matrix([[u, 0.0],
[0.0, 0.0]])
L = tr(e)*dx
U = TrialFunction(FE)
a = derivative(L, u, U)
compute_form_arities(a)
--
Marie
regards,
> patrick
>
> On 11/17/2010 02:43 PM, Anders Logg wrote:
>> I don't know what that means, but I assume the 0.0 is the problem.
>>
>> Does it work if you write Zero()?
>>
>> --
>> Anders
>>
>>
>>
>> On Wed, Nov 17, 2010 at 02:36:54PM +0100, Patrick Riesen wrote:
>>> hello,
>>> i'm trying to update my code for the most recent fenics development
>>> versions.
>>>
>>> compiling+demos for ffc/ufl/dolfin etc. is all ok.
>>>
>>> now my code has a problem, i have the following in the ufl-file:
>>>
>>>
>>> e = as_matrix([[0.5*u.dx(0)**2, 0.5*u.dx(0)],
>>> [0.5*u.dx(0) ,0.0]])
>>>
>>> e_dev = e - 0.5*tr(e)*Identity(2)
>>>
>>> Ie = 0.5*tr(e_dev*e_dev)
>>> beta = K*exp(-c*Ie)
>>>
>>>
>>>
>>> note:
>>> the variable u is a coefficient from a mixed element as
>>> uw = Coefficient(ME)
>>> u, w = split(uw)
>>>
>>>
>>> compiling with ffc now terminates after the compiler stage 1 and gives:
>>>
>>> All components of a list tensor most provide same arguments
>>>
>>> *** FFC: All components of a list tensor most provide same arguments
>>> *** FFC: To get more information about this error, rerun FFC with
>>> --verbose.
>>>
>>> what does this mean? how do i need to fix my syntax above?
>>>
>>> regards,
>>> patrick
>>>
>>> ___
>>> 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] All components of a list tensor most provide same arguments?
On 17. nov. 2010 17:50, Patrick Riesen wrote:
> Ok, i wanted to file a bug report just now, but i got two
>
> 'time out errors' from launchpad services. i'll try again later.
>
> btw. launchpad told me about a related (fixed) bug:
>
> #601965 compute_form_arities crashes in ListTensor
>
>
That bug was related to the same functionality, but a different problem
(which is fixed).
So, feel free to open a new one.
--
Marie
> anyway, many thanks and best regards,
> patrick
>
> On 11/17/2010 05:28 PM, Marie Rognes wrote:
>> On 17. nov. 2010 16:15, Patrick Riesen wrote:
>>> Nope, won't do differnt with Zero().
>>> Here is a simple complete program:
>>> -
>>> cell = interval
>>> FE = FiniteElement("CG", cell, 2)
>>>
>>> v = TestFunction(FE)
>>> U = TrialFunction(FE)
>>>
>>> u = Coefficient(FE)
>>>
>>> K = Constant(cell)
>>> c = Constant(cell)
>>>
>>> e = as_matrix([[0.5*u.dx(0)**2, 0.5*u.dx(0)],
>>> [0.5*u.dx(0) , Zero()]])
>>>
>>> e_dev = e - 0.5*tr(e)*Identity(2)
>>>
>>> Ie = 0.5*tr(e_dev*e_dev)
>>> beta = K*exp(-c*Ie)
>>>
>>> L = v.dx(0)*beta*0.5*u.dx(0)*dx# ok
>>> a = derivative(L, u, U)# it fails here
>>> -
>>>
>>>
>>
>>
>> Thanks. I see what is going on, but do not quite know how to fix it
>> immediately.
>> Please add a bug report (for UFL, which is where the problem is), and
>> I'll think about how to fix it.
>>
>> Here is a simpler example btw:
>>
>> from ufl.algorithms import compute_form_arities
>>
>> cell = interval
>> FE = FiniteElement("CG", cell, 2)
>> u = Coefficient(FE)
>>
>> e = as_matrix([[u, 0.0],
>> [0.0, 0.0]])
>> L = tr(e)*dx
>>
>> U = TrialFunction(FE)
>> a = derivative(L, u, U)
>> compute_form_arities(a)
>>
>> --
>> Marie
>>
>>
>> regards,
>>> patrick
>>>
>>> On 11/17/2010 02:43 PM, Anders Logg wrote:
>>>> I don't know what that means, but I assume the 0.0 is the problem.
>>>>
>>>> Does it work if you write Zero()?
>>>>
>>>> --
>>>> Anders
>>>>
>>>>
>>>>
>>>> On Wed, Nov 17, 2010 at 02:36:54PM +0100, Patrick Riesen wrote:
>>>>> hello,
>>>>> i'm trying to update my code for the most recent fenics development
>>>>> versions.
>>>>>
>>>>> compiling+demos for ffc/ufl/dolfin etc. is all ok.
>>>>>
>>>>> now my code has a problem, i have the following in the ufl-file:
>>>>>
>>>>>
>>>>> e = as_matrix([[0.5*u.dx(0)**2, 0.5*u.dx(0)],
>>>>> [0.5*u.dx(0) ,0.0]])
>>>>>
>>>>> e_dev = e - 0.5*tr(e)*Identity(2)
>>>>>
>>>>> Ie = 0.5*tr(e_dev*e_dev)
>>>>> beta = K*exp(-c*Ie)
>>>>>
>>>>>
>>>>>
>>>>> note:
>>>>> the variable u is a coefficient from a mixed element as
>>>>> uw = Coefficient(ME)
>>>>> u, w = split(uw)
>>>>>
>>>>>
>>>>> compiling with ffc now terminates after the compiler stage 1 and
>>>>> gives:
>>>>>
>>>>> All components of a list tensor most provide same arguments
>>>>>
>>>>> *** FFC: All components of a list tensor most provide same arguments
>>>>> *** FFC: To get more information about this error, rerun FFC with
>>>>> --verbose.
>>>>>
>>>>> what does this mean? how do i need to fix my syntax above?
>>>>>
>>>>> regards,
>>>>> patrick
>>>>>
>>>>> ___
>>>>> 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
