I was trying to read firmware from a NAND chip, and extract its program and data for analyse.
From online I learned, you must create an UBI device with your image file write to it, then you can mount it to your system.
Description
First I read a bin file from FLASH chip. binwalk I get this.
$ binwalk -Me Flash_data.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
771180 0xBC46C device tree image (dtb)
772444 0xBC95C device tree image (dtb)
823236 0xC8FC4 CRC32 polynomial table, little endian
2703360 0x294000 uImage header, header size: 64 bytes, header CRC: 0xF092DEF5, created: 2016-10-04 21:32:58, image size: 2773040 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x365DF8B1, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.2.0"
2703424 0x294040 Linux kernel ARM boot executable zImage (little-endian)
2722452 0x298A94 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
8110080 0x7BC000 UBI erase count header, version: 1, EC: 0x2, VID header offset: 0x800, data offset: 0x1000
From its output files, I foun this ubi image file.
$ binwalk 7BC000.ubi
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0x2, VID header offset: 0x800, data offset: 0x1000
$ file 7BC000.ubi
7BC000.ubi: UBI image, version 1
Some information about NAND chip:
PageSize : 2048
SpareSize : 64
PagesPerBlock : 64
Blocks Size : 128KB + 4KB
Total Block : 2048
Device Size : 256MB + 8192KB8192KB
Bus Width : 8
Then I tried to mount it, like this:
$ sudo modprobe mtdblock
$ sudo modprobe nandsim first_id_byte=0x20 second_id_byte=0xac third_id_byte=0x00 fourth_id_byte=0x15
$ mtdinfo /dev/mtd0
mtd0
Name: NAND simulator partition 0
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 4096 (536870912 bytes, 512.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true
$ sudo flash_erase /dev/mtd0 0 0
$ cp 7BC000.ubi test_infile
$ sudo ubiformat /dev/mtd0 -O 2048 -f test_infile
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 4096 eraseblocks are supposedly empty
ubiformat: error!: file "test_infile" (size 268713984 bytes) is not multiple of eraseblock size (131072 bytes)
error 0 (Success)
The size of "test_file" is 0x10044000, so I just remove the last 0x4000 bytes, and tried to ubiformat again.
$ dd if=test_infile of=test_infile_dd bs=268697600 count=1
$ sudo ubiformat /dev/mtd0 -O 2048 -f test_infile_dd
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 4096 eraseblocks are supposedly empty
ubiformat: flashing eraseblock 1 -- 0 % complete ubiformat: error!: bad UBI magic 0xffffffff, should be 0x55424923
ubiformat: error!: bad EC header at eraseblock 1 of "test_infile_dd"
I did some research and found out, in this UBI image, there are many blocks, and every block contains data and OOB.
The reason last command fails because it searchs 0x55424923 at wrong position which is 0x20000, because of OOB, 0x55424923 is actually at 0x21000, so I think perhaps delete all of OOB part from "this_file_dd" might work. The bash command and test as follows.
#!/bin/bash
# ./dump.sh
# pagesize 0x20000
# oob size 0x01000
# block 1
dd if=infile of=test_infile_dd_nooob bs=$((0x20000)) count=1
declare -i i=1
# block others
while ((i<2048))
do
dd if=test_infile of=out bs=$((0x21000)) count=1 skip=$i
dd if=out of=outfile bs=$((0x20000)) count=1
cat outfile >> test_infile_dd_nooob
rm out
rm outfile
let i++
done
After remove all OOB, compare 2 file, and noticed that OOB has been remove.
$ xxd test_infile_dd | grep "5542 4923" ⏎
00000000: 5542 4923 0100 0000 0000 0000 0000 0002 UBI#............
00021000: 5542 4923 0100 0000 0000 0000 0000 0002 UBI#............
00042000: 5542 4923 0100 0000 0000 0000 0000 0001 UBI#............
00063000: 5542 4923 0100 0000 0000 0000 0000 0001 UBI#............
00084000: 5542 4923 0100 0000 0000 0000 0000 0001 UBI#............
$ xxd test_infile_dd_nooob | grep "5542 4923"
00000000: 5542 4923 0100 0000 0000 0000 0000 0002 UBI#............
00020000: 5542 4923 0100 0000 0000 0000 0000 0002 UBI#............
00040000: 5542 4923 0100 0000 0000 0000 0000 0001 UBI#............
00060000: 5542 4923 0100 0000 0000 0000 0000 0001 UBI#............
00080000: 5542 4923 0100 0000 0000 0000 0000 0001 UBI#............
Then ubiformat again, another error about bad UBI magic.
$ sudo ubiformat /dev/mtd0 -O 2048 -f test_infile_dd_nooob
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 1 eraseblocks have valid erase counter, mean value is 0
ubiformat: 4095 eraseblocks are supposedly empty
ubiformat: warning!: only 1 of 4096 eraseblocks have valid erase counter
ubiformat: erase counter 0 will be used for all eraseblocks
ubiformat: note, arbitrary erase counter value may be specified using -e option
ubiformat: continue? (y/N) y
ubiformat: use erase counter 0 for all eraseblocks
ubiformat: flashing eraseblock 1074 -- 54 % complete ubiformat: error!: bad UBI magic 00000000, should be 0x55424923
ubiformat: error!: bad EC header at eraseblock 1074 of "test_infile_dd_nooob"
Used ghex to fix wrong EC header in EB-1074, and ubiformat again, same block's CRC is not right.
sudo ubiformat /dev/mtd0 -O 2048 -f test_infile_dd_nooob -e 10
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 1074 eraseblocks have valid erase counter, mean value is 10
ubiformat: 3022 eraseblocks are supposedly empty
ubiformat: use erase counter 10 for all eraseblocks
ubiformat: flashing eraseblock 1074 -- 54 % complete ubiformat: error!: bad CRC 0x7d72af58, should be 00000000
ubiformat: error!: bad EC header at eraseblock 1074 of "test_infile_dd_nooob"
Fix CRC and ubiformat again, enable ubi and ubiattach to mtd0, but another error occurs.
sudo ubiformat /dev/mtd0 -O 2048 -f test_infile_dd_nooob -e 10 ⏎
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 1074 eraseblocks have valid erase counter, mean value is 10
ubiformat: 3022 eraseblocks are supposedly empty
ubiformat: use erase counter 10 for all eraseblocks
ubiformat: flashing eraseblock 1987 -- 100 % complete
ubiformat: formatting eraseblock 4095 -- 100 % complete
$ sudo modprobe ubi
$ sudo modprobe ubi mtd=0
$ sudo ubiattach -m 0 -O 2048
ubiattach: error!: cannot attach mtd0
error 22 (Invalid argument)
Do dmesg I found this message.
$ sudo dmesg
[ 6974.021149] 0001efa0: 00 00 00 00 00 00 00 00 10 0a 00 00 01 00 00 00 00 0a d9 d5 05 f9 20 a1 63 d7 00 00 00 02 fb d2 ...................... .c.......
[ 6974.021150] 0001efc0: ce 15 00 00 00 0d 00 00 02 00 00 00 04 00 20 00 c7 00 00 00 0d 0d 0d 00 00 00 0b 01 b8 00 03 db .............. .................
[ 6974.021151] 0001efe0: 03 9d 03 5e 03 20 02 fd 02 d8 02 93 02 4e 02 1b 01 f6 01 b8 20 00 7a 14 08 00 32 3b 81 0e 04 17 ...^. .......N...... .z...2;....
[ 6974.023703] ubi0 error: validate_ec_hdr [ubi]: node with incompatible UBI version found: this UBI version is 1, image version is 0
[ 6974.023707] ubi0 error: validate_ec_hdr [ubi]: bad EC header
[ 6974.023707] Erase counter header dump:
[ 6974.023708] magic 0x55424923
[ 6974.023708] version 0
[ 6974.023709] ec 10
[ 6974.023709] vid_hdr_offset 2048
[ 6974.023710] data_offset 4096
[ 6974.023710] image_seq 144665903
[ 6974.023711] hdr_crc 0xb574c34c
[ 6974.023711] erase counter header hexdump:
[ 6974.023713] 00000000: 55 42 49 23 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 08 00 00 00 10 00 08 9f 6d 2f 00 00 00 00 UBI#......................m/....
[ 6974.023713] 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b5 74 c3 4c .............................t.L
[ 6974.023715] CPU: 4 PID: 14955 Comm: ubiattach Tainted: G W E 5.7.0-kali1-amd64 #1 Debian 5.7.6-1kali2
[ 6974.023716] Hardware name: Dell Inc. Inspiron 7472/0GHVRJ, BIOS 1.1.6 06/14/2018
[ 6974.023716] Call Trace:
[ 6974.023722] dump_stack+0x66/0x90
[ 6974.023725] validate_ec_hdr+0x8a/0xe0 [ubi]
[ 6974.023729] ubi_io_read_ec_hdr+0x1e9/0x280 [ubi]
[ 6974.023732] ubi_attach+0x1d3/0x14c0 [ubi]
[ 6974.023736] ubi_attach_mtd_dev+0x5b3/0xd30 [ubi]
[ 6974.023741] ? __get_mtd_device+0x2c/0xa0 [mtd]
[ 6974.023743] ? _cond_resched+0x15/0x30
[ 6974.023746] ctrl_cdev_ioctl+0xda/0x1c0 [ubi]
[ 6974.023748] ksys_ioctl+0x87/0xc0
[ 6974.023749] __x64_sys_ioctl+0x16/0x20
[ 6974.023751] do_syscall_64+0x52/0x180
[ 6974.023753] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6974.023754] RIP: 0033:0x7f3f55902c87
[ 6974.023756] Code: 00 00 00 48 8b 05 09 92 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d9 91 0c 00 f7 d8 64 89 01 48
[ 6974.023756] RSP: 002b:00007ffd4fec6f88 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[ 6974.023757] RAX: ffffffffffffffda RBX: 00007ffd4fec7020 RCX: 00007f3f55902c87
[ 6974.023758] RDX: 00007ffd4fec6fb0 RSI: 0000000040186f40 RDI: 0000000000000003
[ 6974.023758] RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000
[ 6974.023759] R10: fffffffffffff48e R11: 0000000000000206 R12: 000055c2a393c052
[ 6974.023759] R13: 00007ffd4fec6fb0 R14: 0000000000000000 R15: 0000000000000000
[ 6974.023763] ubi0 error: ubi_io_read_ec_hdr [ubi]: validation failed for PEB 1074
[ 6974.061006] ubi0 error: ubi_attach_mtd_dev [ubi]: failed to attach mtd0, error -22
But I don't know how to solve this, so I just remove block 1074 from file.
$ dd if=test_infile_dd_nooob of=test_infile_dd_nooob_no1074_1 bs=131072 count=1074
$ dd if=test_infile_dd_nooob of=test_infile_dd_nooob_no1074_2 bs=131072 skip=1075
$ cat test_infile_dd_nooob_no1074_1 test_infile_dd_nooob_no1074_2 > test_infile_dd_nooob_no1074
Then ubiformat and attach again, but there was another error.
$ sudo ubiformat /dev/mtd0 -O 2048 -f test_infile_dd_nooob_no1074 -e 10
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 4096 eraseblocks have valid erase counter, mean value is 10
ubiformat: use erase counter 10 for all eraseblocks
ubiformat: flashing eraseblock 1986 -- 100 % complete
ubiformat: formatting eraseblock 4095 -- 100 % complete
$ sudo ubiattach -m 0 -O 2048 ⏎
ubiattach: error!: cannot attach mtd0
error 22 (Invalid argument)
Check dmesg and found this, this is where I don't know how to do, I don't know how I get so many bad blocks.
$ sudo dmesg
ubi0: scanning is finished
[ 7392.005554] ubi0 error: ubi_attach [ubi]: 1205 PEBs are corrupted and preserved
[ 7392.005554] Corrupted PEBs are: 1805 1802 1793 1678 1674 1670 1666 1662 1654 1653 1652 1649 1640 1639 1626 1625 1621 1605 1587 1586 1581 1563 1553 1540 1534 1533 1532 1531 1530 1529 1528 1527 1526 1525 1524 1523 1522 1521 1520 1519 1518 1517 1516 1515 1514 1512 1511 1510 1509 1508 1507 1506 1505 1504 1503 1502 1501 1500 1499 1498 1496 1495 1494 1493 1492 1491 1490 1489 1488 1487 1486 1485 1484 1483 1482 1481 1471 1449 1448 1447 1446 1445 1444 1441 1439 1438 1437 1436 1435 1434 1433 1432 1431 1430 1429 1428 1425 1424 1423 1422 1421 1420 1419 1418 1417 1416 1415 1414 1413 1412 1411 1410 1409 1408 1407 1406 1405 1404 1403 1402 1401 1400 1399 1398 1397 1396 1395 1394 1393 1391 1390 1389 1388 1387 1386 1385 1384 1383 1382 1381 1380 1379 1378 1377 1376 1375 1374 1373 1372 1371 1370 1369 1368 1367 1366 1365 1364 1363 1362 1361 1360 1359 1358 1357 1356 1355 1354 1353 1352 1351 1350 1349 1348 1347 1346 1345 1344 1343 1342 1341 1340 1339 1338 1337 1335 1334 1333 1332 1331 1330 1329 1328 1327 1326
[ 7392.005578] 1325 1324 1323 1322 1321 1294 1275 1274 1273 1264 1230 1223 1221 1219 1214 1211 1210 1207 1204 1203 1202 1201 1200 1199 1198 1197 1196 1195 1194 1193 1192 1191 1190 1189 1188 1187 1186 1185 1184 1183 1182 1181 1180 1179 1178 1177 1176 1175 1174 1173 1172 1165 1164 1163 1157 1147 1144 1143 1142 1141 1140 1139 1138 1137 1136 1134 1133 1132 1131 1130 1129 1128 1127 1126 1125 1124 1123 1122 1121 1120 1119 1118 1117 1116 1115 1114 1112 1111 1110 1109 1108 1106 1105 1098 1085 1053 1052 1044 1016 1003 1002 977 973 972 963 939 938 937 936 935 934 933 932 931 930 929 928 927 926 925 924 923 922 921 920 919 918 917 916 915 914 913 912 911 910 909 908 907 906 905 904 903 902 900 899 898 897 896 895 894 893 892 891 890 889 888 887 886 885 884 883 882 881 880 879 878 877 876 875 874 873 872 871 870 869 868 867 866 865 864 863 862 861 860 859 858 857 856 855 854 853 852 851 850 849 848 847 846 845 844 841 840 839 838 837 836 835 834 833 832 831 830 829 828 827 826 825 824 823 822 821 820
[ 7392.005606] 819 818 817 816 815 814 813 812 811 810 809 808 807 806 805 804 803 802 801 800 799 798 797 796 795 794 793 792 791 790 789 788 787 785 784 782 781 780 779 778 777 776 775 774 773 772 771 770 769 768 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750 749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732 731 730 729 727 726 725 724 723 722 721 720 719 718 716 715 714 713 712 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 675 674 673 672 671 670 668 667 666 665 664 663 662 661 660 659 657 656 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619 618 617 616 615 614 613 611 610 609 608 607 606 605 604 602 601 600 599 598 597 596 595 594 593 592 591 589 588 587 586 585 584 583 582 581 580 579 578 577 576 575 574 573 572 571 570 569 568 567 566 565 564 563
[ 7392.005634] 562 561 560 559 558 557 556 554 553 552 551 550 549 548 547 546 545 544 543 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525 524 523 522 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 506 505 504 503 502 501 500 498 497 496 495 494 493 492 491 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 441 440 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306
[ 7392.005661] 305 304 303 302 301 300 295 294 293 292 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 233 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 177 176 175 174 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30
[ 7392.005690] 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2
[ 7392.005698] ubi0 error: ubi_attach.cold [ubi]: too many corrupted PEBs, refusing
[ 7392.028819] ubi0 error: ubi_attach_mtd_dev [ubi]: failed to attach mtd0, error -22
[ 7393.182325] systemd-journald[331]: /dev/kmsg buffer overrun, some messages lost.
I read the official documents, it says only in 2 senerios a block will be marked as bad. One is
when write opertion to eraseblock fails, UBI will move data from bad EB to a good EB, and do some tests so it can confirm whether bad EB is really bad; or when erase opertion have EIO error, then EB will be marked as bad block immediately. I am not sure which reason caused so much bad block.
My questions
In the progess, is my command doing wrong? If not, how to repair this UBI image so I can read its programs and data?
Is there other ways that can get programs and data from this UBI image file?
Tools and versions
Kali 2020.3
mtd-utils 2.1.1
Problem
I'm running an executable cp2k installed on HPC cluster using mpich-3.2. The output from the executable is printed in an out file. The problem is, that there is no output in the out file after some steps are printed, but when I see the status of my job on the cluster, it turns out that it is still running. Basically, the problem is that my job is still running, but the output is not getting printed.
Script
I'm using the following job script:
#!/bin/bash
#PBS -N test
#PBS -o test.log
#PBS -j oe
#PBS -l nodes=2:ppn=20
#PBS -q mini
#PBS -l walltime=2:00:00
cd $PBS_O_WORKDIR
echo Master process running on `hostname`
echo Directory is `pwd`
echo PBS has allocated the following nodes:
echo `cat $PBS_NBODEFILE`
NPROCS=`wc -l < $PBS_NODEFILE`
echo This job has allocated $NPROCS nodes
export I_MPI_FABRICS=shm:dapl
export I_MPI_PROVIDER=psm2
export I_MPI_FALLBACK=0
export KMP_AFFINITY=verbose,scatter
export OMP_NUM_THREADS=1
export I_MPI_IFACE=ib0
echo Starting executation at `date`
EXEC="/home/arshil/software/cp2k-5.1.0/exe/local/cp2k.popt"
cp $EXEC ./cp2k
mpiexec -np $NPROCS --machinefile $PBS_NODEFILE ./cp2k -i test.inp >& out
rm cp2k
echo Finished at `date`
Error
The ouput in the out file:
SCF WAVEFUNCTION OPTIMIZATION
----------------------------------- OT ---------------------------------------
Minimizer : DIIS : direct inversion
in the iterative subspace
using 7 DIIS vectors
safer DIIS on
Preconditioner : FULL_SINGLE_INVERSE : inversion of
H + eS - 2*(Sc)(c^T*H*c+const)(Sc)^T
Precond_solver : DEFAULT
stepsize : 0.08000000 energy_gap : 0.08000000
eps_taylor : 0.10000E-15 max_taylor : 4
----------------------------------- OT ---------------------------------------
Step Update method Time Convergence Total energy Change
------------------------------------------------------------------------------
1 OT DIIS 0.80E-01 21.3 0.00002878 -8797.2068024142 -8.80E+03
2 OT DIIS 0.80E-01 10.9 0.00007114 -8797.2061897209 6.13E-04
3 OT DIIS 0.80E-01 10.8 0.00001688 -8797.2073257531 -1.14E-03
As it can be seen, there is no printing after step 3 in the output file, but the job is still running in the background. Even after the walltime is over, the output file remains the same as above. Where is the output going?
The executable cp2k is used to perform quantum chemical calculations and was installed on the cluster along with mpich-3.2. All CP2K needs is an input file with extension .inp. For my case, test.inp is the input file.
&FORCE_EVAL
METHOD Quickstep
&DFT
BASIS_SET_FILE_NAME GTH_BASIS_SETS
POTENTIAL_FILE_NAME GTH_POTENTIALS
&MGRID
NGRIDS 4
CUTOFF 380
REL_CUTOFF 60
&END MGRID
&QS
METHOD GPW
MAP_CONSISTENT
EXTRAPOLATION ASPC
EXTRAPOLATION_ORDER 3
&END QS
&SCF
MAX_SCF 1000
EPS_SCF 1.0E-5
SCF_GUESS ATOMIC
&OT
PRECONDITIONER FULL_SINGLE_INVERSE
MINIMIZER DIIS
N_DIIS 7
&END OT
&PRINT
&RESTART OFF
&END RESTART
&END PRINT
&END SCF
&XC
&XC_FUNCTIONAL PBE
&END XC_FUNCTIONAL
&vdW_POTENTIAL
DISPERSION_FUNCTIONAL PAIR_POTENTIAL
&PAIR_POTENTIAL
PARAMETER_FILE_NAME dftd3.dat
TYPE DFTD3
REFERENCE_FUNCTIONAL PBE
R_CUTOFF [angstrom] 12.3
&END PAIR_POTENTIAL
&END vdW_POTENTIAL
&END XC
&END DFT
&SUBSYS
&CELL
ABC 24.6904 24.6904 24.6904
PERIODIC XYZ
&END CELL
&KIND C
BASIS_SET TZV2P-GTH
POTENTIAL GTH-PBE-q4
&END KIND
&KIND P
BASIS_SET TZV2P-GTH
POTENTIAL GTH-PBE-q5
&END KIND
&KIND H
BASIS_SET TZV2P-GTH
POTENTIAL GTH-PBE-q1
&END KIND
&KIND O
BASIS_SET TZV2P-GTH
POTENTIAL GTH-PBE-q6
&END KIND
&KIND N
BASIS_SET TZV2P-GTH
POTENTIAL GTH-PBE-q5
&END KIND
&KIND Mg
BASIS_SET TZV2P-GTH
POTENTIAL GTH-PBE-q10
&END KIND
&COLVAR
&COORDINATION
ATOMS_FROM 41
ATOMS_TO 38
R_0 [bohr] 4.5
NN 6
ND 12
&END COORDINATION
&END COLVAR
&COLVAR
&COORDINATION
ATOMS_FROM 41
ATOMS_TO 42 44 47 50 53 56 59 62 65 68 71 74 77 80 83 86 89 92 95 98 101 104 107 110 113 116 119 122 125 128 131 134 137 140 143 146 149 152 155 158 161 164 167 170 173 176 179 182 185 188 191 194 197 200 203 206 209 212 215 218 221 224 227 230 233 236 239 242 245 248 251 254 257 260 263 266 269 272 275 278 281 284 287 290 293 296 299 302 305 308 311 314 317 320 323 326 329 332 335 338 341 344 347 350 353 356 359 362 365 368 371 374 377 380 383 386 389 392 395 398 401 404 407 410 413 416 419 422 425 428 431 434 437 440 443 446 449 452 455 458 461 464 467 470 473 476 479 482 485 488 491 494 497 500 503 506 509 512 515 518 521 524 527 530 533 536 539 542 545 548 551 554 557 560 563 566 569 572 575 578 581 584 587 590 593 596 599 602 605 608 611 614 617 620 623 626 629 632 635 638 641 644 647 650 653 656 659 662 665 668 671 674 677 680 683 686 689 692 695 698 701 704 707 710 713 716 719 722 725 728 731 734 737 740 743 746 749 752 755 758 761 764 767 770 773 776 779 782 785 788 791 794 797 800 803 806 809 812 815 818 821 824 827 830 833 836 839 842 845 848 851 854 857 860 863 866 869 872 875 878 881 884 887 890 893 896 899 902 905 908 911 914 917 920 923 926 929 932 935 938 941 944 947 950 953 956 959 962 965 968 971 974 977 980 983 986 989 992 995 998 1001 1004 1007 1010 1013 1016 1019 1022 1025 1028 1031 1034 1037 1040 1043 1046 1049 1052 1055 1058 1061 1064 1067 1070 1073 1076 1079 1082 1085 1088 1091 1094 1097 1100 1103 1106 1109 1112 1115 1118 1121 1124 1127 1130 1133 1136 1139 1142 1145 1148 1151 1154 1157 1160 1163 1166 1169 1172 1175 1178 1181 1184 1187 1190 1193 1196 1199 1202 1205 1208 1211 1214 1217 1220 1223 1226 1229 1232 1235 1238 1241 1244 1247 1250 1253 1256 1259 1262 1265 1268 1271 1274 1277 1280 1283 1286 1289 1292 1295 1298 1301 1304 1307 1310 1313 1316 1319 1322 1325 1328 1331 1334 1337 1340 1343 1346 1349 1352 1355 1358 1361 1364 1367 1370 1373 1376 1379 1382 1385 1388 1391 1394 1397 1400 1403 1406 1409 1412 1415 1418 1421 1424 1427 1430 1433 1436 1439 1442 1445 1448 1451 1454 1457
ATOMS_TO 1460 1463 1466 1469 1472 1475 1478 1481 1484 1487 1490 1493 1496 1499 1502 1505
R_0 [bohr] 4.5
NN 6
ND 12
&END COORDINATION
&END COLVAR
&END SUBSYS
&END FORCE_EVAL
&GLOBAL
PROJECT test
RUN_TYPE MD
PRINT_LEVEL LOW
&END GLOBAL
&MOTION
&MD
ENSEMBLE NVT
STEPS 100000
TIMESTEP 0.5
TEMPERATURE 310
TEMP_TOL 100
&THERMOSTAT
&NOSE
LENGTH 3
YOSHIDA 3
TIMECON 100.0
MTS 2
&END NOSE
&END
&PRINT
&ENERGY
&EACH
MD 10
&END
&END
&PROGRAM_RUN_INFO
&EACH
MD 100
&END
&END
FORCE_LAST
&END PRINT
&END MD
&FREE_ENERGY
&METADYN
DO_HILLS
LAGRANGE .TRUE.
NT_HILLS 40
WW [kcalmol] 1
TEMPERATURE 310
TEMP_TOL 10
&METAVAR
SCALE 0.05
COLVAR 1
MASS 50
LAMBDA 2
&WALL
POSITION 0.0
TYPE QUARTIC
&QUARTIC
DIRECTION WALL_MINUS
K 10.0
&END
&END
&END METAVAR
&METAVAR
SCALE 0.05
COLVAR 2
MASS 50
LAMBDA 2
&WALL
POSITION 0.0
TYPE QUARTIC
&QUARTIC
DIRECTION WALL_MINUS
K 10.0
&END
&END
&END METAVAR
&PRINT
&COLVAR
COMMON_ITERATION_LEVELS 3
&EACH
MD 1
&END
&END
&HILLS
COMMON_ITERATION_LEVELS 3
&EACH
MD 1
&END
&END
&END
&END METADYN
&END
&PRINT
&TRAJECTORY
&EACH
MD 1
&END
&END
&VELOCITIES OFF
&END
&RESTART
&EACH
MD 20
&END
ADD_LAST NUMERIC
&END
&RESTART_HISTORY
&EACH
MD 2000
&END
&END
&END
&END MOTION
&EXT_RESTART
RESTART_FILE_NAME NVT-1.restart
RESTART_COUNTERS .FALSE.
&END
The problem in my opinion is not with the input file. It has got to do something with mpich-3.2. I would really appreciate some help.
This may be something similar going on / solutions that can be used here: Python "print" not working when embedded into MPI program It is not perfect as you are not using python however it may help.
At a basic level MPI launches many processes - but only the command that launches it has access to stdio etc. The redirect at the end of the line starting with mpiexec sends the stdout of mpiexec to a file. The output from your script is buffered by mpiexec until the processes end (either they complete or they are stopped).
Where the output is going is a good question and may require changes in test.np or some other way of shutting down (you mention you were out of wall time). I'm looking to solve the same problem - and will update this (if) I find an answer.
Also the output from different processes started by mpi can arrive in random order. I do not care about this but if you do you may need to pass the messages back to some common thread which sorts their order.
I have two files, file 1:
1 800 800 0.51
2 801 801 0.01
3 802 802 0.01
4 803 803 0.23
and file 2:
1 800 800 0.55
2 801 801 0.09
3 802 802 0.88
4 804 804 0.24
I have an awk script that looks in the second file for values that match the first three columns of the first file.
$ awk 'NR==FNR{a[$1,$2,$3];next} {if (($1,$2,$3) in a) {print $4} else {print "not found"}}' f1 f2
0.55
0.09
0.88
not found
Is there a way to make it such that any rows occurring in file 2 that are not in file 1 are still added at the end of the output, after the matches, such as this:
0.55
0.09
0.88
not found
4 804 804 0.24
That way, when I paste the two files back together, they will look something like this:
1 800 800 0.51 0.55
2 801 801 0.01 0.09
3 802 802 0.01 0.88
4 803 803 0.23 not found
4 804 804 not found 0.04
Or is there any other more elegant solution with completely different syntax?
awk '{k=$1FS$2FS$3}NR==FNR{a[k]=$4;next}
k in a{print $4;next}{print "not found";print}' f1 f2
The above one-liner will give you:
0.55
0.09
0.88
not found
4 804 804 0.24
I have following result while running below powershell command,
PS C:\> Get-Process svchost
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
546 34 18528 14884 136 49.76 260 svchost
357 14 4856 4396 47 18.05 600 svchost
314 17 6088 5388 42 12.62 676 svchost
329 17 10044 8780 50 12.98 764 svchost
1515 49 36104 38980 454 232.04 812 svchost
301 33 9736 6428 54 2.90 832 svchost
328 26 8844 9744 52 4.32 856 svchost
247 18 8144 9912 77 37.50 904 svchost
46 5 1504 968 14 0.02 1512 svchost
278 15 4048 5660 43 3.88 2148 svchost
98 14 2536 2460 35 0.66 2504 svchost
Here im trying to calculte the total memory size PM(K) of process(s).i've following line in my ps1 script file
get-process svchost | foreach {$mem=("{0:N2}MB " -f ($_.pm/1mb))}
It gives the output in the following format
17.58MB 4.79MB 6.05MB 9.99MB 35.29MB 9.56MB 8.64MB 7.95MB 1.47MB 3.95MB 2.48MB
but i need total size as a single value like 107.75MB
How to calculate the total used memory size of svchost process ?
Thanks
You can use the Measure-Object cmdlet
$measure = Get-Process svchost | Measure-Object PM -Sum
$mem = ("{0:N2}MB " -f ($measure.sum / 1mb))
Also, you can calculate the total size of the entire collection using the += syntax
$mem = 0
Get-Process svchost | %{$mem += $_.pm}
"{0:N2}MB " -f ($mem/1mb)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I wrote a simple genetic algorithm that can solve traveling salesman problem with 5 cities. I want to see how it does on a problem with more cities, something like 10, 25, 50, 100, but I can't find a sample date for the problem to try it on. Basically, I am looking for 2D lists or matrices with distances between cities. It would be nice if there is a solution. Where should I look?
Thank You in Advance
A well-known benchmark library for the TSP with instances ranging from as few as 14 to close to 100,000 cities is the TSPLIB. The instances have been solved to optimality, for some instances the optimal solution is also available.
Many of the instances have a real-world background such as travel been cities in Germany, Switzerland, the USA, or in the whole world. Some of the instances represent drilling problems for computer board layout There's also an instance that represents the voyage of Ulysses.
The sources I've found online are quite huge. I might be doing something wrong, but 10 places (cities) take ~0.6s and 11 places take ~7s. The smallest known-solution dataset I could find was 15 places (and considered "small", the "classical" one being 48 places) but perhaps those are for optimized (non-brute force) algorithms. In the end I made my own table with real-world cities:
m
a
a h
s h s u
t a e i g l
r a e t e s
i c r t l e b b a e
c h l a e c o e n o p
h e e r e h n r n h e
t n n d n t n g e e n
maastricht 0 29 20 21 16 31 100 12 4 31 18
aachen 29 0 15 29 28 40 72 21 29 41 12
heerlen 20 15 0 15 14 25 81 9 23 27 13
sittard 21 29 15 0 4 12 92 12 25 13 25
geleen 16 28 14 4 0 16 94 9 20 16 22
echt 31 40 25 12 16 0 95 24 36 3 37
bonn 100 72 81 92 94 95 0 90 101 99 84
hulsberg 12 21 9 12 9 24 90 0 15 25 13
kanne 4 29 23 25 20 36 101 15 0 35 18
ohe 31 41 27 13 16 3 99 25 35 0 38
epen 18 12 13 25 22 37 84 13 18 38 0
Optimal (by program): cities 0-7-4-3-9-5-2-6-1-10-8-0 = 253km
maastricht -> hulsberg -> geleen -> sittard -> ohe -> kanne -> echt
-> heerlen -> bonn -> aachen -> epen -> kanne -> maastricht
The data format readable by the program is a partial table (because it's symmetrical):
29 20 21 16 31 100 12 4 31 18
15 29 28 40 72 21 29 41 12
15 14 25 81 9 23 27 13
4 12 92 12 25 13 25
16 94 9 20 16 22
95 24 36 3 37
90 101 99 84
15 25 13
35 18
38
For me this takes ~6.7 seconds to process on a 3rd gen i7 (i7-3630QM). Program is written in C++, single-threaded and simply brute-forces the possibilities. For testing it might be more practical to remove one place, then it takes ~660ms (0.7s) which is still enough to see if code changes make much of a difference.
For next incomes, i'll paste some more "small" cases:
You can find more tests in here. but the file is ".tsp" extension and you should do a simple parse that translate to the matrix of distances.
(distance in miles)
6 cities, expected: 1248.0
9999 64 378 519 434 200
64 9999 318 455 375 164
378 318 9999 170 265 344
519 455 170 9999 223 428
434 375 265 223 9999 273
200 164 344 428 273 9999
15 cities, expected: 1194.0
-1 141 134 152 173 289 326 329 285 401 388 366 343 305 276
141 -1 152 150 153 312 354 313 249 324 300 272 247 201 176
134 152 -1 24 48 168 210 197 153 280 272 257 237 210 181
152 150 24 -1 24 163 206 182 133 257 248 233 214 187 158
173 153 48 24 -1 160 203 167 114 234 225 210 190 165 137
289 312 168 163 160 -1 43 90 124 250 264 270 264 267 249
326 354 210 206 203 43 -1 108 157 271 290 299 295 303 287
329 313 197 182 167 90 108 -1 70 164 183 195 194 210 201
285 249 153 133 114 124 157 70 -1 141 147 148 140 147 134
401 324 280 257 234 250 271 164 141 -1 36 67 88 134 150
388 300 272 248 225 264 290 183 147 36 -1 33 57 104 124
366 272 257 233 210 270 299 195 148 67 33 -1 26 73 96
343 247 237 214 190 264 295 194 140 88 57 26 -1 48 71
305 201 210 187 165 267 303 210 147 134 104 73 48 -1 30
276 176 181 158 137 249 287 201 134 150 124 96 71 30 -1
Hugeeee 29 cities, expected: 27603
imagem: western sahara
-1 74 4110 3048 2267 974 4190 3302 4758 3044 3095 3986 5093 6407 5904 8436 6963 6694 6576 8009 7399 7267 7425 9639 9230 8320 9300 8103 7799
74 -1 4070 3000 2214 901 4138 3240 4702 2971 3021 3915 5025 6338 5830 8369 6891 6620 6502 7939 7326 7193 7351 9571 9160 8249 9231 8030 7725
4110 4070 -1 1173 1973 3496 892 1816 1417 3674 3778 2997 2877 3905 5057 5442 4991 5151 5316 5596 5728 5811 5857 6675 6466 6061 6523 6165 6164
3048 3000 1173 -1 817 2350 1172 996 1797 2649 2756 2317 2721 3974 4548 5802 4884 4887 4960 5696 5537 5546 5634 7045 6741 6111 6805 6091 5977
2267 2214 1973 817 -1 1533 1924 1189 2498 2209 2312 2325 3089 4401 4558 6342 5175 5072 5075 6094 5755 5712 5828 7573 7222 6471 7289 6374 6187
974 901 3496 2350 1533 -1 3417 2411 3936 2114 2175 3014 4142 5450 4956 7491 5990 5725 5615 7040 6430 6304 6459 8685 8268 7348 8338 7131 6832
4190 4138 892 1172 1924 3417 -1 1233 652 3086 3185 2203 1987 3064 4180 4734 4117 4261 4425 4776 4844 4922 4971 5977 5719 5228 5780 5302 5281
3302 3240 1816 996 1189 2411 1233 -1 1587 1877 1979 1321 1900 3214 3556 5175 4006 3947 3992 4906 4615 4599 4700 6400 6037 5288 6105 5209 5052
4758 4702 1417 1797 2498 3936 652 1587 -1 3286 3374 2178 1576 2491 3884 4088 3601 3818 4029 4180 4356 4469 4497 5331 5084 4645 5143 4761 4787
3044 2971 3674 2649 2209 2114 3086 1877 3286 -1 107 1360 2675 3822 2865 5890 4090 3723 3560 5217 4422 4257 4428 7000 6514 5455 6587 5157 4802
3095 3021 3778 2756 2312 2175 3185 1979 3374 107 -1 1413 2725 3852 2826 5916 4088 3705 3531 5222 4402 4229 4403 7017 6525 5451 6598 5142 4776
3986 3915 2997 2317 2325 3014 2203 1321 2178 1360 1413 -1 1315 2511 2251 4584 2981 2778 2753 4031 3475 3402 3531 5734 5283 4335 5355 4143 3897
5093 5025 2877 2721 3089 4142 1987 1900 1576 2675 2725 1315 -1 1323 2331 3350 2172 2275 2458 3007 2867 2935 2988 4547 4153 3400 4222 3376 3307
6407 6338 3905 3974 4401 5450 3064 3214 2491 3822 3852 2511 1323 -1 2350 2074 1203 1671 2041 1725 1999 2213 2173 3238 2831 2164 2901 2285 2397
5904 5830 5057 4548 4558 4956 4180 3556 3884 2865 2826 2251 2331 2350 -1 3951 1740 1108 772 2880 1702 1450 1650 4779 4197 2931 4270 2470 2010
8436 8369 5442 5802 6342 7491 4734 5175 4088 5890 5916 4584 3350 2074 3951 -1 2222 2898 3325 1276 2652 3019 2838 1244 1089 1643 1130 2252 2774
6963 6891 4991 4884 5175 5990 4117 4006 3601 4090 4088 2981 2172 1203 1740 2222 -1 684 1116 1173 796 1041 974 3064 2505 1368 2578 1208 1201
6694 6620 5151 4887 5072 5725 4261 3947 3818 3723 3705 2778 2275 1671 1108 2898 684 -1 432 1776 706 664 756 3674 3090 1834 3162 1439 1120
6576 6502 5316 4960 5075 5615 4425 3992 4029 3560 3531 2753 2458 2041 772 3325 1116 432 -1 2174 930 699 885 4064 3469 2177 3540 1699 1253
8009 7939 5596 5696 6094 7040 4776 4906 4180 5217 5222 4031 3007 1725 2880 1276 1173 1776 2174 -1 1400 1770 1577 1900 1332 510 1406 1002 1499
7399 7326 5728 5537 5755 6430 4844 4615 4356 4422 4402 3475 2867 1999 1702 2652 796 706 930 1400 -1 371 199 3222 2611 1285 2679 769 440
7267 7193 5811 5546 5712 6304 4922 4599 4469 4257 4229 3402 2935 2213 1450 3019 1041 664 699 1770 371 -1 220 3583 2970 1638 3037 1071 560
7425 7351 5857 5634 5828 6459 4971 4700 4497 4428 4403 3531 2988 2173 1650 2838 974 756 885 1577 199 220 -1 3371 2756 1423 2823 852 375
9639 9571 6675 7045 7573 8685 5977 6400 5331 7000 7017 5734 4547 3238 4779 1244 3064 3674 4064 1900 3222 3583 3371 -1 620 1952 560 2580 3173
9230 9160 6466 6741 7222 8268 5719 6037 5084 6514 6525 5283 4153 2831 4197 1089 2505 3090 3469 1332 2611 2970 2756 620 -1 1334 74 1961 2554
8320 8249 6061 6111 6471 7348 5228 5288 4645 5455 5451 4335 3400 2164 2931 1643 1368 1834 2177 510 1285 1638 1423 1952 1334 -1 1401 648 1231
9300 9231 6523 6805 7289 8338 5780 6105 5143 6587 6598 5355 4222 2901 4270 1130 2578 3162 3540 1406 2679 3037 2823 560 74 1401 -1 2023 2617
8103 8030 6165 6091 6374 7131 5302 5209 4761 5157 5142 4143 3376 2285 2470 2252 1208 1439 1699 1002 769 1071 852 2580 1961 648 2023 -1 594
7799 7725 6164 5977 6187 6832 5281 5052 4787 4802 4776 3897 3307 2397 2010 2774 1201 1120 1253 1499 440 560 375 3173 2554 1231 2617 594 -1