cumcm2019
中秋节三天参加了「高教社杯」全国大学生数学建模竞赛。虽然是裸考，但是 考试体验相当不错，和队友小 L、小 C 的合作也是非常愉快。让我们先看几张快乐图片回顾一下当时的盛况：
「我们做做 A 题吧，试试控制压力？」
「可怕，那还是看看 B 题吧。同心鼓怎么玩？」
「什么玩意！感觉还是 C 题简单一点。对了，数据去哪找？」
「……所以到底哪题是能做的？」
「……」
调侃归调侃，结束之后复盘还是需要做一做的。往往我们拿到奖之后才会愿意去复盘，美名其曰「成功经验」，但刚结束时的复盘也许能够让我们更客观地看待准备过程中的优点和不足，增加我们的「经验值」。小 L 在朋友圈发了一篇小作文，那我就在这里发一篇大作文好了（笑）。
本文中涉及到的所有赛前准备和赛中纪实的文件都可以在我们的 GitHub 页面 中找到，欢迎下载！
赛前准备
组队
由于一开始就是打算以体验参赛过程为主，没有打算花太多时间准备，这间接影响到了组队的策略。往年，题目一般有两道可供选择：A 题以物理和工程中的问题为背景，B 题以社会生活中的问题为背景。对我而言，A 题用到的模型是不十分熟悉的 （因为我的物理是从四大开始学的，普物不会），而算法比较熟悉（基本的数值分析和数值代数算法）；B 题则正好相反，模型比较容易建立，但算法不怎么会（规划、运筹学的相关算法）。
因此，组队和准备过程都是面向「A、B 题都能做」的需要来进行的。相反如果有更多的时间来准备，我认为我应该专攻 A 题，毕竟 B 题的算法想补齐还是比较困难的，而模型建立可以通过现场多查文献来提升。
模拟
既然不打算参加什么系统的培训，我们就计划通过做往年题的方式来练手。本来要做 2018 年的 A 题和 2017 年的 B 题，但后来前者被鸽了，实际上我们只做了一题。尽管我们在该题中建立的模型非常奇怪，不过在模拟过程中我们至少达成了以下共识：
- 程序设计：Python + 面向过程，将几个小问都要用到的函数放在函数库中，用导入的方式实现复用；
- 论文写作：LaTeX + CUMCMThesis 模板 + Tikz/pgfplot 作图；
- 文件管理：利用坚果云实现文件实时同步，特别适合于比赛时共同编写程序或论文的情形。
唯一美中不足的是，在模拟的过程中我们 （发扬鸽子本质） 并没有正式地将结果写成论文。后面会看到，这使得我们在比赛过程中的论文编写环节熟练度不太够。
赛中纪实
第零天
18:00 拿到题目之后我们还是非常惊讶的，因为今年本科组多了一题，有 A、B 和 C 三题可选。简单扫了一眼这些题之后，我们打算采取「蚁群搜索」的策略来选题：三个人每人分别研究一题的可行性，一小时之后互相汇报找出最可行的题目，然后三个人针对这个题目继续做可行性研究。
20:00 经过一番权衡之后，我们发现 A 题《高压油管的压力控制》竟然是最有思路的一题，而 B 题完全没有搞懂题目中可以优化什么，C 题则缺乏相应的「自行寻找数据」的信息素养。本着「打死不换题」的精神，我们坚定地选择了 A 题。
22:00 A 题的第一问思路已经完全清楚了，第二问大致清楚但不知道流量如何计算，而第三问还没有思路。对于第零天而言，这已经是不错的进度了，于是我们就各回各家安心睡觉了（笑）。事实证明，在这三天中没有像某些队一样通宵建模的情况下时间也很够用，而且保证了后期精力的充足。
第一天
要开工了。怎么分工呢？传统的分工是一人模型、一人程序、一人论文，不过我们队一致认为这种分工是划水的万恶之源。问题在于：
- 模型、程序和论文的工作量在三天之内的不同时期有所侧重，所以前期写论文的人会过于空闲，后期建模型的人会过于空闲；
- 这使得三个人的交流仅限于交付成果，每个人都只是流水线上的一环而不容易了解整个团队的状态。
基于前面建立的坚果云同步系统，我们选择了一种类似于 GTD 的做法，包括三个步骤：
- 任务收集：在自己的工作中新发现的事情，都记录到工作文件夹下的一个 Markdown 文件（任务池）中；
- 任务处理：每天早上、中午和晚上工作开始前开一个时长为十分钟的短会，根据个人能力和偏好分配任务，在任务池中标注由谁来完成；
- 任务归档：完成后，在任务池中标注已完成，并注明成果放在何处。
分工控制文档示意
当然，这就要求每人至少掌握模型、程序和论文中的两项，才能游刃有余地分配任务，并且时时清楚团队整体的进度和需求。
08:00 鉴于第一问的思路已经清楚了，我开始写第一问的程序，小 L 帮助我进行数据的预处理和函数库的编写，小 C 作为「物理水平担当」，继续研究第二问的流量求解。
13:00 第一问的程序写完了，小 C 也搞明白了第二问，于是小 C 开始试图看懂我写的函数库和第一问的程序，在此基础上修改成为第二问的程序。我则跟小 L 确定了第一问的结果呈现方式，同时开始建立符号表完成基础的推导。
18:00 前两问的程序完成了。我确定了第二问的结果呈现方式。
第二天
08:00 小 C 再次作为「物理水平担当」，向着第三问发起攻击。我和小 L 开始将第一问和第二问的结果写到论文中。
13:00 下午小 L 在写论文时遇到了严重的 bug，几个宏包之间相互打架，修改多次依然编译不通过，但由于不清楚模板 CUMCMThesis 的具体实现，只能将整个文件清空并将内容逐步复制粘贴进去。这也是我不推荐在比赛中使用别人提供模板的原因之一，使用很多自己不了解的复杂命令如同定时炸弹一样危险 （另外一个原因就是，我觉得该模板作者的审美有点堪忧……） ；好在这一问题没有实质性地拖慢进展。
18:00 小 C 在第三问中取得了突破性进展，并确定了论文中的主要结论。所有数据和源码都以外链的方式添加到了论文中（即只添加文件名，编译时 LaTeX 引擎从文件中读取数据并作图和渲染源码）。
第三天
08:00 小 C 最后完善第三问模型中的细节，并写入论文。上午发生了一点小插曲：发现数据预处理时使用的算法有问题（我的锅），导致最基本的压强-密度关系都是错的，所有题目都需要重新计算。不过好在算法不需要改变，所有数据图均为外链，修改起来也不算太麻烦，一小时后基本完成。至此所有建模和程序工作结束。
13:00 我开始优化论文前两问中的结果呈现方式和文字阐释，小 C 优化第三问，小 L 总结了支撑建模过程中各种假设的参考文献。出于 闲得没事，我甚至把高压油管和喷油器的图片也用 Tikz 中的命令画出来了。
18:00 大合并开始，将所有内容合并到一个 .tex 文件中。我润色了语言，小 C 写了高屋建瓴的摘要。
19:57 初稿文件快照上传。然后所有人将强迫症属性发挥到极致查找错误。据坚果云统计，仅 paper.tex 文件在一天内共修改了 252 次。
坚果云的版本统计
21:50 终稿文件快照上传。快乐！
英杰交流中心 425 合影留念
总结
优点
- 团队沟通顺畅，分工合作机制明确，使得效率很高；
- 重视结果的表述和阐释，论文中结果展示和分析非常透彻。
不足
- 论文写作准备不充分，比赛开始前应该自己编写模板或熟悉模板的大部分命令；应该事先规定好所有图表的风格规范做到统一；
- 低估了第三问的工作量，（出于我精神上的懒惰）使得第三问只有小 C 一个人在做，而实际上这一最有创造性的部分应该分配更多精力；另外由于时间限制第三问的论文表述得不如前两问清楚。
下一步行动
- 野路子出身瞎建模果然还是有一定的局限性，以后打算系统学习一些数学建模的课程；
- 代码量上千之后管理代码有点力不从心，应该学习一些项目开发中的 Python 良好写作方式；
- 这次竞赛为我打开了 Tikz 作图的大门，感觉极其优雅～