Skip to content

Conversation

@joewallwork
Copy link
Member

Closes #113.
Supersedes #187.

Okay I think this is a neater implementation. I still had to use (co)function2(co)function in the project approach, although I notice the corresponding tests now fail with small error values. Will have to dig into it to figure out what went wrong there.

@joewallwork joewallwork self-assigned this May 29, 2025
@joewallwork joewallwork added the bug Something isn't working label May 29, 2025
@joewallwork joewallwork requested a review from stephankramer May 29, 2025 08:02
Copy link
Collaborator

@stephankramer stephankramer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, just saw I still had this as "pending review comments" from quite a while ago already. I think this looked good, but I suspect it needs an update to current main and then I can have another look again?

For details on the approach for achieving boundedness through mass lumping and
post-processing, see :cite:`Farrell:2009`.
Overload :func:`firedrake.__future__.interpolate` to account for the case of mixed
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is no longer in __future__ (the future is now!): firedrakeproject/firedrake#4346

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh nice, thanks. Done in 6de0c0a.

:type bounded: :class:`bool`
Extra keyword arguments are passed to :func:`firedrake.projection.project`.
Extra keyword arguments are passed to :func:`firedrake.__future__.interpolate`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 6de0c0a.

Comment on lines 143 to 144
Overload :func:`firedrake.projection.project` to account for the case of mixed
function spaces.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does a bit more than that, no? Implement a bounded version, handle the dual case...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. Done in fe602c3.

@joewallwork
Copy link
Member Author

[Rebased on top of main]

@joewallwork
Copy link
Member Author

Okay we're now at a point where the (two) tests that fail are related to the PR, will look into them.

Copy link
Collaborator

@stephankramer stephankramer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great.
I guess this might also be a candidate for upstreaming to firedrake in the future: project should just be able to handle (dual) projecting cofunctions (even when supermeshing) - and interpolation/projection of mixed functions seems like a reasonable thing to expect Firedrake to handle as well...

@joewallwork
Copy link
Member Author

Looks great. I guess this might also be a candidate for upstreaming to firedrake in the future: project should just be able to handle (dual) projecting cofunctions (even when supermeshing) - and interpolation/projection of mixed functions seems like a reasonable thing to expect Firedrake to handle as well...

Yeah I already had them in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Adjoint interpolation operator is incorrect

3 participants