简介本资源是一套面向水利工程专业学生、初级水利工程师及Python编程学习者的简易水资源配置软件设计源码聚焦水资源优化调度与基础模拟场景解决教学演示、课程设计及小型项目原型开发中的快速建模与交互配置需求。压缩包共23个文件含11个Python核心模块如main.py入口、reservoir.py水库逻辑、construct.py数据结构构建、3个UI界面文件基于Tkinter或PyQt实现参数输入与结果可视化、2个Excel模板与1个xlsx文件用于配置参数与统计数据导入导出另有2个pickle文件支持运行状态持久化以及requirements.txt和readme.txt等工程规范文件整体仅216KB轻量易部署。已有400人学习下载提供完整可运行的本地化配置系统涵盖从算法逻辑、GUI交互到数据序列化的全流程实现目录结构清晰、模块职责分明适合作为Python工程实践、水利信息化入门及毕业设计参考范例。1. 为什么我会写一个简易水资源配置软件聊这个话题之前先交代一下背景。我因为工作关系接触了不少中小型灌区、区域供水的规划数据发现水资源配置这个事看着简单真操作起来非常磨人。尤其到了需要频繁改方案、调数据、对结果的时候用Excel翻来覆去地算既容易出错又很难向别人解释清楚为什么这么分。后来我干脆用Python写了套简易的配置软件把有多少水、哪里要用、怎么分这三件事从数据里抽象出来用代码统一处理。这次就把完整的思路、模型、源码片段和实测中踩过的坑整理出来给打算做相关课程设计、毕业设计或者想给实际工作配个趁手小工具的朋友做个参考。这个项目的定位很清楚不是要去重写一套专业的水资源配置模拟系统那是MIKE BASIN、WAS等专业软件做的事而是用Python做一个麻雀虽小五脏俱全的配置工具。它能完成三件事管理供需节点的基础数据、基于规则或简单优化算法生成配置方案、输出直观的结果报表和图表。核心价值在于把配置过程从手算、来回改表变成改参数、跑脚本、看结果适合四类人参考刚接触水资源配置概念想用代码把课本模型落地的学生需要做课程设计/毕业设计但暂时不打算用大型专业软件的人基层水利工作者想用一个轻量工具快速验证水量分配方案对Python在行业场景中应用感兴趣的开发者。技术选型上我用了Python 3.8 Pandas NumPy SciPy Matplotlib全是开源库安装简单跨平台。文中的代码是我的实际项目简化后整理出来的你可以直接照着搭也可以按自己的区域数据改参数。2. 模型设计把水资源调配翻译成数学语言2.1 供需节点如何抽象水资源配置的第一步不是写代码而是建立对问题的抽象。我们需要把真实世界中复杂的水系、水库、干渠、用水户简化成计算机能处理的对象。我在这个项目里把问题抽象为两类节点水源节点水库、河道取水口、地下水源、再生水厂。每个水源节点有三个关键属性——可用供水量也就是这个水源在配置期内最多能供多少水、供水优先级、供水成本系数可选。需水节点生活用水、农业灌溉、工业用水、生态补水。每个需水节点有关键属性——需水量、最低保证率比如生活用水最低要满足95%、缺水代价权重可选。两类节点之间用供给关系连接。实际中不是每个水源都能供所有需水户的比如再生水一般不能直接用于生活饮用地下水源受开采限制不能超采。所以我在数据文件里通过一个允许供给矩阵来控制哪些供水路径是合法的。这个抽象方式很朴素但够用——它对应了水资源配置中典型的供需网络图。2.2 目标函数选型为什么先从最小总缺水量入手配置模型最关键的是目标函数。专业软件里常常做多目标优化经济效益最大、缺水率最小、生态流量保障、地下水开采均衡……但这些对于简易版来说太重了。我在第一版里只用了单目标——最小化总缺水量。数学上写成min Z Σ (D_j - Σ_i x_ij)其中 D_j 是需水节点 j 的需求量x_ij 是水源 i 向需水节点 j 的供水量。如果再加一层考虑可以对不同用水户的缺水量乘以不同的权重 w_j变成加权缺水最小化这样能体现先生活、后生产、再生态的配水优先级。关于权重怎么定我建议不要拍脑袋。可以参照当地的用水管理办法——生活用水权重最高比如1.0工业次之0.8农业再低一些0.5生态补水在极度缺水时允许不满足0.3。这套权重不是标准答案但能让模型在缺水时自动优先保生活符合基本的配置原则。2.3 约束条件设计最基础的几个约束条件是把现实规则翻译成数学表达式的过程。我做的是简易版只保留了三个核心约束水源供给能力约束每个水源给所有需水户的供水量之和不能超过该水源的可用供水量。需水节点取水上限约束每个需水节点从所有水源获得的水量加总不超过它的需水量这是自然的给多了反而无效。非负约束所有决策变量不能为负物理意义就是没法倒着送水。后期如果数据更全面还可以加入水库蓄变约束、河道生态基流约束、渠道输水能力约束等。但第一版先跑通再逐步加复杂度这样有利于排查是模型问题还是代码问题。2.4 优先级规则的另一种实现方式写约束和目标函数的时候你可能会问用权重处理优先级真的够吗万一权重差得不够大模型会不会为了压生活缺水量而去牺牲大权重节点我实测下来单纯靠权重有风险尤其在多水源、多需水户、大量边界条件同时变化时。一个更稳妥的方法是分层求解第一轮只配置最高优先级用水户生活第二轮在剩余水量里配置第二优先级工业和农业第三轮再处理生态用水。每一轮都是独立的小优化问题天然保证了优先级不会被破坏。这个思路在代码实现上也不复杂把所有需水节点按优先级分成三组逐组调用求解器把水源剩余可用量更新后再进入下一组。虽然速度比单轮求解慢几毫秒但对于确定性、可解释性的提升非常明显。我在项目里默认用分层方案权重方案作为可切换选项留着。3. 数据层用YAML定义区域参数用Excel承载供需数据3.1 场景数据文件的组织代码写之前先把数据文件结构定下来。水资源配置软件的常见痛点之一就是数据杂——水源数据、需水数据、连接关系、配置参数混在一起后期维护极其痛苦。我参考了专业软件的思路把数据拆成两类区域基础配置用YAML文件描述有哪些水源、哪些需水户、允许的供水路径逐时段/逐场景的供需数据用Excel每一行是一个节点的需求/供给数据。YAML文件的好处是可读性强、支持注释、改动起来不容易破坏结构。对人不友好的是它不像数据库那样有强类型校验所以我在读取后加了数据校验逻辑后面细说。一个典型的YAML文件长这样project: name: 某灌区水资源配置示例 period: 2025年6月枯水期 sources: - id: RES_A name: A水库 type: reservoir - id: RES_B name: B水库 type: reservoir - id: GW_C name: C地下水水源 type: groundwater demands: - id: D_LIFE name: 生活用水 priority: 1 - id: D_IND name: 工业用水 priority: 2 - id: D_AGRI name: 农业灌溉 priority: 3 - id: D_ECO name: 生态补水 priority: 4 allowed_paths: - [RES_A, D_LIFE] - [RES_A, D_IND] - [RES_A, D_AGRI] - [RES_A, D_ECO] - [RES_B, D_IND] - [RES_B, D_AGRI] - [GW_C, D_LIFE] - [GW_C, D_IND]有些路径没有列出来比如B水库不供生活、地下水源不供生态就是通过许可路径限制掉的。这个设计在后续可视化绘制供水网络时也很有用。3.2 数据校验为什么不能省第一版我只写了读取逻辑没有校验结果跑出过很多荒唐的方案。后来学乖了加了一个独立的validate_data()模块每次运行前先检查几类问题水源节点ID在YAML中声明了但没有对应的可用量数据需水节点ID在YAML中声明了但Excel里需求量是负数或空值allowed_paths引用了不存在的节点ID可用供水量合计小于需水量合计这个不报错但是会给出警告提示该区域存在缺水风险同一路径重复定义。这些校验规则非常简单但实际运行价值巨大。因为水资源数据经常来自不同部门、不同格式的报表合并过程中特别容易出这类隐性错误。校验不通过就直接中断不让程序继续往下算避免拿着脏数据得出一个精确但错误的配置结果。3.3 单位统一一个必须写死在读取阶段的事情水资源数据里最坑的就是单位。有的表格用万立方米有的用立方米有的用亿立方米。混合在一起算结果能差出好几个数量级。我在读取Excel后做的第一件事就是强制把数值统一到万立方米。统一单位这件事不要在求解阶段做也不要在结果展示阶段做必须在数据读取阶段完成。流程是Excel每列设置一个单位标记列名带单位或者单独一行单位说明读取时按列解析并换算。如果列名里没有单位标记程序直接报错。我第一次做的时候偷懒把Excel里手动换算好了再读取结果换了个数据文件就翻车。后来改成在程序里统一换算再也没出过类似问题。4. 核心求解代码实现4.1 整体模块划分整个项目我分成了五个模块功能边界清晰方便自己后续改也方便其他人阅读water_allocator/ ├── config_loader.py # 读取YAML配置文件 ├── data_loader.py # 读取Excel供需数据 单位统一 ├── model.py # 构建线性规划模型 ├── solver.py # 调用scipy求解 结果整理 └── report.py # 输出图表和Excel报表主程序入口是一个main.py负责串联整个流程加载配置 → 加载数据 → 校验 → 构建模型 → 求解 → 输出结果。模块化最大的好处是如果后来你想把Excel换成数据库只需要改data_loader.py想换成别的求解器只需要改solver.py。4.2 核心数据结构实体类在model.py里我用dataclass定义了水源和需水节点的数据结构清晰且方便扩展from dataclasses import dataclass, field from typing import List, Tuple, Optional dataclass class Source: id: str name: str source_type: str available: float 0.0 # 可用供水量万m³ supply_cost: float 1.0 # 供水成本系数默认1.0 dataclass class Demand: id: str name: str priority: int # 1最高4最低 demand: float 0.0 # 需水量万m³ min_supply_ratio: float 0.0 # 最低保证率如0.95 weight: float 1.0 # 缺水的目标权重 dataclass class AllocationResult: source_id: str demand_id: str amount: float # 分配水量万m³ is_valid: bool True有人可能觉得用dataclass小题大做但在节点数量多了以后直接拿裸字典传参非常容易把键名拼错而且没有类型提示没法自动补全。用dataclass后代码可读性提升很明显尤其是后期要加字段比如供水路径的渠道输水能力时只需要在类里加一个字段。4.3 线性规划求解主逻辑求解部分我直接用scipy.optimize.linprog不自己写单纯形法。原因很简单成熟求解器经过了大量优化和测试稳定性和效率都远超自己实现的版本尤其是处理带边界条件的中小型线性规划时。以最小总缺水量为目标的求解核心代码如下import numpy as np from scipy.optimize import linprog def build_and_solve(sources, demands, allowed_paths): # 构建决策变量索引 var_index {} var_list [] for (sid, did) in allowed_paths: key (sid, did) var_index[key] len(var_list) var_list.append(key) n_vars len(var_list) # 目标函数min Z Σ (D_j - Σ_i x_ij) # 等价于 min Z Σ (weight_j * deficiency_j) # deficiency_j D_j - Σ_i x_ij # 引入辅助变量 s_j 表示缺水量s_j D_j - Σ_i x_ij, s_j 0 # 目标 Σ weight_j * s_j # 这里将 x_ij 和 s_j 合并为决策变量 n_demands len(demands) demand_id_list [d.id for d in demands] demand_index {d.id: i for i, d in enumerate(demands)} n_total n_vars n_demands # 前 n_vars 为供水量后 n_demands 为缺水量 # x_ij 的系数为0s_j 的系数为权重 c np.zeros(n_total) for d in demands: c[n_vars demand_index[d.id]] d.weight # 约束矩阵 A_ub [] # 不等式约束 b_ub [] # 1. 水源供给能力约束: Σ_j x_ij available_i for s in sources: row np.zeros(n_total) for (sid, did) in allowed_paths: if sid s.id: row[var_index[(sid, did)]] 1.0 A_ub.append(row) b_ub.append(s.available) # 2. 需水节点取水上限约束: Σ_i x_ij D_j for d in demands: row np.zeros(n_total) for (sid, did) in allowed_paths: if did d.id: row[var_index[(sid, did)]] 1.0 A_ub.append(row) b_ub.append(d.demand) # 3. 缺水定义约束: s_j D_j - Σ_i x_ij # 即 Σ_i x_ij s_j D_j # 转化为 -Σ_i x_ij - s_j -D_j for d in demands: row np.zeros(n_total) for (sid, did) in allowed_paths: if did d.id: row[var_index[(sid, did)]] -1.0 row[n_vars demand_index[d.id]] -1.0 A_ub.append(row) b_ub.append(-d.demand) A_ub np.array(A_ub) b_ub np.array(b_ub) # 变量边界供水量、缺水量均 0 bounds [(0, None)] * n_total # 求解默认使用 HiGHS 求解器 result linprog(c, A_ubA_ub, b_ubb_ub, boundsbounds, methodhighs) if not result.success: raise RuntimeError(f求解失败: {result.message}) # 整理结果 allocations [] for (sid, did) in allowed_paths: amount result.x[var_index[(sid, did)]] allocations.append(AllocationResult(source_idsid, demand_iddid, amountamount)) deficiencies {} for d in demands: deficiencies[d.id] result.x[n_vars demand_index[d.id]] return allocations, deficiencies这里有一个关键设计点我没有直接用 需水量减去供水量 来算缺水量而是把缺水量也建模成决策变量 s_j。这样做的好处是当供需不平衡时模型可以明确输出每个需水节点的缺水量而不是让负值或隐式的不满足无法表达。这也和后续可视化、报表生成的场景对接得更顺。4.4 分层求解优先级不被权重干扰如果YAML配置里各需水户的权重差不够大单轮优化可能出现为了降低农业缺水而牺牲工业这样不合理的方案。所以我默认启用了分层求解def solve_by_priority(sources, demands, allowed_paths): # 按优先级分组 priority_groups {} for d in demands: priority_groups.setdefault(d.priority, []).append(d) all_allocations [] all_deficiencies {} remaining_available {s.id: s.available for s in sources} for prio in sorted(priority_groups.keys()): group_demands priority_groups[prio] # 构建该分组的临时水源对象可用量为剩余量 temp_sources [] for s in sources: temp_sources.append(Source( ids.id, names.name, source_types.source_type, availableremaining_available[s.id], )) allocs, defs build_and_solve(temp_sources, group_demands, allowed_paths) # 更新剩余可用量 for a in allocs: remaining_available[a.source_id] - a.amount all_allocations.extend(allocs) all_deficiencies.update(defs) return all_allocations, all_deficiencies分层求解看起来很朴素但实际效果很好。每一层的水源可用量被上一层消耗掉高优先级需求被优先满足低优先级只能分剩下的。在极端缺水情况下这个逻辑比单纯调权重要可靠得多。5. 命令行交互与可视化展示5.1 交互菜单设计很多Python课程设计只做一个脚本文件跑完输出结果就结束。但实际使用中用户需要不断调整参数、切换场景所以项目入口我做成简单的命令行交互菜单def main(): print(简易水资源配置软件) print() while True: print(\n请选择操作) print(1. 加载新数据) print(2. 运行水资源配置) print(3. 查看当前配置结果) print(4. 导出报表) print(5. 退出) choice input(请输入选项1-5).strip() if choice 1: config_path input(请输入YAML配置文件路径).strip() excel_path input(请输入Excel数据文件路径).strip() # 加载并校验…… elif choice 2: # 运行求解…… # ……其余选项这种交互方式没做图形界面但胜在简单、跨平台、依赖少。如果你在课程设计中需要GUI可以考虑用Tkinter改造成桌面程序逻辑不用变只需要把控制台的输入输出替换成界面控件。5.2 生成供需对比图表结果只给一堆数字是没说服力的必须可视化。我的report.py里主要生成两张图第一张是需水-供水对比柱状图。每个需水节点画两根柱子一根表示需水量一根表示实际供水量两柱之间的差值就是缺水量。这张图能让决策者一眼看出哪个区域缺水最严重。第二张是水源贡献堆积图。横向是各个需水节点堆叠的色块代表来自不同水源的水量展示供需关系。核心绘制代码import matplotlib.pyplot as plt def plot_supply_demand(allocations, demands): demand_ids [d.id for d in demands] demand_names [d.name for d in demands] demand_values [d.demand for d in demands] # 计算实际供水量 supply_values [0.0] * len(demands) demand_index {d.id: i for i, d in enumerate(demands)} for a in allocations: if a.demand_id in demand_index: supply_values[demand_index[a.demand_id]] a.amount x range(len(demand_ids)) plt.figure(figsize(10, 6)) plt.bar(x, demand_values, width0.35, label需水量, color#4C72B0) plt.bar([i 0.35 for i in x], supply_values, width0.35, label供水量, color#55A868) plt.xticks([i 0.175 for i in x], demand_names, rotation15) plt.ylabel(水量万m³) plt.title(各需水节点供需对比) plt.legend() plt.tight_layout() plt.savefig(supply_demand_comparison.png, dpi150) plt.close()如果Matplotlib的默认样式觉得单调可以换成plt.style.use(seaborn-v0_8-whitegrid)这类内置样式效果会专业不少。5.3 结果表格导出除了图表还需要一份结构化的Excel报表方便归档或作为上报材料。我用pandas.ExcelWriter导出三个工作表配置方案明细、各节点供需汇总、缺水情况统计。每个表都带固定表头单位统一标注。导出这步看似简单但有个细节值得注意不要把float直接写成默认格式。默认情况下Pandas会把 1234.5 显示为 1234.5把 1234.0 显示为 1234.0看起来不够专业。我统一保留1位小数或2位小数并在列名里注明单位导出的表格拿来就能交差。6. 实测中的坑与应对6.1 SciPy版本差异导致linprog参数报错这是第一个坑。老版本SciPy1.5以前的linprog默认使用Simplex方法新版本推荐用methodhighs。如果代码里写的是methodsimplex在新版SciPy里会直接抛异常或提示该方法已移除。更麻烦的是老版本对bounds的处理逻辑和新版本有细微差异可能导致结果不一致。解决办法很简单显式指定methodhighs这是在SciPy 1.6里经过大量优化的求解器稳定性和速度都更好。如果部署环境里的SciPy版本很老建议先升级pip install --upgrade scipy如果你不能联网安装那就只能在代码里做版本判断import scipy from packaging import version if version.parse(scipy.__version__) version.parse(1.6.0): method highs else: method interior-point6.2 数据单位不统一差点把配置结果放大了一万倍有一次实测A水库的可用供水量在Excel里是亿m³单位我读取时没检查后续别的数据都是万m³。结果模型把 A水库当成了一万倍的超级大水缸所有需水节点都优先找A水库要水配置结果完全失真。排查过程花了一个多小时最后是在打印水源可用量的调试信息时发现的。这件事之后我养成了一个习惯任何数据文件在正式计算前先输出一份数据洞察报告包括各水源可用量合计、各需水户需水量合计、缺水量上限、单位统一后的数值范围。看一遍这些汇总数字基本就能识别出单位大错。6.3 约束条件太紧导致无解还有一次我为了模拟水源必须满足需水节点最低保证率的需求给每个需水节点加了Σ_i x_ij 0.9 * D_j的约束。理论上没问题但实际数据里生活需水量很大而允许供水的生活水源可用量太小无论如何也达不到90%的保证率求解器直接返回无解。后来调整思路最低保证率约束只加在高优先级节点上且运行前先做一次供需平衡预判。预判逻辑很简单——先把所有水源的可用量加起来和所有需水节点的最低必需量比较。如果必需量已经超过总可用量程序就给出明确警告而不是让求解器去处理一个注定无解的问题。这个预判不仅提升了稳定性还让用户提前知道这个方案根本没有可行解而不是对着报错发懵。6.4 处理极端场景总需水量为0水资源配置数据偶尔会出现某个需水节点需求量为0的情况比如新建的生态补水区还没投用或者农业灌溉因休耕需求量为0。如果不对这种边界情况做防御模型构建时会生成全零的行和列某些求解器会告警甚至直接报singular matrix错误。我在build_and_solve()里加了一层过滤把需求量小于某个极小阈值比如0.001的需水节点从模型里剔除不参与配置。输出时再补上0供水量记录保证报表结构完整。这个处理方式在工程上很实用既避免数值不稳定又不影响报表展示。7. 从简易到能落地的扩展思路7.1 多时段长系列模拟当前版本只做单时段比如一个月、一个季度的静态配置没有考虑前后时段水量结转。实际水资源配置中水库的蓄水要跨时段分配——这个月多放水下个月就可能不够。如果你需要做长系列模拟比如逐月逐年的调整计算可以在数据结构里增加period维度把水源节点拆成时段水源的组合节点并增加水库蓄水量的状态转移约束。伪代码如下# 水库蓄水量转移约束示例 for t in range(1, T): storage[t] storage[t-1] inflow[t] - total_release[t] - evaporation[t] storage_min storage[t] storage_max这一步会让模型复杂度上一个台阶但本质上还是线性约束scipy依然能处理。7.2 引入多目标经济、生态如果毕业设计想做得更有深度可以把单目标扩展为多目标比如同时考虑经济效益最大化和生态缺水量最小化。最简单的做法是加权求和但权重标定麻烦进阶做法是用pymoo这类多目标遗传算法库做帕累托前沿分析展示一组均衡解让决策者根据偏好选方案。7.3 Web化/报告自动化把命令行程序包装成一个小的Web应用是更常见的落地路径。用Flask或者FastAPI包一层接口用户上传Excel、填参数后台运行求解逻辑前端展示图表和报表下载链接。这样基层管理人员不需要装Python环境打开浏览器就能用。我后来在公司内部就是用这种方式把工具交付出去的。部署时建议用Gunicorn Nginx或者直接用Streamlit做数据应用原型开发成本低很多。7.4 让结果可解释输出每个需水户的缺水原因一个容易被忽视但实际价值极高的功能是生成缺水原因分析。具体做法是对每一个缺水的需水节点统计它有多少需求是因为水源供给总量不够而缺的有多少是因为许可路径受限而缺的。这个分析可以帮助决策者判断到底该新建水源、扩建水厂还是调整现有供水路径。用代码来实现本质是比较无路径约束下的理论可供给量和有路径约束下的实际供水量输出一个对比表即可。我在实际使用中体会最深的一点是这种简易工具在精度上虽不能和专业软件相比但只要数据结构清晰、逻辑透明、结果能解释它在日常方案验证和汇报沟通中的价值非常大。因为它让拍脑袋定方案变成了数据驱动快速试算而且方案之间可以横向比较效率提升是实打实的。如果你决定照着这个思路自己写一个记住三件事第一先把数据文件结构设计好这比写求解代码更影响整体体验第二宁可先跑通一个超简单的单目标模型也别一上来就堆复杂约束第三所有中间变量和校验信息都打印出来调试的时候你会感谢自己写了这些。本文还有配套的精品资源点击获取