Message Boards Message Boards


Amazing comparison (700+ pages!) of PDE solving. There's a gap to be filled

Posted 1 year ago
8 Replies
29 Total Likes

On February 11, Nasser M. Abbasi compiled a huge report about PDE solving with Mathematica 11.3 and a recent (2018 version) of another major CAS system , listing some of the PDE textbooks consulted (strangely no one among Evans, Farlow, Strauss, Sauvigny, Taylor is included).

According to the results and to the table of results , Mathematica is dramaticaly behind its competitor and the knowledge of PDE by both the system seem very limited, compared to results one can find in a textbook.

To be noticed, if you look at his page , Abbasi seems to use more Mathematica than the competitor.

Let's hope that researchers at Wolfram will implement a better knowledge of PDE into Mathematica, rather than spreading their efforts on all those (some of them kind of bizarre) fields : not just to fill the gap with its competitor, but because PDE is a very crucial MATHEMATICAL topic.

8 Replies

I would venture to say that numeric solving of PDEs is vastly more important than exact solving. I am guessing this comparison is much more about the latter.

Dan, that is all you are able to say??? This report clearly shows, that Mathematica symbolic capabilities for PDE are dramatically poor. Wolfram developers should work very hard on this topic instead of introducing numerous bizare new functionalities.

Posted 1 year ago

Indeed! Though, it's also true that symbolic manipulations (and exact solutions) give the big allure to CASs

Question of NDSolve limitation: are there any major ones? (Neil Singer, AC Kinetics, Inc. gave a great answer as to what is underlying - the underlying components are not hidden they are available to read)

I did not get past the first few of 700 pg. However I saw some inconsistency.

(1) maple cannot do arbitrary precision so it cannot answer "the same questions" mm is

(2) mathematica was counted as "incapable" due to time of solving - which does not mean it cannot solve (it)

(3) in the maple column unsolved integrals were "allowed", but apparently not in mm's column

(from links above, a result mathematica "failed")

DSolve[{cw(1,0)(x,t)+w(0,1)(x,t)=0,w(x,0)=f(x),w(0,t)=h(t)},w(x,t),{x,t},Assumptions->c>0 && x>0 && t>0]

I do not think this test is "correct". c>0 does not mean, in Mathematica, that c is a constant.

"therefore w(x(t),t) is constant" (from link above of test results)

olver intro to PDE, transport and traveling wave equations, "in which c is a fixed, nonzero constant" (which i borrowed from the intro (still saving to afford a copy!))

Correct me if i'm wrong that c>0 does not mean "is a constant" in Mathematica but that in Maple it likely does

Mathematica too assumes that c is constant. For example:

In[15]:= DSolve[y'[x] == c, y, x]

Out[15]= {{y -> Function[{x}, c x + C[1]]}}

(responding to Gianluca Gorni) That is right, DSolve does automatically assign un-involved variables as (constants), so your right, that was not the problem.

I see more issues I'd like to discuss about the one problem already mentioned, in PDE section of tests.

Mathematica solves (noting f can be f[t] or f[x] but generically f[x,t]):

a D[w[x, t], t] + b D[w[x, t], x] == f

DSolveValue[a D[u[x, t], x] + b D[u[x, t], t] == c, u[x, t], {x, t}] (* works *)

Taken from tests (see how conditions specify the form of w, not a value):

pde = D[w[x, t], t] + c*D[w[x, t], x] == 0;
ic = w[x, 0] == f[x];
bc = w[0, t] == h[t];
DSolveValue[pde, w[x, t], {x, t}]
    C[1][(c t - x)/c]
DSolveValue[{pde, ic, bc}, w[x, t], {x, t}]  (* no *)

Another way of expressing w (that will have solution(s) done by hand) is:

DSolveValue[{a D[f[x] h[t], x] + b D[f[x] h[t], t] == 0}, f h, {x, t}]  (* does not work *)

The initial conditions for f h demand it have a particular form (which is neither a systems of equation and nor an initial condition). It may be true Mathematica doesn't allow it. However: I'm not an expert.

DSolveValue[a D[u[x, t], x] + b D[u[x, t], t] == c, x u, {x, t}]

In the above, x u is not a separation of x from answer u (changed form), it is u solution times x. Only "u" or "u[x]" are considered by DSolve.

DSolveValue[{a D[u[x, t], x] + b D[u[x, t], t] == 0, u[x, t] == -((b x C[2])/a)}, u[x, t], {x, t}] (* no *)

The above may be solvable, but Mathematica does not "like" over-determination (being told what u is as a condition of solving for u).

Mathematica cannot be called "incorrect" or "incapable" because it solves problems a different way.

I'll also say that seeking to get a particular form:


as a "result of DSolve", is unreasonable. Because there could be other forms with other assumptions. In Mathematica to get a particular form you must try to solve ONLY what would yield only that form to get that form, not something much more general which could involve things such as (what realm constants are in, when replacements for conditions are to apply (during reasoning or to replace constants), etc). In Mathematica you can change forms (using mm library) to shift form before or after DSolve, but not during. It makes sense that DSolve's solver takes province of form, taking routes that have less doubt, to to provide an accurate reliable answer.

(repeated from post above): maple was given a "check" for returning an expression no one has argued tet as (being correct in all cases, or being a weak answer, or perhaps incorrect). Is it true the (by hand solution) is invalid when the laplace cannot be solved? Or is that bogus?

I comment and like the topic because I'm learning it and would like to know more.

4.7 First order wave PDE, with initial and boundary conditions (discussed above)

4.17 General solution of a ?rst order nonlinear PDE (same as discussed above, form of w specified in initial conditions, though i do not show a rewrite of it)

4.19 ?rst order PDE of three unknowns. Works - test maked fail incorrectly.

Mathematica does claim DSolve[eqn,y[x1,x2,...],{x1,x2,...] (noted by another post, mm's NDSolve was stated as "better"). that's a win for Maple (assuming all answers are not bogus).

DSolveValue[(y - z) D[u[x, y, z], y] + (z - x) D[u[x, y, z], 
    y] + (x - y) D[u[x, y, z], z] == 0, u[x, y, z], {x, y, z}]  (* works *)

    C[1][x][y + z]

(The Mathematica book explains GeneratedParameters controls the form of generated parameters; for ODEs and DAEs these are by default constants C[n] and for PDEs they are arbitrary functions C[n][...]) Now a good question: is Maples answer as "good"?

For tests there is a "cheat" to expose: it is that 'build' is pumped as arg to pdsolve and is counted as "correct answer". "build - (optional) try to build an explicit expression for the indeterminate function, no matter what the generality of the solution found" (it's obviously a weak / not strong solution so calling it a win, even if by hand it is the same, is improper, since it is only "right" by retrospect comparison)

"build" was used in 3 test problems in the PDE Mathematica v. Maple tests section

(((errata: however my first tests I got an immediate fail (not a timeout) on both solved problems above 4.7 4.19, and after resetting kernel (to be sure) a "long timeout" while the kernel loaded (which happens any time an error forces Quit[]). So I'm guessing the test went astray somewhere and the reasons why were not investigated well. Mine went astray because I had been solving ODE and, despite clearing normal vars, had "issues" with definitions I didn't know of (perhaps upon C[1]). (there is a mm option to insure C is unique across all answers in kernel btw)))

u[x, t] := f[x] h[t];
DSolve[{a D[u[x, t], x] + b D[u[x, t], t] == 0}, u[x, t], {x, t}]
    ... DSolve:  f[x] h[t] cannot be used as a function

DSolveValue: "The function h[t] does not have the same number of arguments as independent variables (2)."

and u[x, t] := f[x,0] h[0,t]; ... "f[x,0] h[0,t] cannot be used as a function."

Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract