One-sided boundary conditions?

[gentryml]

First, thanks so much for this package -- it's beautifully implemented.

I am trying to solve an initial value problem with a boundary condition on one side only. Intuitively, I want to construct a recombination basis for which left_op = Derivative(0) and right_op = null. Unfortunately, after quite a bit of experimentation, I have been unable to figure out how to do this. I can easily impose any nontrivial restriction for right_op, but not a trivial restriction. Is this functionality currently supported?

Apologies if I'm missing something obvious. In the meanwhile I'll use a manual workaround, but wanted to ask just in case there was an easy solution!

[jipolanco]

Hi, thank you for your kind words!

You're right, currently it's not possible to impose "free" boundary conditions on one side. In principle this should be possible and would require some minor changes only.

On the other hand, I haven't thought too much about this, but wouldn't this lead to an underdetermined system (too many degrees of freedom compared to the number of "timesteps") and to a lack of unique solution for your IVP? But I might be wrong about this.

Not sure if you've looked into this, but you might also be interested in the Natural boundary condition, which can help to avoid spurious oscillations near a boundary.

[gentryml]

Thanks for the quick reply! I work with auction models in economics, where such one-sided boundary conditions are fairly common. In this case I know the IVP has a unique solution, so an appropriately discretized version should too. Fortunately, it's not hard to replicate what I need using existing functionality (just drop one polynomial and one collocation point), but wanted to flag the free-boundary case as a feature that would certainly be useful in my domain!

…

On Tue, Nov 12, 2024 at 3:59 AM Juan Ignacio Polanco < ***@***.***> wrote: Hi, thank you for your kind words! You're right, currently it's not possible to impose "free" boundary conditions on one side. In principle this should be possible and would require some minor changes only. On the other hand, I haven't thought too much about this, but wouldn't this lead to an underdetermined system (too many degrees of freedom compared to the number of "timesteps") and to a lack of unique solution for your IVP? But I might be wrong about this. Not sure if you've looked into this, but you might also be interested in the Natural boundary condition, which can help to avoid spurious oscillations near a boundary. — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETJBRCBCRIPNMMWL4EK2NL2AG7O5AVCNFSM6AAAAABRSQ5LDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRSGMZDAMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jipolanco]

I just created a PR which should allow free boundary conditions on one side (or even both, but that's not very useful). This can be simply achieved by passing nothing (or an empty tuple) as operator, e.g. right_op = nothing. I'd be happy to know if you have any comments!

[gentryml]

Sorry for my slow response; I was just now able to circle back to this! I have downloaded the updated version and it's fantastic -- it does exactly what I need in a simple, clean and elegant way. Thanks again for incorporating this suggestion so quickly, far above and beyond what I was expecting!

…

On Tue, Nov 12, 2024 at 4:24 PM Juan Ignacio Polanco < ***@***.***> wrote: I just created a PR <#99> which should allow free boundary conditions on one side (or even both, but that's not very useful). This can be simply achieved by passing nothing (or an empty tuple) as operator, e.g. right_op = nothing. I'd be happy to know if you have any comments! — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETJBRG7TNUJSFX4WC5NZCD2AJWZ7AVCNFSM6AAAAABRSQ5LDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRTGI3DANY> . You are receiving this because you authored the thread.Message ID: ***@***.***>