简介：这份资源是面向地质勘探、矿山生产与矿产资源评价领域初学者及技术人员的 SURPAC 建模入门笔记，围绕建模前的基础概念与数据组织流程展开，帮助读者理清项目数据存储、原始数据整理、剖面与中段解译等环节的先后关系。压缩包仅含 1 个 docx 文档，约 17KB，篇幅紧凑，可直接作为案头速查材料。内容从勘探线编号、勘探线_ID、中段编号与中段_ID、宏文件、正交与斜交剖面等概念讲起，进而说明项目数据在微机中的存储组织、原始数据来源与整理要求，并重点展开剖面解译与中段解译两条主线，细述文件组织、文件命名规则以及线串号在勘探线、地层、矿体、小矿体、剖面坐标线、钻孔剖面、用于打印的剖面图等类型文件中的分配方式，还涉及解译时矿体品级的处理说明。目前已有 488 人学习，适合希望先打牢概念与文件规范基础、再进入实际上机建模的读者系统梳理知识框架。

1. 建模卡在编号上：这份 SURPAC 建模文档真正解决的是什么

拿到一份 SURPAC 软件建模的文档，不少人的第一反应是翻到剖面解译那一页去找按钮，结果真正让项目停摆的，往往是最前面那几行编号规则。这份资料做的是一件很具体的事：把勘探线编号、勘探线_ID、中段编号、中段_ID、线串号、文件命名这一整套口径固定下来，让原始数据表、剖面线文件、中段线文件和最终出图能够一一对上。它面向的是手上已经有一批钻孔数据、准备在 SURPAC 里建地质模型和矿体模型的人，新手可以照着填表，做过几年的人可以拿它当团队内部的作业规范。文档里没有花哨的算法，全是会实实在在卡住你的细节。

2. 项目数据落盘：目录骨架、命名公式与 ID 补齐的三条硬规矩

很多人以为建模的起点是打开软件，其实起点是资源管理器。一份钻孔数据从 Excel 表格变成 SURPAC 能认的线文件、块模型，中间要经过解译、合并、旋转、出图好几道工序，每一道都会产生新文件。目录和命名要是没有提前定死，做到一半就会出现“地层 4006.str”和“地层 40006.str”同时存在的情况，软件不报错，你自己也说不清哪一个是 6 号勘探线的。

2.1 一个项目一棵目录树：六个子目录各管什么

我习惯在项目根目录下按“数据流向”而不是按“文件类型”来分子目录，因为建模是流水线，按阶段分才能一眼看出哪一步还没做。常见做法是建 six 个固定子目录，路径里不带中文、不带空格、不带括号，盘符也固定下来，不要今天放 D 盘明天放桌面。

# 项目根目录只放这六个子目录，名字全小写，避免大小写混用 mkdir -p prj_x/orig # 原始数据：井口、测斜、样品、岩性的 CSV mkdir -p prj_x/sec # 剖面解译：勘探线、地层、矿体、坐标线等 .str mkdir -p prj_x.plan # 中段解译：按标高组织的 .str mkdir -p prj_x/merge # 合并后的地质剖面、旋转后的出图文件 mkdir -p prj_x/macro # 录制的 .TCL 宏与改过的批处理脚本 mkdir -p prj_x/bak # 按日期归档，只进不出

上面这段只是骨架，真正要守的是几条约定：orig目录里的文件只读不写，任何修改都另存；sec和plan里的.str一律按下一节的命名公式生成；merge目录里允许出现临时文件，但每次出图前清空一次；bak按20240612_剖面解译完成这种“日期+阶段”的方式建子目录，不做覆盖式备份。.str本质是文本文件，同一条勘探线的两次解译可以直接做文本比对，这比事后靠记忆判断“哪一版是对的”靠谱得多。

有一点容易被忽略：项目根目录不要放在同步盘或者带自动备份的目录里。建模过程中.str会被反复读写，同步进程正好在你保存的瞬间去读，文件被锁住的情况不算罕见，报错信息通常还很难看懂。

2.2 命名公式 内容+勘探线_ID.str 与四位补齐

文档把命名规则写得很干脆：文件内容 + 勘探线_ID.str，比如“地层 40006.str”就表示 6 号勘探线上的地层线文件。这里的勘探线_ID不是地勘单位原来那个线号，而是为了配合软件对文件名的处理方式，用一个四位或五位的整数来代表某条勘探线。转换办法就是在原线号前面补 0 或补 1，补齐到四位或者五位。

问题在于勘探线号并不总是阿拉伯数字。文档里明确说了，实际线号可能是阿拉伯数字、罗马数字，也可能是字符编号。遇到0线、A线、Ⅲ线这类编号，直接补零是补不出来的，必须建一张映射表，把“人读的线号”翻译成“软件认的 ID”，并且这张表要跟着项目一起归档。

四位还是五位，一个项目里只能选一种，中途不能改。选四位的理由是文件名短、肉眼好读；选五位的理由是线号超过 9999 时不用重构。我一般按矿区勘探线总数来定，几十条线用四位完全够，上百条且未来还会加密的，一开始就上五位，省得后面返工。

2.3 路径、字符集和版本备份

这三件事单独看不起眼，凑在一起就是建模前期最集中的翻车点。SURPAC 处理文件名的逻辑决定了它对路径里的特殊字符并不宽容，中文目录、空格、#、&、超长路径都可能让某个批量操作只成功一半——最麻烦的是它不一定报错，只是少处理了几个文件。

字符集方面，.str文件里的属性字段（比如地层名称、矿体号）如果混用了两种编码，合并之后中文会变成乱码，而乱码在图形界面上不一定立刻显示出来。统一用一套编码，从 Excel 导出 CSV 的那一步就定下来，后面所有脚本都按这套编码读写。

备份不要用“文件名加日期”的方式散落一地，比如地层 40006_最终版_改.str。正确做法是整个sec目录打包归档，命名成20240612_sec_剖面解译v3.zip，同时在bak下留一份 README 说明这一版改了什么、对应哪批钻孔。后悔药只有提前准备好才叫后悔药。

3. 原始数据四张表：井口、测斜、样品、岩性的字段口径与入库校验

原始数据这一层决定了模型的地基。文档把矿区信息拆成五个数据表在 Excel 里录入，其中井口表、测斜表、样品分析结果表、岩性表是最核心的四张。这四张表看起来就是普通的表格，但字段口径只要有一处不统一，后面解译出来的矿体边界就会整体偏移，而且这种偏移在单张剖面上往往看不出来。

3.1 井口表：勘探线_ID 怎么从线号推出来

井口表回答的是“这个钻孔在哪条勘探线上、孔口在什么位置、设计多深”。必填字段至少包括钻孔号、勘探线_ID、孔口 X/Y/Z 坐标、开孔方位角、开孔倾角、设计孔深。其中勘探线_ID 不是随手填的，它是按 2.2 节那张映射表推出来的四位或五位整数，和文件名里的 ID 必须是同一个值。

这一步最常见的误用是把“勘探线号”和“勘探线_ID”混成一列。线号是给人看的，可以是 6、0、A；ID 是给软件和文件名看的，只能是齐位整数。两列都留，一列都不省，将来核对的时候能省下大量时间。

孔口坐标的 Z 值要确认是绝对标高还是相对标高，整个项目只能有一种。井口表的 Z 和测斜表算出来的孔底标高，如果和地质剖面图上的标高对不上，八成就是这里混了基准。

3.2 测斜表：深度、倾角、方位角的单位与顺序

测斜表记录的是钻孔轨迹，字段是钻孔号、测斜深度、倾角、方位角。文档特意点明：深度单位是米，倾角和方位角的单位是度。这句话看着像废话，实际是血泪经验——有的钻探原始记录里倾角用度分表示，有的用弧度，有的把方位角写成磁方位而没有标注磁偏角修正。

单位之外还有几个必须校验的点：

• 测斜深度必须严格递增，不能出现两个相同深度，否则插值会出问题；
• 第一条测斜记录的深度通常不为 0，但也不能大于设计孔深；
• 最后一条测斜深度要覆盖到终孔深度附近，缺失时按最后一条的轨迹外推，这一点要在数据说明里写清楚；
• 方位角跨 360° 时（比如从 359° 跳到 1°），如果按数值大小排序会得到错误结果，做角度插值时要先做归一化。

倾角的符号约定也要统一。有的资料里向上为负、向下为正，有的正好相反，同一个项目里两种写法混着来，算出来的孔底位置能差出几十米。

3.3 样品分析结果表：段、样号与品位字段

样品分析结果表是品级处理的数据来源，核心字段是钻孔号、采样起始深度、采样终止深度、样品号、品位值，再加上品位对应的元素或品级名称。这张表的坑集中在“段”的语义上：起止深度是包含还是不包含、相邻样品段是否允许重叠、空样和低于检出限怎么表示。

常见做法是要求“起 < 止”且同一样品号唯一，相邻样品段首尾相接即可、不允许重叠；低于检出限的值统一填一个约定好的极小值并在数据说明里注明，不要留空，也不要填“未检出”这类文本——文本在后续计算里会变成 0，等于人为抬高了矿石量。

一个钻孔的样品段总长一般不等于孔深，中间的岩芯采取率损失段就是空的。这些空段在组合样的时候要单独处理，不能简单按长度加权平均，否则富集段的品位会被稀释。

3.4 岩性表与字典表：别让代号各写各的

岩性表记录钻孔揭露的岩性分段，字段是钻孔号、起始深度、终止深度、岩性代号。它和样品分析结果表在深度上是对应的，但分段边界通常不一致，这一点在解译剖面前要有心理准备。

真正的问题出在岩性代号上。有的钻孔记录写“花岗岩”，有的写“γ”，有的写“花岗岩(γ)”，同一种岩石三种写法，剖面解译时就会变成三条互不相干的线。解决办法是建一张岩性字典表，左列是各种原始写法，右列是唯一的标准化代号，入库前先做一遍映射。

字典表还有个隐藏作用：它是解译时分配线串号的依据。一种岩性对应一个线号，字典有多少条，线号段就要留多少位。

3.5 入库前跑一遍校验脚本

四张表录完之后不要直接进软件，先跑一遍校验。用 Python 把 CSV 全按字符串读进来，避免前导零被吃掉，然后逐项检查。

import re import pandas as pd PATH = "prj_x/orig/" # dtype=str 是关键：不加这一行，0006 会被读成 6 collar = pd.read_csv(PATH + "collar.csv", dtype=str, keep_default_na=False) survey = pd.read_csv(PATH + "survey.csv", dtype=str, keep_default_na=False) assay = pd.read_csv(PATH + "assay.csv", dtype=str, keep_default_na=False) lith = pd.read_csv(PATH + "lith.csv", dtype=str, keep_default_na=False) # 1) 勘探线_ID 必须是 4 位或 5 位纯数字 bad_id = collar.loc[~collar["勘探线_ID"].str.fullmatch(r"\d{4,5}"), "勘探线_ID"] print("ID 不合规：", bad_id.unique()) # 2) 钻孔号在四张表里必须能对上 base = set(collar["钻孔号"]) for name, df in [("测斜", survey), ("样品", assay), ("岩性", lith)]: orphan = set(df["钻孔号"]) - base print(f"{name}表游离钻孔：", orphan) # 3) 测斜深度单调递增且不超过设计孔深 collar["设计孔深"] = collar["设计孔深"].astype(float) for hid, g in survey.groupby("钻孔号"): d = g["测斜深度"].astype(float).to_numpy() if any(d[i] >= d[i + 1] for i in range(len(d) - 1)): print("测斜深度非递增：", hid) if len(d) and d[-1] > collar.loc[collar["钻孔号"] == hid, "设计孔深"].iloc[0] + 0.01: print("测斜超出孔深：", hid) # 4) 样品段不允许重叠，岩性段也不允许 for name, df, a, b in [("样品", assay, "起始深度", "终止深度"), ("岩性", lith, "起始深度", "终止深度")]: for hid, g in df.groupby("钻孔号"): g = g.assign(s=g[a].astype(float), e=g[b].astype(float)).sort_values("s") if (g["s"].shift(-1) < g["e"]).any(): print(f"{name}段重叠：", hid)

这段脚本的四个检查项对应四类错误：ID 不合规会导致文件名生成失败或生成出两个不同的名字；游离钻孔说明某张表漏录了孔或者钻孔号打错了；测斜深度出问题会让轨迹跑飞；段重叠会让品位组合和岩性分段都失真。参数方面，dtype=str和keep_default_na=False必须同时加，前者防止前导零丢失，后者防止空字符串被自动转成 NaN 之后再写回去变成 “nan”。容差0.01是留给浮点误差的，实际项目里按数据精度调整，一般不超过 0.05 米。校验输出不是空就直接停下来改数据，不要带着问题往下走。

4. 剖面与中段解译：七类线文件、D1/D2 属性和线串号分配

剖面解译是整个建模流程里工作量最大的一段。它的本质是把三维空间里的地质界线投影到勘探线剖面上，在二维视图里画成线，再给每条线分配可追溯的编号和属性，最后由软件重新拉回三维。文件组织、命名、线串号这三件事只要有一件没定好，合并的时候就会出现“线画对了但属性对不上”这种最难排查的问题。

4.1 七类线文件与 D1/D2 属性字段

按内容划分，剖面解译涉及的文件类型包括勘探线、地层、矿体、小矿体、剖面坐标线、钻孔剖面、用于打印的剖面图，另外还有地质剖面、旋转为东西向、旋转为水平、剖面块模型这些派生文件。其中前七类是日常打交道最多的。

每种文件承担的信息不同，属性字段的约定也不同。文档里对勘探线文件的规定最明确：每条勘探线用一个线段记录，只记两个端点；D1 属性字段记“勘探线_ID”，D2 属性字段记“勘探线号”；文件本身的 ID 号取 1。

勘探线文件的方向约定必须严格执行：各勘探线要以南、南西、西、北西侧的端点为起点，以北、北东、东、东南侧的端点为终点。这条规定听起来只是“从哪头开始画”的小事，但它决定了后面旋转剖面时的坐标变换方向。起点反了的勘探线，旋转之后剖面会整体镜像，坐标线和钻孔轨迹对不上，而且因为图面上看起来仍然是一条完整的剖面，肉眼很难第一眼发现。

4.2 初始解译先拆开：地层、矿体、小矿体分开成文件

解译的初始阶段不要图省事把所有界线画进一个文件。文档给的做法是：先对每个剖面上的各种岩性和矿体单独解译，命名方法是“地层编号或矿体号 + 勘探线_ID.str”，并且地层文件和矿体文件要在 D1 属性里记录地层名称或矿体号。

举个例子，6 号勘探线上要解译三种地层和两个矿体，初始阶段会得到五个文件：

地层 GRA 40006.str D1 = GRA 地层 SKA 40006.str D1 = SKA 地层 MAR 40006.str D1 = MAR 矿体 M1 40006.str D1 = M1 矿体 M2 40006.str D1 = M2

等到单个剖面的解译确认无误，再按类型合并成“地层 40006.str”和“矿体 40006.str”，合并时靠 D1 属性区分不同岩性和矿体。先拆后合的好处是错误可以局部修正——某条地层线画错了，只重做那一个文件，不用把整个剖面的线全部重画。

提示：初始拆分阶段生成的文件数量会明显多于最终文件数，这是正常的。合并完成后要把中间文件移进bak，不要留在sec目录里，否则后续批量处理会把这些半成品也扫进去。

4.3 线串号分配：按文件类型逐条对照

线串号是文件和线之间的桥梁。同一条剖面里可能画了几十条线，软件靠线号来区分它们分别属于哪种地层、哪个矿体。文档对分配规则给得比较克制，只说“线号与文件关联”，具体数字要项目自己定。我一般按下面的思路落地。

勘探线文件的线号通常取 1，或者每条勘探线各取一个单独的线号，两种都行，一个项目里统一即可。地层文件是每个剖面形成一个地层线文件，线号和文件一一对应，也就是一种岩性占一个线号，这个线号在整个项目里保持不变，靠 3.4 节的岩性字典来维护。矿体文件同理，一个矿体号对应一个线号。小矿体单独占一段线号，不要和主矿体连号，避免合并时混在一起。剖面坐标线占独立的一段，因为它是辅助线，出图时要单独控制显示。钻孔剖面每个钻孔一个线号，用于和地质剖面扣合。用于打印的平面图文件 ID 固定为 0，这个不要改。

线号段可以按百位划分，比如 1–99 给勘探线和坐标线，100–199 给地层，200–299 给矿体，300–399 给小矿体，400 以后给钻孔剖面。段内具体取哪个号，写进项目的数据字典，所有人按字典取号，不要各自发挥。这条规则的价值在于：半年后你打开一个不知道谁做的文件，看线号落在哪一段，就知道它大概是什么内容。

4.4 中段解译：标高当 ID 的文件组织

中段解译和剖面解译是同一套逻辑换了个切面。文件组织上同样分勘探线、地层、矿体、小矿体、钻孔中段这几类，命名方法也沿用“内容 + 中段_ID.str”的结构。

区别在于中段_ID 的来源。文档给的口径很直接：中段编号通常按各中段的标高命名，所以可以直接用中段标高作为 ID；遇有负标高时，把负的标高值作为 ID；标高是小数时，去掉小数点变成整数作为 ID。

这套规则在纸面上没问题，落到文件名上就有几处要提前约定。负标高带负号，-50和50在文件名里只差一个字符，排序和肉眼核对都容易看错，所以我一般会在映射表里加一列“文件用 ID”，把负号转成固定前缀，或者整体加一个偏移量（比如统一加 1000），保证落到文件名上的永远是正整数。小数标高去掉小数点之后位数会变，1250.5变成12505，125.05也变成12505，这两个是不同的中段却撞了号，所以小数点后的位数要统一，要么都保留一位，要么都保留两位，转换规则写死在脚本里。

中段文件的线串号分配和剖面基本一致：地层、矿体、小矿体各自占段，钻孔中段单独一类。合并顺序建议按标高从高到低，这样生成的实体在三维视图里叠放关系正确，后期切块模型时不容易出现面交叉。

4.5 出图链路：先转东西向，再换 Y/Z

剖面解译完成之后是出图。文档把这条链路拆得很清楚：地质剖面是把各勘探线剖面上的地层、矿体、剖面坐标线等文件合并成一个文件，记录该剖面除钻孔剖面以外的所有地质信息。此时信息仍然是三维空间里的，要打印出图，得先把它变换到平面上。

第一步是旋转为东西向。用的是“线文件 2D 转换”功能，把剖面旋转到东西方向；针对勘探线段来说，就是把相应的勘探线段移动到东坐标轴上，并把勘探线的左端点移动到坐标原点。这一步做完，剖面还是立在垂面上的。

第二步是旋转为水平。把文件的 Y 坐标和 Z 坐标互换，剖面就从铅直面变换到了水平面。至此剖面上的信息和钻孔剖面的信息扣合到一起，可以打印了。

顺序不能反。先换 Y/Z 再旋转，等于在已经躺平的图形上做二维旋转，角度关系和原始空间对不上，转出来的图看着像那么回事，实际比例和方位都是错的。旋转完成后建议拿一条已知长度的勘探线做校核：在原始三维里量一次长度，在出图文件里量一次，两者应当一致。这是最便宜也最有效的验证手段。

5. 避坑排查：五条让模型对不上的记录

下面这五条都是我在实际项目里反复见到的，症状各不相同，共同点是软件不报错、图面看起来正常，等到做块模型或者算资源量的时候才暴露。

5.1 Excel 存 CSV 把 004006 变成了 4006

现象：剖面解译做完，合并时发现 6 号勘探线的文件被识别成另一条线，或者同一条线出现两个文件。原因：井口表里的勘探线_ID 在 Excel 里被当成数字，前导零被自动去掉，存成 CSV 之后就是4006而不是40006。解决：录入前把该列设为文本格式，导出时用“另存为 CSV UTF-8”，读取脚本一律加dtype=str，并且在 3.5 节的校验里把位数检查作为第一项。

5.2 勘探线段起点方向不统一，旋转后剖面镜像

现象：某几条勘探线出图后，钻孔轨迹和地质界线的相对位置是反的，坐标网也偏到一边。原因：画勘探线段时起点选在了北侧，而约定是南侧或西南侧为起点，旋转为东西向时整条线被翻了个方向。解决：把“南、南西、西、北西为起点”写进作业规范，解译完成后用一个脚本批量检查每条勘探线段的起点坐标是否小于终点坐标（按主方向判断），不符合的自动翻转。

5.3 负标高做中段_ID，排序和查重都出问题

现象：中段文件按名称排序时，-50排在了50后面，合并顺序错乱；或者两个不同中段生成了同一个文件名。原因：负号参与字符串排序，小数标高去点后位数不齐导致撞号。解决：在映射表里加一列纯数字的文件用 ID，负标高统一加偏移量转正，小数统一保留固定位数后再去点，转换过程写成脚本，不允许手工命名。

5.4 中文路径和空格让批量操作只成功一半

现象：跑宏或者批量合并时，控制台没有明显报错，但结果文件少了几个。原因：路径里有中文、空格或者特殊符号，部分命令解析失败后被跳过。解决：项目根目录用纯英文短路径，层级不超过四级；宏文件里的路径全部用正斜杠，或者在引用时加引号；批处理跑完统计一次输入文件数和输出文件数，对不上就停下来查。

5.5 D1/D2 属性漏填，合并后线还在但归属没了

现象：地层线和矿体线都在图面上，但合并之后分不清哪条线属于哪个地层，属性查询结果是空的。原因：初始解译时只画了线，没有在 D1 里写地层名称或矿体号，合并时软件只能按线号猜，线号又恰好没按字典取。解决：把属性填写纳入解译完成的检查项，用一个脚本遍历sec目录下所有.str，逐条列出线号和 D1 值，空的或者不在字典里的打出来，改完再合并。

注意：这五条里有四条都能靠脚本在半小时内查出来，只有第二条需要人工确认方向约定。前期花在脚本上的时间，比后期返工重画剖面便宜太多。

6. 宏文件 TCL 批处理：把重复操作录下来，再改成能校验的脚本

SURPAC 能把软件操作过程录下来生成宏文件，扩展名是.TCL，用它可以重复执行同一套操作。真正好用的用法不是“录一遍然后原样重放”，而是录完之后打开文件，看清它到底记了哪些命令、哪些参数是写死的，再把循环和校验塞进去。

# 示例结构：批量处理某目录下所有剖面文件 # 具体命令名以录制结果为准，不要照抄这里的伪命令 set root "D:/prj_x/sec" set files [glob -nocomplain -directory $root *.str] foreach f $files { # 1) 打开文件，参数是完整路径 open_line_file $f # 2) 检查 D1 属性是否为空，空则记录并跳过 set d1 [get_line_attribute D1] if {$d1 eq ""} { puts "属性缺失：$f" close_line_file continue } # 3) 按命名规则推导勘探线_ID，与文件内 D1 交叉验证 set fid [file rootname [file tail $f]] puts "处理 $fid D1=$d1" close_line_file } puts "共处理 [llength $files] 个文件"

这段结构里有三个关键点。glob的-nocomplain是必须的，路径下没有匹配文件时它返回空列表而不是报错，批处理不会中断。foreach里第一步先做属性检查，把不合格的文件打出来并continue，比整批跑完再回头找要省时间。最后输出总数，用来和输入目录的文件数对账。

参数方面，root一定要用正斜杠或者双反斜杠，TCL 里单个反斜杠是转义符，D:\prj会被解析成别的意思。文件名推导 ID 那一步，如果项目用的是四位 ID，就按四位去截取和校验，不要用模糊匹配——模糊匹配会把地层 40006.str和地层 40006_改.str都放过。

宏文件本身要纳入版本管理。录制生成的第一版叫batch_v1_raw.tcl，改过的叫batch_v2_check.tcl，每一版在文件头写清楚改了什么、对应哪批数据。我吃过一次亏：直接在工作版上改参数，改到第三轮已经忘了最初录的是什么样，出了问题时连回退的基准都没有。从那以后每次录制完第一件事就是另存一份原始版本，之后所有修改都在副本上做，跑完再拿 5.5 节那个属性检查脚本过一遍，确认没有文件被静默跳过。希望帮到你。

本文还有配套的精品资源，点击获取