Matlab中的PDEPE求解"瞬态型"或"发展型"非线性偏微分方程组

背景

求解真实问题中建模得到的非线性偏微分方程组, 尽可能少手写代码,如果用matlab, 可能的选项很有限。pdetoolbox有限元方法能够求解一些,但是要求对微分方程的类型以及pdetoolbox特有的书写方式非常熟悉,并能够把问题转为相应繁琐的格式;

早在Matlab 6.x版本的时候(已经10多年的历史了)出现了一个pdepe求解函数, 虽然同样繁琐,要写代码, 但对偏微分方程的知识的要求相对少多了。不需要区分什么类型，只要方程看上去能写成特定的形式即可。傻瓜型和通用性好是求解界面友好程度的标准。

这个函数算法的思想基于

Robert D. Skeel
Purdue University

和

Martin Berzins
University of Utah

的一篇文章

论文标题: A Method for the Spatial Discretization of Parabolic Equations in One Space Variable

发表的刊物和时间: SIAM JOURNAL ON SCIENTIFIC AND STATISTICAL COMPUTING ·JANUARY 1990

可以从这里免费获取文章: https://www.researchgate.net/publication/244958749

第二作者发文章的时候还在英国利兹大学

(北京大学数学系毕业的 @数学文化 微薄的作者,原香港浸会大学理学院院长,专业方向谱方法解微分方程,现深圳科技大学科研副校长汤涛教授博士也毕业于这个学校)

pdepe能解的非线性偏微分方程组

方程就不用说了，关键是可以求解一类包括非线性在内的偏微分方程组。只要能改写成如下等价通解的形式（这个公式在上面的论文中以及pdepe的matlab帮助文档中都有）：

c⃗ (x,t,u⃗ (x,t),∂u⃗ (x,t)∂x)∂u⃗ (x,t)∂t=x−m∂∂x(xmf(x,t,u⃗ (x,t),∂u⃗ (x,t)∂x))+s⃗ (x,t,u⃗ (x,t),∂u⃗ (x,t)∂x)

华东理工大学的黄华江博士在所著的一本畅销书（《实用化工计算机模拟：MATLAB在化学工程中的应用》化学工业出版社2004年第一版）书中提到，pdepe用的也是“MOL（method of lines）”，其实这种说法是错误的。不过，pdepe的确可以求解一个空间维度的很多MOL方法可以求解的类似问题。

——从以求解为目的的用户角度来看，区分这些概念（不论是方程组属于什么类型，还是求解方法属于什么类型）本来没有什么意义，只要问题拿过来，用户可以解决就行了；本来分享自己的求解器就是为了节省用户的精力和时间，明明solver都是现成的了，还要求用户做那样这样的概念层面的区分，这不是好笑吗？这些交给计算机来判断最理想。

局限性

十多年前第一次用pdepe求解微分方程组的时候，还是很稀里糊涂的。比葫芦画瓢，拿来一个例子，完全没有实际应用背景，写完代码、运行结束，提交作业就以为自己明白了。

而在实际中也很少用pdepe来解这样的问题。最近尝试了一个实际的问题，发现pdepe局限性颇多。很难成为首选的求解器。

1. 并不是所有能够改写成这种形式的都可以求解，对于本质上具有高于1阶“微分-代数”方程组性质的“抛物-椭圆”型方程组，实际上是会罢工的；大致会提示出错信息，differential algebraic equations index up to 1 之类（这当然也可能是初边值条件设置不合理导致）
2. 并不是所有该写成这种形式，而且转化之后得到的微分代数方程组的“微分-代数”阶数不高于1的偏微分方程组都能求解的；前面提到了初边值条件设置不合理，不符合PDEPE的要求，这个即使从形式上满足了，还可能在实际计算中出现行不通的情况。这个PDEPE使用的ode15s自适应性非常牵强；mathworks的风格这方面实在不好；
3. 为了所谓“stiffness”,求解估计用的是精度阶数较低的差分格式（我看到美国劳伦斯Livermore国家实验室早年创作Fortran77版本的VODE的作者，在一篇文章中对比ode15s和某个其它的常微分方程求解器的文章中，对一个简单示例的计算结果，ode15s精度要差很多）,这导致在某些实际计算中可能出现各种数值问题：比如雅克比矩阵降秩、出现复数计算结果、溢出等等，都会产生一个matlab拒绝执行下去的异常；处理这类问题，给我的感觉是，matlab做得还不如C++好。
4. 现在计算机的CPU还有显卡，远远不是PDEPE刚出道那个年代的了，多线程并行计算也已经很普遍，尤其是微分方程求解中涉及的大量的求解线性方程组、非线性方程组的迭代问题等，但PDEPE的这部分核心算法不知道为什么，至今保留着不支持并行计算加速的特性；对于真正大型的问题或网格点数很多的情况，计算效率之低不言而喻。
5. 改写成特定的形式，对于一般拿来举举例子的非线性方程组，还是很容易的；但是，最近碰到的一个让人头大的偏微分方程组，让我差点崩溃。也正是求解这个问题，而且尝试用pdepe,才切实体会到，这个函数居然有这么多的局限。

求解器的用户界面

求解非线性偏微分方程组最好的用户界面是什么样的？

在我看来根本不是matlab的pdetoolbox或COMSOL中的广义系数或其它类似形式的GUI界面，完全让不懂PDE的外行崩溃，让懂PDE的内行也摸不着头脑。

大部分求解PDEs的用户，多少还是会一些简单的编程语言的。因此，在没有特殊要求情况下（比如上面那个公式那样特殊的形式要求），把自己的方程组直接改写成某种形式的高级语言（C/C++,Fortran,Matlab,Pascal,Python,R…)表达式，还是相对容易上手的；如果是改写成Maple中或Mathematica中那样简直跟数学公式一模一样的形式，则上手会更容易。所有的GUI都是按照自己的编程者的思路，生搬硬套出一种奇怪的标准，以为用鼠标操作就能降低学习难度，实际上并不见得。

所以，求解非线性偏微分方程组，好的用户界面应该是，只需输入跟数学公式的自然形态一模一样的方程组（至多作自然形式的公式到特定编程语言的语法的直接转换），然后就能求解，并根据反馈信息，逐条增加或改进，直至任务完成。

这种用户界面方面做得最出色的具有符号和数值计算功能的Maple和Mathematica。而数值求解方面，拥有这种界面的，mathematica无疑最强。

让图形用户界面见鬼吧，如果是求解非线性偏微分方程组。pdepe核心代码的功能太弱。这是应用pdepe求解一个实际问题给我的体会。