DTF文件的解析 1.DTF文件的个人理解
DTF文件是一种树级结构的数据存储方式，其中以此有Simulation、Zone、Bc，Vc等分别存储simulation信息，区块信息，边界条件和块条件。结构视图中Coordinates存储该Zone中所有坐标点的位置信息，往往一个网格划分的基础就是将coordinates中的坐标准确无误的对应上去。BC Records中记录的是各个zone之间的边界信息，边界的种类分为interface(交界面)，wall（墙类型），inlet（流场入口），outlet（流场出口）等。
2.DTF文件的生成
最简单的DTF文件生成方式是通过fastran中的Geom软件直接创建一个网格文件，然后另存为DTF即可。这里笔者是通过代码生成的方式，其实也很简单，关键在于如何确定DTF网格文件的几何建模，其次需要注意各个Zone之间的边界问题。能够准确做好这两个方面，一个简单的DTF文件便可以完成
3.构建DTF文件的问题
笔者在构建DTF文件的时候遇到很多的问题，这里将一些问题记录在下面，方便以后自己查找
3.1 如何将DTF文件中的I，J，K坐标序列和真实x，y，z坐标对应起来
如图片所示，coordinates中存在Index，I，J，K，这三个是系统自动生成的，其中Index为以此增加从一维的角度来记录各个点的索引，而I，J，K则是从三维的下标来对实际的坐标位置进行建立。就好像是三维数组，每个数组的值是一个坐标点实际位置。I，J，K就好比三维数组的下标，x，y，z就好比三维数组实际对应的坐标点的位置信息。IBlanking这个值，笔者还没有具体了解，这里猜测和该坐标的显示与否相关。明白之后会更新
3.2 关于Patches和BC Records的对应关系
一个简单的Zone区域是由6个patches来决定的，每一个patch都有自己对应的bc record。但是BC Records和Patches的确定是分开的。BC Records中的6个面是通过I，J，K以此从小到大来进行确定的。也就是说这里面的I，J，K的关系是确定的，但是Patches在指定的时候需要单独对I，J，K进行额外的确定，而非内部直接实现。下图是Patch 2的I，J，K大小。
3.3 BC Records中的对应关系的确定
之前说过BcType有很多类型，在我们确定网格模型的时候其实就已经确定了所有的边界条件。在边界条件的具体写入也容易出Bug了。笔者往往在算好Coordinates值后还要在这里卡一段时间，也是一个比较费时间的工作。每个zone都有自己的VC，这里理解为对Zone的整体控制，比如这个Zone是Fluid类型或者是Solid类型这些，还有表示这个Zone的Key值也放在VC中。每个边界都有和其相关的Zone，这里我们就需要在每个边界的record中写入他所毗邻的zone的key值。
由于每个BC和相应的I，J，K相关，而不同的计算方式得到的坐标序列不同，必然会导致I，J，K的区别，这里尤其需要注意每个边界和实际中的哪一个面是对应的关系。
同样每个边界也有自己的Key值，对于interface的边界条件，每个interface的边界必然毗邻两个不同的zone，这两个zone的该边界必须完全一致。