·[521]|1000天行动计划
读书笔记/热点追踪/论文研读/教程手册
继续水质模型的项目流程，上几节围绕建模的准备工作进行了详细的叙述，本节开始模型的构建的环节，模型的构建的目标就是完成模型的搭建及校准过程，为模型应用打下基础。在实际项目中，模型构建工作是模型项目的核心，而这个环节又以模型的校准为重点和难点。我将模型的构建过程分为三大部分：模型选择和开发，模型的构建，模型的校准。
本节为模型的选择和开发，可以看出选择在前，开发在后。之所以这么区分是因为实际应用型项目中，一般优先尝试使用现有成熟模型，而后针对具体的问题再进行局部的完善，即站在巨人的肩膀上。如果现有模型不能满足要求，或者其他原因（如费用、封装等因素），也会退而求其次找现有的开源模型进行修改构建，最麻烦的可能就是完全从零开始开发一个全新的水质模型。
模型的选择
如何选择模型在之前介绍模型的类型时有所提及，具体到模型的选择，WM0-2.2.1_水质模型的类型 ，其具体要考虑的因素，在Steven C. Chapra老师的《Surface Water-Quality Modeling》书中写的非常好了，自己之前也有对其进行翻译：
我们在明确目标之后，我们就可以针对性的选择模型，一般使用已经存在且之前学者已经使用过的模型包，为什么我们要这样做？ 主要有以下理由，俗话说的好，我们要站在巨人的肩膀上。首先，如果之前有相应的成功应用的成果，那么我们利用起来的话，就不会发生重新发明轮子这种事情，毕竟重新构造一系列的方程组需要花费很多精力。更重要的是如果模型之前在其他地方成功应用过，我们就能够在他们经验基础上进行，并且可信度也更高，模型也是一种产品，对于其他地方成功的应用，我们当然会有更多的信心。----模型的选择和开发
再具体点的话，选择模型过程中会遇到诸如不同模式的I「架构」，就是所谓的同样一个模型有好多个版本，甚至可能有不同的公司开发，让初学者完全搞不清楚是怎么回事，如：EFDC就有多种版本，现解释下到底是怎么一回事。
模型的运行方式介绍
目前的模型，有不同的操作方式，有的是在图形界面上的，有的是在命令行的，有的直接操作代码，有的是基于Excel的，百花齐放，之前自己有对其的几种模式做个简介（具体可打开查看 ——Delft3D的编译及运行）：
困难模式 我们知道数学模型本身内部是很多个数学方程组，那个年代的通过数学模型解决问题，就需要去手动列方程，然后求解方程，可以想象这个过程必然是庙堂之上的东西，一般人没有深厚的数学功底是无法做的。…… 中等模式 随着计算机的普及，模型应用的广泛，必然科学家们也感觉到模型的复用问题，所以就考虑将参数从代码中抽离出来，放在一个地方（通常是一个文本文件），使用者仅仅需要更改这些参数，同时由于不同模型数组大小不同，计算机需要依据此管理内存，所以需要针对具体情况设置好需要的数组大小，那么每次都需要将其编译后，可以运行使用。…… 容易模式 计算机行业的快速发展也会推动数学模型的发展，随着Fortan的发展，其有了动态数组（根据条件自动判断），同时将汇总的参数分类，在可视化的界面上表达出来，就形成了目前易用的商业软件包，……
好像没看明白，没关系，拿我们熟悉的东西来类比，模型的运行方式的发展有点像计算机编程语言（实际上两者密不可分）。在发展的初期，计算机语言为汇编语言，其用来驱动计算机运行。什么是汇编语言呢？基本等同于直接对计算机底层进行操作了，什么叫直接操作，计算机的核心部分 CPU 实际就是很多个晶体管组成的电路，而汇编语言就是用助记符代替机器指令的操作码。这个时候的特征就是底层操作，与计算机运行的细节接触非常的多，基本每个步骤都需要手动运行——这个对应水质模型的方程--困难模式，也是水质模型的发展的初级阶段，其以S-P的模型为代表的采用方程进行求解，用户需要建立相应的方程级别的操作，并进行相应的求解。需要说明的是，虽然现在很多环评中用的简单的评估模型也用类似的方法，但是其仅仅是单一的方程，复杂度远小于主流水质模型。
随后发展出了高级语言，诸如C语言等高级语言了，可以理解为将汇编语言进行封装，以更贴近人的思考从逻辑出发，便于使用，用户不用每一步都去操作底层的机器码，而只需要采用表达式和语句来实现对计算机的控制。它不仅可以发挥出高级编程语言的功用，还具有汇编语言的优点，其虽然是高级语言，还是可以进行内存级别的操作。此时的特点就是相对的高级，经过一定的抽象，用户不需要一步步的十分细节操作，只需要调用一些高级的接口——而水质模型中则是编程式的参数输入，这个阶段对应将水质模型的内在方程中的关键的参数提取出来汇总，用户建模时只需要修改这些参数就可以进行建模分析，其他参数已经封装，必要时进行底层的方程进行修改，当然这些参数中有很多底层的控制选项，诸如方程求解的方式等也是接近底层的，还是比较复杂的。
后来高级语言又有了诸如Python的脚本语言，Python的简洁之美大家有目共睹，用过的人都会感叹其的简洁且强大，非计算机行业的人也能够快速上手，更重要的是有非常多的库，使得用户的操作更加的方便。实际上其相当于基于C语言进行进一步的封装，其底层的操作如内存方面的垃圾回收等都自动化了——对应水质模型的界面模式，通过对命令行的封装，添加了完美的壳，让用户更加方便操作，同时如同python中的库生态，界面增加了数据的预处理、后处理的可视化等功能，使得用户能够方面快速的建模，但是其由于经过两层抽象，使得用户和方程相距较远，对方程理解不够时，遇到错误时，很难调试。
上面可以看出，越抽象，离细节越远，越方便，同时带来的弊端就是离底层越远，越黑箱化，越不够灵活，无法修改方程来获取自定义高级需求，同时限制于定制化的界面，很难进行系统的集成化（面对信息化平台而言），对于大批量的测试，也很难耦合编程来实现（这点在当前融合机器学习的大背景下是个缺点）。实际上，对于信息化平台，将模型的应用部分抽象出来，形成一个独立功能的模型，这样的抽象使得非专业管理人员也可以使用模型来进行分析，算是对水质模型的又一次简化。
写到这里，自己发现上述的例子可能还是过于难了，比较很多小伙伴并不是编程出身，我就再啰嗦几句吧，拿我们熟悉的计算机来操作系统类比水质模型的各种模式，我们知道计算机刚开始计算时用的穿孔纸带，用其来操作计算机（实际上是输入数据），这个阶段就是非常初级的模式，后面微软的DOS命令出现（现在计算机上仍然保留的cmd命令行），虽然是一个黑色的框，还需要输入字母来操作，但是这个比之前操作计算机方便了不知道多少倍，再后面就是我们现在用的图形操作界面了。这三个阶段对应上述的阶段，大家可以体会下。
之所以这么多篇幅来介绍其的不同模式，就是因为很多小伙伴还没接触模型，就被各种模型及模型的不同版本搞的云里雾里，不同的模型模式也是伴随着模型的发展而形成的，其逐渐的降低建模门槛，使得模型能够应用的更加广泛，正如计算机的普及能够进入千家万户与图形操作界面有很大关系，互联网的普及是苹果首创的交互式手机操作系统的助力，模型的界面模式也使得小白也能迅速搭建起模型（用好是另一回事），降低门槛使得研究的人更多，反过来促进模型的发展。
那么，依据上述介绍，大家对于选择模型模式心里有数了。简单说，如果你要进行研究学习，就从底层开始，甚至理论开始学起，如果需要集成应用，可能需要从命令行编程式开始，如果短期的应用项目或者研究生的论文，有界面的模型是最好的选择。
同时，从入门角度，上述模型模式的介绍，从而能把握其不同模式的特征，明白其模型的本质，弄清楚什么是重要的，依据自己的目的选择合适的学习的路径。
在谈模型学习过程之前，先说说有关模型不同模式的误区：
学习模型定要从底层方程开始，编程开始，甚至从方程开始才是正宗路径，用命令行模式的比界面要高级。错！方程重不重要，重要，但是对于初学者来说其并不是重点（为什么？后面模型开发会细说），用程序的底层版本就比界面要高级吗？不一定，初学者一定要弄清楚这个，不要觉得从界面开始好像不够专业。两者的本质区别是：是否能够用模型解决好问题，而用什么方式无关，只能说越接近底层使用，可能意味着使用者对模型的理解更深，这并不绝对，同时也还有习惯问题，有的可能就是之前师门在用这个，延续下来了而已。图形界面更容易上手，且有界面开发者的抽象简化，使得其能够更快的建模，从而使得初学者能够快速的进入状态，获取成就感，所谓万事开头难，突破这一关后面就会容易一点。所以我建议，对于小白来说一定要找那种有界面的模型，可从界面开始熟悉，在对模型有了感性认识后再深入理解内部过程，到熟悉之后的，就只有了解机理内部，才能进一步提升，当然再后面还需要一些艺术层面的想象力，因为模型是科学和艺术的结合。
具体到主流的水质模型，后面自己会针对主流模型进行汇总，现在就先说两个模型，比如Deflt3D和EFDC都有界面的版本可以试用。说到这里也会顺便简单介绍下这两个模型的情况，EFDC最初由John Hamrick(1996)年设计形成，本身是开源的，其对应的一个界面的版本EFDC_Explorer由Dynamic Solutions-International, LLC 公司以EFDC为内核，增加图形操作界面构成的，实质还是EFDC。而Delft3D是由荷兰Delft大学WL Delft Hydraulics开发的一套功能强大的软件包，也就是有图形界面的版本，但其内核的计算代码也2017年进行了开源（界面还没有开源，但是可以试用）。所以，初学者可以两者其一进行学习，其他诸如MIKE等，如果有正版授权，也可优先学，其教程最为丰富，没有正版不建议使用盗版，学习角度也不要，有法律风险。
综上，模型的选择，一般对现有模型、熟悉的模型进行优先选择，可能还需要考虑开源、闭源模型的问题，同时对于特殊的问题，还可能需要对模型进行模块的升级，甚至重新开发一个模型。
模型的开发
模型的开发并非必须，之前总有人觉得学习使用模型必须是要能够开发模型，只有开发自己的模型才是牛逼，用现有的模型都比较低级。对于模型开发而言，是有一定难度但没有那么难，但开发一个好的模型，应用广泛，精度高，容错性强等就不是一件简单的事情了。
国内前几年流行一股模型开发风，仿佛必须是自己开发的模型才能拿出手，用现有的模型都比较丢人，从应用角度而言，根本没有必要，现有的模型基本能够满足大部分需求，特殊需求也能通过局部修改来完善，没有必要去开发新的模型。所以学模型也没有必要上来就冲着要修改代码，以开发一个模型的目标来学。拿开车举例子吧，大多数人开车，更需要的是驾驶技术，而不是汽车的理论知识和汽车各个零件的运转机理，那些是汽车工程师做的事情，如果你从汽车理论开始学，汽缸怎么提供动力的等，估计学个一年半载的，肯定没有开了一年的人驾驶技术高，只有对于赛车手，而且还是顶级的选手而言（一般水平的还是以驾驶技术为主导）才需要深刻的理解汽车的理论，从而在比赛中人车合一，但是其也不是需要到汽车工程师那种理论水平，其更多的还是了解汽车运转的层面。
模型也一样，现在数据分析师比较流行，实际上数据分析的职业主要可分为数据分析师、数据工程师和机器学习算法工程师，三者职责略有不同，数据分析师主要是挖掘商业信息，支持决策；构建数据流程，数据产品设计；商业问题量化分析；而数据工程师是承上启下的作用，主要是进行大数据开发的工作，为数据分析师提供分析平台和服务。而机器学习算法工程师，构建分析算法，更加的底层。
水质模型本身也跟这个类似，最底层的可为模型算法工程师，主要复杂模型的底层研发，从机理方程、数值计算角度开发模型；模型工程师可能进行底层算法和建模耦合工作，构建模型进行参数校准等；而模型分析师可能就是在构建好的模型上进行应用分析。当然，上述职位目前是不存在的，国内应该还没有细分到这种程度，仅仅是为了说明问题，这几个职责实际上也是模型应用的全过程，模型应用角度而言，主要集中在模型分析师和模型工程师的工作，后者为建模工作，前者为应用。而模型算法工程师则一般的项目没有到这个程度，除非涉及到特殊问题需求要完善代码。
模型开发本质属于很深奥的工作，需要强大的环境理论、数学、编程的功底才能完成，但是这部分工作基本对于使用、应用模型来说的必要性不是很大，所以将精力先集中在使用模型上，如何正确的使用模型上，也就是所谓的上面的模型工程师的任务职责，后面在需要时转向算法工程师学习。
如果你真的想开发模型，因为我也没有吃过猪肉，所以告诉需要学习的相关理论了。
物理
水力学
化学
水环境化学
化学动力学
生物学
植物的动力学
生态系统学
数学
数值分析
线性代数
计算机语言
Fortran
C++
有关模型的开发除了需要相关环境学科的理论知识，还需要在开发中注意下面的问题：
小结
由于是水质模型的基础教程且导向是项目的应用，所以从大家关注的问题出发，介绍了模型的不同模式和模型的开发的必要性，以便能够正确认识模型。模型的不同形式和按职责的任务分解，找到自己正确的学习路径和方向。
由于教程系列文章需要花费很多时间，难免出错，而这里不能进行后续完善，所以推荐大家关注我的博客，获取最新的修正和补充。 公众号的社群同步开启，感兴趣可在公众号对话框回复“社群”，获取群号和加入方式。
微信公众号 | 水环境编Cheng长 网 站 | comieswater.com
2019-9-15
folder=/微信公众号/水环境编Cheng长/
参考文献： 1 Chapra, Steven C. Surface water-quality modeling. Waveland press, 2008. [2] JACOBKALFF. 湖沼学:内陆水生态系统[M]. 高等教育出版社, 2011.
