-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functions/co-functions and vectors/co-vectors #1159
Comments
I've run into this same problem in other contexts. An alternative to introducing
Not sure that it's any better or worse, just food for thought! |
I brought this up again in the slack channel the other day. Taking the dual of a function space might be a bad idea, because then you start having to worry about what happens when you take the dual twice. With that in mind, using a We also talked about how algebra on cofunctions would work -- what happens when you add
If you can't add a bilinear form and a matrix, then it's perfectly consistent if you also can't add a linear form and a cofunction. |
Update, work in progress document describing the new algebraic constructs in UFL: https://www.overleaf.com/read/tqzqzdybsdsq Comments to @dham. |
Finite dimensional vector spaces are reflexive so V** is isometrically isomorphic to V, hence we can just identify V** as V. |
This came up in a slack discussion that isn't archived, but I think at the time someone objected on the grounds that L^1 isn't reflexive. I also had the impression from the discussions about Koki's work that, at the UFL level, a finite-dimensional basis hasn't been introduced yet. It seems like this is moving towards using CoFunctions rather than representing the dual spaces themselves, in which case the question about double-duals is a moot point. And either way I'm happy to see this moving forward! |
The plan is to have dual spaces. However, I don't think L^1 is a relevant space. Everything in UFL is in L^2 at least, and that space is reflexive (all Hilbert spaces are reflexive). The objections to Koki's work was that it appeared to require UFL to know about the specific choice of basis. That UFL spaces are finite-dimensional and have a basis is, I believe, uncontroversial. The extensions I am proposing only assume the existence of a dual basis, not what it actually is. I think that won't cause too many fights. |
I think this issue should be closed now that the dual space changes have been merged (see #2294) |
I'm raising an issue here to keep track of this ongoing problem we have with describing a function vs a co-function.
We know mathematically what the difference is: Functions are linear combinations of finite element basis functions. These are the usual
firedrake.Function
s (ufl.Coefficient
s). Cofunctions are bounded linear maps which take functions and returns some scalar.I think this is what currently happens (please correct me if I'm wrong): Let
f
be some function. Thenfor some test function
v
produces aFunction
,g
, whose ith component is the evaulated inner product off
with the ith global finite element basis function. These are not functions! They are assembled functionals or co-functions are should be treated as such.In Slate, there are
AssembledVectors
which are only used in local actions (mat-vec multiplication). In most cases, these are actual vectors formed from a finite element function, but there may be instances where these may be co-vectors corresponding to assembled 1-forms.It makes sense to ask cofunctions for their arguments like a form, and ideally one should be able to use existing form operations on them with assembled or symbolic (UFL) forms. Basically, we need a way to distinguish functions/vectors and co-functions/co-vectors in Firedrake. This may require some changes to UFL.
So, questions:
What changes are required in UFL?
- New object:
Co-coefficient
?- How should we handle expressions like this: let
lv
be a hypothetical co-function andf
some coefficient. What do we do with:Firedrake changes?
- Probably should add
CoFunction
or something like that.- How to assemble expressions like the one above?
- Slate changes:
AssembledVector
/AssembledCoVector
?Please feel free to edit this post to add additional points/development discussions.
The text was updated successfully, but these errors were encountered: