search

SciML / PDERoadmap

A repository for the discussion of PDE tooling for scientific machine learning (SciML) and physics-informed machine learning
https://tutorials.sciml.ai/
18 stars 6 forks source link

Mental test of "Interior" boundary conditions and Q #20

Closed jlperla closed 6 years ago

jlperla commented 6 years ago

See https://github.com/JuliaDiffEq/DiffEqOperators.jl/issues/59 for a more formal description of the setup. But the idea is what happens if we patch operators together on the domain with value matching and smooth pasting conditions... In those cases, we no longer only have corner boundary values to worry about in the gaussian elimination we are understanding in #18.

Basically, lets say that I have an operator L1 which is defined on [0,1] and a L2 which is defined on [1, 2]. This comes up a lot in solving HJBE which are processes in different states at some threshold value.

If we had a bellman equation with u(x) being the value, where we patch together: u(x) = u1(x) when x <= 1 and u(x) = u2(x) when x >= 1. Then we have the following boundary value: u1'(1) = u2'(1) and u1(1) = u2(1) . This would mean that if we discreteize the L1 operator and augment it with a bunch of 0s for the [1 + dx, 2]domain and augment theL2operator with 0s for the[0, 1-dx]domain, we can combined the operators to form aL = L1 + L2`. Then we have an interior boundary condition around the nodes at 1 which must be eliminated in the gaussian elimination to generate the Q.

jlperla commented 6 years ago

@MSeeker1340 @ChrisRackauckas

Just flagging this consideration when designing the lazy application in #15 It is perfectly conceivable that down the road we might want to compose operators defined on different subsets of a domain. If so, then having an interface that can write to a buffer/tagged vector/etc. given a particular offset would make things easier. Basically, hardcoding the lazy expansion of 0s to be related to the size of the extension (as I had suggested previously) may make it less flexible.

ChrisRackauckas commented 6 years ago

Interior BCs like this shouldn't be a problem with the Q setup. In fact, this is one of the things I would point to as much easier within the framework compared to what we were doing before. The only difficult thing here is creating functions to build the right Qs, but since the operation on the closure is well-defined the resulting multiplication doesn't need a modification.

jlperla commented 6 years ago

Yup. Agree completely, and I think the sanity check is done. My point on this one was the composition of operators defined on different domains, since you are designing the lazy expansion right now.

This tells me two things:

  1. we need to have the operators we define have either a domain or a grid (regular or otherwise) passed into them upon construction.
  2. figuring out the offset based approach for dealing with different extension sizes would eventually make composing operators defined on different parts of the domain much easier.