Znn3bq.jpeg
²é¿´: 825  |  »Ø¸´: 8
µ±Ç°Ö÷ÌâÒѾ­´æµµ¡£
¡¾Óн±½»Á÷¡¿»ý¼«»Ø¸´±¾Ìû×Ó£¬²ÎÓë½»Á÷£¬¾ÍÓлú»á·ÖµÃ×÷Õß dxp5380 µÄ 3 ¸ö½ð±Ò
µ±Ç°Ö»ÏÔʾÂú×ãÖ¸¶¨Ìõ¼þµÄ»ØÌû£¬µã»÷ÕâÀï²é¿´±¾»°ÌâµÄËùÓлØÌû

dxp5380

½ð³æ (ÖøÃûдÊÖ)

[½»Á÷] ¡¾ÇóÖú¡¿¼ÆËãʱ³öÏÖµÄÎÊÌâ

ÓÃABINIT ¼ÆËãʱ³öÏÖÒ»ÏÂÎÊÌ⣬Çë³æÓÑÃǰïæÕÒÒ»ÏÂÔ­Òò£¬¸ÃÈçºÎ½â¾ö¡£³õ´Î½Ó´¥ABINIT£¬Íû´ó¼Ò²»Áߴͽ̣¡Ð»Ð»£¡
-P-0000  kpgsph : BUG -
-P-0000   The variables ikg, mkmem, and mpw  must satisfy ikg<=(mkmem-1)*mpw,
-P-0000   while the arguments of the routine are
-P-0000   ikg =  291671, mkmem =      18, mpw =   16959
-P-0000   Probable cause: Known error in invars1 for parallel spin-polarized case.
-P-0000   Temporary solution: Change the number of parallel processes.
-P-0000
-P-0000  leave_new : decision taken to exit ...
-P-0000  leave_new : synchronization done...
-P-0000  leave_new : exiting...
»Ø¸´´ËÂ¥

» ²ÂÄãϲ»¶

ÒÑÔÄ   »Ø¸´´ËÂ¥   ¹Ø×¢TA ¸øTA·¢ÏûÏ¢ ËÍTAºì»¨ TAµÄ»ØÌû

netx_ray

ľ³æ (СÓÐÃûÆø)

¡ï ¡ï ¡ï ¡ï ¡ï
zxzj05(½ð±Ò+2,VIP+0):3Q! ¹ÄÀøÌÖÂÛ£¡ 10-13 13:53
dxp5380(½ð±Ò+3,VIP+0):²»Ì«Ã÷°×£¡Ð»Ð»Ä㣡 10-13 14:33
ABINITµÄmaillistÓÐÈËÌáµ½¹ýÕâ¸öÎÊÌ⣬ÊÇgetcell ºÍgetxred ÒýÆðµÄ

Dear Colleagues, I have identified a bug in kpgsph.F90 (or else, a bug in how
it's called) which arises when getcell 1 is used to initiate a calculation
given the optimized cell from a previous run.

The problem arises in the calculation of the number of planewaves npw. At about
line 390 is the line npw=ig, where ig was calculated in the above loops. The
variable npw is then used later in several places involving the array kg_small,
which was dimensioned (3,mpw*np_band). The problem is that in the getcell 1
case, it occurs occasionally to have ig and hence npw exceed mpw, in which case
the program crashes due to array out of bounds.

In the nested loops where ig is computed, there are multiple places where the
array limits are checked for  (see line 273 for example: if (ig <= mpw*np_band)
then...).  However, the value of ig itself is not controlled in this way, so
later when npw=ig is set, it can be that npw is too big for the array.

I have implemented the following work-around (wouldn't call it a bug fix
because it seems too dirty):

npw=ig is replaced by

if (mpw*np_band > 0 .and. ig > mpw*np_band) then
npw=mpw
else
npw=ig
endif

this works but I'm not sure it's quite the proper thing to do. To be honest I
don't really understand the calculation of ig leading up to this point so there
might be unintended consequences of this assignment.

Please note that this is not a failure to use dilatmx in the second
calculation, the code requires you in the getcell = 1 case to use a big enough
dilatmx to account for the changes to acell that occured in the optimization.
So in other words I use dilatmx in both the optimization and subsequent
calculations using getcell 1.

I would appreciate comments and clarifications.
9Â¥2009-10-13 11:02:44
ÒÑÔÄ   »Ø¸´´ËÂ¥   ¹Ø×¢TA ¸øTA·¢ÏûÏ¢ ËÍTAºì»¨ TAµÄ»ØÌû
²é¿´È«²¿ 9 ¸ö»Ø´ð

casjxm

Í­³æ (ÕýʽдÊÖ)

¡ï ¡ï
dxp5380(½ð±Ò+1,VIP+0):лл 8-29 15:53
zxzj05(½ð±Ò+1,VIP+0):3Q! ¹ÄÀøÌÖÂÛ£¡ 10-13 13:52
¸öÈ˹۵㣺 ¿ÉÄÜÓëʹÓõĺËÊýÓйأ¬ÎÒÔøËãÁËÒ»¸ö¶«Î÷£¬³¬¹ý10¸öºË£¬Ëã×ÅËãמͻá³ö´í£¬ÉèÖÃСÓÚ10¸öºË¾ÍûÎÊÌâÁË¡£
2Â¥2009-08-29 14:52:13
ÒÑÔÄ   »Ø¸´´ËÂ¥   ¹Ø×¢TA ¸øTA·¢ÏûÏ¢ ËÍTAºì»¨ TAµÄ»ØÌû

dxp5380

½ð³æ (ÖøÃûдÊÖ)

¡ï ¡ï
fegg7502(½ð±Ò+2,VIP+0):¹ÄÀø½»Á÷2 8-30 17:06
ÎҸоõ²»ÊÇcpuÊýÁ¿µÄÔ­Òò¡£ÎÒÁ¬ÐøÓÅ»¯¹ý£¬
ndtset 3  getcell -1  getxred -1
  ngkpt1 8 8 8
  ngkpt2 10 10 10
  ngkpt3 12 12 12
Ò»ÇÐÕý³£¡£µ«ÔÚÏÂÃæµÄ¼ÆËãÖгöÏÖÁËÎÊÌ⣺
ndtset 4  getcell -1  getxred -1
strtarget1
strtarget2
strtarget3
strtarget4
(ºóÃæ¾ßÌåµÄÊý¾Í²»ÁÐÁË£©
Ö»ËãÁËÒ»²½£¬¾Í³öÏÖÁËÉÏÃæµÄÎÊÌâ¡£ÇëÎÊ£ºÔÚÕâÖÖÇé¿öϵÄÓÅ»¯²ÎÊýÈçºÎÉ裿Èçoptcell£¬ionmov£¬iscfµÈ¡£ÁíÍ⻹ÐèÒªÄÇЩ²ÎÊý£¿Ð»Ð»£¡
4Â¥2009-08-29 16:19:23
ÒÑÔÄ   »Ø¸´´ËÂ¥   ¹Ø×¢TA ¸øTA·¢ÏûÏ¢ ËÍTAºì»¨ TAµÄ»ØÌû

zxzj05

ÈÙÓþ°æÖ÷ (ÖøÃûдÊÖ)

¡ï ¡ï ¡ï
freshgirl(½ð±Ò+1,VIP+0):лл²ÎÓë~ 9-16 22:09
dxp5380(½ð±Ò+2,VIP+0):лл 9-23 08:17
The variables ikg, mkmem, and mpw  must satisfy ikg<=(mkmem-1)*mpw,
¿ÏÄÜÊDzÎÊýÖ®¼äµÄÉèÖÃÓгåÍ»
´¢Çâ¼Ò×å»¶Ó­´¢ÇâÑо¿Õߣ¡
6Â¥2009-09-16 21:34:19
ÒÑÔÄ   »Ø¸´´ËÂ¥   ¹Ø×¢TA ¸øTA·¢ÏûÏ¢ ËÍTAºì»¨ TAµÄ»ØÌû
×î¾ßÈËÆøÈÈÌûÍÆ¼ö [²é¿´È«²¿] ×÷Õß »Ø/¿´ ×îºó·¢±í
[¿¼ÑÐ] 314Çóµ÷¼Á +9 weltZeng 2026-04-09 9/450 2026-04-09 18:45 by vgtyfty
[¿¼ÑÐ] Ò»Ö¾Ô¸Öпƴó070300»¯Ñ§£¬314·ÖÇóµ÷¼Á +11 wakeluofu 2026-04-09 11/550 2026-04-09 18:03 by lijunpoly
[¿¼ÑÐ] 085501»úеӢ¶þ77×Ü·Ö294Çóµ÷¼Á£¬½ÓÊÜ¿çרҵѧϰ +6 ÊØ·¨¹«ÃñØÁ¼Í 2026-04-08 6/300 2026-04-09 15:55 by wp06
[¿¼ÑÐ] 085501»úеר˶ 302·Ö ²»ÌôרҵÇóµ÷¼Á +5 Íôij. 2026-04-09 5/250 2026-04-09 15:38 by ½¯ð©Óí
[¿¼ÑÐ] ²ÄÁÏ¿¼ÑÐÇóµ÷¼Á×Ü·Ö280 +30 mkjlz1 2026-04-06 35/1750 2026-04-08 21:25 by cyh¡ª315
[¿¼ÑÐ] 324Çóµ÷¼Á +17 ÏëÉÏѧÇóµ÷ 2026-04-03 17/850 2026-04-08 20:04 by ÎÒ¼õ·Ê1
[¿¼ÑÐ] 318Çóµ÷¼Á +5 ÀîÇàɽɽɽ 2026-04-07 5/250 2026-04-07 18:24 by À¶ÔÆË¼Óê
[ÂÛÎÄͶ¸å] Decision: Revise for Editor»¹»áËÍÉóÂð 100+3 CccccccccFD 2026-04-04 5/250 2026-04-07 10:58 by ±±¾©À³ÒðÈóÉ«
[¿¼ÑÐ] Çóµ÷¼Á +4 µçÆøÐ¡Éñͯ 2026-04-04 6/300 2026-04-07 00:14 by guanxin1001
[¿¼ÑÐ] 338Çóµ÷¼Á +4 ÎÒÏëÉϰ¶ii 2026-04-05 4/200 2026-04-06 21:04 by ľ×Ó¾ý1218
[¿¼ÑÐ] ¿¼Ñе÷¼Á +3 WwwwwwwÍÛ 2026-04-06 3/150 2026-04-06 20:55 by lbsjt
[¿¼ÑÐ] »¯Ñ§357·Ö£¬¿¼Ñе÷¼Á +11 .Starry. 2026-04-04 12/600 2026-04-06 06:28 by houyaoxu
[¿¼ÑÐ] 306·Ö²ÄÁÏÓ뻯¹¤Çóµ÷¼Á +7 Àè°ÉÀ²À²ÄãºÜÓÐà 2026-04-03 7/350 2026-04-05 17:18 by Hdyxbekcb
[¿¼ÑÐ] ¹¤¿ÆÇóµ÷¼Á +15 11ggg 2026-04-03 15/750 2026-04-05 16:24 by zzx2138
[¿¼ÑÐ] 333Çóµ÷¼Á +12 wfh030413@ 2026-04-03 13/650 2026-04-04 21:02 by jj987
[¿¼ÑÐ] 338Çóµ÷¼Á +7 êɹ¦? 2026-04-03 7/350 2026-04-04 20:37 by À¶ÔÆË¼Óê
[¿¼ÑÐ] Ò»Ö¾Ô¸¶«±±´óѧ085901ÍÁľר˶345Çóµ÷¼Á +3 zxt11111 2026-04-04 3/150 2026-04-04 14:21 by ÍÁľ˶ʿÕÐÉú
[¿¼ÑÐ] Ò»Ö¾Ô¸ÖйúʯÓÍ´óѧ»¯Ñ§¹¤³Ì323·ÖÇóµ÷¼Á +4 »¯¹¤×¨Ë¶323·Ö 2026-04-03 6/300 2026-04-03 22:12 by dongzh2009
[¿¼ÑÐ] Êý¶þÓ¢¶þ348Çóµ÷¼Á +4 hxdzj1 2026-04-03 5/250 2026-04-03 21:25 by zhq0425
[¿¼ÑÐ] 274Çóµ÷¼Á +9 ˳Àí³ÉÕÅ 2026-04-03 10/500 2026-04-03 15:10 by °¡¿¡£¡
ÐÅÏ¢Ìáʾ
ÇëÌî´¦ÀíÒâ¼û