E. Curricula model checking declarative representation and verification of properties

信息系统测试管理规范修订记录目录1. 引言 (1)1.1.目的 (1)1.2.范围 (1)1.3.参考 (1)1.4.术语 (1)2. 测试项目范围管理 (1)2.1.管理目的 (1)2.2.活动定义 (2)2.3.角色和职责 (3)2.4.管理文档 (4)3. 测试项目规划管理 (5)3.3.管理目的 (5)3.4.活动定义 (5)3.5.角色和职责 (8)3.6.管理文档 (8)4. 测试缺陷管理 (9)4.1.管理目的 (9)4.2.活动定义 (9)4.3.角色和职责 (10)4.4.工作流程 ................................................................................................................. 错误!未定义书签。

4.5.流程描述 (11)4.7.退出条件 (11)4.8.缺陷属性 (12)4.8.1. 缺陷属性字段解释说明 (12)4.8.2. 缺陷状态定义 (13)4.8.3. 缺陷严重等级 (14)4.8.4. 缺陷优先级 (18)4.8.5. 缺陷来源 (18)4.8.6. 缺陷发现阶段 (19)4.9.管理文档 (19)5. 问题管理................................................................................................................... 错误!未定义书签。

5.1.管理目的 ................................................................................................................. 错误!未定义书签。

5.2.活动定义 ................................................................................................................. 错误!未定义书签。

lingo 错误代码大全LINGO出错时错误代码含义：在LINGO程序求解时，系统首先会对程序进行编译．系统在编译或执行其他命令时，会因程序中的错误或运行错误，弹出一个出错报告窗口，显示其错误代码，并简要指出错误的原因．这些错误报告信息能够提示用户发现程序中的错误，以便能尽快修改．下面我们给出出错信息的一个简要说明，仅供参考．LINGO错误编号及原因对照表。

错误代码含义0 LINGO模型生成器的内存已经用尽(可用“LINGO|Options"命令对General Solver选项卡中的“Generator Memory Limit"选项进行内存大小的修改) 1 模型中的行数太多(对于有实际意义的模型，这个错误很少出现)2 模型中的字符数太多(对于有实际意义的模型，这个错误很少出现)3 模型中某行的字符数太多(每行不应该超过200个字符，否则应换行)4 指定的行号超出了模型中实际具有的最大行号(这个错误通常在LOOK命令中指定了非法的行号时出现)5 当前内存中没有模型6 脚本文件中TAKE命令的嵌套重数太多(LINGO中限定TAKE命令最多嵌套10次)7 无法打开指定的文件(通常是指定的文件名拼写错误)8 脚本文件中的错误太多，因此直接返回到命令模式(不再继续处理这个脚本文件)9 (该错误编号目前没有使用)10 (该错误编号目前没有使用)11 模型中的语句出现了语法错误(不符合LINGO语法)12 模型中的括号不匹配13 在电子表格文件中找不到指定的单元范围名称14 运算所需的，临时堆栈空间不够(这通常意味着模型中的表达式太长了)15 找不到关系运算符(通常是丢了“<”，“＝”或“>”)16 输入输出时不同对象的大小不一样(使用集合循环方式输入输出时，集合大小应相同)17 集合元素的索引的内存堆栈空间不够18 集合的内存堆栈空间不够19 索引函数@INDEX使用不当20 集合名使用不当21 属性名使用不当22 不等式或等式关系太多(例如，约束2<x<4是不允许出现在同一个语句中的)23 参数个数不符24 集合名不合法25 函数@WKX()的参数非法(注：在LING09.0中已经没有函数@WKX())26 集合的索引变量的个数不符27 在电子表格文件中指定的单元范围不连续28 行名不合法29 数据段或初始段的数据个数不符30 链接到Excel时出现错误31 使用@TEXT函数时参数不合法32 使用了空的集合成员名33 使用@OLET函数时参数不合法34 用电子表格文件中指定的多个单元范围生成派生集合时，单元范围的大小应该一致35 输出时用到了不可识别的变量名36 基本集合的元素名不合法37 集合名已经被使用过38 ODBC服务返回了错误信息39 派生集合的分量元素(下标)不再原来的父集合中40 派生集合的索引元素的个数不符41 定义派生集合时所使用的基本集合的个数太多(一般不会出现这个错误)42 集合过滤条件的表达式中出现了取值不固定的变量43 集合过滤条件的表达式运算出错44 过滤条件的表达式没有结束(即没有“:”标志)45 @ODBC函数的参数列表错误46 文件名不合法47 打开的文件太多48 不能打开文件49 读文件时发生错误50 @FOR函数使用不合法51 编译时LINGO模型生成器的内存不足52 @IN函数使用不当53 在电子表格文件中找不到指定的单元范围名称(似乎与出错代码“13”含义类似)54 读取电子表格文件时出现错误55 @TEXT函数不能打开文件56 @TEXT函数读文件时发生错误57 @TEXT函数读文件时出现了非法输入数据58 @TEXT函数读文件时出现发现输入数据比实际所需要的少59 @TEXT函数读文件时出现发现输入数据比实际所需要的多60 用@TEXT函数输入数据时，没有指定文件名61 行命令拼写错误62 LINGO生成模型时工作内存不足63 模型的定义不正确64 @FOR函数嵌套太多65 @WARN函数使用不当66 警告：固定变量取值不唯一(例如：任意正数都是约束@SIGN(X)＝l的解)67 模型中非零系数过多导致内存耗尽68 对字符串进行非法的算术运算69 约束中的运算符非法70 属性的下标越界71 变量定界函数(@GIN，@BIN，@FREE，@BND)使用错误 72 不能从固定约束(只含有固定变量的约束)中求出固定变量的值(相当于方程无解，或者LINGO的算法解不出来，如迭代求解算法不收敛)73 在LINGO生成模型(对模型进行结构分析)时，用户中断了模型生成过程74 变量越界，超出了103275 对变量的定界相互冲突(例如：一个模型中同时指定@BND(-6，X，6)和@BND(-5,X，5)是允许的，但同时指定@BND(-6，X，6)和@BND(7，X，9)则是冲突的.)76 LINGO生成模型时出现错误，不能将模型转交给优化求解程序77 无定义的算术运算(例如除数为0)78 (该错误编号目前没有使用)79 (该错误编号目前没有使用)80 生成LINGO模型时系统内存已经用尽81 找不到可行解82 最优值无界83 (该错误编号目前没有使用)84 模型中非零系数过多85 表达式过于复杂导致堆栈溢出86 算术运算错误(如1／0或@LOG(-1)等)87 @IN函数使用不当(似乎与错误代码“52”相同)88 当前内存中没有存放任何解89 LINGO运行时出现了意想不到的错误(请与LINGO公司联系解决问题)90 在LINGO生成模型时，用户中断了模型生成过程91 当在数据段有“变量＝?”语句时，LINGO运行中将要求用户输人这个变量的值, 如果这个值输入错误，将显示这个错误代码92 警告：当前解可能不是可行的／最优的93 命令行中的转换修饰词错误94 (该错误编号目前没有使用)95 模型求解完成前，用户中断了求解过程96 (该错误编号目前没有使用)97 用TAKE命令输入模型时，出现了不可识别的语法98 用TAKE命令输入模型时，出现了语法错误99 语法错误，缺少变量100 语法错误，缺少常量101 (该错误编号目前没有使用)102 指定的输出变量名不存在103 (该错误编号目前没有使用)104 模型还没有被求解，或者模型是空的105 (该错误编号目前没有使用)106 行宽的最小最大值分别为68和200107 函数@POINTER指定的索引值无效108 模型的规模超出了当前LINGO版本的限制109 达到了迭代上限，所以LINGO停止继续求解模型(迭代上限可以通过“LING0|0ptions”命令对General Solver选项卡中的“Iteration”选项进行修改)110 HIDE(隐藏)命令指定的密码超出了8个字符的限制111 模型是隐藏的，所以当前命令不能使用112 恢复隐藏模型时输入的密码错误113 因为一行内容太长，导致LOOK或SAVE命令失败114 HIDE(隐藏)命令指定的两次密码不一致，命令失败115 参数列表过长116 文件名(包括路径名)太长117 无效的命令118 命令不明确(例如，可能输入的是命令的缩写名，而这一缩写可有多个命令与之对应)119 命令脚本文件中的错误太多，LINGO放弃对它继续处翠120 LINGO无法将配置文件(LINGO．CNF)写入启动目录或工作目录(可能是权限问题)121 整数规划没有敏感性分析122 敏感性分析选项没有激活，敏感性分析不能进行(可通过“LINGO|Options”命令对General Solver选项卡中的“Dual Computation”选项进行修改)123 调试(Debug)命令只对线性模型、且模型不可行或无界时才能使用124 对一个空集合的属性进行初始化125 集合中没有元素126 使用ODBC连接输出时，发现制定的输出变量名不存在127 使用ODBC连接输出时，同时输出的变量的维数必须相同128 使用SET命令时指定的参数索弓I无效129 使用SET命令时指定的参数的取值无效130 使用SET命令时指定的参数名无效131 FREEZE命令无法保存配置文件LINGO．CNF(可能是权限问题)132 LINGO读配置文件(LINGO．CNF)时发生错误133 LINGO无法通过OLE连接电子表格文件(如：当其他人正在编辑这个文件时)134 输出时出现错误，不能完成所有输出操作135 求解时间超出了限制(可通过“LING0|0ptions”命令对General Solver选项卡中的“Time”选项进行修改)136 使用@TEXT函数输出时出现错误操作137 (该错误编号目前没有使用)138 DIVERT(输出重新定向)命令的嵌套次数太多(最多不能超过10次嵌套)139 DIVERT(输出重新定向)命令不能打开指定文件140 只求原始最优解时无法给出敏感性分析信息(可通过“LING0|0ptions”命令对General Solver选项卡中的“Dual Computation”选项进行修改)141 对某行约束的敏感性分析无法进行，因为这一行已经是固定约束(即该约束中所有变量都已经在直接求解程序进行预处理时被固定下来了)142 出现了意想不到的错误(请与LINDO公司联系解决这个问题) 143 使用接口函数输出时，同时输出的对象的维数必须相同144 @POINTER函数的参数列表无效145 @POINTER函数出错：2-输出变量无效；3-内存耗尽；4-只求原始最优解时无法给出敏感性分析信息；5-对固定行无法给出敏感性分析信息；6-意想不到的错误．146 基本集合的元素名与模型中的变量名重名(当前版本的LINGO中这本来是允许的，但如果通过“LING0|0ptions”命令在“General Solver”选项卡选择“Check forduplicates name s in data and model”，则会检查重名，这主要是为了与以前的LINGO版本兼容) 147 @WARN函数中的条件表达式中只能包含固定变量148 @OLE函数在当前操作系统下不能使用(只在Windows操作系统下可以使用)149 (该错误编号目前没有使用)150 @ODBC函数在当前操作系统下不能使用(只在Windows操作系统下可以使用)151 @POINTER函数在当前系统下不能使用(只在Windows操作系统下可以使用)152 输入的命令在当前操作系统下不能使用153 集合的初始化(定义元素)不能在初始段中进行，只能在集合段或数据段进行154 集合名只能被定义一次155 在数据段对集合进行初始化(定义元素)时，必须显示地列出所有元素，不能省略元素156 在数据段对集合和(或)变量进行初始化时，给出的参数个数不符157 @INDEX函数引用的集合名不存在158 当前函数需要集合的成员名作为参数159 派生集合中的一个成员(分量)不是对应的父集合的成员160 数据段中的一个语句不能对两个(或更多)的集合进行初始化(定义元素)161 (该错误编号目前没有使用)162 电子表格文件中指定的单元范围内存在不同类型的数据(即有字符，又有数值)，LINGO无法通过这些单元同时输入(或输出)不同类型的数据163 在初始段对变量进行初始化时，给出的参数个数不符164 模型中输入的符号名不符合LINGO的命名规则165 当前的输出函数不能按集合进行输出166 不同长度的输出对象无法同时输出到表格型的文件(如数据库和文本文件)167 在通过Excel进行输入输出时，一次指定了多个单元范围168 @DUAL，@RANGEU，@RANGED函数不能对文本数据(如集合的成员名)使用，而只能对变量和约束行使用169 运行模型时才输入集合成员是不允许的170 LINGO系统的密码输入错误，请重新输入171 LINGO系统的密码输入错误，系统将以演示版方式运行172 LINGO的内部求解程序发生了意想不到的错误(请与LINDO 公司联系解决这个问题)173 内部求解程序发生了数值计算方面的错误174 LINGO预处理阶段(preprocessing)内存不足175 系统的虚拟内存不足176 LINGO后处理阶段(postprocessing)内存不足177 为集合分配内存时出错(如内存不足等)178 为集合分配内存时堆栈溢出179 将MPS格式的模型文件转化成LINGO模型文件时出现错误(如变量名冲突等)180 将MPS格式的模型文件转化成LINGO模型文件时，不能分配内存(通常是内存不足181 将MPS格式的模型文件转化成LINGO模型文件时，不能生成模型(通常是内存不足)182 将MPS格式的模型文件转化成LINGO模型文件时出现错误(会给出出错的行号)183 LINGO目前不支持MPS格式的二次规划模型文件184 敏感性分析选项没有激活，敏感性分析不能进行(可通过“LINGO|Options”命令对General Solver选项卡中的“Dual Computation”选项进行修改)185 没有使用内点法的权限(LINGO中的内点法是选件，需要额外购买)186 不能用@QRAND函数对集合进行初始化(定义元素)187 用@QRAND函数对属性进行初始化时，一次只能对一个属性进行处理188 用@QRAND函数对属性进行初始化时，只能对稠密集合对应的属性进行处理189 随机函数中指定的种子(SEED)无效190 用隐式方法定义集合时，定义方式不正确191 LINDOAPI返回了错误(请与LINDO公司联系解决这个问题) 192 LINGO不再支持@WKX函数，请改用@OLE函数193 内存中没有当前模型的解(模型可能还没有求解，或者求解错误)194 无法生成LINGO的内部环境变量(通常是因为内存不足) 195 写文件时出现错误(如磁盘空间不足)196 无法为当前模型计算对偶解(这个错误非同寻常，欢迎你将这个模型提供给LINDO公司进行进一步分析)197 调试程序目前不能处理整数规划模型198 当前二次规划模型不是凸的，不能使用内点法，请通过“LINGO[Options，’命令取消对二次规划的判别199 求解二次规划需要使用内点法，但您使用的LINGO版本没有这个权限(请通过“LINGO|Options”命令取消对二次规划的判别) 200 无法为当前模型计算对偶解，请通过“LINGO|Options”命令取消对对偶计算的要求201 模型是局部不可行的202 全局优化时，模型中非线性变量的个数超出了全局优化求解程序的上限203 无权使用全局优化求解程序204 无权使用多初始点求解程序205 模型中的数据不平衡(数量级差异太大)206 “线性化”和“全局优化”两个选项不能同时存在207 缺少左括号208 @WRITEFOR函数只能在数据段出现209 @WRITEFOR函数中不允许出现关系运算符210 @WRITEFOR函数使用不当211 输出操作中出现了算术运算错误212 集合的下标越界213 当前操作参数不应该是文本，但模型中指定的是文本214 多次对同一个变量初始化215 @DUAL，@RANGEU，@RANGED函数不能在此使用(参阅错误代码“168”)216 这个函数应该需要输入文本作为参数217 这个函数应该需要输入数值作为参数218 这个函数应该需要输入行名或变量名作为参数219 无法找到指定的行220 没有定义的文本操作221 @WRITE或@WRITEFOR函数的参数溢出222 需要指定行名或变量名223 向Excel文件中写数据时，动态接收单元超出了限制224 向Excel文件中写数据时，需要写的数据的个数多于指定的接收单元的个数225 计算段(CALC)的表达式不正确226 不存在默认的电子表格文件，请为@OLE函数指定一个电子表格文件227 为APISET命令指定的参数索引不正确228 通过Excel输入输出数据时，如果LINGO中的多个对象对应于Excel中的名，则列数应该一致229 为APISET命令指定的参数类型不正确230 为APISET命令指定的参数值不正确231 APISET命令无法完成232 (该错误编号目前没有使用)1000 (错误编号为1000以上的信息，只对Windows系统有效) 1001 LINGO找不到与指定括号匹配的括号1002 当前内存中没有模型，不能求解1003 LINGO现在正忙，不能马上响应您的请求1004 LINGO不能写LOG(日志)文件，也许磁盘已满1005 LINGO不能打开指定的LOG(日志)文件1006 不能打开文件1007 没有足够内存完成命令1008 不能打开新窗口(可能内存不够)1009 没有足够内存空间生成解答报告1010 不能打开Excel文件的链接(通常是由于系统资源不足) 1011 LINGO不能完成对图形的请求1012 LINGO与ODBC连接时出现错误1013 通过OBDC传递数据时不能完成初始化1014 向Excel文件传递数据时，指定的参数不够1015 不能保存文件1016 Windows环境下不支持Edit命令，请使用File|Open菜单命令9999 由于出现严重错误，优化求解程序运行失败（最可能的原因是数学函数出错，如函数@LOG(X-1)当X<=1时就会出现这类错误）11。

principles of model checkingModel checking is a formal verification technique used to check whether a model of a system meets a desired property or specification. The principles of model checking include:1. Formal specification: The desired property or behavior of the system is formally specified using a temporal logic language, such as linear temporal logic (LTL) or computational tree logic (CTL). This specification serves as the basis for model checking.2. Finite-state model: The system is modeled as a finite-state model, which consists of a set of states and transitions between states. This model captures the behavior of the system's components and their interactions.3. State space exploration: The state space of the model is systematically explored to check whether the desired property holds for all possible system executions. This involves generating and evaluating the possible execution paths of the system.4. Verification algorithm: A verification algorithm is used to traverse the state space and check the specified property at each state. Model checking algorithms, such as depth-first search or breadth-first search, are typically used for this purpose.5. Counterexample generation: If the desired property does not hold, the model checking process can generate a counterexample, which is a specific sequence of system states and transitions that violates the property. This provides insights into the specific causes of the violation and helps in debugging and refinement.6. Scalability: Model checking can be applied to both small-scale and large-scale systems. To handle complex systems, various techniques such as abstraction, symmetry reduction, and partial order reduction are used to reduce the size of the state space and make the verification process more efficient.7. Automation: Model checking is largely an automated process, where computer tools are used to systematically explore the state space and check the specified property. This helps in reducing human error and makes the verification process more reproducible and reliable.8. Soundness and completeness: Model checking aims to provide sound and complete results. Soundness means that if the model checker reports that the property holds, then it indeed holds in all possible executions of the system. Completeness means that if the property does not hold, the model checker will eventually find a counterexample.By following these principles, model checking provides a systematic and rigorous approach to verify the correctness of system models, which has applications in various domains such as software engineering, hardware design, and protocol verification.。

Verification of multiagent systems via ordered binary decision diagrams:an algorithm and its implementationFranco Raimondi,Alessio LomuscioDepartment of Computer ScienceKing’s College LondonLondon,UKemail:franco,alessio@AbstractWe investigate the problem of the verification of epis-temic properties of multiagent systems via model checking. Specifically,we extend and adapt methods based on ordered binary decision diagrams,a mainstream verification tech-nique in reactive systems.We provide an algorithm,and present a software package that implements it.We discuss the software and benchmark it by means of a standard ex-ample in the literature,the dining cryptographers.1.IntroductionTheories for multiagent systems(MAS)are traditionally concerned with the problem of specification of agents,and it is only recently that attention is given to the problem of ver-ification of multiagent systems.Verification is a mainstream topic of research in traditional Software Engineering,where attention is given both to the broad topics of testing and formal verification.Formal verification encompasses two main approaches:theorem proving,and model checking. Theorem-proving-based approaches involve specifying a program by means of a formal logic system;the problem of checking whether the program in question displays a cer-tain behaviour is translated into the problem of checking whether a particular formula,representing the property to be checked,is a theorem of the logic.One of the problems of the theorem-proving approach is that often the logics in-volved are computationally very demanding,hindering the feasibility of the approach.More recently,model checking has been presented as an alternative to theorem proving in hardware and software verification.In this paradigm a system is represented as a temporal model by means of a program(representing )written in a model-checking friendly language such as SMV.The property to be checked is written as a formula in temporal logic.Checking whether system satis-fies property amounts then to checking formally whether the model satisfies the formula:.The main problem with this approach is to manage the so called ”state explosion problem”,i.e.,the fact that typically a sys-tem generates so many states(figures in the region of10 are possible even for relatively simple systems)that it is difficult to represent them.In attempt to solve this,sym-bolic approaches have been developed.In these,the tem-poral model is represented in a symbolic way by means oflogical structures.The leading technique in this effort uses ordered binary decision diagrams or,in short,OBDD’s[5]. Mainstream model checking packages such as VIS[1]and SMV[13]use this technique.Other techniques,notably SAT-based such as bounded model checking[3]and unbounded model checking[14],have proven to be very promising.While several proposal for model checking MAS have been put forward,none of them uses OBDD’s technol-ogy directly1.In[24],M.Wooldridge et al.present the MABLE language for the specification of MAS.In this work,modalities are translated into nested data structures (in the spirit of[2]).Bordini et al.[4]use a modified ver-sion of the AgentSpeak(L)language[21]to specify agents and to exploit existing model checkers.Both the works of M.Wooldridge et al.and of Bordini et al.translate the spec-ification into a SPIN specification to perform the verifica-tion.Effectively,the attitudes for the agents are reduced to predicates,and the verification involves only the temporal verification of those.In[20]a tool is provided to translate an interpreted system into SMV code,but the verification is limited to static epistemic properties,i.e.the temporal di-mension is not present,and the approach is not fully sym-bolic.The works of van der Meyden and Shilov[15],and van der Meyden and Su[16],are concerned with verifica-tion of interpreted systems.They consider the verification ofa particular class of interpreted systems,namely the class ofsynchronous distributed systems with perfect recall.An al-gorithm for model checking is introduced in thefirst paperusing automata,and[16]suggests the use of OBDD’s forthis approach,but no algorithm or implementation is pro-vided.The research presented in this paper is an attempt tofillthis gap by showing how it is possible to extend the main-stream verification technique in reactive systems—modelchecking via OBDD’s—to verify key properties of MAS.State-of-the-art MAS theories account for a variety of at-titudes of the agents,such as their knowledge,beliefs,de-sires,as well as their temporal evolution.All these attitudesare expressed in MAS logics by means of modal opera-tors[23].OBDD’s-based techniques for reactive systems al-low for the verification of properties expressed in plain tem-poral logic,either in its LTL or in CTL variants.This means that they cannot readily be employed for the verification ofMAS,where richer formalisms are needed.In this paper we look at the case of knowledge,extend OBDD’s-based tech-nology to verify temporal-epistemic properties of a MAS,treating both sets of operators on the same level.We carry out this investigation for the case of knowledge because ofits traditional key importance in MAS,but clearly we wouldlike to extend our approach to include other modalities of in-terest.The paper is organised as follows.In Section2,we intro-duce basic syntax and semantics of epistemic logic on in-terpreted systems as well as the basic definitions for modelchecking via ordered binary decision diagrams.In Section3we present a model checking algorithm for temporal epis-temic logic based on OBDD’s.In Section4we present animplementation of this algorithm.In Section5,we test the correctness and evaluate the performance of the implemen-tation with a traditional example from the security literature—the dining cryptographers–that generates a state space in the region of10states.2.PreliminariesIn this section we introduce the main concepts and the notation that we are going to use in the rest of the paper.In Section2.1we review symbolic model checking using OBDD’s.In Section2.2we present the formalism of inter-preted systems for modelling temporal-epistemic propertiesof multi-agent systems.2.1.Symbolic model checking and OBDD’sThe problem of model checking can be defined as es-tablishing whether or not a model satisfies a formula ().Though could be a model for any logic,tra-ditionally the problem of building tools to perform model checking automatically has been investigated almost only for temporal logics.This is because temporal logic has been identified for more than two decades as an adequate formal-ism to reason about properties of reactive systems Thus,to verify that a system complies with a certain property,one can represent the system by means of a(temporal)model and the property by means of a(temporal)logic formula ,and then check whether or not.There are various temporal logics that can be used to ab-stract reactive systems.Here we introduce CTL[12],a logic used to reason about the evolution of a system represented as a branching paths.Given a countable set of propositional variables,CTL formulae are defined as fol-lows:where the temporal operator means in the next state, means globally and means until.Each temporal opera-tor is pre-fixed by the existential quantifier.Thus,for ex-ample,means that“there exists a path in which is globally true”.Traditionally,other operators are added to the syntax of CTL,namely(no-tice the“universal”quantifier over paths,dual of). These operators can be derived from the operators intro-duced here[12].The semantics of CTL is given via a modelwhere is a set of states, is a binary relation,is an evalua-tion function,and is a set of initial states.A path is a sequence of states such that and.A state in a path is denoted with.Satisfaction in a state is defined inductively as fol-lows:iff,iff there exists a path such thatand,iff there exists a path such thatand for all.iff there exists a path such thatand a such thatand for all.It has been shown[8]that the problem of CTL model checking can be solved in time where.However,this bound assumes that the modelis given explicitly,which is not the case for real-life sys-tems.Instead,the model is usually built via a more succinct representation,for example using a dedicated pro-gramming language such as PROMELA[11]or SMV[13].If this indirect description is considered,the size of the model grows exponentially with the number of variables in the pro-gram,rendering infeasible the explicit representation of the model,a difficulty often referred to as the state explosion problem.To try and overcome this issue,various techniques have been developed to perform symbolic model checking. In symbolic model checking,the algorithms operate on asymbolic representation of the model using automata[11], OBDD’s,[5],and other algebraic structures.By means ofthis techniques state-spaces of the region of have been verified.For the purposes of this paper we consider CTL model checking using OBDD’s,as presented in[9].It has been shown that OBDD’s are a compact representa-tion for boolean functions,and that there are efficient algorithms to perform operations on OBDD’s[5].As an ex-ample,consider the boolean formula.The truth value of this formula can be evaluated by represent-ing the formula using a graph,as in the left hand side of Fig.1.Under certain assumptions,this graph can be sim-plified into the graph pictured on the right-hand side of the same Figure,which is the OBDD for.The key idea of CTL model checking using OBDD’s is to represent states of the model,the temporal relation be-tween states,and the evaluation function by means of boolean formulae.This is done by encoding a state as a boolean vector.Following this,set of states and relations between two states can be expressed by means of boolean formulae.All these boolean parameters are translated into OBDD’s;verification is then conducted by performing oper-ations on them(we refer to[9]for details).This idea has been implemented successfully in a num-ber of software tools such as SMV[13]and NuSMV[7]. Thanks to these tools,large systems have been checked,in-cluding hardware and software components.2.2.Interpreted systemsAn interpreted system[10]is a semantic structure to reason about temporal-epistemic properties of a system of agents.In this formalism,each agent() is characterised by a set of local states and by a set of actions that may be performed.Actions are per-formed in compliance with a protocol(no-tice that this definition allows for non-determinism).A tu-ple,where for each ,is called a global state and gives a snapshot of the system. Given a set of initial global states,the evolution of the sys-tem is described by evolution functions(this definition is equivalent to the definition of a single evolution functionas in[10]):. In this formalism,the environment in which agents“live”is usually modelled by means of a special agent;we re-fer to[10]for more details.The set,the evolution func-tions,and the protocols generate a set of computa-tions(also called runs).A computation is a sequence of global states such that and,for each pair,there exists a set of actions en-abled by the protocols such that.The setdenotes the set of reachable global states.Interpreted systems semantics can be used to interpret formulae of a temporal language enriched with epistemic operators[10].Here we assume a temporal tree structure to interpret CTLK formulae[18],an extension of CTL that includes epistemic modalities.The syntax of CTLK is de-fined in terms of a countable set of propositional variablesand using the following modalities:The modalities are derived in the standard way.Further,given a set of agents,two group modalities can be introduced:and denote,respec-tively,that every agent in the group knows,and that is common knowledge in the group(see[10]for details).Given a valuation function,sat-isfaction in a global state is defined as follows:iff,iff,iff or,iff there exists a computation such thatand,iff there exists a computation such thatand for all,iff there exists a computation such thatand a such thatand for all,iff,implies,iff,implies,iff,implies, where denotes the global state at place in.The re-lation is an epistemic accessibility relation for agent defined by:iff,i.e.if the lo-cal state of agent is the same in and in(notice that this is an equivalence relation).The relation be-tween two global states holds iff for some .The relation is the reflexive transitive clo-sure of.3.Symbolic model checking of interpretedsystemsIn this section we present an algorithm based on OBDD’s to verify temporal and epistemic properties of multi-agentsystems,in the spirit of traditional model checking for tem-poral logics.Following the standard approach for model checking CTL formulae,we encode all the parame-ters needed by the algorithm by means of boolean functions (this is explained in Section3.1).Verification of CTLK for-mulae is performed,using these parameters,by means of the algorithm presented in Section3.2.3.1.Translation into boolean formulaeWe translate an interpreted system into a set of boolean formulae,starting with the local states of an agent;these can be encoded by means of boolean variables.Given ,a global state can be identified by means of boolean variables:.Similarly,given,joint actions can be encoded by means of boolean variables:.The evaluation function associates a set of global states to each proposi-tional atom,and so it can be translated into a boolean func-tion.Also,the protocols,can be expressed as boolean func-tions relating local states and actions.The definition of in Section2.2can be seen as specifying a list of condi-tions under which agent changes the value of its local state.Each has the form“if[conditions on global state and actions]then[value of“next”local state for]”.Hence,is expressed as a boolean formula as fol-lows:,i.e.we impose that one and only one condition must hold.We assume that the last condition prescribes that,if none of the condi-tions on global states and actions in is true,then the local state for does not change.This assumption is key to keep compact the description of an interpreted system,as in this way only the conditions that are actually causing a change need to be listed.The algorithm presented in Section3.2requires the def-inition of a boolean function representing a tem-poral relation between and.can be obtained from the evolution function as follows.First,we intro-duce a global evolution function:.No-tice that is a boolean function involving two global states, by means of their local states components,and joint ac-tions.To abstract from joint actions,and obtain a boolean func-tion relating two global states only,we can define as fol-lows:iff is true and each local action is enabled by the protocol of agent in the local state.The quantification over actions can be translated into a propositional formula using a disjunc-tion(see[13,9]for a similar approach to boolean quantifi-cation):where is a boolean formula imposing that the joint action must be consistent with the agents’protocols in global state.The formula above gives the desired boolean relation between global states.3.2.The algorithmIn this section we present the algorithm to compute the set of global states in which a CTLK formula holds.The following are the parameters needed by the al-gorithm:the boolean variables andto encode global states and joint actions;the boolean functions to encode the protocols of the agents;the boolean function to encode the temporal transi-tion;the function returning the set of global states in which the atomic proposition holds.We assume that the global states are returned encoded as a boolean function of;the set of initial states,encoded as a boolean func-tion;the set of reachable states.This can be computed as thefix-point of the operatorwhere is true if is an initial state and denotes a set of global states.Thefix-point of can be computed by it-erating by standard procedure(see[13]);the boolean functions to encode the accessibility relations(these functions are easily defined using equivalence on local states of);the boolean function to encode,defined by.The algorithm is as follows:is an atomic formula:return;is:return;is:return;is:return;is:return;is:return;is:return;is:return;is:return;In the algorithm above,,,are the standard procedures for CTL model checking[12], in which the temporal relation is and,instead of tem-poral states,global states are considered.The procedures ,and are pre-sented below.X=;Y=andreturn Y;X=;Y=andreturn Y;X=;Y=;while(X!=Y)X=Y;Y=and andreturn Y;The procedure is based on the equiva-lence[10]which implies that the set of states satisfying,denoted with,is the great-estfix-point of the(monotonic)operator.Hence,can be obtained by iterating. Notice that all the parameters can be encoded as OBDD’s. Moreover,all the operations inside the algorithms can be performed on OBDD’s.The algorithm presented here computes the set of states in which a formula holds,but we are usually interested in checking whether or not a formula holds in the whole model.can be used to verify whether or not a formula holds in a model by comparing two set of states: the set and the set of reachable states. As sets of states are expressed as OBDD’s,verification in a model is reduced to the comparison of the two OBDD’s forand for.4.ImplementationIn this section we present an implementation of the al-gorithm introduced in Section3.In Section4.1we define a language to encode interpreted systems symbolically,while in Section4.2we describe how the language is translated into OBDD’s as well as the structure of the algorithm.The implementation is available for download[19].4.1.How to define an interpreted systemTo define an interpreted system it is necessary to specify all the parameters presented in Section2.2.In other words, for each agent,we need to represent:a list of local states;a list of actions;a protocol for the agent;an evolution function for the agent.In our implementation,the parameters listed above are pro-vided via a textfile.The formal syntax of a textfile speci-fying a list of agents is as follows:agentlist::=agentdef|agentlist agentdefagentdef::="Agent"IDLstateDef;ActionDef;ProtocolDef;EvolutionDef;"end Agent"LstateDef::="Lstate={"IDLIST"}"ActionDef::="Action={"IDLIST"}"ProtocolDef::="Protocol"ID":{"IDLIST"}";..."end Protocol"EvolutionDef::="Ev:"ID"if"BOOLEANCOND;..."end Ev"IDLIST::=ID|IDLIST","IDID::=[a-zA-Z][a-zA-Z0-9_]*In the definition above,BOOLEANCOND is a string express-ing a boolean condition;we omit its description here and we refer to the source code for more details.To complete the specification of an interpreted system,it is also neces-sary to define the following parameters:an evaluation function;a set of initial states(expressed as a boolean condi-tion);optionally,a set of groups for group modalitiesThe syntax for this set of parameters is as follows:EvaluationDef::="Evaluation"ID"if"BOOLEANCOND;..."end Evaluation"InitstatesDef::="InitStates"BOOLEANCOND;"end InitStates"GroupDef::="Groups"ID"={"IDLIST"}";..."end Groups"Due to space limitations we refer to thefiles available on-line for a full example of specification of an interpreted sys-tem.Formulae to be checked are specified using the following syntaxformula::=ID|formula"AND"formula|"NOT"formula|"EX("formula")"|"EG("formula")"|"E("formula"U"formula")"|"K("ID","formula")"|"GK("ID","formula")"|"GCK("ID","formula")"In the syntax above we denote the operator for“everybody in a group knows”with GK(group knowledge)and the op-erator for common knowledge with GCK(group common knowledge).K denotes knowledge of the agent identified by the string ID.The remaining temporal operators are de-fined in a similar way.Notice that this corresponds to the full CTLK language.4.2.Implementation of the algorithmThe steps from2to6,inside the dashed box,are per-formed automatically upon invocation of the tool.These steps are coded mainly in C++and can be summarised as follows:In step2,the inputfile is parsed using the standard tools Lex and Yacc.In this step various parameters are stored in temporary lists;such parameters include agents’names,local states,actions,protocols,etc.In step3,the lists obtained in step2are traversed to build the OBDD’s for the verification algorithm.OBDD’s are created and manipulated using the CUDD library[22].In this step the number of variables needed to represent local states and actions are computed;fol-lowing this,all the OBDD’s are built by translating the boolean formulae for protocols,evolution functions, evaluation,etc.Also,the set of reachable states is com-puted using the operator presented in Section3.2.In steps4,the formulae to check are read from a text file,and parsed.In step5,verification is performed by implementing the algorithm of Section3.2.At the end step5,an OBDD representing the set of states in which a formula holds is computed.In step6,the set of reachable states is compared with the OBDD corresponding to each formula.If they are equivalent,the formula holds in the model and the tool produces a positive output.Otherwise,the tool pro-duces a negative output.5.Examples and experimental resultsIn this section we test our tool by model-checking temporal-epistemic properties of a communication sce-nario:the protocol of the dining cryptographers.In[6] it is shown that there exists a protocol that allows for the change in the knowledge of the participants about some global property of the system,without them be-ing able to detect the source of this information.In Sec-tion5.1we describe how the example can be modelled by means of an interpreted system.In Section5.2we pro-vide an evaluation of the performance of our tool on this example.5.1.The interpreted system of the dining cryptog-raphersThe protocol of the dining cryptographers is introduced in[6]with the following example:“Three cryptographers are sitting down to dinner at their favourite three-star restaurant.Their waiter informs them that arrangements have been made with the maitre d’hotel for the bill to be paid anonymously.One of the cryptogra-phers might be paying for the dinner,or it might have been NSA(U.S.National Security Agency).The three cryptogra-phers respect each other’s right to make an anonymous pay-ment,but they wonder if NSA is paying.They resolve their uncertainty fairly by carrying out the following protocol: Each cryptographerflips an unbiased coin behind his menu,between him and the cryptographer on his right,so that only the two of them can see the outcome.Each cryp-tographer then states aloud whether the two coins he can see–the one heflipped and the one his left-hand neigh-bourflipped–fell on the same side or on different sides.If one of the cryptographers is the payer,he states the oppo-site of what he sees.An odd number of differences uttered at the table indicates that a cryptographer is paying;an even number indicates that NSA is paying(assuming that the din-ner was paid for only once).Yet if a cryptographer is pay-ing,neither of the other two learns anything from the utter-ances about which cryptographer it is.”[6]Notice that the same protocol works for any number of cryptographers greater or equal to three(see[6]).We introduce three agents()to model the three cryptographers,and one agent for the environ-ment.In our representation the environment is used to selectnon-deterministically the identity of the payer and the re-sults the of coin tosses.This makes a total of32possible lo-cal states for the environment We assume that the environ-ment can perform only one action,the null action.There-fore,the protocol is simply mapping every local state to the null action.Also,there is no evolution of the local states for the environment.We model the local states of the cryptogra-phers as a string containing three parameters:whether or not the coins that a cryptographer can see are equal,whether or not the cryptographer is the payer,and the number of“dif-ferent”utterances.Considering that all these parameters are not initialised at the beginning of the run,there are27possi-ble combinations of these,hence27possible local states are required.For each cryptographer,the actions allowed are “say nothing”,“say equal”,“say different”,and these ac-tions are performed in compliance with the protocol stated above.We refer to the code for the details of the protocol and of the evolution function.We define the following set of atomic propositions(is a global state):if Paidif Paidif Paidif Even for everyif Odd for everyPaid denotes a local state in which the string contains the value Paid(i.e.the cryptographer paid for the dinner). Even and Odd are defined similarly.We can now express formally various properties of this interpreted sys-tem.For example:This formula expresses the claim made at the beginning of this section:if thefirst cryptographer did not pay for the dinner and there is an odd number of differences in the ut-terances,then thefirst cryptographer knows that either the second or the third cryptographer paid for the dinner;more-over,in this case,thefirst cryptographer does not know which one of the remaining cryptographers is the payer.Analogously,it is possible to check that,if a cryptogra-pher paid for the dinner,then there will be an odd number of“different”utterances,that is:Consider now the group of the three cryptographers. An interesting property is the following:This formula expresses the fact that,in presence of an even number of“different”utterances,it is common knowledge that none of the cryptographers paid for the dinner.Hence, in this protocol common knowledge can be achieved.All these formulae were correctly verified by the tool.5.2.Experimental resultsWe have encoded the interpreted system introduced in the previous section by means of the language defined in Section4.1(a copy of the code is included in the downlod-ablefiles).In this section we evaluate some experimental results.First,we define the size of the interpreted system.In Section2.1the size of a model has been defined as,where is the set of states and is the temporal relation.Here we define as the number all the possible combinations of local states and actions.For the example in Section5.1,there are32local states for the en-vironment,27local states and3actions for each cryptogra-pher;hence,.To define we must take into account that,besides the temporal relation,there are also the epistemic relations.Hence,we define as the sum of the sizes of temporal and epistemic relations.We approximate as,hence.To evaluate the performance of the tool,we consider the running time and the memory requirements.The run-ning time is the sum of the time required for building all the OBDD’s for the parameters and the actual running time for the verification.To quantify the memory requirements we consider the maximum number of nodes allocated for OBDD’s.Notice that thisfigure over-estimates the number of nodes required to encode the state space and the rela-tions.Also,we report the total memory used by the tool (in MBytes).We ran the tool on a1.2GHz AMD Athlon with256MBytes of RAM,running Debian Linux with ker-nel2.4.20.The average experimental results are reported in Tables1and2.We tested the formulae presented in Section—5.1(more tests can be found in[19]);they were all correctly verified All the formulae require a similar amounts of memory.The required time for the construc-tion of OBDD’s isfixed(32sec);the verification time ranges from1.5sec for small formulae to3.5sec for formulae in-volving nested modalities.We see these as very encouraging results.We have been able to check formulae with temporal and epistemic modal-ities in a few seconds on a standard PC,for a fairly large model.Moreover,our implementation does not include any optimisation technique[9].Therefore,we estimate that our tool could perform well even in bigger scenarios.For the same reason,we estimate that it is possible to include other modal operators,besides the temporal and epistemic ones.。

第1章关于 Abaqus 基本知识的常见问题第一篇基础篇第1章关于 Abaqus 基本知识的常见问题第1章关于 Abaqus 基本知识的常见问题1.1 Abaqus 的基本约定1.1.1 自由度的定义【常见问题1-1】Abaqus 中的自由度是如何定义的？1.1.2 选取各个量的单位【常见问题1-2】在 Abaqus 中建模时，各个量的单位应该如何选取？1.1.3 Abaqus 中的时间【常见问题1-3】怎样理解 Abaqus 中的时间概念？第1章关于 Abaqus 基本知识的常见问题1.1.4 Abaqus 中的重要物理常数【常见问题1-4】Abaqus 中有哪些常用的物理常数？1.1.5 Abaqus 中的坐标系【常见问题1-5】如何在 Abaqus 中定义局部坐标系？1.2 Abaqus 中的文件类型及功能【常见问题1-6】Abaqus 建模和分析过程中会生成多种类型的文件，它们各自有什么作用？ 【常见问题1-7】提交分析后，应该查看 Abaqus 所生成的哪些文件？1.3 Abaqus 的帮助文档1.3.1 在帮助文档中查找信息【常见问题1-8】如何打开 Abaqus 帮助文档？第1章关于 Abaqus 基本知识的常见问题【常见问题1-9】Abaqus 帮助文档的内容非常丰富，如何在其中快速准确地找到所需要的信息？1.3.2 在 Abaqus/CAE 中使用帮助【常见问题1-10】Abaqus/CAE 的操作界面上有哪些实时帮助功能？【常见问题1-11】Abaqus/CAE 的 Help 菜单提供了哪些帮助功能？1.4 更改工作路径【常见问题1-12】Abaqus 读写各种文件的默认工作路径是什么？如何修改此工作路径？1.5 Abaqus 的常用 DOS 命令【常见问题1-13】Abaqus 有哪些常用的 DOS 命令？第1章关于 Abaqus 基本知识的常见问题1.6 设置 Abaqus 的环境文件1.6.1 磁盘空间不足【常见问题1-14】提交分析作业时出现如下错误信息，应该如何解决？***ERROR: UNABLE TO COMPLETE FILE WRITE. CHECK THAT SUFFICIENT DISKSPACE IS AVAILABLE. FILE IN USE AT F AILURE IS shell3.stt.（磁盘空间不足）或者***ERROR:SEQUENTIAL I/O ERROR ON UNIT 23, OUT OF DISK SPACE OR DISK QUOTAEXCEEDED.（磁盘空间不足）1.6.2 设置内存参数【常见问题1-15】提交分析作业时出现如下错误信息，应该如何解决？***ERROR: THE SETTING FOR PRE_MEMORY REQUIRES THAT 3 GIGABYTES OR MOREBE ALLOCATED BUT THE HARDWARE IN USE SUPPORTS ALLOCATION OF AT MOST 3GIGABYTES OF MEMORY. EITHER PRE_MEMORY MUST BE DECREASED OR THE JOBMUST BE RUN ON HARDWARE THAT SUPPORTS 64-BIT ADDRESSING.（所设置的pre_memory 参数值超过3G，超出了计算机硬件所能分配的内存上限）或者***ERROR: THE REQUESTED MEMORY CANNOT BE ALLOCATED. PLEASE CHECK THESETTING FOR PRE_MEMORY. THIS ERROR IS CAUSED BY PRE_MEMORY BEINGGREATER THAN THE MEMORY AVAILABLE TO THIS PROCESS. POSSIBLE CAUSES AREINSUFFICIENT MEMORY ON THE MACHINE, OTHER PROCESSES COMPETING FORMEMORY, OR A LIMIT ON THE AMOUNT OF MEMORY A PROCESS CAN ALLOCATE.（所设置的 pre_memory 参数值超出了计算机的可用内存大小）第1章关于 Abaqus 基本知识的常见问题或者***ERROR: INSUFFICIENT MEMORY. PRE_MEMORY IS CURRENTLY SET TO 10.00MBYTES. IT IS NOT POSSIBLE TO ESTIMATE THE TOTAL AMOUNT OF MEMORY THATWILL BE REQUIRED. PLEASE INCREASE THE VALUE OF PRE_MEMORY.（请增大pre_memory 参数值）或者***ERROR: THE VALUE OF 256 MB THAT HAS BEEN SPECIFIED FORSTANDARD_MEMORY IS TOO SMALL TO RUN THE ANALYSIS AND MUST BEINCREASED. THE MINIMUM POSSIBLE VALUE FOR STANDARD_MEMORY IS 560 MB.（默认的standard_memory 参数值为256 M，而运行分析所需要的standard_memory 参数值至少为560 M）1.7 影响分析时间的因素【常见问题1-16】使用 Abaqus 软件进行有限元分析时，如何缩短计算时间？【常见问题1-17】提交分析作业后，在 Windows 任务管理器中看到分析作业正在运行，但 CPU 的使用率很低，好像没有在执行任何工作任务，而硬盘的使用率却很高，这是什么原因？1.8 Abaqus 6.7新增功能【常见问题1-18】Abaqus 6.7 版本新增了哪些主要功能？第1章关于 Abaqus 基本知识的常见问题1.9 Abaqus 和其它有限元软件的比较【常见问题1-19】Abaqus 与其他有限元软件有何异同？第2章关于 Abaqus/CAE 操作界面的常见问题第2章关于Abaqus/CAE 操作界面的常见问题2.1 用鼠标选取对象【常见问题2-1】在 Abaqus/CAE 中进行操作时，如何更方便快捷地用鼠标选取所希望选择的对象（如顶点、线、面等）？2.2 Tools 菜单下的常用工具2.2.1 参考点【常见问题2-2】在哪些情况下需要使用参考点？2.2.2 面【常见问题2-3】面（surface）有哪些类型？在哪些情况下应该定义面？第2章关于 Abaqus/CAE 操作界面的常见问题2.2.3 集合【常见问题2-4】集合（set）有哪些种类？在哪些情况下应该定义集合？2.2.4 基准【常见问题2-5】基准（datum）的主要用途是什么？使用过程中需要注意哪些问题？2.2.5 定制界面【常见问题2-6】如何定制 Abaqus/CAE 的操作界面？【常见问题2-7】6.7版本的 Abaqus/CAE 操作界面上没有了以前版本中的视图工具条（见图2-6），操作很不方便，能否恢复此工具条？图2-6 Abaqus/CAE 6.5版本中的视图工具条第3章Part 功能模块中的常见问题第3章Part 功能模块中的常见问题3.1 创建、导入和修补部件3.1.1 创建部件【常见问题3-1】在 Abaqus/CAE 中创建部件有哪些方法？其各自的适用范围和优缺点怎样？ 3.1.2 导入和导出几何模型【常见问题3-2】在 Abaqus/CAE 中导入或导出几何模型时，有哪些可供选择的格式？【常见问题3-3】将 STEP 格式的三维 CAD 模型文件（*.stp）导入到 Abaqus/CAE 中时，在窗口底部的信息区中看到如下提示信息：A total of 236 parts have been created.（创建了236个部件）此信息表明 CAD 模型已经被成功导入，但是在 Abaqus/CAE 的视图区中却只显示出一条白线，看不到导入的几何部件，这是什么原因？第3章Part 功能模块中的常见问题3.1.3 修补几何部件【常见问题3-4】Abaqus/CAE 提供了多种几何修补工具，使用时应注意哪些问题？【常见问题3-5】将一个三维 CAD 模型导入 Abaqus/CAE 来生成几何部件，在为其划分网格时，出现如图3-2所示的错误信息，应如何解决？图3-2 错误信息：invalid geometry（几何部件无效），无法划分网格3.2 特征之间的相互关系【常见问题3-6】在 Part 功能模块中经常用到三个基本概念：基本特征（base feature）、父特征（parent feature）和子特征（children feature），它们之间的关系是怎样的？第3章Part 功能模块中的常见问题3.3 刚体和显示体3.3.1 刚体部件的定义【常见问题3-7】什么是刚体部件（rigid part）？它有何优点？在 Part 功能模块中可以创建哪些类型的刚体部件？3.3.2 刚体部件、刚体约束和显示体约束【常见问题3-8】刚体部件（rigid part）、刚体约束（rigid body constraint）和显示体约束（display body constraint）都可以用来定义刚体，它们之间有何区别与联系？3.4 建模实例【常见问题3-9】一个边长 100 mm 的立方体，在其中心位置挖掉半径为20 mm 的球，应如何建模？ 『实现方法1』『实现方法2』第4章Property 功能模块中的常见问题第4章 Property 功能模块中的常见问题4.1 超弹性材料【常见问题4-1】如何在 Abaqus/CAE 中定义橡胶的超弹性（hyperelasticity）材料数据？4.2 梁截面形状、截面属性和梁横截面方位4.2.1 梁截面形状【常见问题4-2】如何定义梁截面的几何形状和尺寸?【常见问题4-3】如何在 Abaqus/CAE 中显示梁截面形状？4.2.2 截面属性【常见问题4-4】截面属性（section）和梁截面形状（profile）有何区别?第4章Property 功能模块中的常见问题【常见问题4-5】提交分析作业时，为何在 DAT 文件中出现错误提示信息“elements have missing property definitions（没有定义材料特性）”？『实 例』出错的 INP 文件如下：*NODE1, 0.0 , 0.0 , 0.02, 20.0 , 0.0 , 0.0*ELEMENT, TYPE=T3D2, ELSET=link1, 1, 2*BEAM SECTION, ELSET=link, MATERIAL= steel, SECTION=CIRC15.0,提交分析作业时，在 DAT 文件中出现下列错误信息：***ERROR:.80 elements have missing property definitions The elements have been identified inelement set ErrElemMissingSection.4.2.3 梁横截面方位【常见问题4-6】梁横截面方位（beam orientation）是如何定义的？它有什么作用？【常见问题4-7】如何在 Abaqus 中定义梁横截面方位？【常见问题4-8】使用梁单元分析问题时，为何出现下列错误信息：***ERROR: ELEMENT 16 IS CLOSE TO PARALLEL WITH ITS BEAM SECTION AXIS.第4章Property 功能模块中的常见问题DIRECTION COSINES OF ELEMENT AXIS 2.93224E-04 -8.20047E-05 1.0000. DIRECTIONCOSINES OF FIRST SECTION AXIS 0.0000 0.0000 1.0000。