DedalusProject / dedalus

A flexible framework for solving PDEs with modern spectral methods.
http://dedalus-project.org/
GNU General Public License v3.0
492 stars 115 forks source link

antidifferentiate is obsolete in d3 #209

Open liamoconnor9 opened 2 years ago

liamoconnor9 commented 2 years ago

The antidifferentiate method in field.py hasn't been updated for use in d3. Daniel suggested it might not be possible to antidifferentiate in curvilinear bases. I'm going to update it for Fourier and Chebyshev

kburns commented 2 years ago

I think we have to think a little carefully about what we want this to actually do, since now in d3 there's lots more freedom around tau terms and the output basis. My preference would honestly be to remove it and let people define their own LBVPs if they need to do so for e.g. initial conditions, like we do for the balanced flow in the shallow water example. Do you have another use case for this?

liamoconnor9 commented 2 years ago

If we could get an Antidifferentiate operator class working with delayed operation, that would add some functionality. Do you think that's possible? If not, then I agree there's no real advantage beyond doing it manually with LBVP.

kburns commented 2 years ago

You mean to have it in an operator tree that's used during an IVP? The best route might be to update the GeneralFunction class and pass in an LBVP through that.

liamoconnor9 commented 2 years ago

To clarify, I do have a use case but only if we can get delayed evaluation working

liamoconnor9 commented 2 years ago

You mean to have it in an operator tree that's used during an IVP? The best route might be to update the GeneralFunction class and pass in an LBVP through that.

Yep that's what I'm looking for! Thanks I'll try that out

bpbrown commented 1 year ago

Just ran back into this old issue. Should we remove the field.antidifferentiate() method so that it doesn't mislead?

liamoconnor9 commented 1 year ago

it would be great to be able to perform quick evaluations without creating objects (even if those objects are created autonomously behind the scenes).

On Mon, Apr 24, 2023 at 12:02 AM Ben Brown @.***> wrote:

Just ran back into this old issue. Should we remove the field.antidifferentiate() method so that it doesn't mislead?

— Reply to this email directly, view it on GitHub https://github.com/DedalusProject/dedalus/issues/209#issuecomment-1519386150, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZEVZ6GIGERKFL3WCF7WQLXCYCP7ANCNFSM5ZVGOPMA . You are receiving this because you modified the open/close state.Message ID: @.***>

kburns commented 1 year ago

I think the way to do this is really to wrap solving an LBVP in a GeneralFunction. I think we should add a docs page on General Functions and include this as an example, and remove the antidifferentiate method.

jsoishi commented 1 year ago

I agree with Keaton.

On Wed, Apr 26, 2023, 14:21 Keaton J. Burns @.***> wrote:

I think the way to do this is really to wrap solving an LBVP in a GeneralFunction. I think we should add a docs page on General Functions and include this as an example, and remove the antidifferentiate method.

— Reply to this email directly, view it on GitHub https://github.com/DedalusProject/dedalus/issues/209#issuecomment-1523860575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7SHYLO36DKGOZ5HMCLGCDXDFRT5ANCNFSM5ZVGOPMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

kburns commented 1 year ago

Removed in 0b0d1314a1fec92305dda4da11ef604b55a06ab1, but we should still add docs on GF+LBVP before closing.