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

Draft comments #2

Closed ChrisRackauckas closed 6 years ago

ChrisRackauckas commented 6 years ago

L is de ned as the discretization of the partial di erential operator in use.

Be consistent with the discretization "operator". Always adding hats is an easy way to make it explicit, or whatever you choose it should be done to the \mathcal{L}. Or abuse notation and let L "multiple dispatch" depending on whether it's applied to discretized/continuous values.

Q is the operator that is de ned as

https://ocw.mit.edu/courses/mathematics/18-086-mathematical-methods-for-engineers-ii-spring-2006/readings/am63.pdf

R is the restriction operator just like in a geometric multigrid. Q isn't interpolation though since it's extrapolation to the boundary. So maybe boundary extrapolation operator?

Equation 7 is missing a uhat. If you move the uhats by taking the interior then you see that it essentially goes away.

^ud = LQu

What you actually want to solve has uhat on both sides, which is why there's Q (since then you know the derivative of all of the quantities you're solving for!).

Equation 11 is incorrect. Should be (r-L)u(x) = x, or if you want to be explicit (r*I-L)u(x)

R^6 should be mathbb.

You never defined P, but it seems to be r*I-L

Putting the delta on top with a negative exponent in 18 is odd. 22 as well.

For 21 and 26, just use R to go from the full to the interior.

jlperla commented 6 years ago

cc: @stevenzhangdx @FernandoKuwer

A few questions:

I want to better understand your comment that:

Seems odd to have y and y(x) be different since the former is used in many of the equations as shorthand for the latter. Just use the common interior operator and have that hats be the discretized versions?

  • First, lets agree to the switch to $\bar{u}$, etc. for the interior + boundary.
  • Is the suggestion that we would have the discretized vectors as $\hat{u} \in R^K$, $\hat{y} \in R^K$, etc. when looking at the discretized versions of $u(x)$ and $y(x)$?
  • My worry is that this means almost all of the notation in code should have the $\hat{ }$ on it. Is this a standard notation? (I am a stickler for believing that code should use the notation of the math as perfectly as possible).
ChrisRackauckas commented 6 years ago

My only worry about the topology analogy is that the boundary here is often much thicker than the typical closure of an open set people might think of in topology, but I defer to you.

It's not an analogy, it's equivalent. More generally, when talking about PDEs defined on differentiable manifolds this still applies (since differential manifold implies topological manifold), so the terminology is used.

Regardless, I just want to verify that we should skip the circle for the "interior" whenever we are talking about the function/grid/etc. without the boundary. For example, it would be $\bar{u}$ when defined on the $\bar{K}$ grid points, and the function of interest is $u$ on the $K$ grid points, where $\bar{K} - K$ is the thickness of the boundary

Yeah, that sounds good. u is the interior, and then ubar is the full space. That also will translate nicely to code.

My worry is that this means almost all of the notation in code should have the $\hat{ }$ on it. Is this a standard notation? (I am a stickler for believing that code should use the notation of the math as perfectly as possible).

There is no standard version of the notation. The most common is probably to annotate it with the discretization. So you have u(x) as the continuous solution, but u_h(x) is the discretized solution by h. More generally, you define a partition \Pi or \Delta, and then annotate it u_{\Pi}(x). That can get tedious though. We can just use a convenient convention, like u for discretized and utilde for continuous. As long as its consistent and defined early it's fine.

That actually highlights another thing. So the main issue with y vs y(x) is that it falls apart quickly, like u_t = u_xx is the standard way to write the continuous equation. But another issue is that the discretized solution is "continuous" as well since there's a natural interpolation that's used to define the continuous H^{1} norm. So the discretized solution is in some sense a continuous function as well, making that y vs y(x) notation a bit odd.

jlperla commented 6 years ago

It's not an analogy, it's equivalent Done. Just to confirm: we will refer to the extended space as the "closure"?

We can just use a convenient convention, like u for discretized and utilde for continuous. As long as its consistent and defined early it's fine. OK, lets try that out. To summarize:

  • The functions will start as $\tilde{u}(x)$
  • The discretized function on the "interior" nodes is $u$... I hear what you are saying about the interpolation. We can add in more notation for that natural interpolation later.
  • The discretized vector on the closure is $\bar{u}$
ChrisRackauckas commented 6 years ago

We can add in more notation for that natural interpolation later

With yours it's just u(x) as opposed to u_i.

jlperla commented 6 years ago

OK. I think we have convergence on those parts of the notation

The last one is the $L$, $\mathcal{L}$, $A$, etc.

@MSeeker1340 said that he didn't like the use of the $\mathcal{A}$ we had before for the differential operator, because it was tough to type out, and suggested the move to $L$. This may not have been implemented the way he wanted, but I think he wanted to use a different symbol for the operator than the matrices. Here is a way to do this:

The big question I have, then, is what our basic notation for the composition is? Would we denote the composition of a diffusion process and drift as things like:

ChrisRackauckas commented 6 years ago

I am fine with any of those. mathcal or not, use A or L, and L = L_1 + L_2. All sounds good to me and I have no preferences here as long as it's consistent. The last part is consistent because then the (linear part of the) PDE operator is always A/L/\mathcal{L}, so that's fine.

jlperla commented 6 years ago

Just to be clear on what you mean by consistency. Say we leave the differential operators we work with as $\mathcal{L}$, does that mean you want the matrices (current called $L$) to remain as $L$ or can we (consistently) use them as $A$? I think the reason that @MSeeker1340 wanted to have different symbols was to make it easier to write in the code (i.e. use L rather than script L when reprsenting the operator in the code, and then use $A$ as the matrix?)

Also, what is the correct terminology for the current $L$ (or $A$) matrix? Is it correct to call it the "discretization of the linear operator"?

MSeeker1340 commented 6 years ago

Rename the current L matrix for the discretization of the closure of the operator be A

Yes that would be perfectly fine. In fact I think this blends well with the existing convention in DiffEqOperators of naming derivative operators as A.

Regarding $\mathcal{L}$... you can nitpick a bit and say "L" might give the impression of "linear" whereas the operator can be sometimes affine. But this seems to be a minor detail and I would not worry about it :P

ChrisRackauckas commented 6 years ago

Is it correct to call it the "discretization of the linear operator"?

Yes.