| 查看: 4398 | 回复: 53 | ||||||
| 【奖励】 本帖被评价40次，作者ghcacj增加金币 32 个 | ||||||
| 本帖产生 1 个 模拟EPI ，点击这里进行查看 | ||||||
[资源]
ghcacj与gtolv8688合力推出Code Music之FAQ
|
||||||
这个FAQ主要是对我在小木虫分子模拟版发的帖子中的答疑，原帖的链接是http://muchong.com/bbs/viewthread.php?tid=1812516，不包括原帖关于我写的更新部分，主要是将虫友提问与我的回答进行汇总集中，这里需要提到虫友gtolv8688，这份FAQ初稿是经过他整理，我在他的基础之上进行一些加工处理，修正了帖子中的一些错误。所以我认为，如果这份FAQ有他的一半的功劳，特此声明下。此版本目前定为1.00版，之后会加入或者删减一些内容，定期推出更新。同时也欢迎大家加入到该FAQ的编辑整理之中。 更新记录： v1.01：将原帖答疑更新至2010-12-29，第65页处。 对所有问答进行整理，原帖经gtolv8688整理后约有150个问答（记为v1.00版，未公布出来），但是其中存在一些价值不高的问答，包括反复提出的问题、由于当时认识不深刻而未能正确回答或者未给出解决方法的问题、以及一些显而易见的问题。因此本次更新对其进行删减精炼，保留其中最精华的部分，同时对原帖语言进行一定精炼（诸如去掉“楼主”，“请教”之类的词语）；对格式进行排版，使其更加整洁。目前提炼出问答共95个，计划在1.02版将问答更新至最新，在1.10版对问答进行分类。 ==================================== 推出这个FAQ目的是方便各位使用code Music的虫友方便查阅问题。 V1.02: 将原帖答疑更新至2011-5-27，第72页处。 新增原帖问答6个，新增自问自答2个，问题总共增至103个。将虫友lmylmy提供的关于A57与A66的其他解决途径新增进去，也欢迎其他虫友加入进来。对现有的部分问题回答进行了更新，使回答变得更加完整（本次更新的回答用下划线表示）。目前暂将8个新增问答放在最后，计划v1.10版时对整个问题的顺序进行条件，届时将增加分类并再增加问答10-15个。[ Last edited by ghcacj on 2011-6-9 at 15:47 ] |
回复此楼» 收录本帖的淘帖专辑推荐
 第一性原理 | 多孔材料 | condensed matter physics | 分子模拟 |
» 猜你喜欢
0703化学336分求调剂
已经有6人回复
-
304求调剂
已经有9人回复
-
293求调剂
已经有13人回复
-
281求调剂（0805）
已经有8人回复
-
环境领域全国重点实验室招收博士1-2名
已经有3人回复
-
材料专硕306英一数二
已经有10人回复
-
301求调剂
已经有6人回复
-
一志愿天津大学化学工艺专业（081702）315分求调剂
已经有7人回复
-
302求调剂
已经有6人回复
-
26博士申请
已经有3人回复
» 本主题相关商家推荐: (我也要在这里推广)
» 本主题相关价值贴推荐，对您同样有帮助:
- mac上安装使用fortran
已经有5人回复
- 第一性原理计算材料光学性质 conductivity
已经有7人回复
- 【笑话一则，轻松一刻47】A Fine Match
已经有27人回复
- 大家用的MUsic是什么版本的
已经有8人回复
- 关于error bounds!!!
已经有6人回复
- R or Fortran?
已经有4人回复
- Windows下编译安装MuSic code
已经有22人回复
- 求助： PDF built error
已经有11人回复
- 【求助】big_mac的问题
已经有6人回复
- 【求助】Segmentation fault
已经有15人回复
- 【分享】excting code helium
已经有11人回复
- 【讨论】请教 intel fortran【已完结】
已经有6人回复
- 【求助成功】Segmentation fault 问题
已经有7人回复
- 【求助】如何根据势能曲线拟合力场参数
已经有19人回复
- 【求助】请问有使用Flexible Atomic Code(FAC)程序包的虫虫吗
已经有13人回复
4楼2011-05-29 01:55:12
★★★★★ 五星级,优秀推荐
★ ★ ★ ★ ★
ghcacj(金币+5): 谢谢你的方法，不知道你的方法是如何得知的，谢谢。 2011-05-30 12:56:53
ghcacj(金币+5): 谢谢你的方法，不知道你的方法是如何得知的，谢谢。 2011-05-30 12:56:53
|
感谢作者的辛勤、无私的贡献。 关于Q57，可以有个其他的解决办法。 Q57：这是 map 运行模块过程中出现的，好像快要结束了，不知道怎么回事 Map progress: 2862000 points calculated 99.96% of total Map progress: 2863000 points calculated 99.99% of total mapmaker.F90 581 total points : 2863288 100.000000000000 段错误 A57：可能是网格划分的太细，将 grid 划分大一些，比如 0.3A 等 我最近也在Linux下折腾Music，但是还没完全成功。我用的操作系统是Ubuntu11.04，最新的Intel fortran XE版。 我重复Tina Durun网页上的IRMOF-1吸附甲烷的例子，生产Pmap的时候遇见了这个问题，开始在AMD的cpu下实验，后来用Intel的CPU实验，都遇到同样的Q57问题。 此问题可以用如下命令来解决： # ulimit -s unlimited 我运行CH4吸附的GCMC时，算了一会就出现错误，也是和段错误相关的，至今还没解决。也可能是编译器的版本问题。 另外斑竹的163盘上的文件都变木马了，可否另找个地方共享一下，谢谢了！ |
6楼2011-05-30 12:47:46
7楼2011-05-30 14:50:24
★ ★ ★ ★ ★ ★ ★ ★
ghcacj(金币+8): 谢谢 2011-06-06 17:02:54
ghcacj(金币+8): 谢谢 2011-06-06 17:02:54
|
从Intel 的网站上得到的信息。 http://software.intel.com/en-us/ ... gmentation+fault%29 Determining Root Cause of SIGSEGV or SIGBUS errors Submit New Article July 23, 2009 9:50 AM PDT Problem : When I run my code compiled with the Intel Fortran Compiler I get 'sigsegv' on linux (or sigbus on Mac OS X). This code has run fine for years on Environment : linux or Mac OS* X Root Cause : There are many possible causes. A segmention fault (bus error Mac OS X) is a general fault that can have multiple causes. We outline these potential causes below and give suggestions for avoiding the segmentation fault Possible Cause #1 Fortran Specific Stackspace Exhaustion: Solution, -heap-arrays compiler option. The Intel Fortran Compiler use stack space to allocate a number of temporary or intermediate copies of array data. NON-OpenMP and NON-Auto-parallelized Applications: IF your program is not using OpenMP or Auto-parallelization (-parallel compiler switch) and your compiler is newer than Linux v9.1.037 (or all Mac OS* compilers), try the -heap-arrays compiler option. OpenMP or Auto-parallelization users and users with Linux compilers older than v9.1.037 please read ahead to Possible Cause #2 for tips on unlimiting the stack size. -heap-arrays If this removes the sigsegv or bus error, you may STOP at this point. You may wish to read the attached PDF presentation (link at bottom of page) to learn about when and where array temporaries are created. With a few code changes you may be able to avoid some array temporaries, and hence reduce your application's need for temporary copies (improves performance). Also, the -heap-arrays compiler option can take an optional argument [size] to specify the threshold size in Kbytes at which arrays larger than [size] are allocated on heap, all others on stack. For example: -heap-arrays 10 puts all automatic and temporary arrays larger than 10Kbytes on heap Cause #2 Stackspace Exhaustion. Solution: Unlimiting Stacksize for OpenMP Applications or any Application: The first step is to try to increase your shell stack limit on Linux and Mac OS* X. However, this option can have unwanted effects on data sharing with OpenMP or auto-parallelized code. Because of this, OpenMP and auto-parallelization users are advised to not use -heap-arrays and insted try to unlimit their shell stack size limit. Linux, bash: ulimit -s unlimited Linux, csh/tcsh: unlimit stacksize You may check your stack size limit with: bash: ulimit -a csh: limit and look for 'stack size' limit for your shell environment Notes: If you run your program under the control of a batch subsystem you may need to add the command above to your user startup files ( ~/.bashrc ~/.profile or ~/.cshrc ) For Mac OS* X, there is a hard upper limit on the shell stacksize. For most systems, this is: bash: ulimit -s 65532 which sets the limit to 64Mbytes. An alternative is to use a linker option to increase the executable's default shell stacksize, as documented here: http://software.intel.com/en-us/ ... segmentation-fault/ Re-run your application, if this fixes the issue you may stop. If your application still generates sigsegv or bus error, continue reading. Possible Cause #3, Stack Corruption Due to User Coding Error. There are a number of user coding errors that can cause stack corruption and lead to a sigsegv or bus error at run time. These errors are particularly hard to find since the segmentation fault may occur later in the program in a section unrelated to where the stack was initially corrupted. The first step is to try to isolate where in the code the fault occurs. This is done by generating an execution 'traceback'. Compile and link using the ifort driver and these options: -g -traceback When the code faults, you will often get a report showing the call stack when the fault occurs. If you do not get a stack traceback, insure that you have used -g for both compilation and link and make sure that -traceback was used on the compilation. There are cases where the seg fault occurs while the program is in kernel space and thus no user stack is available for trace back. We are working to improve this in a future release. This trace back report is read from the bottom of the list upwards. Find the uppermost subroutine or function from your code along with it's line number to isolate which instruction caused the fault. Check for user coding errors at this statement. If no obvious user error, continue below Possible Cause #4, exceeding Array Bound. Solution, try -check bounds The -check-bounds compiler option provides a run-time check of array accesses and character string expressions to insure that the indices are within the boundaries of the array. This checking is useful to find cases where the indices go outside of the declared size of the array. This option has a big impact on performance, the magnitude of which depends on how many array accesses are performed in the application. Also, -check-bounds array bounds checking is not performed for arrays that are dummy arguments in which the last dimension bound is specified as * or when both upper and lower dimensions are 1. To enable bounds checking, compile with: -check bounds -g and run your program. The checking is performed at run time and not at compile time. If this finds your error STOP. ELSE keep reading. Possible Cause #5, calling a function as a subroutine, or invoking a subroutine as if it were a function. These are user coding errors where a user does something similar to this: --- main program --- ... call ThisIsIllegal( some_arguments ) ... --- end main program --- --- ThisIsIllegal --- integer function ThisIsIllegal( some_arguments ) ... --- end ThisIsIllegal --- In the example above, the main program calls ThisIsIllegal as if it were a subroutine, however ThisIsIllegal is declared as a function. This can cause stack corruption. To test for these conditions, try using compiler option -fp-stack-check -g -traceback compile with these options and run. If the stack is corrupted by something similar to the above, your code will exit and give a stack trace. You can check the interfaces of your procedures with a compile time check: -gen-interfaces -warn interfaces This compile time check will generate INTERFACE blocks for your procedures. The -warn interfaces will then use these compiler-generated interfaces and check the calls to your procedures to make sure arguments and interfaces match between caller and callee. Note that this check occurs only for Fortran source files. This will not check interfaces in mixed language program. Possible Cause #6, large array temporaries caused by passing non-contiguous array sections. Solution, detect with -check arg_temp_created and fix with coding change to include explicit interface and assumed shaped arrays. Consider this 'before' example: --- main program --- real(8) :: f(1800,3600,1) external sub ... call sub( f(1:900,:,  )... --- end main program --- and the "sub" subroutine is in a separately compiled source file: --- external subroutine "sub" --- subroutine sub( f ) real(8) :: f(900,3600,1) ... --- end subroutine "sub" --- In this case, "sub" is expecting a contiguous array of size 900x3600x1. However, the call is passing an array that is not contiguous in memory. In situations such as this, the compiler will make an array temporary at the call to copy the elements of the array "f" from non-contiguous chucks into a contiguous array such as what "sub" is expecting. This temporary is allocated on stack unless -heap-arrays is specified. To check if this is occuring in your code, compile with -check arg_temp_created and run the program. Messages will be written when argument temporaries are created. To work around the issue, creating a explicit interface and using an assumed shaped array in "sub" will remove the need for an array temporary: --- main --- real(8) :: f(1800,3600,1) interface subroutine sub(f) real(8) :: f(:,:, end subroutine sub end interface ... call sub( f(1:900,:, )... --- end main program --- --- "sub" --- subroutine sub( f ) real(8) :: f(:,:, ... end subroutine sub Keep in mind, that although this avoids the array temporary, within "sub" the compiler is now aware that the array "f" may be non-contiguous. Thus, some optimizations on statements using "f" may be disabled and thus affect performance. Case NONE OF THE ABOVE: Solution, more in-depth analysis is needed. 99% of the sigsegv or bus error cases tend to fall into the categories above. However, there are other cases where segmentation faults can occur. If your application is linking in external libraries, make sure that the library is compatible with your compiler. Was the external library compiled with the Intel Compiler? If so, were the major versions the same - that is, was the library compiled with Intel Fortran v9.1 but your application built with Intel Fortran v10.x or v11.x? Intel only guarantees compatibility within major versions ( 9, 10, 11 are examples of major versions). If the external library is from a software vendor or tool: does this vendor explicitly name the Intel Compiler as compatible, and if so, with which version(s) have they verified their library? You should only use the version(s) of the Intel Compiler certified by your vendor. If you need an older version of the Intel Compiler, please see How do I get an older version of an Intel(R) Software Development Product. |
8楼2011-06-06 01:27:26
★ ★ ★ ★ ★
ghcacj(金币+5): 谢谢 2011-06-06 17:03:05
ghcacj(金币+5): 谢谢 2011-06-06 17:03:05
|
A66 66:在转换吸附量的时候,所用到的密度不是吸附剂的密度,而是吸附质在对应 P 和 T 下的密度, 这个密度是用状态方程,一般是 PR,也有人有 SRK 计算得到的。 气体的真实密度可以从NIST的网站直接查得：http://webbook.nist.gov/chemistry/fluid/ |
9楼2011-06-06 01:43:41
10楼2011-06-06 08:17:06
12楼2011-06-09 15:48:52
13楼2011-06-27 09:20:52
對於完全沒有基礎的新手，幫助很大！感謝！ 21楼2012-09-20 22:17:52
38楼2014-10-17 15:48:23
简单回复
2011-05-26 23:54
回复
五星好评 
2011-05-28 18:00
回复
五星好评 顶一下，感谢分享！
sophy_065楼
2011-05-30 09:26
回复
五星好评 顶一下，感谢分享！
allenyangzl11楼
2011-06-08 10:57
回复
五星好评 顶一下，感谢分享！
kkou14楼
2011-07-18 19:49
回复
顶一下，感谢分享！
xinji15楼
2011-07-23 11:21
回复
五星好评 顶一下，感谢分享！
badercao16楼
2012-03-29 11:02
回复
顶一下，感谢分享！
sys9917楼
2012-04-28 10:33
回复
五星好评 顶一下，感谢分享！
molvib18楼
2012-06-28 15:19
回复
五星好评 顶一下，感谢分享！
飞天小红猪19楼
2012-08-05 18:25
回复
五星好评 顶一下，感谢分享！
飞天小红猪20楼
2012-08-05 18:25
回复
顶一下，感谢分享！
xinghe9922楼
2012-11-01 14:55
回复
五星好评 顶一下，感谢分享！
star201023楼
2012-12-06 11:04
回复
五星好评 顶一下，感谢分享！
hplc30324楼
2013-01-20 21:50
回复
五星好评 顶一下，感谢分享！
leipei.12325楼
2013-02-02 14:22
回复
五星好评 顶一下，感谢分享！
拍拍熊出隐刀26楼
2013-02-28 15:10
回复
五星好评 顶一下，感谢分享！
hplc30327楼
2013-02-28 15:34
回复
顶一下，感谢分享！
ifmc123428楼
2013-03-06 10:05
回复
五星好评 顶一下，感谢分享！
zhangyan0229楼
2013-03-31 19:06
回复
顶一下，感谢分享！
oxox608530楼
2013-04-12 22:48
回复
五星好评 顶一下，感谢分享！
ifmc123431楼
2013-04-25 18:06
回复
顶一下，感谢分享！
qqdys201232楼
2013-05-08 20:18
回复
五星好评 顶一下，感谢分享！
wl40510390633楼
2013-09-14 20:30
回复
五星好评 顶一下，感谢分享！
qqdys201234楼
2013-09-22 14:58
回复
顶一下，感谢分享！
笑笑愁35楼
2013-10-15 19:40
回复
五星好评 
duandian1236楼
2013-10-26 16:10
回复
五星好评 顶一下，感谢分享！
zhangmingmin37楼
2014-05-15 15:16
回复
五星好评 顶一下，感谢分享！
Ronny_chou39楼
2014-11-02 15:34
回复
五星好评 顶一下，感谢分享！
sprout小萌40楼
2014-11-13 16:16
回复
五星好评 
华叶落尽41楼
2015-01-22 10:47
回复
五星好评 顶一下，感谢分享！
youyno42楼
2015-03-09 21:06
回复
五星好评 顶一下，感谢分享！
jdblll43楼
2015-04-14 11:31
回复
五星好评 顶一下，感谢分享！
xyz199244楼
2015-04-22 14:43
回复
五星好评 顶一下，感谢分享！
sunny1122345楼
2015-05-23 11:34
回复
五星好评 顶一下，感谢分享！
青原行思46楼
2015-07-17 14:36
回复
五星好评 顶一下，感谢分享！
xyz199247楼
2015-09-11 16:30
回复
顶一下，谢谢分享！
zhixiaol48楼
2015-12-19 17:15
回复
五星好评 顶一下，感谢分享！
缘亦是亦不是49楼
2016-03-24 20:03
回复
五星好评 顶一下，感谢分享！
缘亦是亦不是50楼
2016-03-24 20:03
回复
20