Compare commits
967 Commits
patch_30Ma
...
patch_22Au
| Author | SHA1 | Date | |
|---|---|---|---|
| b47e492233 | |||
| bb72604eec | |||
| 316f265e3d | |||
| 25bc74eb21 | |||
| 9d4994b383 | |||
| fc47b8c6dd | |||
| c4bda59f9a | |||
| 87afaa44fd | |||
| 2baa0b3452 | |||
| fd0b041e0e | |||
| c0150e80e9 | |||
| 4b0382cadd | |||
| fd788e5bbd | |||
| ee3b7a67a0 | |||
| 2b5618dc40 | |||
| 95d462e5d3 | |||
| 3aedfbf9d5 | |||
| d66d696dff | |||
| 2c19079707 | |||
| 21c332353a | |||
| f8faf4dfe2 | |||
| c719af8bcd | |||
| f402d2f520 | |||
| 044141eb8f | |||
| 2248bf12d5 | |||
| 0ca0e0a93c | |||
| 639573ff87 | |||
| f73ffb829b | |||
| 353c004d6c | |||
| 703a795af8 | |||
| 4f37b46b10 | |||
| 5436169c20 | |||
| 7dac513235 | |||
| 6c5d339a94 | |||
| c0544ba346 | |||
| eb7568a4fb | |||
| 2a547ede68 | |||
| bfaa345536 | |||
| f8c9ab4a3e | |||
| a8c687aee8 | |||
| 73540e6b44 | |||
| e05d471869 | |||
| 4c3bd3909e | |||
| b7d64e0374 | |||
| 8c0c6659e4 | |||
| 47f02b323a | |||
| 3f15353616 | |||
| b55f3162f4 | |||
| 17e5da978b | |||
| 34b9b44cb6 | |||
| 8cea92d0bd | |||
| 481924fccc | |||
| 71227cb3c6 | |||
| 2137668c35 | |||
| 07cd194e27 | |||
| ccc9fcda77 | |||
| ccacf0d4bb | |||
| 6cc653f631 | |||
| 46f1e63a19 | |||
| 9e154abba0 | |||
| 6069d392a3 | |||
| e541074697 | |||
| c9131cf1de | |||
| b9e2b26b65 | |||
| 023c8e5d6e | |||
| 1776ade72e | |||
| 3bb8fefb12 | |||
| 60c9477e96 | |||
| 95bfc3b536 | |||
| 1823fc2bd1 | |||
| 6eededb190 | |||
| 6c90410260 | |||
| 1f65150e16 | |||
| 9c3748e07c | |||
| ad9126f30e | |||
| b72048097c | |||
| 9526db44ce | |||
| 63f57bbece | |||
| 7ec52784cb | |||
| 64d539d9d2 | |||
| 7ab11488d0 | |||
| 3384c683df | |||
| 13bb02b100 | |||
| afbfaf0a8f | |||
| 8634301b53 | |||
| fef2b8260b | |||
| 6e8a68a420 | |||
| 11f04fde5c | |||
| e01185c283 | |||
| 907b061e0b | |||
| 135b877161 | |||
| 28c03e4518 | |||
| b33452040a | |||
| ddd8533d81 | |||
| bc8939a08b | |||
| f67b198c24 | |||
| 13d1f26a0f | |||
| 8318b96c11 | |||
| 0b523cb48e | |||
| 76289cd955 | |||
| edb535d36f | |||
| 4db08f5351 | |||
| 630a46ad67 | |||
| aca9416c7f | |||
| f7164e593e | |||
| a5170e93ec | |||
| 108f2d0ed7 | |||
| 6663fbeb11 | |||
| cfc1b3a823 | |||
| c97e6537c8 | |||
| 9dde50a4f2 | |||
| 08636889ca | |||
| bb25e5d98a | |||
| 8e9ea1e4fa | |||
| f4ea28cd32 | |||
| 1604f011d2 | |||
| a065143723 | |||
| df20fbbca4 | |||
| a97ad15d22 | |||
| d5594350c4 | |||
| 9521814441 | |||
| dd9fed11dc | |||
| 65d11171c4 | |||
| 01b8134746 | |||
| 6d60075d3b | |||
| 32658c20d4 | |||
| 1c550d8f39 | |||
| d8aa6d534b | |||
| 9202896e75 | |||
| 985318203d | |||
| ff87cdb8f4 | |||
| a3fad229ab | |||
| fac5e29f48 | |||
| 64e152bced | |||
| 5d87e0c651 | |||
| 3d537850fd | |||
| b6c458192c | |||
| ac7aeb6862 | |||
| d27215b7e1 | |||
| 32917f4caa | |||
| e88311235f | |||
| 78bddacd88 | |||
| fba9f0aaae | |||
| 6927ed5eb9 | |||
| 6de3dab72a | |||
| 82744773b3 | |||
| 31c3c6c93e | |||
| 382e3b08ac | |||
| 5789ef9128 | |||
| 2321c8ff37 | |||
| 9cc75792d6 | |||
| f330013584 | |||
| 39f61a78f2 | |||
| c105e21a73 | |||
| 1b0a8fdc9b | |||
| fb03924e83 | |||
| 4faeda28ee | |||
| ad88ecd3ef | |||
| d598e7c60e | |||
| 42948b60ee | |||
| d877a12e0c | |||
| c8be5a3f2d | |||
| 90897f570e | |||
| 77e5445bfe | |||
| eb967a8a6c | |||
| 2b7b61d5b7 | |||
| ff351bd5f7 | |||
| c6186bf00d | |||
| e9d40d3c6d | |||
| 8c0955aaff | |||
| 67e70316de | |||
| bbaf522430 | |||
| 6dad2f59d8 | |||
| 50fe209782 | |||
| 24e293326d | |||
| f3615e83e8 | |||
| 18a7b1ab4f | |||
| 57cd1ab55a | |||
| 34f619ea1d | |||
| a8e2a0a54b | |||
| d9c328932f | |||
| ee822bec1b | |||
| b02362b943 | |||
| 82c9e8a52c | |||
| 2bb11ef47a | |||
| 4a8f2c2d29 | |||
| 882e1e5138 | |||
| b76f86602a | |||
| a00d7becc3 | |||
| 2c9e96be11 | |||
| 82fc3b99d9 | |||
| 528fc8f6a1 | |||
| fa9b46fb40 | |||
| 8fccf6b9b4 | |||
| 99985a1d5b | |||
| 6cd7299920 | |||
| 28993d9823 | |||
| 2af88dcc26 | |||
| 8075b98fc5 | |||
| f63e2b6eaf | |||
| 06335e77cb | |||
| 9ffd262039 | |||
| 819e47b69e | |||
| c8b9a727e4 | |||
| ae0979e1ad | |||
| 532d09bd56 | |||
| 353ecd2c7a | |||
| e6e026433c | |||
| 1d9ad55796 | |||
| dff8977156 | |||
| 592804d56f | |||
| ee394b0ed1 | |||
| 030f1c0127 | |||
| 22c9258b8e | |||
| 0fc789bae5 | |||
| 8d49d1a8c5 | |||
| c31d7c6f45 | |||
| 45532b7106 | |||
| bf83e55cfa | |||
| 80d85841af | |||
| 7ac3f08eec | |||
| 678df2498a | |||
| c3661272f1 | |||
| 8385f5666b | |||
| d83d05088f | |||
| da1be29278 | |||
| e37ee02eed | |||
| 57ad197b7d | |||
| eee0df45dd | |||
| 923ae041dc | |||
| 2ac3953e17 | |||
| 35ffa0a214 | |||
| 40dcfa44c9 | |||
| 644888d03c | |||
| b612c7ee75 | |||
| d71e037c23 | |||
| 94da4be922 | |||
| 01c27194d4 | |||
| 223de57401 | |||
| 5c21d2aff9 | |||
| 884e72a4ba | |||
| 2732b8b647 | |||
| de8176b4fc | |||
| 36081f9ffd | |||
| 2eb8d779e8 | |||
| 7d4de932b6 | |||
| dfd40c1b70 | |||
| f9c7fa973b | |||
| 843b96e8dd | |||
| de69e24551 | |||
| d23788831c | |||
| 203f82ed47 | |||
| fa73fab5df | |||
| a3b6f38a42 | |||
| 5abbea3606 | |||
| 783839e985 | |||
| cfa6e8717d | |||
| 27dc7f3205 | |||
| c589029219 | |||
| 140767be16 | |||
| 1c007ce7a1 | |||
| 6f1b6e7abd | |||
| 5fc4aaef06 | |||
| f7d551eb54 | |||
| aa3d3213c9 | |||
| d00eaef070 | |||
| 8447d8dd91 | |||
| d4f8940ff2 | |||
| 16381a52b1 | |||
| 85511a4db8 | |||
| 21f749243a | |||
| 4ac47ba037 | |||
| 6dfb74f23e | |||
| b31f0245d0 | |||
| aa705f6122 | |||
| 65d12b1961 | |||
| f288331874 | |||
| 71f6991233 | |||
| 5d13321425 | |||
| acdc240cdd | |||
| 69baaaec16 | |||
| 1f1447c3ac | |||
| c3a32dde12 | |||
| 930215a4b1 | |||
| eaf3d1ea9e | |||
| c3bf7d0971 | |||
| 5124c9e993 | |||
| 9a70f4a08c | |||
| 1ed25d195b | |||
| 792b182cb0 | |||
| ade9b7bfc3 | |||
| 9d5dc561ca | |||
| 199c96f985 | |||
| ad4f61a5ce | |||
| 13338bf8cb | |||
| 0c1dcfb617 | |||
| db75232957 | |||
| 24405217d0 | |||
| a52ddf8759 | |||
| 0f71ed1fec | |||
| 43ffee980d | |||
| 560b34aad0 | |||
| ea35235ca0 | |||
| 474b59a1f3 | |||
| c63d77d0b8 | |||
| bf9646cbbe | |||
| d2dd76e655 | |||
| d649a6fe38 | |||
| a8b7153f4e | |||
| c3fe26a614 | |||
| bbe77e4c31 | |||
| b819018084 | |||
| 6900f9edf9 | |||
| 11a8d4e1c3 | |||
| d9396df5b9 | |||
| 0e047f2786 | |||
| e08ccd0a7c | |||
| ec99b0957c | |||
| 75a3968039 | |||
| a3a2981cd2 | |||
| 4f9c0456e6 | |||
| ad4720ef00 | |||
| 946bca82c5 | |||
| 85d7f7ddc9 | |||
| ee0e9f94f1 | |||
| 9f1aabea50 | |||
| b3bc5fd823 | |||
| e0dc53ab3f | |||
| 206d349d5b | |||
| 4d629872d8 | |||
| 7a783870e2 | |||
| 0df8587c18 | |||
| ad3d049edd | |||
| 7abc960d39 | |||
| 23fb0370a9 | |||
| a043ddcb82 | |||
| a2b2507121 | |||
| 6bd5a3d69b | |||
| 086e83456b | |||
| 1db4705a3d | |||
| 8e77be0848 | |||
| fc3694189e | |||
| 75aacfd17f | |||
| 08552fefe9 | |||
| 20fe0cd9d0 | |||
| 8f4b7161c5 | |||
| 38cdc1828d | |||
| 9353569d30 | |||
| 868f5711a2 | |||
| 7ffab9a228 | |||
| 58559d9e62 | |||
| 3eed23d3f7 | |||
| d3b83885d1 | |||
| 3549345830 | |||
| 244963aa19 | |||
| 264f832b18 | |||
| 5c4bf8ac47 | |||
| 6008cee6aa | |||
| f33a2c982c | |||
| 8e14143908 | |||
| e6ef8ce5ee | |||
| ebe622ff7d | |||
| f94cdf856c | |||
| e2622f0230 | |||
| e4dd6dec40 | |||
| b0126dd9d6 | |||
| f36e1a2cdc | |||
| c9d147c366 | |||
| 19f81e0802 | |||
| 49a91db0b2 | |||
| bad750eb2b | |||
| 5e48565761 | |||
| af91f7fa5d | |||
| 0cd86bab22 | |||
| bec82e4045 | |||
| 06b3209ad8 | |||
| 2fd45050cd | |||
| 8ffa96c9e9 | |||
| 6a9251245c | |||
| cb2cf5b773 | |||
| c4d0994d5e | |||
| e2c03f0596 | |||
| 9108306c11 | |||
| 86519ce213 | |||
| 0b1d4a1696 | |||
| 264e4fd3b1 | |||
| d237625d2a | |||
| ce0f3daad6 | |||
| cb7b23e220 | |||
| 3f17d33fbe | |||
| 510834cb7b | |||
| 2165a2aa9b | |||
| ac41cc2c9a | |||
| f5f73b0172 | |||
| 35f5a685f6 | |||
| 62984c1de0 | |||
| 04d040b863 | |||
| 92f0f19df6 | |||
| dcdc7877a4 | |||
| 2f11f2d7b2 | |||
| e25b6c81ee | |||
| 80cca7c4c1 | |||
| 2fe0eabc09 | |||
| 7da8e69b45 | |||
| e8e1349da4 | |||
| dc132c8bf1 | |||
| f0a2c57401 | |||
| 4ca3d30db7 | |||
| cbfb751e92 | |||
| 65c895721f | |||
| bfacfc46be | |||
| 919d95d375 | |||
| 258185690d | |||
| cea0227f14 | |||
| 3e58ebea4f | |||
| 7a22612bea | |||
| 9805b5d34a | |||
| 9f3cb83fb3 | |||
| 9f3fae1c47 | |||
| 0e603493af | |||
| 7f0c88c74b | |||
| 1f770a6a8f | |||
| 596acaf4d2 | |||
| 472a1a501d | |||
| eb485afc45 | |||
| 4265e68ff8 | |||
| 90f0586c9e | |||
| c371ce1005 | |||
| e3a528a493 | |||
| 28504e91c0 | |||
| 47482afbc1 | |||
| 7d3a549de9 | |||
| a9b794b2ab | |||
| 3ae8fdccd8 | |||
| 70a7b37614 | |||
| 036647c102 | |||
| 37b901eadb | |||
| 4a88f53d22 | |||
| d4861e71d2 | |||
| 5a3ef99272 | |||
| 605b4dca22 | |||
| dade67664d | |||
| 93d6510d34 | |||
| 4f8d1893e9 | |||
| 7c7a80b31a | |||
| da5931d65d | |||
| 83ae0ad26f | |||
| b189a328ed | |||
| 469b67a39b | |||
| 1d0773d10d | |||
| 03a7d1cd5d | |||
| 08331da93d | |||
| ab0f3debeb | |||
| fe14bfd1d2 | |||
| d55c7039ee | |||
| 87dcef7115 | |||
| 7e234497ff | |||
| 277b43b2fd | |||
| 6f61ed2af5 | |||
| 16cc613993 | |||
| 6842a527e0 | |||
| d094bf789c | |||
| 3750e0a427 | |||
| 40c4461a78 | |||
| d830fc2301 | |||
| 265b6c261e | |||
| 3411b0e576 | |||
| 47458f1ca0 | |||
| c4bcb7e73d | |||
| 18b543179c | |||
| 14c4438a72 | |||
| acd20512f0 | |||
| 5fcdfe6dcb | |||
| 7c9afc1be2 | |||
| b2e6863d93 | |||
| cb887d48a1 | |||
| 9ef1bfe814 | |||
| 76b85e4d25 | |||
| 8a2faff541 | |||
| fe483a769f | |||
| f312fbfe32 | |||
| f68c6dddb8 | |||
| c5b51df06e | |||
| 479cc9424d | |||
| 673202d05f | |||
| 3e79296dcf | |||
| fcf9ed0fc2 | |||
| 14c4aea32d | |||
| 666a13ea8a | |||
| 661848139c | |||
| 12d8370ec5 | |||
| 3c781afa6c | |||
| 37268e435b | |||
| 29e555213c | |||
| 965ac3cedd | |||
| 30e3e9ab88 | |||
| 6cb0c2e9c5 | |||
| ebd93cac69 | |||
| a2dd21dca5 | |||
| e78ed7d044 | |||
| 142de878f9 | |||
| 3495141dbe | |||
| d0ba8e1dcb | |||
| 4bf9a93c11 | |||
| 4c28827aa1 | |||
| 824a21a661 | |||
| 5a383aa518 | |||
| a4a3133b76 | |||
| 0e96918313 | |||
| 031077b4fa | |||
| 9dda907f7d | |||
| fa5ecf88a5 | |||
| 7ca794beb9 | |||
| 962946ee45 | |||
| 1ee85e59c3 | |||
| c386bdddf9 | |||
| 56c3a0be29 | |||
| cf3095e938 | |||
| 6056c1db4d | |||
| 38182dcc60 | |||
| ef3c0dbf7b | |||
| 4c18a07193 | |||
| e3e040227b | |||
| 82b1ab2ac4 | |||
| f5e9b1e021 | |||
| 1fbd4fffd4 | |||
| d4cca615fb | |||
| f2a6aa249f | |||
| 6457e5eedb | |||
| 7aab932731 | |||
| c27e617fd8 | |||
| b9a8f91753 | |||
| 95e259fe71 | |||
| 69a9f1bf94 | |||
| e7773808a5 | |||
| 0368202d12 | |||
| f2c302c2c4 | |||
| 6438cffa57 | |||
| 6b9637eaa3 | |||
| 4ca870b2a9 | |||
| 179dcd6895 | |||
| 5a23342934 | |||
| 3ba87e52e9 | |||
| 1422b0413b | |||
| dd3278ea07 | |||
| 4bd4b2a1c7 | |||
| 4308f005ab | |||
| 41687a84a4 | |||
| 18c6d7f289 | |||
| 1b4068b575 | |||
| 5f0e6d0aa7 | |||
| 99f4274483 | |||
| 341fa160fe | |||
| d10a470245 | |||
| c960b9295c | |||
| 102be8dd8b | |||
| 6c42c9b378 | |||
| ce4a446cea | |||
| 933cf92e36 | |||
| 69903cb4aa | |||
| 6de4569483 | |||
| ad5cfb5ae6 | |||
| fbc435a0cb | |||
| 108c31e24a | |||
| e550f5120b | |||
| 2f9e6d4566 | |||
| 1641f78e3e | |||
| 4ec31564fe | |||
| f5b7419108 | |||
| 1f193e02e0 | |||
| 838a1938bb | |||
| df3eb36519 | |||
| bb6dcb8ebd | |||
| e6f76451eb | |||
| cfb350d40b | |||
| 5daf1fe0d4 | |||
| 2e7b919774 | |||
| 858c211fdc | |||
| 6997aedf30 | |||
| cab602045e | |||
| 124641dc8a | |||
| 6944973484 | |||
| 9e82c86fbd | |||
| 68dd7d4f2b | |||
| b2da3ca3e9 | |||
| e1361a9dca | |||
| 94c6d2d546 | |||
| 585a164e78 | |||
| 5a4a7cebc1 | |||
| 133f0922b3 | |||
| 1a88ffd5ab | |||
| 307e471456 | |||
| f5d66e74c5 | |||
| bebf25dcb3 | |||
| 3f316f71ef | |||
| 8303d1a375 | |||
| 363d8ef775 | |||
| a449488b1d | |||
| e076d08ee9 | |||
| 1a5144bf37 | |||
| ca6920be72 | |||
| 55d8cc0341 | |||
| 6b73e29f64 | |||
| 09046ad3f7 | |||
| 06c18dd36c | |||
| 55bd823339 | |||
| 77e04a9213 | |||
| 233f03ea8e | |||
| f65b06de0e | |||
| 0f32d603b5 | |||
| 3440b1a2a7 | |||
| 8952b1107c | |||
| b3b3c225e8 | |||
| 4d34e55072 | |||
| 437e854741 | |||
| 4820cef5d4 | |||
| e7598eeec0 | |||
| a5d29fa52e | |||
| 821ef0cf77 | |||
| 42f22a9723 | |||
| 0d8110bc19 | |||
| 44c5e88e24 | |||
| 8d24101df4 | |||
| 308dac6821 | |||
| 944dab1351 | |||
| c3cc07bd3d | |||
| c50258e89c | |||
| 9674512997 | |||
| f864584bce | |||
| 075598b405 | |||
| 7780d92823 | |||
| 66caf1c1a3 | |||
| 95eb86d6c7 | |||
| 724ade0af3 | |||
| d43c556263 | |||
| 40a8b1af79 | |||
| 33a41a4fb3 | |||
| d7992f324d | |||
| 79d1d3458e | |||
| a25895d31d | |||
| 4f762deff8 | |||
| 843f89fc92 | |||
| 6336c3b975 | |||
| a43e74180a | |||
| 6626cd5aaa | |||
| aa1d815fe5 | |||
| 863a85353a | |||
| 662535865f | |||
| 6226ec8831 | |||
| 6c91cc1f76 | |||
| 4e42ee2cfc | |||
| 1224296365 | |||
| 25cef528c9 | |||
| 6359392834 | |||
| 71e1867dd2 | |||
| f90af1839e | |||
| 2ebd4eb26e | |||
| 3682bc47c2 | |||
| 2797afbf3e | |||
| 635383c00c | |||
| b6a8168e3f | |||
| 71fce2e413 | |||
| 994fd2af0e | |||
| d8138a5b4c | |||
| a001f2c248 | |||
| 8104568b6a | |||
| 96d1c421df | |||
| dde271db36 | |||
| a7a83b118d | |||
| 8697cac6aa | |||
| 96c5c92b1a | |||
| 793260f227 | |||
| e5a589e05a | |||
| dc8e141501 | |||
| 9f03a6798f | |||
| b4e5828a60 | |||
| 671876efef | |||
| 8705ea9fc5 | |||
| 16697fc4cb | |||
| 53fc9f1f0f | |||
| 6960529594 | |||
| fccc16f42c | |||
| e7e1827e57 | |||
| c9817b0db9 | |||
| 318dfd0613 | |||
| f4d14c96e8 | |||
| 3394d18a2a | |||
| ff6507e7b7 | |||
| fff962646f | |||
| f39a8d46d1 | |||
| 00b92cd93b | |||
| 808eb2a25e | |||
| 1888b616c4 | |||
| 761b15b8f4 | |||
| cde6e9b7c4 | |||
| 104dde27ed | |||
| bfdfd36c1c | |||
| a4759210a8 | |||
| 7fed6c7e4c | |||
| 82217001c8 | |||
| b2370b6986 | |||
| 624173d25a | |||
| 7cf42e42eb | |||
| d80b375e26 | |||
| d203118286 | |||
| 74fbb84b8c | |||
| 5076b6d161 | |||
| fcdcdb3286 | |||
| 722549965e | |||
| ca96a7ab05 | |||
| 8ec033e823 | |||
| a7c9418629 | |||
| bc0c405bfa | |||
| 1ea5b9eabb | |||
| d9d33ac766 | |||
| d51745fd27 | |||
| c3588f08b7 | |||
| ecfe5c8373 | |||
| 009666d9a5 | |||
| 551ea9694d | |||
| d7339bbd9e | |||
| 934f825388 | |||
| f4fbdea0b3 | |||
| 14588f6242 | |||
| 5e49976b70 | |||
| 9d9d7cb9ed | |||
| 941d289a69 | |||
| e1f9ee1347 | |||
| 916ed71760 | |||
| 9d6891823a | |||
| e14b61e4a4 | |||
| 2d321a602c | |||
| 9acd35abe2 | |||
| 0c53afbfcf | |||
| 2616dd91f9 | |||
| f7c37a7a98 | |||
| 095ca76b5b | |||
| f9f8e2bdbe | |||
| 735bceb468 | |||
| 81293b0fda | |||
| 88dca11b3c | |||
| 460e8bd298 | |||
| ce86ff6cd1 | |||
| 36126ccb7d | |||
| b7210e931c | |||
| 53342a5cec | |||
| d53dc541d8 | |||
| 974ea3420b | |||
| c83fedf100 | |||
| 7edeccae80 | |||
| e242b37619 | |||
| 9a389c946c | |||
| 1b31b4899a | |||
| d24885f805 | |||
| 345c212828 | |||
| 477d9feb5c | |||
| 0a835c499a | |||
| 6dcee30b1a | |||
| 5670dc5e6e | |||
| b11757adb3 | |||
| b61834f28d | |||
| 1d54c93df8 | |||
| 330f29db0b | |||
| 366aaf2450 | |||
| c9d41178d8 | |||
| 6886dcb2e4 | |||
| 23f71ee4ad | |||
| 844858d3a7 | |||
| 2b8576c7c7 | |||
| eeee2d3026 | |||
| 53cc609c4c | |||
| c8a0689d78 | |||
| 28786ef99b | |||
| 749f1ff407 | |||
| 654fec164d | |||
| 35294dafbc | |||
| 83f5c331cd | |||
| 1fdb010c41 | |||
| b5b70b429f | |||
| 07a15a719f | |||
| 75cffc78c5 | |||
| 0c005f5cb0 | |||
| fc0110a2e0 | |||
| 072a063afc | |||
| fbf96b680b | |||
| ed3f8d4b3f | |||
| efbee4a292 | |||
| 2e2f19770c | |||
| 59b59573a7 | |||
| 25ac1fd16c | |||
| 51d2625daf | |||
| 4e6188cff6 | |||
| ca6f99129d | |||
| 0015b15b18 | |||
| e4071d7f46 | |||
| 6b92826a1a | |||
| f202f1bcf6 | |||
| d504dcc465 | |||
| eaaad3f6d5 | |||
| 75069ec55b | |||
| 392816a807 | |||
| 1b8669c620 | |||
| ce80d1a3ea | |||
| 8709f6044b | |||
| a315599bac | |||
| 08bc115380 | |||
| 65b7e43a91 | |||
| 436a5de3a6 | |||
| f0cca6fb9d | |||
| 3ed640666f | |||
| 6a9ecde742 | |||
| 2a3b93ca3d | |||
| e4c6c46b4c | |||
| 7990826ca2 | |||
| fa499ff95d | |||
| 86cfbb3010 | |||
| f409f4ff53 | |||
| eab737a45c | |||
| b422480002 | |||
| 3d18f55155 | |||
| 10b38cda93 | |||
| 6490ee46b7 | |||
| 642c8f9859 | |||
| 755bda2275 | |||
| 05a7e5011f | |||
| 3abb7f0eaf | |||
| 5b93fc6a27 | |||
| 1e096d77ef | |||
| 38e940a392 | |||
| 7cc62f4234 | |||
| 01f378d265 | |||
| ab200cff06 | |||
| 5fe0b0a2cc | |||
| 6df54ac3ec | |||
| 1e9d91bd8f | |||
| 749336ae1f | |||
| 925e647acf | |||
| 148d26d943 | |||
| 2bfd30f7d7 | |||
| f4bb33de4b | |||
| 49f0a7a89a | |||
| f1182df776 | |||
| 1828274a99 | |||
| 813343928a | |||
| cc44a8863c | |||
| f3e58440a2 | |||
| 4cbda74df4 | |||
| c6bb9586ef | |||
| b219392d59 | |||
| f6b4587fe8 | |||
| 72d9795d7f | |||
| 54832a8fe4 | |||
| d144ab0164 | |||
| 87993368f9 | |||
| 3de0cf5ab4 | |||
| f5ff30df83 | |||
| 45ea7b3cc7 | |||
| 023b018ed2 | |||
| 64b08d3ca8 | |||
| c7edc6636a | |||
| 98a22c2b55 | |||
| b88f7aac32 | |||
| 7519dee502 | |||
| 8746ab547e | |||
| 2c5597ae4b | |||
| 8a56b8ad3a | |||
| b934621651 | |||
| bf5b3f96e9 | |||
| 4d375e72f0 | |||
| 7cc59fbbbe | |||
| d53def5853 | |||
| af45d55b3f | |||
| 3168704858 | |||
| bf18d84273 | |||
| 9b0f8a0c55 | |||
| 56d0014a4a | |||
| 26d22a4b7a | |||
| c5e884fb41 | |||
| c4373c7afa | |||
| 69665c218a | |||
| 6f9a2245d2 | |||
| d5ec76290b | |||
| 836027dbd8 | |||
| c5127eca89 | |||
| 91b407570a | |||
| 5bf8e1bc5b | |||
| 164537cf37 | |||
| f1ee46cc64 | |||
| caa990746e | |||
| a087813d01 | |||
| 48e42a4e1e | |||
| 6027de5387 | |||
| 398f3173aa | |||
| 798fcacd77 | |||
| bc0fd5496a | |||
| 430027465f | |||
| 7f9400eadc | |||
| 1b965d4d3a | |||
| 6e31b7da63 | |||
| 8f1487fbc6 | |||
| e2bc4d461e | |||
| dee945c01d | |||
| bc49ce611a | |||
| 72cd13aac7 | |||
| 49d524e442 | |||
| 3c6102a0c3 | |||
| 4517c85c77 | |||
| aa4f044709 | |||
| 2d4e0fcfd3 | |||
| 4fa95de91c | |||
| 24e0ca5377 | |||
| e1a17d428f | |||
| 8e3ba36a4f | |||
| 12bc84163d | |||
| 5221ac2d55 | |||
| af8e258ebb | |||
| d1356c1d76 | |||
| 3f3bab4e71 | |||
| f089d8d247 | |||
| 25d2f4b1f6 | |||
| 020fc66ad9 | |||
| 6d0b53ff16 | |||
| 192f83164c | |||
| 78d8be311c | |||
| 70c5f3bff8 | |||
| 49aad1d157 | |||
| 04bd268745 | |||
| 959883ad03 | |||
| 52446eed6d | |||
| e8eeb52636 | |||
| a323147819 | |||
| 89de70ff32 | |||
| 21364f38b0 | |||
| 51b19dfd1a | |||
| 3b90f60064 | |||
| 7d1de34533 | |||
| d5e43a9ab1 | |||
| 3787b89447 | |||
| 8fef7880e7 | |||
| a8eb3ff77f | |||
| 38ce56f252 | |||
| 5191071581 | |||
| b6821ed942 | |||
| deeba53a24 | |||
| daae906162 | |||
| b252866393 | |||
| d52c5435a7 | |||
| 75a432833b | |||
| 5843be1557 | |||
| a04a975d3a | |||
| 996c62f4e0 | |||
| 3d63c29abd | |||
| b0b67ca610 | |||
| bf9f084d72 | |||
| 08bdc4e422 | |||
| eb0e64b2f3 | |||
| fd0fae4847 | |||
| cccd6c441c | |||
| 88d54d49b8 | |||
| 3d614bbc87 | |||
| 6e945f72f4 | |||
| 251bc882cf | |||
| f56a345ae9 | |||
| 76cc545d2a | |||
| eed4815953 | |||
| fa5ec0bae7 | |||
| 7572dc63db |
50
.github/CODEOWNERS
vendored
@ -9,13 +9,51 @@ lib/kokkos/* @stanmoore1
|
||||
lib/molfile/* @akohlmey
|
||||
lib/qmmm/* @akohlmey
|
||||
lib/vtk/* @rbberger
|
||||
lib/kim/* @ellio167
|
||||
|
||||
# packages
|
||||
src/KOKKOS @stanmoore1
|
||||
src/USER-CGSDK @akohlmey
|
||||
src/USER-COLVARS @giacomofiorin
|
||||
src/USER-OMP @akohlmey
|
||||
src/USER-QMMM @akohlmey
|
||||
# whole packages
|
||||
src/COMPRESS/* @akohlmey
|
||||
src/GPU/* @ndtrung81
|
||||
src/KOKKOS/* @stanmoore1
|
||||
src/KIM/* @ellio167
|
||||
src/LATTE/* @cnegre
|
||||
src/SPIN/* @julient31
|
||||
src/USER-CGDNA/* @ohenrich
|
||||
src/USER-CGSDK/* @akohlmey
|
||||
src/USER-COLVARS/* @giacomofiorin
|
||||
src/USER-DPD/* @timattox
|
||||
src/USER-INTEL/* @wmbrownintel
|
||||
src/USER-MANIFOLD/* @Pakketeretet2
|
||||
src/USER-MEAMC/* @martok
|
||||
src/USER-MOFFF/* @hheenen
|
||||
src/USER-MOLFILE/* @akohlmey
|
||||
src/USER-NETCDF/* @pastewka
|
||||
src/USER-PHONON/* @lingtikong
|
||||
src/USER-OMP/* @akohlmey
|
||||
src/USER-QMMM/* @akohlmey
|
||||
src/USER-REAXC/* @hasanmetin
|
||||
src/USER-TALLY/* @akohlmey
|
||||
src/USER-UEF/* @danicholson
|
||||
src/USER-VTK/* @rbberger
|
||||
|
||||
# individual files in packages
|
||||
src/GPU/pair_vashishta_gpu.* @andeplane
|
||||
src/KOKKOS/pair_vashishta_kokkos.* @andeplane
|
||||
src/MANYBODY/pair_vashishta_table.* @andeplane
|
||||
src/USER-MISC/fix_bond_react.* @jrgissing
|
||||
src/USER-MISC/*_grem.* @dstelter92
|
||||
|
||||
# tools
|
||||
tools/msi2lmp/* @akohlmey
|
||||
tools/emacs/* @HaoZeke
|
||||
|
||||
# cmake
|
||||
cmake/* @junghans @rbberger
|
||||
|
||||
# python
|
||||
python/* @rbberger
|
||||
|
||||
# docs
|
||||
doc/utils/*/* @rbberger
|
||||
doc/Makefile @rbberger
|
||||
doc/README @rbberger
|
||||
|
||||
17
README
@ -25,7 +25,7 @@ The LAMMPS distribution includes the following files and directories:
|
||||
README this file
|
||||
LICENSE the GNU General Public License (GPL)
|
||||
bench benchmark problems
|
||||
couple code coupling examples using LAMMPS as a library
|
||||
cmake CMake build system
|
||||
doc documentation
|
||||
examples simple test problems
|
||||
lib libraries LAMMPS can be linked with
|
||||
@ -36,7 +36,14 @@ tools pre- and post-processing tools
|
||||
|
||||
Point your browser at any of these files to get started:
|
||||
|
||||
doc/Manual.html the LAMMPS manual
|
||||
doc/Section_intro.html hi-level introduction to LAMMPS
|
||||
doc/Section_start.html how to build and use LAMMPS
|
||||
doc/Developer.pdf LAMMPS developer guide
|
||||
http://lammps.sandia.gov/doc/Manual.html the LAMMPS manual
|
||||
http://lammps.sandia.gov/doc/Intro.html hi-level introduction
|
||||
http://lammps.sandia.gov/doc/Build.html how to build LAMMPS
|
||||
http://lammps.sandia.gov/doc/Run_head.html how to run LAMMPS
|
||||
http://lammps.sandia.gov/doc/Developer.pdf LAMMPS developer guide
|
||||
|
||||
You can also create these doc pages locally:
|
||||
|
||||
% cd doc
|
||||
% make html # creates HTML pages in doc/html
|
||||
% make pdf # creates Manual.pdf and Developer.pdf
|
||||
|
||||
@ -1,22 +0,0 @@
|
||||
# - Find fftw2
|
||||
# Find the native FFTW2 headers and libraries.
|
||||
#
|
||||
# FFTW2_INCLUDE_DIRS - where to find fftw2.h, etc.
|
||||
# FFTW2_LIBRARIES - List of libraries when using fftw2.
|
||||
# FFTW2_FOUND - True if fftw2 found.
|
||||
#
|
||||
|
||||
find_path(FFTW2_INCLUDE_DIR fftw.h)
|
||||
|
||||
find_library(FFTW2_LIBRARY NAMES fftw)
|
||||
|
||||
set(FFTW2_LIBRARIES ${FFTW2_LIBRARY})
|
||||
set(FFTW2_INCLUDE_DIRS ${FFTW2_INCLUDE_DIR})
|
||||
|
||||
include(FindPackageHandleStandardArgs)
|
||||
# handle the QUIETLY and REQUIRED arguments and set FFTW2_FOUND to TRUE
|
||||
# if all listed variables are TRUE
|
||||
|
||||
find_package_handle_standard_args(FFTW2 DEFAULT_MSG FFTW2_LIBRARY FFTW2_INCLUDE_DIR)
|
||||
|
||||
mark_as_advanced(FFTW2_INCLUDE_DIR FFTW2_LIBRARY )
|
||||
25
cmake/Modules/FindFFTW3F.cmake
Normal file
@ -0,0 +1,25 @@
|
||||
# - Find fftw3f
|
||||
# Find the native FFTW3F headers and libraries.
|
||||
#
|
||||
# FFTW3F_INCLUDE_DIRS - where to find fftw3f.h, etc.
|
||||
# FFTW3F_LIBRARIES - List of libraries when using fftw3f.
|
||||
# FFTW3F_FOUND - True if fftw3f found.
|
||||
#
|
||||
|
||||
find_package(PkgConfig)
|
||||
|
||||
pkg_check_modules(PC_FFTW3F fftw3f)
|
||||
find_path(FFTW3F_INCLUDE_DIR fftw3.h HINTS ${PC_FFTW3F_INCLUDE_DIRS})
|
||||
|
||||
find_library(FFTW3F_LIBRARY NAMES fftw3f HINTS ${PC_FFTW3F_LIBRARY_DIRS})
|
||||
|
||||
set(FFTW3F_LIBRARIES ${FFTW3F_LIBRARY})
|
||||
set(FFTW3F_INCLUDE_DIRS ${FFTW3F_INCLUDE_DIR})
|
||||
|
||||
include(FindPackageHandleStandardArgs)
|
||||
# handle the QUIETLY and REQUIRED arguments and set FFTW3F_FOUND to TRUE
|
||||
# if all listed variables are TRUE
|
||||
|
||||
find_package_handle_standard_args(FFTW3F DEFAULT_MSG FFTW3F_LIBRARY FFTW3F_INCLUDE_DIR)
|
||||
|
||||
mark_as_advanced(FFTW3F_INCLUDE_DIR FFTW3F_LIBRARY )
|
||||
22
cmake/Modules/FindMSCG.cmake
Normal file
@ -0,0 +1,22 @@
|
||||
# - Find mscg
|
||||
# Find the native MSCG headers and libraries.
|
||||
#
|
||||
# MSCG_INCLUDE_DIRS - where to find mscg.h, etc.
|
||||
# MSCG_LIBRARIES - List of libraries when using mscg.
|
||||
# MSCG_FOUND - True if mscg found.
|
||||
#
|
||||
|
||||
find_path(MSCG_INCLUDE_DIR mscg.h PATH_SUFFIXES mscg)
|
||||
|
||||
find_library(MSCG_LIBRARY NAMES mscg)
|
||||
|
||||
set(MSCG_LIBRARIES ${MSCG_LIBRARY})
|
||||
set(MSCG_INCLUDE_DIRS ${MSCG_INCLUDE_DIR})
|
||||
|
||||
include(FindPackageHandleStandardArgs)
|
||||
# handle the QUIETLY and REQUIRED arguments and set MSCG_FOUND to TRUE
|
||||
# if all listed variables are TRUE
|
||||
|
||||
find_package_handle_standard_args(MSCG DEFAULT_MSG MSCG_LIBRARY MSCG_INCLUDE_DIR)
|
||||
|
||||
mark_as_advanced(MSCG_INCLUDE_DIR MSCG_LIBRARY )
|
||||
@ -1,8 +1,8 @@
|
||||
# - Find quip
|
||||
# Find the native QUIP libraries.
|
||||
#
|
||||
# QUIP_LIBRARIES - List of libraries when using fftw3.
|
||||
# QUIP_FOUND - True if fftw3 found.
|
||||
# QUIP_LIBRARIES - List of libraries of the QUIP package
|
||||
# QUIP_FOUND - True if QUIP library was found.
|
||||
#
|
||||
|
||||
find_library(QUIP_LIBRARY NAMES quip)
|
||||
|
||||
46
cmake/Modules/FindTBB.cmake
Normal file
@ -0,0 +1,46 @@
|
||||
# - Find parts of TBB
|
||||
# Find the native TBB headers and libraries.
|
||||
#
|
||||
# TBB_INCLUDE_DIRS - where to find tbb.h, etc.
|
||||
# TBB_LIBRARIES - List of libraries when using tbb.
|
||||
# TBB_FOUND - True if tbb found.
|
||||
#
|
||||
|
||||
########################################################
|
||||
# TBB
|
||||
|
||||
# TODO use more generic FindTBB
|
||||
|
||||
find_path(TBB_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
|
||||
find_library(TBB_LIBRARY NAMES tbb PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
|
||||
$ENV{TBBROOT}/lib/intel64/gcc4.4
|
||||
$ENV{TBBROOT}/lib/intel64/gcc4.1)
|
||||
set(TBB_LIBRARIES ${TBB_LIBRARY})
|
||||
set(TBB_INCLUDE_DIRS ${TBB_INCLUDE_DIR})
|
||||
|
||||
include(FindPackageHandleStandardArgs)
|
||||
# handle the QUIETLY and REQUIRED arguments and set TBB_FOUND to TRUE
|
||||
# if all listed variables are TRUE
|
||||
|
||||
find_package_handle_standard_args(TBB DEFAULT_MSG TBB_LIBRARY TBB_INCLUDE_DIR)
|
||||
|
||||
mark_as_advanced(TBB_INCLUDE_DIR TBB_LIBRARY )
|
||||
|
||||
########################################################
|
||||
# TBB Malloc
|
||||
|
||||
find_path(TBB_MALLOC_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
|
||||
find_library(TBB_MALLOC_LIBRARY NAMES tbbmalloc PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
|
||||
$ENV{TBBROOT}/lib/intel64/gcc4.4
|
||||
$ENV{TBBROOT}/lib/intel64/gcc4.1)
|
||||
|
||||
set(TBB_MALLOC_LIBRARIES ${TBB_MALLOC_LIBRARY})
|
||||
set(TBB_MALLOC_INCLUDE_DIRS ${TBB_MALLOC_INCLUDE_DIR})
|
||||
|
||||
include(FindPackageHandleStandardArgs)
|
||||
# handle the QUIETLY and REQUIRED arguments and set TBB_MALLOC_FOUND to TRUE
|
||||
# if all listed variables are TRUE
|
||||
|
||||
find_package_handle_standard_args(TBB_MALLOC DEFAULT_MSG TBB_MALLOC_LIBRARY TBB_MALLOC_INCLUDE_DIR)
|
||||
|
||||
mark_as_advanced(TBB_MALLOC_INCLUDE_DIR TBB_MALLOC_LIBRARY )
|
||||
@ -45,14 +45,10 @@ function(FindStyleHeadersExt path style_class extension headers sources)
|
||||
endfunction(FindStyleHeadersExt)
|
||||
|
||||
function(CreateStyleHeader path filename)
|
||||
math(EXPR N "${ARGC}-2")
|
||||
|
||||
set(temp "")
|
||||
if(N GREATER 0)
|
||||
math(EXPR ARG_END "${ARGC}-1")
|
||||
|
||||
foreach(IDX RANGE 2 ${ARG_END})
|
||||
list(GET ARGV ${IDX} FNAME)
|
||||
if(ARGC GREATER 2)
|
||||
list(REMOVE_AT ARGV 0 1)
|
||||
foreach(FNAME ${ARGV})
|
||||
get_filename_component(FNAME ${FNAME} NAME)
|
||||
set(temp "${temp}#include \"${FNAME}\"\n")
|
||||
endforeach()
|
||||
@ -107,35 +103,6 @@ function(RegisterStyles search_path)
|
||||
FindStyleHeaders(${search_path} REGION_CLASS region_ REGION ) # region ) # domain
|
||||
endfunction(RegisterStyles)
|
||||
|
||||
function(RemovePackageHeader headers pkg_header)
|
||||
get_property(hlist GLOBAL PROPERTY ${headers})
|
||||
list(REMOVE_ITEM hlist ${pkg_header})
|
||||
set_property(GLOBAL PROPERTY ${headers} "${hlist}")
|
||||
endfunction(RemovePackageHeader)
|
||||
|
||||
function(DetectAndRemovePackageHeader fname)
|
||||
RemovePackageHeader(ANGLE ${fname})
|
||||
RemovePackageHeader(ATOM_VEC ${fname})
|
||||
RemovePackageHeader(BODY ${fname})
|
||||
RemovePackageHeader(BOND ${fname})
|
||||
RemovePackageHeader(COMMAND ${fname})
|
||||
RemovePackageHeader(COMPUTE ${fname})
|
||||
RemovePackageHeader(DIHEDRAL ${fname})
|
||||
RemovePackageHeader(DUMP ${fname})
|
||||
RemovePackageHeader(FIX ${fname})
|
||||
RemovePackageHeader(IMPROPER ${fname})
|
||||
RemovePackageHeader(INTEGRATE ${fname})
|
||||
RemovePackageHeader(KSPACE ${fname})
|
||||
RemovePackageHeader(MINIMIZE ${fname})
|
||||
RemovePackageHeader(NBIN ${fname})
|
||||
RemovePackageHeader(NPAIR ${fname})
|
||||
RemovePackageHeader(NSTENCIL ${fname})
|
||||
RemovePackageHeader(NTOPO ${fname})
|
||||
RemovePackageHeader(PAIR ${fname})
|
||||
RemovePackageHeader(READER ${fname})
|
||||
RemovePackageHeader(REGION ${fname})
|
||||
endfunction(DetectAndRemovePackageHeader)
|
||||
|
||||
function(RegisterStylesExt search_path extension sources)
|
||||
FindStyleHeadersExt(${search_path} ANGLE_CLASS ${extension} ANGLE ${sources})
|
||||
FindStyleHeadersExt(${search_path} ATOM_CLASS ${extension} ATOM_VEC ${sources})
|
||||
@ -181,3 +148,21 @@ function(GenerateStyleHeaders output_path)
|
||||
GenerateStyleHeader(${output_path} READER reader ) # read_dump
|
||||
GenerateStyleHeader(${output_path} REGION region ) # domain
|
||||
endfunction(GenerateStyleHeaders)
|
||||
|
||||
function(DetectBuildSystemConflict lammps_src_dir)
|
||||
if(ARGC GREATER 1)
|
||||
list(REMOVE_AT ARGV 0)
|
||||
foreach(SRC_FILE ${ARGV})
|
||||
get_filename_component(FILENAME ${SRC_FILE} NAME)
|
||||
if(EXISTS ${lammps_src_dir}/${FILENAME})
|
||||
message(FATAL_ERROR "\n########################################################################\n"
|
||||
"Found package(s) installed by the make-based build system\n"
|
||||
"\n"
|
||||
"Please run\n"
|
||||
"make -C ${lammps_src_dir} no-all purge\n"
|
||||
"to uninstall\n"
|
||||
"########################################################################")
|
||||
endif()
|
||||
endforeach()
|
||||
endif()
|
||||
endfunction(DetectBuildSystemConflict)
|
||||
|
||||
1758
cmake/README.md
2
cmake/etc/profile.d/lammps.csh.in
Normal file
@ -0,0 +1,2 @@
|
||||
# set environment for LAMMPS executables to find potential files
|
||||
if ( "$?LAMMPS_POTENTIALS" == 0 ) setenv LAMMPS_POTENTIALS @LAMMPS_POTENTIALS_DIR@
|
||||
2
cmake/etc/profile.d/lammps.sh.in
Normal file
@ -0,0 +1,2 @@
|
||||
# set environment for LAMMPS executables to find potential files
|
||||
export LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}
|
||||
@ -13,6 +13,6 @@ Description: Large-scale Atomic/Molecular Massively Parallel Simulator Library
|
||||
URL: http://lammps.sandia.gov
|
||||
Version:
|
||||
Requires:
|
||||
Libs: -L${libdir} -llammps@LAMMPS_MACHINE@
|
||||
Libs: -L${libdir} -llammps@LIB_SUFFIX@@
|
||||
Libs.private: -lm
|
||||
Cflags: -I${includedir} @LAMMPS_API_DEFINES@
|
||||
|
||||
22
cmake/presets/all_off.cmake
Normal file
@ -0,0 +1,22 @@
|
||||
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
||||
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
|
||||
MOLECULE MPIIO MSCG OPT PERI POEMS
|
||||
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
|
||||
|
||||
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
|
||||
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
foreach(PKG ${ALL_PACKAGES})
|
||||
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
22
cmake/presets/all_on.cmake
Normal file
@ -0,0 +1,22 @@
|
||||
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
||||
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
|
||||
MOLECULE MPIIO MSCG OPT PERI POEMS
|
||||
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
|
||||
|
||||
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
|
||||
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
foreach(PKG ${ALL_PACKAGES})
|
||||
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
69
cmake/presets/manual_selection.cmake
Normal file
@ -0,0 +1,69 @@
|
||||
set(PKG_ASPHERE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_BODY OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_CLASS2 OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_COLLOID OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_COMPRESS OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_CORESHELL OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_DIPOLE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_GPU OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_GRANULAR OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_KIM OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_KOKKOS OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_KSPACE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_LATTE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_LIB OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MANYBODY OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MEAM OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MISC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MOLECULE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MPIIO OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_MSCG OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_OPT OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_PERI OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_POEMS OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_PYTHOFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_QEQ OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_REAX OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_REPLICA OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_RIGID OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_SHOCK OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_SNAP OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_SRD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_VOROFFOI OFF CACHE BOOL "" FORCE)
|
||||
|
||||
set(PKG_USER OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-ATC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-AWPMD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-BOCS OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-CGDNA OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-CGSDK OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-COLVARS OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-DIFFRACTIOFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-DPD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-DRUDE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-EFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-FEP OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-H5MD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-INTEL OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-LB OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MANIFOLD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MEAMC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MESO OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MGPT OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MISC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-TALLY OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-UEF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-VTK OFF CACHE BOOL "" FORCE)
|
||||
22
cmake/presets/nolib.cmake
Normal file
@ -0,0 +1,22 @@
|
||||
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
||||
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
|
||||
MOLECULE MPIIO MSCG OPT PERI POEMS
|
||||
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
|
||||
|
||||
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
|
||||
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
foreach(PKG ${PACKAGES_WITH_LIB})
|
||||
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
22
cmake/presets/std.cmake
Normal file
@ -0,0 +1,22 @@
|
||||
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
||||
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
|
||||
MOLECULE MPIIO MSCG OPT PERI POEMS
|
||||
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
|
||||
|
||||
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
|
||||
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
foreach(PKG ${STANDARD_PACKAGES})
|
||||
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
26
cmake/presets/std_nolib.cmake
Normal file
@ -0,0 +1,26 @@
|
||||
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
||||
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
|
||||
MOLECULE MPIIO MSCG OPT PERI POEMS
|
||||
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
|
||||
|
||||
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
|
||||
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
foreach(PKG ${STANDARD_PACKAGES})
|
||||
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
|
||||
foreach(PKG ${PACKAGES_WITH_LIB})
|
||||
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
22
cmake/presets/user.cmake
Normal file
@ -0,0 +1,22 @@
|
||||
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
|
||||
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
|
||||
MOLECULE MPIIO MSCG OPT PERI POEMS
|
||||
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
|
||||
|
||||
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
|
||||
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
foreach(PKG ${USER_PACKAGES})
|
||||
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
|
||||
endforeach()
|
||||
15
doc/Makefile
@ -9,6 +9,7 @@ TXT2RST = $(VENV)/bin/txt2rst
|
||||
ANCHORCHECK = $(VENV)/bin/doc_anchor_check
|
||||
|
||||
PYTHON = $(shell which python3)
|
||||
VIRTUALENV = virtualenv
|
||||
HAS_PYTHON3 = NO
|
||||
HAS_VIRTUALENV = NO
|
||||
|
||||
@ -16,7 +17,13 @@ ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
|
||||
HAS_PYTHON3 = YES
|
||||
endif
|
||||
|
||||
ifeq ($(shell which virtualenv-3 >/dev/null 2>&1; echo $$?), 0)
|
||||
VIRTUALENV = virtualenv-3
|
||||
HAS_VIRTUALENV = YES
|
||||
endif
|
||||
|
||||
ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
|
||||
VIRTUALENV = virtualenv
|
||||
HAS_VIRTUALENV = YES
|
||||
endif
|
||||
|
||||
@ -42,11 +49,11 @@ help:
|
||||
|
||||
# ------------------------------------------
|
||||
|
||||
clean-all:
|
||||
clean-all: clean
|
||||
rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
|
||||
|
||||
clean:
|
||||
rm -rf $(RSTDIR) html
|
||||
rm -rf $(RSTDIR) html old epub
|
||||
rm -rf spelling
|
||||
|
||||
clean-spelling:
|
||||
@ -150,7 +157,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
|
||||
@(\
|
||||
mkdir -p $(RSTDIR) ; \
|
||||
. $(VENV)/bin/activate ;\
|
||||
txt2rst $< > $@ ;\
|
||||
txt2rst -v $< > $@ ;\
|
||||
deactivate ;\
|
||||
)
|
||||
|
||||
@ -158,7 +165,7 @@ $(VENV):
|
||||
@if [ "$(HAS_PYTHON3)" == "NO" ] ; then echo "Python3 was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
|
||||
@if [ "$(HAS_VIRTUALENV)" == "NO" ] ; then echo "virtualenv was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
|
||||
@( \
|
||||
virtualenv -p $(PYTHON) $(VENV); \
|
||||
$(VIRTUALENV) -p $(PYTHON) $(VENV); \
|
||||
. $(VENV)/bin/activate; \
|
||||
pip install Sphinx; \
|
||||
pip install sphinxcontrib-images; \
|
||||
|
||||
49
doc/src/Build.txt
Normal file
@ -0,0 +1,49 @@
|
||||
"Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run_head.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS :h2
|
||||
|
||||
LAMMPS can be built as an executable or library from source code via
|
||||
either traditional makefiles (which may require manual editing)
|
||||
for use with GNU make or gmake, or a build environment generated by CMake
|
||||
(Unix Makefiles, Xcode, Visual Studio, KDevelop or more). As an
|
||||
alternative you can download a package with pre-built executables
|
||||
as described on the "Install"_Install.html doc page.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Build_cmake
|
||||
Build_make
|
||||
Build_link
|
||||
Build_basics
|
||||
Build_settings
|
||||
Build_package
|
||||
Build_extras
|
||||
Build_windows
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Build LAMMPS with CMake"_Build_cmake.html
|
||||
"Build LAMMPS with make"_Build_make.html
|
||||
"Link LAMMPS as a library to another code"_Build_link.html
|
||||
"Basic build options"_Build_basics.html
|
||||
"Optional build settings"_Build_settings.html
|
||||
"Include packages in build"_Build_package.html
|
||||
"Packages with extra build options"_Build_extras.html
|
||||
"Notes for building LAMMPS on Windows"_Build_windows.html :all(b)
|
||||
|
||||
If you have problems building LAMMPS, it is often due to software
|
||||
issues on your local machine. If you can, find a local expert to
|
||||
help. If you're still stuck, send an email to the "LAMMPS mail
|
||||
list"_http://lammps.sandia.gov/mail.html.
|
||||
315
doc/src/Build_basics.txt
Normal file
@ -0,0 +1,315 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Basic build options :h3
|
||||
|
||||
The following topics are covered on this page, for building both with
|
||||
CMake and make:
|
||||
|
||||
"Serial vs parallel build"_#serial
|
||||
"Choice of compiler and compile/link options"_#compile
|
||||
"Build LAMMPS as an executable or a library"_#exe
|
||||
"Build the LAMMPS documentation"_#doc
|
||||
"Install LAMMPS after a build"_#install :ul
|
||||
|
||||
:line
|
||||
|
||||
Serial vs parallel build :h4,link(serial)
|
||||
|
||||
LAMMPS can be built to run in parallel using the ubiquitous "MPI
|
||||
(message-passing
|
||||
interface)"_https://en.wikipedia.org/wiki/Message_Passing_Interface
|
||||
library. Or it can built to run on a single processor (serial)
|
||||
without MPI. It can also be built with support for OpenMP threading
|
||||
(see more discussion below).
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D BUILD_MPI=value # yes or no, default is yes if CMake finds MPI, else no
|
||||
-D BUILD_OMP=value # yes or no (default)
|
||||
-D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
|
||||
# no default value :pre
|
||||
|
||||
The executable created by CMake (after running make) is lmp_name. If
|
||||
the LAMMPS_MACHINE variable is not specified, the executable is just
|
||||
lmp. Using BUILD_MPI=no will produce a serial executable.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
cd lammps/src
|
||||
make mpi # parallel build, produces lmp_mpi using Makefile.mpi
|
||||
make serial # serial build, produces lmp_serial using Makefile/serial
|
||||
make mybox :pre # uses Makefile.mybox to produce lmp_mybox :pre
|
||||
|
||||
Serial build (see src/MAKE/Makefile.serial):
|
||||
|
||||
MPI_INC = -I../STUBS
|
||||
MPI_PATH = -L../STUBS
|
||||
MPI_LIB = -lmpi_stubs :pre
|
||||
|
||||
For a parallel build, if MPI is installed on your system in the usual
|
||||
place (e.g. under /usr/local), you do not need to specify the 3
|
||||
variables MPI_INC, MPI_PATH, MPI_LIB. The MPI wrapper on the compiler
|
||||
(e.g. mpicxx, mpiCC) knows where to find the needed include and
|
||||
library files. Failing this, these 3 variables can be used to specify
|
||||
where the mpi.h file (MPI_INC), and the MPI library files (MPI_PATH)
|
||||
are found, and the name of the library files (MPI_LIB).
|
||||
|
||||
For a serial build, you need to specify the 3 varaibles, as shown
|
||||
above.
|
||||
|
||||
For a serial LAMMPS build, use the dummy MPI library provided in
|
||||
src/STUBS. You also need to build the STUBS library for your platform
|
||||
before making LAMMPS itself. A "make serial" build does this for.
|
||||
Otherwise, type "make mpi-stubs" from the src directory, or "make"
|
||||
from the src/STUBS dir. If the build fails, you will need to edit the
|
||||
STUBS/Makefile for your platform.
|
||||
|
||||
The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
|
||||
that calls gettimeofday() . If your system doesn't support
|
||||
gettimeofday() , you'll need to insert code to call another timer.
|
||||
Note that the ANSI-standard function clock() rolls over after an hour
|
||||
or so, and is therefore insufficient for timing long LAMMPS
|
||||
simulations.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
If you are installing MPI yourself, we recommend MPICH2 from Argonne
|
||||
National Laboratory or OpenMPI. MPICH can be downloaded from the
|
||||
"Argonne MPI site"_http://www.mcs.anl.gov/research/projects/mpich2/.
|
||||
OpenMPI can be downloaded from the "OpenMPI
|
||||
site"_http://www.open-mpi.org. Other MPI packages should also work.
|
||||
If you are running on a large parallel machine, your system admins or
|
||||
the vendor should have already installed a version of MPI, which is
|
||||
likely to be faster than a self-installed MPICH or OpenMPI, so find
|
||||
out how to build and link with it.
|
||||
|
||||
The majority of OpenMP (threading) support in LAMMPS is provided by
|
||||
the USER-OMP package; see the "Speed omp"_Speed_omp.html doc page for
|
||||
details. The USER-INTEL package also provides OpenMP support (it is
|
||||
compatible with USER-OMP) and adds vectorization support when compiled
|
||||
with the Intel compilers on top of that. Also, the KOKKOS package can
|
||||
be compiled for using OpenMP threading.
|
||||
|
||||
However, there are a few commands in LAMMPS that have native OpenMP
|
||||
support. These are commands in the MPIIO, SNAP, USER-DIFFRACTION, and
|
||||
USER-DPD packages. In addition some packages support OpenMP threading
|
||||
indirectly through the libraries they interface to: e.g. LATTE and
|
||||
USER-COLVARS. See the "Packages details"_Packages_details.html doc
|
||||
page for more info on these packages and the doc pages for their
|
||||
respective commands for OpenMP threading info.
|
||||
|
||||
For CMake, if you use BUILD_OMP=yes, you can use these packages and
|
||||
turn on their native OpenMP support and turn on their native OpenMP
|
||||
support at run time, by setting the OMP_NUM_THREADS environment
|
||||
variable before you launch LAMMPS.
|
||||
|
||||
For building via conventional make, the CCFLAGS and LINKFLAGS
|
||||
variables in Makefile.machine need to include the compiler flag that
|
||||
enables OpenMP. For GNU compilers it is -fopenmp. For (recent) Intel
|
||||
compilers it is -qopenmp. If you are using a different compiler,
|
||||
please refer to its documentation.
|
||||
|
||||
:line
|
||||
|
||||
Choice of compiler and compile/link options :h4,link(compile)
|
||||
|
||||
The choice of compiler and compiler flags can be important for
|
||||
performance. Vendor compilers can produce faster code than
|
||||
open-source compilers like GNU. On boxes with Intel CPUs, we suggest
|
||||
trying the "Intel C++ compiler"_intel.
|
||||
|
||||
:link(intel,https://software.intel.com/en-us/intel-compilers)
|
||||
|
||||
On parallel clusters or supercomputers which use "modules" for their
|
||||
compile/link environments, you can often access different compilers by
|
||||
simply loading the appropriate module before building LAMMPS.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D CMAKE_CXX_COMPILER=name # name of C++ compiler
|
||||
-D CMAKE_C_COMPILER=name # name of C compiler
|
||||
-D CMAKE_Fortran_COMPILER=name # name of Fortran compiler :pre
|
||||
|
||||
-D CMAKE_CXX_FlAGS=string # flags to use with C++ compiler
|
||||
-D CMAKE_C_FlAGS=string # flags to use with C compiler
|
||||
-D CMAKE_Fortran_FlAGS=string # flags to use with Fortran compiler :pre
|
||||
|
||||
By default CMake will use a compiler it finds and it will add
|
||||
optimization flags appropriate to that compiler and any "accelerator
|
||||
packages"_Speed_packages.html you have included in the build.
|
||||
|
||||
You can tell CMake to look for a specific compiler with these varaible
|
||||
settings. Likewise you can specify the FLAGS variables if you want to
|
||||
experiment with alternate optimization flags. You should specify all
|
||||
3 compilers, so that the small number of LAMMPS source files written
|
||||
in C or Fortran are built with a compiler consistent with the one used
|
||||
for all the C++ files:
|
||||
|
||||
Building with GNU Compilers:
|
||||
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
|
||||
Building with Intel Compilers:
|
||||
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
|
||||
Building with LLVM/Clang Compilers:
|
||||
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang :pre
|
||||
|
||||
NOTE: When the cmake command completes, it prints info to the screen
|
||||
as to which compilers it is using, and what flags will be used in the
|
||||
compilation. Note that if the top-level compiler is mpicxx, it is
|
||||
simply a wrapper on a real compiler. The underlying compiler info is
|
||||
what will be listed in the CMake output. You should check to insure
|
||||
you are using the compiler and optimization flags are the ones you
|
||||
want.
|
||||
|
||||
[Makefile.machine settings]:
|
||||
|
||||
Parallel build (see src/MAKE/Makefile.mpi):
|
||||
|
||||
CC = mpicxx
|
||||
CCFLAGS = -g -O3
|
||||
LINK = mpicxx
|
||||
LINKFLAGS = -g -O :pre
|
||||
|
||||
Serial build (see src/MAKE/Makefile.serial):
|
||||
|
||||
CC = g++
|
||||
CCFLAGS = -g -O3
|
||||
LINK = g++
|
||||
LINKFLAGS = -g -O :pre
|
||||
|
||||
The "compiler/linker settings" section of a Makefile.machine lists
|
||||
compiler and linker settings for your C++ compiler, including
|
||||
optimization flags. You should always use mpicxx or mpiCC for
|
||||
a parallel build, since these compiler wrappers will include
|
||||
a variety of settings appropriate for your MPI installation.
|
||||
|
||||
NOTE: If you build LAMMPS with any "accelerator
|
||||
packages"_Speed_packages.html included, they have specific
|
||||
optimization flags that are either required or recommended for optimal
|
||||
performance. You need to include these in the CCFLAGS and LINKFLAGS
|
||||
settings above. For details, see the individual package doc pages
|
||||
listed on the "Speed packages"_Speed_packages.html doc page. Or
|
||||
examine these files in the src/MAKE/OPTIONS directory. They
|
||||
correspond to each of the 5 accelerator packages and their hardware
|
||||
variants:
|
||||
|
||||
Makefile.opt # OPT package
|
||||
Makefile.omp # USER-OMP package
|
||||
Makefile.intel_cpu # USER-INTEL package for CPUs
|
||||
Makefile.intel_coprocessor # USER-INTEL package for KNLs
|
||||
Makefile.gpu # GPU package
|
||||
Makefile.kokkos_cuda_mpi # KOKKOS package for GPUs
|
||||
Makefile.kokkos_omp # KOKKOS package for CPUs (OpenMP)
|
||||
Makefile.kokkos_phi # KOKKOS package for KNLs (OpenMP) :pre
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS as an executable or a library :h4,link(exe)
|
||||
|
||||
LAMMPS can be built as either an executable or as a static or shared
|
||||
library. The LAMMPS library can be called from another application or
|
||||
a scripting language. See the "Howto couple"_Howto_couple.html doc
|
||||
page for more info on coupling LAMMPS to other codes. See the
|
||||
"Python"_Python doc page for more info on wrapping and running LAMMPS
|
||||
from Python via its library interface.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D BUILD_EXE=value # yes (default) or no
|
||||
-D BUILD_LIB=value # yes or no (default)
|
||||
-D BUILD_SHARED_LIBS=value # yes or no (default) :pre
|
||||
|
||||
Setting BUILD_EXE=no will not produce an executable. Setting
|
||||
BUILD_LIB=yes will produce a static library named liblammps.a.
|
||||
Setting both BUILD_LIB=yes and BUILD_SHARED_LIBS=yes will produce a
|
||||
shared library named liblammps.so.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
cd lammps/src
|
||||
make machine # build LAMMPS executable lmp_machine
|
||||
make mode=lib machine # build LAMMPS static lib liblammps_machine.a
|
||||
make mode=shlib machine # build LAMMPS shared lib liblammps_machine.so :pre
|
||||
|
||||
The two library builds also create generic soft links, named
|
||||
liblammps.a and liblammps.so, which point to the liblammps_machine
|
||||
files.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
Note that for a shared library to be usable by a calling program, all
|
||||
the auxiliary libraries it depends on must also exist as shared
|
||||
libraries. This will be the case for libraries included with LAMMPS,
|
||||
such as the dummy MPI library in src/STUBS or any package libraries in
|
||||
the lib/packages directroy, since they are always built as shared
|
||||
libraries using the -fPIC switch. However, if a library like MPI or
|
||||
FFTW does not exist as a shared library, the shared library build will
|
||||
generate an error. This means you will need to install a shared
|
||||
library version of the auxiliary library. The build instructions for
|
||||
the library should tell you how to do this.
|
||||
|
||||
As an example, here is how to build and install the "MPICH
|
||||
library"_mpich, a popular open-source version of MPI, distributed by
|
||||
Argonne National Lab, as a shared library in the default
|
||||
/usr/local/lib location:
|
||||
|
||||
:link(mpich,http://www-unix.mcs.anl.gov/mpi)
|
||||
|
||||
./configure --enable-shared
|
||||
make
|
||||
make install :pre
|
||||
|
||||
You may need to use "sudo make install" in place of the last line if
|
||||
you do not have write privileges for /usr/local/lib. The end result
|
||||
should be the file /usr/local/lib/libmpich.so.
|
||||
|
||||
:line
|
||||
|
||||
Build the LAMMPS documentation :h4,link(doc)
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D BUILD_DOC=value # yes or no (default) :pre
|
||||
|
||||
This will create the HTML doc pages within the CMake build directory.
|
||||
The reason to do this is if you want to "install" LAMMPS on a system
|
||||
after the CMake build via "make install", and include the doc pages in
|
||||
the install.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
cd lammps/doc
|
||||
make html # html doc pages
|
||||
make pdf # single Manual.pdf file :pre
|
||||
|
||||
This will create a lammps/doc/html dir with the HTML doc pages so that
|
||||
you can browse them locally on your system. Type "make" from the
|
||||
lammps/doc dir to see other options.
|
||||
|
||||
:line
|
||||
|
||||
Install LAMMPS after a build :h4,link(install)
|
||||
|
||||
After building LAMMPS, you may wish to copy the LAMMPS executable of
|
||||
library, along with other LAMMPS files (library header, doc files) to
|
||||
a globally visible place on your system, for others to access. Note
|
||||
that you may need super-user priveleges (e.g. sudo) if the directory
|
||||
you want to copy files to is protected.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
cmake -D CMAKE_INSTALL_PREFIX=path \[options ...\] ../cmake
|
||||
make # perform make after CMake command
|
||||
make install # perform the installation into prefix :pre
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
There is no "install" option in the src/Makefile for LAMMPS. If you
|
||||
wish to do this you will need to first build LAMMPS, then manually
|
||||
copy the desired LAMMPS files to the appropriate system directories.
|
||||
196
doc/src/Build_cmake.txt
Normal file
@ -0,0 +1,196 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS with CMake :h3
|
||||
|
||||
This page is a short summary of how to use CMake to build LAMMPS.
|
||||
Details on CMake variables that enable specific LAMMPS build options
|
||||
are given on the pages linked to from the "Build"_Build.html doc page.
|
||||
|
||||
Richard Berger (Temple U) has also written a "more comprehensive
|
||||
guide"_https://github.com/lammps/lammps/blob/master/cmake/README.md
|
||||
for how to use CMake to build LAMMPS. If you are new to CMake it is a
|
||||
good place to start.
|
||||
|
||||
:line
|
||||
|
||||
Building LAMMPS with CMake is a two-step process. First you use CMake
|
||||
to create a build environment in a new directory. On Linux systems,
|
||||
this will be based on makefiles for use with make. Then you use the
|
||||
make command to build LAMMPS, which uses the created
|
||||
Makefile(s). Example:
|
||||
|
||||
cd lammps # change to the LAMMPS distribution directory
|
||||
mkdir build; cd build # create a new directory (folder) for build
|
||||
cmake ../cmake \[options ...\] # configuration with (command-line) cmake
|
||||
make # compilation :pre
|
||||
|
||||
The cmake command will detect available features, enable selected
|
||||
packages and options, and will generate the build environment. The make
|
||||
command will then compile and link LAMMPS, producing (by default) an
|
||||
executable called "lmp" and a library called "liblammps.a" in the
|
||||
"build" folder.
|
||||
|
||||
If your machine has multiple CPU cores (most do these days), using a
|
||||
command like "make -jN" (with N being the number of available local
|
||||
CPU cores) can be much faster. If you plan to do development on
|
||||
LAMMPS or need to recompile LAMMPS repeatedly, installation of the
|
||||
ccache (= Compiler Cache) software may speed up compilation even more.
|
||||
|
||||
After compilation, you can optionally copy the LAMMPS executable and
|
||||
library into your system folders (by default under /usr/local) with:
|
||||
|
||||
make install # optional, copy LAMMPS executable & library elsewhere :pre
|
||||
|
||||
:line
|
||||
|
||||
There are 3 variants of CMake: a command-line verison (cmake), a text mode
|
||||
UI version (ccmake), and a graphical GUI version (cmake-GUI). You can use
|
||||
any of them interchangeably to configure and create the LAMMPS build
|
||||
environment. On Linux all the versions produce a Makefile as their
|
||||
output. See more details on each below.
|
||||
|
||||
You can specify a variety of options with any of the 3 versions, which
|
||||
affect how the build is performed and what is included in the LAMMPS
|
||||
executable. Links to pages explaining all the options are listed on
|
||||
the "Build"_Build.html doc page.
|
||||
|
||||
You must perform the CMake build system generation and compilation in
|
||||
a new directory you create. It can be anywhere on your local machine.
|
||||
In these Build pages we assume that you are building in a directory
|
||||
called "lammps/build". You can perform separate builds independently
|
||||
with different options, so long as you perform each of them in a
|
||||
separate directory you create. All the auxiliary files created by one
|
||||
build process (executable, object files, log files, etc) are stored in
|
||||
this directory or sub-directories within it that CMake creates.
|
||||
|
||||
NOTE: To perform a CMake build, no packages can be installed or a
|
||||
build been previously attempted in the LAMMPS src directory by using
|
||||
"make" commands to "perform a conventional LAMMPS
|
||||
build"_Build_make.html. CMake detects if this is the case and
|
||||
generates an error, telling you to type "make no-all purge" in the src
|
||||
directory to un-install all packages. The purge removes all the *.h
|
||||
files auto-generated by make.
|
||||
|
||||
You must have CMake version 2.8 or later on your system to build
|
||||
LAMMPS. A handful of LAMMPS packages (KOKKOS, LATTE, MSCG) require a
|
||||
later version. CMake will print a message telling you if a later
|
||||
version is required. Installation instructions for CMake are below.
|
||||
|
||||
After the initial build, if you edit LAMMPS source files, or add your
|
||||
own new files to the source directory, you can just re-type make from
|
||||
your build directory and it will re-compile only the files that have
|
||||
changed. If you want to change CMake options you can run cmake (or
|
||||
ccmake or cmake-gui) again from the same build directory and alter
|
||||
various options; see details below. Or you can remove the entire build
|
||||
folder, recreate the directory and start over.
|
||||
|
||||
:line
|
||||
|
||||
[Command-line version of CMake]:
|
||||
|
||||
cmake \[options ...\] /path/to/lammps/cmake # build from any dir
|
||||
cmake \[options ...\] ../cmake # build from lammps/build :pre
|
||||
|
||||
The cmake command takes one required argument, which is the LAMMPS
|
||||
cmake directory which contains the CMakeLists.txt file.
|
||||
|
||||
The argument can be preceeded or followed by various CMake
|
||||
command-line options. Several useful ones are:
|
||||
|
||||
-D CMAKE_INSTALL_PREFIX=path # where to install LAMMPS executable/lib if desired
|
||||
-D CMAKE_BUILD_TYPE=type # type = Release or Debug
|
||||
-G output # style of output CMake generates
|
||||
-DVARIABLE=value # setting for a LAMMPS feature to enable
|
||||
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir :pre
|
||||
|
||||
All the LAMMPS-specific -D variables that a LAMMPS build supports are
|
||||
described on the pages linked to from the "Build"_Build.html doc page.
|
||||
All of these variable names are upper-case and their values are
|
||||
lower-case, e.g. -D LAMMPS_SIZES=smallbig. For boolean values, any of
|
||||
these forms can be used: yes/no, on/off, 1/0.
|
||||
|
||||
On Unix/Linux machines, CMake generates a Makefile by default to
|
||||
perform the LAMMPS build. Alternate forms of build info can be
|
||||
generated via the -G switch, e.g. Visual Studio on a Windows machine,
|
||||
Xcode on MacOS, or KDevelop on Linux. Type "cmake --help" to see the
|
||||
"Generator" styles of output your system supports.
|
||||
|
||||
NOTE: When CMake runs, it prints configuration info to the screen.
|
||||
You should review this to verify all the features you requested were
|
||||
enabled, including packages. You can also see what compilers and
|
||||
compile options will be used for the build. Any errors in CMake
|
||||
variable syntax will also be flagged, e.g. mis-typed variable names or
|
||||
variable values.
|
||||
|
||||
CMake creates a CMakeCache.txt file when it runs. This stores all the
|
||||
settings, so that when running CMake again you can use the current
|
||||
folder '.' instead of the path to the LAMMPS cmake folder as the
|
||||
required argument to the CMake command. Either way the existing
|
||||
settings will be inherited unless the CMakeCache.txt file is removed.
|
||||
|
||||
If you later want to change a setting you can rerun cmake in the build
|
||||
directory with different setting. Please note that some automatically
|
||||
detected variables will not change their value when you rerun cmake.
|
||||
In these cases it is usually better to first remove all the
|
||||
files/directories in the build directory, or start with a fresh build
|
||||
directory.
|
||||
|
||||
:line
|
||||
|
||||
[Curses version (terminal-style menu) of CMake]:
|
||||
|
||||
ccmake ../cmake :pre
|
||||
|
||||
You initiate the configuration and build environment generation steps
|
||||
separately. For the first you have to type [c], for the second you
|
||||
have to type [g]. You may need to type [c] multiple times, and may be
|
||||
required to edit some of the entries of CMake configuration variables
|
||||
in between. Please see the "ccmake
|
||||
manual"_https://cmake.org/cmake/help/latest/manual/ccmake.1.html for
|
||||
more information.
|
||||
|
||||
:line
|
||||
|
||||
[GUI version of CMake]:
|
||||
|
||||
cmake-gui ../cmake :pre
|
||||
|
||||
You initiate the configuration and build environment generation steps
|
||||
separately. For the first you have to click on the [Configure] button,
|
||||
for the second you have to click on the [Generate] button. You may
|
||||
need to click on [Configure] multiple times, and may be required to
|
||||
edit some of the entries of CMake configuration variables in between.
|
||||
Please see the "cmake-gui
|
||||
manual"_https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html
|
||||
for more information.
|
||||
|
||||
:line
|
||||
|
||||
[Installing CMake]
|
||||
|
||||
Check if your machine already has CMake installed:
|
||||
|
||||
which cmake # do you have it?
|
||||
which cmake3 # version 3 may have this name
|
||||
cmake --version # what specific version you have :pre
|
||||
|
||||
On clusters or supercomputers which use environment modules to manage
|
||||
software packages, do this:
|
||||
|
||||
module list # is a cmake module already loaded?
|
||||
module avail # is a cmake module available?
|
||||
module load cmake3 # load cmake module with appropriate name :pre
|
||||
|
||||
Most Linux distributions offer precompiled cmake packages through
|
||||
their package management system. If you do not have CMake or a new
|
||||
enough version, you can download the latest version at
|
||||
"https://cmake.org/download/"_https://cmake.org/download/.
|
||||
Instructions on how to install it on various platforms can be found
|
||||
"on this page"_https://cmake.org/install/.
|
||||
952
doc/src/Build_extras.txt
Normal file
@ -0,0 +1,952 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Packages with extra build options :h3
|
||||
|
||||
When building with some packages, additional steps may be required,
|
||||
in addition to:
|
||||
|
||||
-D PKG_NAME=yes # CMake
|
||||
make yes-name # make :pre
|
||||
|
||||
as described on the "Build_package"_Build_package.html doc page.
|
||||
|
||||
For a CMake build there may be additional optional or required
|
||||
variables to set. For a build with make, a provided library under the
|
||||
lammps/lib directory may need to be built first. Or an external
|
||||
library may need to exist on your system or be downloaded and built.
|
||||
You may need to tell LAMMPS where it is found on your system.
|
||||
|
||||
This is the list of packages that may require additional steps.
|
||||
|
||||
"COMPRESS"_#compress,
|
||||
"GPU"_#gpu,
|
||||
"KIM"_#kim,
|
||||
"KOKKOS"_#kokkos,
|
||||
"LATTE"_#latte,
|
||||
"MEAM"_#meam,
|
||||
"MSCG"_#mscg,
|
||||
"OPT"_#opt,
|
||||
"POEMS"_#poems,
|
||||
"PYTHON"_#python,
|
||||
"REAX"_#reax,
|
||||
"VORONOI"_#voronoi,
|
||||
"USER-ATC"_#user-atc,
|
||||
"USER-AWPMD"_#user-awpmd,
|
||||
"USER-COLVARS"_#user-colvars,
|
||||
"USER-H5MD"_#user-h5md,
|
||||
"USER-INTEL"_#user-intel,
|
||||
"USER-MOLFILE"_#user-molfile,
|
||||
"USER-NETCDF"_#user-netcdf,
|
||||
"USER-OMP"_#user-omp,
|
||||
"USER-QMMM"_#user-qmmm,
|
||||
"USER-QUIP"_#user-quip,
|
||||
"USER-SMD"_#user-smd,
|
||||
"USER-VTK"_#user-vtk :tb(c=6,ea=c,a=l)
|
||||
|
||||
:line
|
||||
|
||||
COMPRESS package :h4,link(compress)
|
||||
|
||||
To build with this package you must have the zlib compression library
|
||||
available on your system.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
If CMake cannot find the library, you can set these variables:
|
||||
|
||||
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
|
||||
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file :pre
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
If make cannot find the library, you can edit the
|
||||
lib/compress/Makefile.lammps file to specify the paths and library
|
||||
name.
|
||||
|
||||
:line
|
||||
|
||||
GPU package :h4,link(gpu)
|
||||
|
||||
To build with this package, you must choose options for precision and
|
||||
which GPU hardware to build for.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D GPU_API=value # value = opencl (default) or cuda
|
||||
-D GPU_PREC=value # precision setting
|
||||
# value = double or mixed (default) or single
|
||||
-D OCL_TUNE=value # hardware choice for GPU_API=opencl
|
||||
# generic (default) or intel (Intel CPU) or fermi, kepler, cypress (NVIDIA)
|
||||
-D GPU_ARCH=value # hardware choice for GPU_API=cuda
|
||||
# value = sm_XX, see below
|
||||
# default is Cuda-compiler dependent, but typically sm_20
|
||||
-D CUDPP_OPT=value # optimization setting for GPU_API=cudea
|
||||
# enables CUDA Performance Primitives Optimizations
|
||||
# yes (default) or no :pre
|
||||
|
||||
GPU_ARCH settings for different GPU hardware is as follows:
|
||||
|
||||
sm_20 for Fermi (C2050/C2070, deprecated as of CUDA 8.0) or GeForce GTX 580 or similar
|
||||
sm_30 for Kepler (K10)
|
||||
sm_35 for Kepler (K40) or GeForce GTX Titan or similar
|
||||
sm_37 for Kepler (dual K80)
|
||||
sm_50 for Maxwell
|
||||
sm_60 for Pascal (P100)
|
||||
sm_70 for Volta :ul
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the GPU library in lib/gpu.
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
lib/gpu/README. Note that the GPU library uses MPI calls, so you must
|
||||
use the same MPI library (or the STUBS library) settings as the main
|
||||
LAMMPS code. This also applies to the -DLAMMPS_BIGBIG,
|
||||
-DLAMMPS_SMALLBIG, or -DLAMMPS_SMALLSMALL settings in whichever
|
||||
Makefile you use.
|
||||
|
||||
You can also build the library in one step from the lammps/src dir,
|
||||
using a command like these, which simply invoke the lib/gpu/Install.py
|
||||
script with the specified args:
|
||||
|
||||
make lib-gpu # print help message
|
||||
make lib-gpu args="-b" # build GPU library with default Makefile.linux
|
||||
make lib-gpu args="-m xk7 -p single -o xk7.single" # create new Makefile.xk7.single, altered for single-precision
|
||||
make lib-gpu args="-m mpi -a sm_60 -p mixed -b" # build GPU library with mixed precision and P100 using other settings in Makefile.mpi :pre
|
||||
|
||||
Note that this procedure starts with a Makefile.machine in lib/gpu, as
|
||||
specified by the "-m" switch. For your convenience, machine makefiles
|
||||
for "mpi" and "serial" are provided, which have the same settings as
|
||||
the corresponding machine makefiles in the main LAMMPS source
|
||||
folder. In addition you can alter 4 important settings in the
|
||||
Makefile.machine you start from via the corresponding -h, -a, -p, -e
|
||||
switches (as in the examples above), and also save a copy of the new
|
||||
Makefile if desired:
|
||||
|
||||
CUDA_HOME = where NVIDIA CUDA software is installed on your system
|
||||
CUDA_ARCH = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above
|
||||
CUDA_PRECISION = precision (double, mixed, single)
|
||||
EXTRAMAKE = which Makefile.lammps.* file to copy to Makefile.lammps :ul
|
||||
|
||||
If the library build is successful, 3 files should be created:
|
||||
lib/gpu/libgpu.a, lib/gpu/nvc_get_devices, and
|
||||
lib/gpu/Makefile.lammps. The latter has settings that enable LAMMPS
|
||||
to link with CUDA libraries. If the settings in Makefile.lammps for
|
||||
your machine are not correct, the LAMMPS build will fail, and
|
||||
lib/gpu/Makefile.lammps may need to be edited.
|
||||
|
||||
NOTE: If you re-build the GPU library in lib/gpu, you should always
|
||||
un-install the GPU package in lammps/src, then re-install it and
|
||||
re-build LAMMPS. This is because the compilation of files in the GPU
|
||||
package uses the library settings from the lib/gpu/Makefile.machine
|
||||
used to build the GPU library.
|
||||
|
||||
:line
|
||||
|
||||
KIM package :h4,link(kim)
|
||||
|
||||
To build with this package, the KIM library must be downloaded and
|
||||
built on your system. It must include the KIM models that you want to
|
||||
use with LAMMPS.
|
||||
|
||||
Note that in LAMMPS lingo, a KIM model driver is a pair style
|
||||
(e.g. EAM or Tersoff). A KIM model is a pair style for a particular
|
||||
element or alloy and set of parameters, e.g. EAM for Cu with a
|
||||
specific EAM potential file. Also note that installing the KIM API
|
||||
library with all its models, may take around 30 min to build. Of
|
||||
course you only need to do that once.
|
||||
|
||||
See the list of KIM model drivers here:
|
||||
https://openkim.org/kim-items/model-drivers/alphabetical
|
||||
|
||||
See the list of all KIM models here:
|
||||
https://openkim.org/kim-items/models/by-model-drivers
|
||||
|
||||
See the list of example KIM models included by default here:
|
||||
https://openkim.org/kim-api on the "What is in the KIM API source
|
||||
package?" page.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_KIM=value # download OpenKIM API v1 for build, value = no (default) or yes
|
||||
-D KIM_LIBRARY=path # KIM library file (only needed if a custom location)
|
||||
-D KIM_INCLUDE_DIR=path # KIM include directory (only needed if a custom location) :pre
|
||||
|
||||
If DOWNLOAD_KIM is set, the KIM library will be downloaded and built
|
||||
inside the CMake build directory. If the KIM library is already on
|
||||
your system (in a location CMake cannot find it), KIM_LIBRARY is the
|
||||
filename (plus path) of the KIM library file, not the directory the
|
||||
library file is in. KIM_INCLUDE_DIR is the directory the KIM include
|
||||
file is in.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
You can download and build the KIM library manually if you prefer;
|
||||
follow the instructions in lib/kim/README. You can also do it in one
|
||||
step from the lammps/src dir, using a command like these, which simply
|
||||
invoke the lib/kim/Install.py script with the specified args.
|
||||
|
||||
make lib-kim # print help message
|
||||
make lib-kim args="-b " # (re-)install KIM API lib with only example models
|
||||
make lib-kim args="-b -a Glue_Ercolessi_Adams_Al__MO_324507536345_001" # ditto plus one model
|
||||
make lib-kim args="-b -a everything" # install KIM API lib with all models
|
||||
make lib-kim args="-n -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # add one model or model driver
|
||||
make lib-kim args="-p /usr/local/kim-api" # use an existing KIM API installation at the provided location
|
||||
make lib-kim args="-p /usr/local/kim-api -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver :pre
|
||||
|
||||
:line
|
||||
|
||||
KOKKOS package :h4,link(kokkos)
|
||||
|
||||
To build with this package, you must choose which hardware you want to
|
||||
build for, either CPUs (multi-threading via OpenMP) or KNLs (OpenMP)
|
||||
or GPUs (NVIDIA Cuda).
|
||||
|
||||
For a CMake or make build, these are the possible choices for the
|
||||
KOKKOS_ARCH settings described below. Note that for CMake, these are
|
||||
really Kokkos variables, not LAMMPS variables. Hence you must use
|
||||
case-sensitive values, e.g. BDW, not bdw.
|
||||
|
||||
ARMv80 = ARMv8.0 Compatible CPU
|
||||
ARMv81 = ARMv8.1 Compatible CPU
|
||||
ARMv8-ThunderX = ARMv8 Cavium ThunderX CPU
|
||||
BGQ = IBM Blue Gene/Q CPUs
|
||||
Power8 = IBM POWER8 CPUs
|
||||
Power9 = IBM POWER9 CPUs
|
||||
SNB = Intel Sandy/Ivy Bridge CPUs
|
||||
HSW = Intel Haswell CPUs
|
||||
BDW = Intel Broadwell Xeon E-class CPUs
|
||||
SKX = Intel Sky Lake Xeon E-class HPC CPUs (AVX512)
|
||||
KNC = Intel Knights Corner Xeon Phi
|
||||
KNL = Intel Knights Landing Xeon Phi
|
||||
Kepler30 = NVIDIA Kepler generation CC 3.0
|
||||
Kepler32 = NVIDIA Kepler generation CC 3.2
|
||||
Kepler35 = NVIDIA Kepler generation CC 3.5
|
||||
Kepler37 = NVIDIA Kepler generation CC 3.7
|
||||
Maxwell50 = NVIDIA Maxwell generation CC 5.0
|
||||
Maxwell52 = NVIDIA Maxwell generation CC 5.2
|
||||
Maxwell53 = NVIDIA Maxwell generation CC 5.3
|
||||
Pascal60 = NVIDIA Pascal generation CC 6.0
|
||||
Pascal61 = NVIDIA Pascal generation CC 6.1 :ul
|
||||
|
||||
[CMake build]:
|
||||
|
||||
For multicore CPUs using OpenMP, set these 2 variables.
|
||||
|
||||
-D KOKKOS_ARCH=archCPU # archCPU = CPU from list above
|
||||
-D KOKKOS_ENABLE_OPENMP=yes :pre
|
||||
|
||||
For Intel KNLs using OpenMP, set these 2 variables:
|
||||
|
||||
-D KOKKOS_ARCH=KNL
|
||||
-D KOKKOS_ENABLE_OPENMP=yes :pre
|
||||
|
||||
For NVIDIA GPUs using CUDA, set these 4 variables:
|
||||
|
||||
-D KOKKOS_ARCH="archCPU;archGPU" # archCPU = CPU from list above that is hosting the GPU
|
||||
# archGPU = GPU from list above
|
||||
-D KOKKOS_ENABLE_CUDA=yes
|
||||
-D KOKKOS_ENABLE_OPENMP=yes
|
||||
-D CMAKE_CXX_COMPILER=wrapper # wrapper = full path to Cuda nvcc wrapper :pre
|
||||
|
||||
The wrapper value is the Cuda nvcc compiler wrapper provided in the
|
||||
Kokkos library: lib/kokkos/bin/nvcc_wrapper. The setting should
|
||||
include the full path name to the wrapper, e.g.
|
||||
|
||||
-D CMAKE_CXX_COMPILER=/home/username/lammps/lib/kokkos/bin/nvcc_wrapper :pre
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Choose which hardware to support in Makefile.machine via
|
||||
KOKKOS_DEVICES and KOKKOS_ARCH settings. See the
|
||||
src/MAKE/OPTIONS/Makefile.kokkos* files for examples.
|
||||
|
||||
For multicore CPUs using OpenMP:
|
||||
|
||||
KOKKOS_DEVICES = OpenMP
|
||||
KOKKOS_ARCH = archCPU # archCPU = CPU from list above :pre
|
||||
|
||||
For Intel KNLs using OpenMP:
|
||||
|
||||
KOKKOS_DEVICES = OpenMP
|
||||
KOKKOS_ARCH = KNL :pre
|
||||
|
||||
For NVIDIA GPUs using CUDA:
|
||||
|
||||
KOKKOS_DEVICES = Cuda
|
||||
KOKKOS_ARCH = archCPU,archGPU # archCPU = CPU from list above that is hosting the GPU
|
||||
# archGPU = GPU from list above :pre
|
||||
|
||||
For GPUs, you also need these 2 lines in your Makefile.machine before
|
||||
the CC line is defined, in this case for use with OpenMPI mpicxx. The
|
||||
2 lines define a nvcc wrapper compiler, which will use nvcc for
|
||||
compiling CUDA files and use a C++ compiler for non-Kokkos, non-CUDA
|
||||
files.
|
||||
|
||||
KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
|
||||
export OMPI_CXX = $(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
|
||||
CC = mpicxx :pre
|
||||
|
||||
:line
|
||||
|
||||
LATTE package :h4,link(latte)
|
||||
|
||||
To build with this package, you must download and build the LATTE
|
||||
library.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
|
||||
-D LATTE_LIBRARY=path # LATTE library file (only needed if a custom location) :pre
|
||||
|
||||
If DOWNLOAD_LATTE is set, the LATTE library will be downloaded and
|
||||
built inside the CMake build directory. If the LATTE library is
|
||||
already on your system (in a location CMake cannot find it),
|
||||
LATTE_LIBRARY is the filename (plus path) of the LATTE library file,
|
||||
not the directory the library file is in.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
You can download and build the LATTE library manually if you prefer;
|
||||
follow the instructions in lib/latte/README. You can also do it in
|
||||
one step from the lammps/src dir, using a command like these, which
|
||||
simply invokes the lib/latte/Install.py script with the specified
|
||||
args:
|
||||
|
||||
make lib-latte # print help message
|
||||
make lib-latte args="-b" # download and build in lib/latte/LATTE-master
|
||||
make lib-latte args="-p $HOME/latte" # use existing LATTE installation in $HOME/latte
|
||||
make lib-latte args="-b -m gfortran" # download and build in lib/latte and
|
||||
# copy Makefile.lammps.gfortran to Makefile.lammps
|
||||
:pre
|
||||
|
||||
Note that 3 symbolic (soft) links, "includelink" and "liblink" and
|
||||
"filelink.o", are created in lib/latte to point into the LATTE home
|
||||
dir. When LAMMPS itself is built it will use these links. You should
|
||||
also check that the Makefile.lammps file you create is appropriate for
|
||||
the compiler you use on your system to build LATTE.
|
||||
|
||||
:line
|
||||
|
||||
MEAM package :h4,link(meam)
|
||||
|
||||
NOTE: the use of the MEAM package is discouraged, as it has been
|
||||
superseded by the USER-MEAMC package, which is a direct translation of
|
||||
the Fortran code in the MEAM library to C++. The code in USER-MEAMC
|
||||
should be functionally equivalent to the MEAM package, fully supports
|
||||
use of "pair_style hybrid"_pair_hybrid.html (the MEAM packaged doesn
|
||||
not), and has optimizations that make it significantly faster than the
|
||||
MEAM package.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_MEAM=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the MEAM library in lib/meam.
|
||||
You can build the MEAM library manually if you prefer; follow the
|
||||
instructions in lib/meam/README. You can also do it in one step from
|
||||
the lammps/src dir, using a command like these, which simply invoke
|
||||
the lib/meam/Install.py script with the specified args:
|
||||
|
||||
make lib-meam # print help message
|
||||
make lib-meam args="-m mpi" # build with default Fortran compiler compatible with your MPI library
|
||||
make lib-meam args="-m serial" # build with compiler compatible with "make serial" (GNU Fortran)
|
||||
make lib-meam args="-m ifort" # build with Intel Fortran compiler using Makefile.ifort :pre
|
||||
|
||||
The build should produce two files: lib/meam/libmeam.a and
|
||||
lib/meam/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
|
||||
Fortran (MEAM library). Typically the two compilers used for LAMMPS
|
||||
and the MEAM library need to be consistent (e.g. both Intel or both
|
||||
GNU compilers). If necessary, you can edit/create a new
|
||||
lib/meam/Makefile.machine file for your system, which should define an
|
||||
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
|
||||
:line
|
||||
|
||||
MSCG package :h4,link(mscg)
|
||||
|
||||
To build with this package, you must download and build the MS-CG
|
||||
library. Building the MS-CG library and using it from LAMMPS requires
|
||||
a C++11 compatible compiler and that the GSL (GNU Scientific Library)
|
||||
headers and libraries are installed on your machine. See the
|
||||
lib/mscg/README and MSCG/Install files for more details.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_MSCG=value # download MSCG for build, value = no (default) or yes
|
||||
-D MSCG_LIBRARY=path # MSCG library file (only needed if a custom location)
|
||||
-D MSCG_INCLUDE_DIR=path # MSCG include directory (only needed if a custom location) :pre
|
||||
|
||||
If DOWNLOAD_MSCG is set, the MSCG library will be downloaded and built
|
||||
inside the CMake build directory. If the MSCG library is already on
|
||||
your system (in a location CMake cannot find it), MSCG_LIBRARY is the
|
||||
filename (plus path) of the MSCG library file, not the directory the
|
||||
library file is in. MSCG_INCLUDE_DIR is the directory the MSCG
|
||||
include file is in.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
You can download and build the MS-CG library manually if you prefer;
|
||||
follow the instructions in lib/mscg/README. You can also do it in one
|
||||
step from the lammps/src dir, using a command like these, which simply
|
||||
invoke the lib/mscg/Install.py script with the specified args:
|
||||
|
||||
make lib-mscg # print help message
|
||||
make lib-mscg args="-b -m serial" # download and build in lib/mscg/MSCG-release-master
|
||||
# with the settings compatible with "make serial"
|
||||
make lib-mscg args="-b -m mpi" # download and build in lib/mscg/MSCG-release-master
|
||||
# with the settings compatible with "make mpi"
|
||||
make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release :pre
|
||||
|
||||
Note that 2 symbolic (soft) links, "includelink" and "liblink", will
|
||||
be created in lib/mscg to point to the MS-CG src/installation dir.
|
||||
When LAMMPS is built in src it will use these links. You should not
|
||||
need to edit the lib/mscg/Makefile.lammps file.
|
||||
|
||||
:line
|
||||
|
||||
OPT package :h4,link(opt)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_OPT=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
The compile flag "-restrict" must be used to build LAMMPS with the OPT
|
||||
package when using Intel compilers. It should be added to the CCFLAGS
|
||||
line of your Makefile.machine. See src/MAKE/OPTIONS/Makefile.opt for
|
||||
an example.
|
||||
|
||||
:line
|
||||
|
||||
POEMS package :h4,link(poems)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_OPT=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the POEMS library in lib/poems.
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
lib/poems/README. You can also do it in one step from the lammps/src
|
||||
dir, using a command like these, which simply invoke the
|
||||
lib/poems/Install.py script with the specified args:
|
||||
|
||||
make lib-poems # print help message
|
||||
make lib-poems args="-m serial" # build with GNU g++ compiler (settings as with "make serial")
|
||||
make lib-poems args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi")
|
||||
make lib-poems args="-m icc" # build with Intel icc compiler :pre
|
||||
|
||||
The build should produce two files: lib/poems/libpoems.a and
|
||||
lib/poems/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to build LAMMPS with the
|
||||
POEMS library (though typically the settings are just blank). If
|
||||
necessary, you can edit/create a new lib/poems/Makefile.machine file
|
||||
for your system, which should define an EXTRAMAKE variable to specify
|
||||
a corresponding Makefile.lammps.machine file.
|
||||
|
||||
:line
|
||||
|
||||
PYTHON package :h4,link(python)
|
||||
|
||||
Building with the PYTHON package requires you have a Python shared
|
||||
library available on your system, which needs to be a Python 2
|
||||
version, 2.6 or later. Python 3 is not yet supported. See
|
||||
lib/python/README for more details.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D PYTHON_EXECUTABLE=path # path to Python executable to use :pre
|
||||
|
||||
Without this setting, CMake will ues the default Python on your
|
||||
system. To use a different Python version, you can either create a
|
||||
virtualenv, activate it and then run cmake. Or you can set the
|
||||
PYTHON_EXECUTABLE variable to specify which Python interpreter should
|
||||
be used. Note note that you will also need to have the development
|
||||
headers installed for this version, e.g. python2-devel.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
The build uses the lib/python/Makefile.lammps file in the compile/link
|
||||
process to find Python. You should only need to create a new
|
||||
Makefile.lammps.* file (and copy it to Makefile.lammps) if the LAMMPS
|
||||
build fails.
|
||||
|
||||
:line
|
||||
|
||||
REAX package :h4,link(reax)
|
||||
|
||||
NOTE: the use of the REAX package and its "pair_style
|
||||
reax"_pair_reax.html command is discouraged, as it is no longer
|
||||
maintained. Please use the USER-REAXC package and its "pair_style
|
||||
reax/c"_pair_reaxc.html command instead, and possibly its KOKKOS
|
||||
enabled variant (pair_style reax/c/kk), which has a more robust memory
|
||||
management. See the "pair_style reax/c"_pair_reaxc.html doc page for
|
||||
details.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_REAX=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the REAX library in lib/reax.
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
lib/reax/README. You can also do it in one step from the lammps/src
|
||||
dir, using a command like these, which simply invoke the
|
||||
lib/reax/Install.py script with the specified args:
|
||||
|
||||
make lib-reax # print help message
|
||||
make lib-reax args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
|
||||
make lib-reax args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
|
||||
make lib-reax args="-m ifort" # build with Intel ifort compiler :pre
|
||||
|
||||
The build should produce two files: lib/reax/libreax.a and
|
||||
lib/reax/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
|
||||
Fortran (REAX library). Typically the two compilers used for LAMMPS
|
||||
and the REAX library need to be consistent (e.g. both Intel or both
|
||||
GNU compilers). If necessary, you can edit/create a new
|
||||
lib/reax/Makefile.machine file for your system, which should define an
|
||||
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
|
||||
:line
|
||||
|
||||
VORONOI package :h4,link(voronoi)
|
||||
|
||||
To build with this package, you must download and build the "Voro++
|
||||
library"_voro_home.
|
||||
|
||||
:link(voro_home,http://math.lbl.gov/voro++)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_VORO=value # download Voro++ for build, value = no (default) or yes
|
||||
-D VORO_LIBRARY=path # Voro++ library file (only needed if at custom location)
|
||||
-D VORO_INCLUDE_DIR=path # Voro++ include directory (only needed if at custom location) :pre
|
||||
|
||||
If DOWNLOAD_VORO is set, the Voro++ library will be downloaded and
|
||||
built inside the CMake build directory. If the Voro++ library is
|
||||
already on your system (in a location CMake cannot find it),
|
||||
VORO_LIBRARY is the filename (plus path) of the Voro++ library file,
|
||||
not the directory the library file is in. VORO_INCLUDE_DIR is the
|
||||
directory the Voro++ include file is in.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
You can download and build the Voro++ library manually if you prefer;
|
||||
follow the instructions in lib/voronoi/README. You can also do it in
|
||||
one step from the lammps/src dir, using a command like these, which
|
||||
simply invoke the lib/voronoi/Install.py script with the specified
|
||||
args:
|
||||
|
||||
make lib-voronoi # print help message
|
||||
make lib-voronoi args="-b" # download and build the default version in lib/voronoi/voro++-<version>
|
||||
make lib-voronoi args="-p $HOME/voro++" # use existing Voro++ installation in $HOME/voro++
|
||||
make lib-voronoi args="-b -v voro++0.4.6" # download and build the 0.4.6 version in lib/voronoi/voro++-0.4.6 :pre
|
||||
|
||||
Note that 2 symbolic (soft) links, "includelink" and "liblink", are
|
||||
created in lib/voronoi to point to the Voro++ src dir. When LAMMPS
|
||||
builds in src it will use these links. You should not need to edit
|
||||
the lib/voronoi/Makefile.lammps file.
|
||||
|
||||
:line
|
||||
|
||||
USER-ATC package :h4,link(user-atc)
|
||||
|
||||
The USER-ATC package requires the MANYBODY package also be installed.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_REAX=yes" and "-D
|
||||
PKG_MANYBODY=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the ATC library in lib/atc.
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
lib/atc/README. You can also do it in one step from the lammps/src
|
||||
dir, using a command like these, which simply invoke the
|
||||
lib/atc/Install.py script with the specified args:
|
||||
|
||||
make lib-atc # print help message
|
||||
make lib-atc args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
|
||||
make lib-atc args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
|
||||
make lib-atc args="-m icc" # build with Intel icc compiler :pre
|
||||
|
||||
The build should produce two files: lib/atc/libatc.a and
|
||||
lib/atc/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to build LAMMPS with the ATC
|
||||
library. If necessary, you can edit/create a new
|
||||
lib/atc/Makefile.machine file for your system, which should define an
|
||||
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
|
||||
Note that the Makefile.lammps file has settings for the BLAS and
|
||||
LAPACK linear algebra libraries. As explained in lib/atc/README these
|
||||
can either exist on your system, or you can use the files provided in
|
||||
lib/linalg. In the latter case you also need to build the library in
|
||||
lib/linalg with a command like these:
|
||||
|
||||
make lib-linalg # print help message
|
||||
make lib-linalg args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
|
||||
make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
|
||||
make lib-linalg args="-m gfortran" # build with GNU Fortran compiler :pre
|
||||
|
||||
:line
|
||||
|
||||
USER-AWPMD package :h4,link(user-awpmd)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-AQPMD=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the AWPMD library in lib/awpmd.
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
lib/awpmd/README. You can also do it in one step from the lammps/src
|
||||
dir, using a command like these, which simply invoke the
|
||||
lib/awpmd/Install.py script with the specified args:
|
||||
|
||||
make lib-awpmd # print help message
|
||||
make lib-awpmd args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
|
||||
make lib-awpmd args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
|
||||
make lib-awpmd args="-m icc" # build with Intel icc compiler :pre
|
||||
|
||||
The build should produce two files: lib/awpmd/libawpmd.a and
|
||||
lib/awpmd/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to build LAMMPS with the
|
||||
AWPMD library. If necessary, you can edit/create a new
|
||||
lib/awpmd/Makefile.machine file for your system, which should define
|
||||
an EXTRAMAKE variable to specify a corresponding
|
||||
Makefile.lammps.machine file.
|
||||
|
||||
Note that the Makefile.lammps file has settings for the BLAS and
|
||||
LAPACK linear algebra libraries. As explained in lib/awpmd/README
|
||||
these can either exist on your system, or you can use the files
|
||||
provided in lib/linalg. In the latter case you also need to build the
|
||||
library in lib/linalg with a command like these:
|
||||
|
||||
make lib-linalg # print help message
|
||||
make lib-linalg args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
|
||||
make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
|
||||
make lib-linalg args="-m gfortran" # build with GNU Fortran compiler :pre
|
||||
|
||||
:line
|
||||
|
||||
USER-COLVARS package :h4,link(user-colvars)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-COLVARS=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the COLVARS library in
|
||||
lib/colvars. You can do this manually if you prefer; follow the
|
||||
instructions in lib/colvars/README. You can also do it in one step
|
||||
from the lammps/src dir, using a command like these, which simply
|
||||
invoke the lib/colvars/Install.py script with the specified args:
|
||||
|
||||
make lib-colvars # print help message
|
||||
make lib-colvars args="-m serial" # build with GNU g++ compiler (settings as with "make serial")
|
||||
make lib-colvars args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
|
||||
make lib-colvars args="-m g++-debug" # build with GNU g++ compiler and colvars debugging enabled :pre
|
||||
|
||||
The build should produce two files: lib/colvars/libcolvars.a and
|
||||
lib/colvars/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to build LAMMPS with the
|
||||
COLVARS library (though typically the settings are just blank). If
|
||||
necessary, you can edit/create a new lib/colvars/Makefile.machine file
|
||||
for your system, which should define an EXTRAMAKE variable to specify
|
||||
a corresponding Makefile.lammps.machine file.
|
||||
|
||||
:line
|
||||
|
||||
USER-H5MD package :h4,link(user-h5md)
|
||||
|
||||
To build with this package you must have the HDF5 software package
|
||||
installed on your system, which should include the h5cc compiler and
|
||||
the HDF5 library.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-H5MD=yes".
|
||||
|
||||
This should autodetect the H5MD library on your system. Several
|
||||
advanced CMake H5MD options exist if you need to specify where it is
|
||||
installed. Use the ccmake (terminal window) or cmake-gui (graphical)
|
||||
tools to see these options and set them interactively from their user
|
||||
interfaces.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the CH5MD library in lib/h5md.
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
lib/h5md/README. You can also do it in one step from the lammps/src
|
||||
dir, using a command like these, which simply invoke the
|
||||
lib/h5md/Install.py script with the specified args:
|
||||
|
||||
make lib-h5md # print help message
|
||||
make lib-hm5d args="-m h5cc" # build with h5cc compiler :pre
|
||||
|
||||
The build should produce two files: lib/h5md/libch5md.a and
|
||||
lib/h5md/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to build LAMMPS with the
|
||||
system HDF5 library. If necessary, you can edit/create a new
|
||||
lib/h5md/Makefile.machine file for your system, which should define an
|
||||
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
|
||||
:line
|
||||
|
||||
USER-INTEL package :h4,link(user-intel)
|
||||
|
||||
To build with this package, you must choose which hardware you want to
|
||||
build for, either Intel CPUs or Intel KNLs. You should also typically
|
||||
"install the USER-OMP package"_#user-omp, as it can be used in tandem
|
||||
with the USER-INTEL package to good effect, as explained on the "Speed
|
||||
intel"_Speed_intel.html doc page.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D INTEL_ARCH=value # value = cpu (default) or knl
|
||||
-D BUILD_OMP=yes # also required to build with the USER-INTEl package :pre
|
||||
|
||||
Requires an Intel compiler as well as the Intel TBB and MKL libraries.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Choose which hardware to compile for in Makefile.machine via the
|
||||
following settings. See src/MAKE/OPTIONS/Makefile.intel_cpu* and
|
||||
Makefile.knl files for examples.
|
||||
|
||||
For CPUs:
|
||||
|
||||
OPTFLAGS = -xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high
|
||||
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
|
||||
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
|
||||
LIB = -ltbbmalloc :pre
|
||||
|
||||
For KNLs:
|
||||
|
||||
OPTFLAGS = -xMIC-AVX512 -O2 -fp-model fast=2 -no-prec-div -qoverride-limits
|
||||
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
|
||||
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
|
||||
LIB = -ltbbmalloc :pre
|
||||
|
||||
:line
|
||||
|
||||
USER-MOLFILE package :h4,link(user-molfile)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-MOLFILE=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
The lib/molfile/Makefile.lammps file has a setting for a dynamic
|
||||
loading library libdl.a that is typically present on all systems. It
|
||||
is required for LAMMPS to link with this package. If the setting is
|
||||
not valid for your system, you will need to edit the Makefile.lammps
|
||||
file. See lib/molfile/README and lib/molfile/Makefile.lammps for
|
||||
details.
|
||||
|
||||
:line
|
||||
|
||||
USER-NETCDF package :h4,link(user-netcdf)
|
||||
|
||||
To build with this package you must have the NetCDF library installed
|
||||
on your system.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-NETCDF=yes".
|
||||
|
||||
This should autodetect the NETCDF library if it is installed on your
|
||||
system at standard locations. Several advanced CMake NETCDF options
|
||||
exist if you need to specify where it was installed. Use the ccmake
|
||||
(terminal window) or cmake-gui (graphical) tools to see these options
|
||||
and set them interactively from their user interfaces.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
The lib/netcdf/Makefile.lammps file has settings for NetCDF include
|
||||
and library files which LAMMPS needs to build with this package. If
|
||||
the settings are not valid for your system, you will need to edit the
|
||||
Makefile.lammps file. See lib/netcdf/README for details.
|
||||
|
||||
:line
|
||||
|
||||
USER-OMP package :h4,link(user-omp)
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are required besides "-D PKG_USER-OMP=yes". If
|
||||
CMake detects OpenMP support, the USER-OMP code will be compiled with
|
||||
multi-threading support enabled, otherwise as optimized serial code.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
To enable multi-threading support in the USER-OMP package (and other
|
||||
styles supporting OpenMP) the following compile and link flags must
|
||||
be added to your Makefile.machine file.
|
||||
See src/MAKE/OPTIONS/Makefile.omp for an example.
|
||||
|
||||
CCFLAGS: -fopenmp # for GNU Compilers
|
||||
CCFLAGS: -qopenmp -restrict # for Intel compilers on Linux
|
||||
LINKFLAGS: -fopenmp # for GNU Compilers
|
||||
LINKFLAGS: -qopenmp # for Intel compilers on Linux :pre
|
||||
|
||||
For other platforms and compilers, please consult the documentation
|
||||
about OpenMP support for your compiler.
|
||||
|
||||
:line
|
||||
|
||||
USER-QMMM package :h4,link(user-qmmm)
|
||||
|
||||
NOTE: The LAMMPS executable these steps produce is not yet functional
|
||||
for a QM/MM simulation. You must also build Quantum ESPRESSO and
|
||||
create a new executable (pwqmmm.x) which links LAMMPS and Quantum
|
||||
ESPRESSO together. These are steps 3 and 4 described in the
|
||||
lib/qmmm/README file. Unfortunately, the Quantum ESPRESSO developers
|
||||
have been breaking the interface that the QM/MM code in LAMMPS is using,
|
||||
so that currently (Summer 2018) using this feature requires either
|
||||
correcting the library interface feature in recent Quantum ESPRESSO
|
||||
releases, or using an outdated version of QE. The last version of
|
||||
Quantum ESPRESSO known to work with this QM/MM interface was version
|
||||
5.4.1 from 2016.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
The CMake build system currently does not support building the full
|
||||
QM/MM-capable hybrid executable of LAMMPS and QE called pwqmmm.x.
|
||||
You must use the traditional make build for this package.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Before building LAMMPS, you must build the QMMM library in lib/qmmm.
|
||||
You can do this manually if you prefer; follow the first two steps
|
||||
explained in lib/qmmm/README. You can also do it in one step from the
|
||||
lammps/src dir, using a command like these, which simply invoke the
|
||||
lib/qmmm/Install.py script with the specified args:
|
||||
|
||||
make lib-qmmm # print help message
|
||||
make lib-qmmm args="-m serial" # build with GNU Fortran compiler (settings as in "make serial")
|
||||
make lib-qmmm args="-m mpi" # build with default MPI compiler (settings as in "make mpi")
|
||||
make lib-qmmm args="-m gfortran" # build with GNU Fortran compiler :pre
|
||||
|
||||
The build should produce two files: lib/qmmm/libqmmm.a and
|
||||
lib/qmmm/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.* and has settings needed to build LAMMPS with the
|
||||
QMMM library (though typically the settings are just blank). If
|
||||
necessary, you can edit/create a new lib/qmmm/Makefile.machine file
|
||||
for your system, which should define an EXTRAMAKE variable to specify
|
||||
a corresponding Makefile.lammps.machine file.
|
||||
|
||||
You can then install QMMM package and build LAMMPS in the usual
|
||||
manner. After completing the LAMMPS build and compiling Quantum
|
||||
ESPRESSO with external library support, go back to the lib/qmmm folder
|
||||
and follow the instructions on the README file to build the combined
|
||||
LAMMPS/QE QM/MM executable (pwqmmm.x) in the lib/qmmm folder.
|
||||
|
||||
:line
|
||||
|
||||
USER-QUIP package :h4,link(user-quip)
|
||||
|
||||
To build with this package, you must download and build the QUIP
|
||||
library. It can be obtained from GitHub. For support of GAP
|
||||
potentials, additional files with specific licensing conditions need
|
||||
to be downloaded and configured. See step 1 and step 1.1 in the
|
||||
lib/quip/README file for details on how to do this.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D QUIP_LIBRARIES=path # path to libquip.a (only needed if a custom location) :pre
|
||||
|
||||
CMake will not download and build the QUIP library. But once you have
|
||||
done that, a CMake build of LAMMPS with "-D PKG_USER-QUIP=yes" should
|
||||
work. Set QUIP_LIBRARIES if CMake cannot find the QUIP library.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
The download/build procedure for the QUIP library, described in
|
||||
lib/quip/README file requires setting two environment variables,
|
||||
QUIP_ROOT and QUIP_ARCH. These are accessed by the
|
||||
lib/quip/Makefile.lammps file which is used when you compile and link
|
||||
LAMMPS with this package. You should only need to edit
|
||||
Makefile.lammps if the LAMMPS build can not use its settings to
|
||||
successfully build on your system.
|
||||
|
||||
:line
|
||||
|
||||
USER-SMD package :h4,link(user-smd)
|
||||
|
||||
To build with this package, you must download the Eigen3 library.
|
||||
Eigen3 is a template library, so you do not need to build it.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
|
||||
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location) :pre
|
||||
|
||||
If DOWNLOAD_EIGEN3 is set, the Eigen3 library will be downloaded and
|
||||
inside the CMake build directory. If the Eig3n3 library is already on
|
||||
your system (in a location CMake cannot find it), EIGEN3_INCLUDE_DIR
|
||||
is the directory the Eigen3++ include file is in.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
You can download the Eigen3 library manually if you prefer; follow the
|
||||
instructions in lib/smd/README. You can also do it in one step from
|
||||
the lammps/src dir, using a command like these, which simply invoke
|
||||
the lib/smd/Install.py script with the specified args:
|
||||
|
||||
make lib-smd # print help message
|
||||
make lib-smd args="-b" # download to lib/smd/eigen3
|
||||
make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3 :pre
|
||||
|
||||
Note that a symbolic (soft) link named "includelink" is created in
|
||||
lib/smd to point to the Eigen dir. When LAMMPS builds it will use
|
||||
this link. You should not need to edit the lib/smd/Makefile.lammps
|
||||
file.
|
||||
|
||||
:line
|
||||
|
||||
USER-VTK package :h4,link(user-vtk)
|
||||
|
||||
To build with this package you must have the VTK library installed on
|
||||
your system.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-VTK=yes".
|
||||
|
||||
This should autodetect the VTK library if it is installed on your
|
||||
system at standard locations. Several advanced VTK options exist if
|
||||
you need to specify where it was installed. Use the ccmake (terminal
|
||||
window) or cmake-gui (graphical) tools to see these options and set
|
||||
them interactively from their user interfaces.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
The lib/vtk/Makefile.lammps file has settings for accessing VTK files
|
||||
and its library, which LAMMPS needs to build with this package. If
|
||||
the settings are not valid for your system, check if one of the other
|
||||
lib/vtk/Makefile.lammps.* files is compatible and copy it to
|
||||
Makefile.lammps. If none of the provided files work, you will need to
|
||||
edit the Makefile.lammps file. See lib/vtk/README for details.
|
||||
85
doc/src/Build_link.txt
Normal file
@ -0,0 +1,85 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Link LAMMPS as a library to another code :h3
|
||||
|
||||
LAMMPS can be used as a library by another application, including
|
||||
Python scripts. The files src/library.cpp and library.h define the
|
||||
C-style API for using LAMMPS as a library. See the "Howto
|
||||
library"_Howto_library.html doc page for a description of the
|
||||
interface and how to extend it for your needs.
|
||||
|
||||
The "Build basics"_Build_basics.html doc page explains how to build
|
||||
LAMMPS as either a shared or static library. This results in one of
|
||||
these 2 files:
|
||||
|
||||
liblammps.so # shared library
|
||||
liblammps.a # static library
|
||||
|
||||
:line
|
||||
|
||||
[Link with LAMMPS as a static library]:
|
||||
|
||||
The calling application can link to LAMMPS as a static library with a
|
||||
link command like this:
|
||||
|
||||
g++ caller.o -L/home/sjplimp/lammps/src -llammps -o caller
|
||||
|
||||
The -L argument is the path to where the liblammps.a file is. The
|
||||
-llammps argument is shorthand for the file liblammps.a.
|
||||
|
||||
:line
|
||||
|
||||
[Link with LAMMPS as a shared library]:
|
||||
|
||||
If you wish to link to liblammps.so, the operating system finds shared
|
||||
libraries to load at run-time using the environment variable
|
||||
LD_LIBRARY_PATH. To enable this you can do one of two things:
|
||||
|
||||
(1) Copy the liblammps.so file to a location the system can find it,
|
||||
such as /usr/local/lib. I.e. a directory already listed in your
|
||||
LD_LIBRARY_PATH variable. You can type
|
||||
|
||||
printenv LD_LIBRARY_PATH :pre
|
||||
|
||||
to see what directories are in that list.
|
||||
|
||||
(2) Add the LAMMPS src directory (or the directory you perform CMake
|
||||
build in) to your LD_LIBRARY_PATH, so that the current version of the
|
||||
shared library is always available to programs that use it.
|
||||
|
||||
For the csh or tcsh shells, you would add something like this to your
|
||||
~/.cshrc file:
|
||||
|
||||
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
|
||||
|
||||
:line
|
||||
|
||||
[Calling the LAMMPS library]:
|
||||
|
||||
Either flavor of library (static or shared) allows one or more LAMMPS
|
||||
objects to be instantiated from the calling program.
|
||||
|
||||
When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
|
||||
namespace; you can safely use any of its classes and methods from
|
||||
within the calling code, as needed.
|
||||
|
||||
When used from a C or Fortran program, the library has a simple
|
||||
C-style interface, provided in src/library.cpp and src/library.h.
|
||||
|
||||
See the "Python library"_Python_library.html doc page for a
|
||||
description of the Python interface to LAMMPS, which wraps the C-style
|
||||
interface.
|
||||
|
||||
See the sample codes in examples/COUPLE/simple for examples of C++ and
|
||||
C and Fortran codes that invoke LAMMPS thru its library interface.
|
||||
Other examples in the COUPLE directory use coupling ideas discussed on
|
||||
the "Howto couple"_Howto_couple.html doc page.
|
||||
|
||||
|
||||
85
doc/src/Build_make.txt
Normal file
@ -0,0 +1,85 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS with make :h3
|
||||
|
||||
Building LAMMPS with traditional makefiles requires that you have a
|
||||
Makefile."machine" file appropriate for your system in the src/MAKE,
|
||||
src/MAKE/MACHINES, src/MAKE/OPTIONS, or src/MAKE/MINE directory (see
|
||||
below). It can include various options for customizing your LAMMPS
|
||||
build with a number of global compilation options and features.
|
||||
|
||||
To include LAMMPS packages (i.e. optional commands and styles) you
|
||||
must install them first, as discussed on the "Build
|
||||
package"_Build_package.html doc page. If the packages require
|
||||
provided or external libraries, you must build those libraries before
|
||||
building LAMMPS. Building "LAMMPS with CMake"_Build_cmake.html can
|
||||
automate all of this for many types of machines, especially
|
||||
workstations, desktops and laptops, so we suggest you try it first.
|
||||
|
||||
These commands perform a default LAMMPS build, producing the LAMMPS
|
||||
executable lmp_serial or lmp_mpi in lammps/src:
|
||||
|
||||
cd lammps/src
|
||||
make serial # build a serial LAMMPS executable
|
||||
make mpi # build a parallel LAMMPS executable with MPI
|
||||
make # see a variety of make options :pre
|
||||
|
||||
This initial compilation can take a long time, since LAMMPS is a large
|
||||
project with many features. If your machine has multiple CPU cores
|
||||
(most do these days), using a command like "make -jN mpi" (with N =
|
||||
the number of available CPU cores) can be much faster. If you plan to
|
||||
do development on LAMMPS or need to recompile LAMMPS repeatedly, the
|
||||
installation of the ccache (= Compiler Cache) software may speed up
|
||||
compilation even more.
|
||||
|
||||
After the initial build, whenever you edit LAMMPS source files, or add
|
||||
or remove new files to the source directory (e.g. by installing or
|
||||
uninstalling packages), you must recompile and relink the LAMMPS
|
||||
executable with the same "make" command. This makefiles dependencies
|
||||
should insure that only the subset of files that need to be are
|
||||
recompiled.
|
||||
|
||||
NOTE: When you build LAMMPS for the first time, a long list of *.d
|
||||
files will be printed out rapidly. This is not an error; it is the
|
||||
Makefile doing its normal creation of dependencies.
|
||||
|
||||
:line
|
||||
|
||||
The lammps/src/MAKE tree contains all the Makefile.machine files
|
||||
included in the LAMMPS distribution. Typing "make machine" uses
|
||||
Makefile.machine. Thus the "make serial" or "make mpi" lines above
|
||||
use Makefile.serial and Makefile.mpi. Others are in these dirs:
|
||||
|
||||
OPTIONS # Makefiles which enable specific options
|
||||
MACHINES # Makefiles for specific machines
|
||||
MINE # customized Makefiles you create (you may need to create this folder) :pre
|
||||
|
||||
Typing "make" lists all the available Makefile.machine files. A file
|
||||
with the same name can appear in multiple folders (not a good idea).
|
||||
The order the dirs are searched is as follows: src/MAKE/MINE,
|
||||
src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES. This gives preference
|
||||
to a customized file you put in src/MAKE/MINE.
|
||||
|
||||
Makefiles you may wish to try include these (some require a package
|
||||
first be installed). Many of these include specific compiler flags
|
||||
for optimized performance. Please note, however, that some of these
|
||||
customized machine Makefile are contributed by users. Since both
|
||||
compilers, OS configs, and LAMMPS itself keep changing, their settings
|
||||
may become outdated:
|
||||
|
||||
make mac # build serial LAMMPS on a Mac
|
||||
make mac_mpi # build parallel LAMMPS on a Mac
|
||||
make intel_cpu # build with the USER-INTEL package optimized for CPUs
|
||||
make knl # build with the USER-INTEL package optimized for KNLs
|
||||
make opt # build with the OPT package optimized for CPUs
|
||||
make omp # build with the USER-OMP package optimized for OpenMP
|
||||
make kokkos_omp # build with the KOKKOS package for OpenMP
|
||||
make kokkos_cuda_mpi # build with the KOKKOS package for GPUs
|
||||
make kokkos_phi # build with the KOKKOS package for KNLs :pre
|
||||
223
doc/src/Build_package.txt
Normal file
@ -0,0 +1,223 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Include packages in build :h3
|
||||
|
||||
In LAMMPS, a package is a group of files that enable a specific set of
|
||||
features. For example, force fields for molecular systems or
|
||||
rigid-body constraints are in packages. In the src directory, each
|
||||
package is a sub-directory with the package name in capital letters.
|
||||
|
||||
An overview of packages is given on the "Packages"_Packages.html doc
|
||||
page. Brief overviews of each package are on the "Packages
|
||||
details"_Packages_details.html doc page.
|
||||
|
||||
When building LAMMPS, you can choose to include or exclude each
|
||||
package. In general there is no need to include a package if you
|
||||
never plan to use its features.
|
||||
|
||||
If you get a run-time error that a LAMMPS command or style is
|
||||
"Unknown", it is often because the command is contained in a package,
|
||||
and your build did not include that package. Running LAMMPS with the
|
||||
"-h command-line switch"_Run_options.html will print all the included
|
||||
packages and commands for that executable.
|
||||
|
||||
For the majority of packages, if you follow the single step below to
|
||||
include it, you can then build LAMMPS exactly the same as you would
|
||||
without any packages installed. A few packages may require additional
|
||||
steps, as explained on the "Build extras"_Build_extras.html doc page.
|
||||
|
||||
These links take you to the extra instructions for those select
|
||||
packages:
|
||||
|
||||
"COMPRESS"_Build_extras.html#compress,
|
||||
"GPU"_Build_extras.html#gpu,
|
||||
"KIM"_Build_extras.html#kim,
|
||||
"KOKKOS"_Build_extras.html#kokkos,
|
||||
"LATTE"_Build_extras.html#latte,
|
||||
"MEAM"_Build_extras.html#meam,
|
||||
"MSCG"_Build_extras.html#mscg,
|
||||
"OPT"_Build_extras.html#opt,
|
||||
"POEMS"_Build_extras.html#poems,
|
||||
"PYTHON"_Build_extras.html#python,
|
||||
"REAX"_Build_extras.html#reax,
|
||||
"VORONOI"_Build_extras.html#voronoi,
|
||||
"USER-ATC"_Build_extras.html#user-atc,
|
||||
"USER-AWPMD"_Build_extras.html#user-awpmd,
|
||||
"USER-COLVARS"_Build_extras.html#user-colvars,
|
||||
"USER-H5MD"_Build_extras.html#user-h5md,
|
||||
"USER-INTEL"_Build_extras.html#user-intel,
|
||||
"USER-MOLFILE"_Build_extras.html#user-molfile,
|
||||
"USER-NETCDF"_Build_extras.html#user-netcdf,
|
||||
"USER-OMP"_Build_extras.html#user-omp,
|
||||
"USER-QMMM"_Build_extras.html#user-qmmm,
|
||||
"USER-QUIP"_Build_extras.html#user-quip,
|
||||
"USER-SMD"_Build_extras.html#user-smd,
|
||||
"USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c,a=l)
|
||||
|
||||
The mechanism for including packages is simple but different for CMake
|
||||
versus make.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D PKG_NAME=value # yes or no (default) :pre
|
||||
|
||||
Examples:
|
||||
|
||||
-D PKG_MANYBODY=yes
|
||||
-D PKG_USER-INTEL=yes :pre
|
||||
|
||||
All standard and user packages are included the same way. Note that
|
||||
USER packages have a hyphen between USER and the rest of the package
|
||||
name, not an underscore.
|
||||
|
||||
See the shortcut section below for how to install many packages at
|
||||
once with CMake.
|
||||
|
||||
NOTE: If you toggle back and forth between building with CMake vs
|
||||
make, no packages in the src directory can be installed when you
|
||||
invoke cmake. CMake will give an error if that is not the case,
|
||||
indicating how you can un-install all packages in the src dir.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
cd lammps/src
|
||||
make ps # check which packages are currently installed
|
||||
make yes-name # install a package with name
|
||||
make no-name # un-install a package with name
|
||||
make mpi # build LAMMPS with whatever packages are now installed :pre
|
||||
|
||||
Examples:
|
||||
|
||||
make no-rigid
|
||||
make yes-user-intel :pre
|
||||
|
||||
All standard and user packages are included the same way.
|
||||
|
||||
See the shortcut section below for how to install many packages at
|
||||
once with make.
|
||||
|
||||
NOTE: You must always re-build LAMMPS (via make) after installing or
|
||||
un-installing a package, for the action to take effect.
|
||||
|
||||
NOTE: You cannot install or un-install packages and build LAMMPS in a
|
||||
single make command with multiple targets, e.g. make yes-colloid mpi.
|
||||
This is because the make procedure creates a list of source files that
|
||||
will be out-of-date for the build if the package configuration changes
|
||||
within the same command. You can include or exclude multiple packages
|
||||
in a single make command, e.g. make yes-colloid no-manybody.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
Any package can be included or excluded in a LAMMPS build, independent
|
||||
of all other packages. However, some packages include files derived
|
||||
from files in other packages. LAMMPS checks for this and does the
|
||||
right thing. Individual files are only included if their dependencies
|
||||
are already included. Likewise, if a package is excluded, other files
|
||||
dependent on that package are also excluded.
|
||||
|
||||
When you download a LAMMPS tarball or download LAMMPS source files
|
||||
from the Git or SVN repositories, no packages are pre-installed in the
|
||||
src directory.
|
||||
|
||||
NOTE: Prior to Aug 2018, if you downloaded a tarball, 3 packages
|
||||
(KSPACE, MANYBODY, MOLECULE) were pre-installed in the src directory.
|
||||
That is no longer the case, so that CMake will build as-is without the
|
||||
need to un-install those packages.
|
||||
|
||||
:line
|
||||
|
||||
[CMake shortcuts for installing many packages]:
|
||||
|
||||
Instead of specifying all the CMake options via the command-line,
|
||||
CMake allows initializing the variable cache using script files. These
|
||||
are regular CMake files which can manipulate and set variables, and
|
||||
can also contain control flow constructs.
|
||||
|
||||
LAMMPS includes several of these files to define configuration
|
||||
"presets", similar to the options that exist for the Make based
|
||||
system. Using these files you can enable/disable portions of the
|
||||
available packages in LAMMPS. If you need a custom preset you can take
|
||||
one of them as a starting point and customize it to your needs.
|
||||
|
||||
cmake -C ../cmake/presets/all_on.cmake \[OPTIONS\] ../cmake | enable all packages
|
||||
cmake -C ../cmake/presets/all_off.cmake \[OPTIONS\] ../cmake | disable all packages
|
||||
cmake -C ../cmake/presets/std.cmake \[OPTIONS\] ../cmake | enable standard packages
|
||||
cmake -C ../cmake/presets/user.cmake \[OPTIONS\] ../cmake | enable user packages
|
||||
cmake -C ../cmake/presets/std_nolib.cmake \[OPTIONS\] ../cmake | enable standard packages that do not require extra libraries
|
||||
cmake -C ../cmake/presets/nolib.cmake \[OPTIONS\] ../cmake | disable all packages that do not require extra libraries
|
||||
cmake -C ../cmake/presets/manual_selection.cmake \[OPTIONS\] ../cmake | example of how to create a manual selection of packages :tb(s=|,a=l)
|
||||
|
||||
NOTE: Running cmake this way manipulates the variable cache in your
|
||||
current build directory. You can combine presets and options with
|
||||
multiple cmake runs.
|
||||
|
||||
[Example:]
|
||||
|
||||
# build LAMMPS with all "standard" packages which don't
|
||||
# use libraries and enable GPU package
|
||||
mkdir build
|
||||
cd build
|
||||
cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake :pre
|
||||
|
||||
:line
|
||||
|
||||
[Make shortcuts for installing many packages]:
|
||||
|
||||
The following commands are useful for managing package source files
|
||||
and their installation when building LAMMPS via traditional make.
|
||||
Just type "make" in lammps/src to see a one-line summary.
|
||||
|
||||
These commands install/un-install sets of packages:
|
||||
|
||||
make yes-all | install all packages
|
||||
make no-all | un-install all packages
|
||||
make yes-standard or make yes-std | install standard packages
|
||||
make no-standard or make no-std| un-install standard packages
|
||||
make yes-user | install user packages
|
||||
make no-user | un-install user packages
|
||||
make yes-lib | install packages that require extra libraries
|
||||
make no-lib | un-install packages that require extra libraries
|
||||
make yes-ext | install packages that require external libraries
|
||||
make no-ext | un-install packages that require external libraries :tb(s=|,a=l)
|
||||
|
||||
which install/un-install various sets of packages. Typing "make
|
||||
package" will list all the these commands.
|
||||
|
||||
NOTE: Installing or un-installing a package works by simply copying
|
||||
files back and forth between the main src directory and
|
||||
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
|
||||
so that the files are included or excluded when LAMMPS is built.
|
||||
|
||||
The following make commands help manage files that exist in both the
|
||||
src directory and in package sub-directories. You do not normally
|
||||
need to use these commands unless you are editing LAMMPS files or are
|
||||
"installing a patch"_Install_patch.html downloaded from the LAMMPS web
|
||||
site.
|
||||
|
||||
Type "make package-status" or "make ps" to show which packages are
|
||||
currently installed. For those that are installed, it will list any
|
||||
files that are different in the src directory and package
|
||||
sub-directory.
|
||||
|
||||
Type "make package-installed" or "make pi" to show which packages are
|
||||
currently installed, without listing the status of packages that are
|
||||
not installed.
|
||||
|
||||
Type "make package-update" or "make pu" to overwrite src files with
|
||||
files from the package sub-directories if the package is installed.
|
||||
It should be used after a "patch has been applied"_Install_patch.html,
|
||||
since patches only update the files in the package sub-directory, but
|
||||
not the src files.
|
||||
|
||||
Type "make package-overwrite" to overwrite files in the package
|
||||
sub-directories with src files.
|
||||
|
||||
Type "make package-diff" to list all differences between pairs of
|
||||
files in both the src dir and a package dir.
|
||||
341
doc/src/Build_settings.txt
Normal file
@ -0,0 +1,341 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Optional build settings :h3
|
||||
|
||||
LAMMPS can be built with several optional settings. Each sub-section
|
||||
explain how to do this for building both with CMake and make.
|
||||
|
||||
"FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
|
||||
"Size of LAMMPS data types"_#size
|
||||
"Read or write compressed files"_#gzip
|
||||
"Output of JPG and PNG files"_#graphics via the "dump image"_dump_image.html command
|
||||
"Output of movie files"_#graphics via the "dump_movie"_dump_image.html command
|
||||
"Memory allocation alignment"_#align
|
||||
"Workaround for long long integers"_#longlong
|
||||
"Error handling exceptions"_#exceptions when using LAMMPS as a library :all(b)
|
||||
|
||||
:line
|
||||
|
||||
FFT library :h4,link(fft)
|
||||
|
||||
When the KSPACE package is included in a LAMMPS build, the
|
||||
"kspace_style pppm"_kspace_style.html command performs 3d FFTs which
|
||||
require use of an FFT library to compute 1d FFTs. The KISS FFT
|
||||
library is included with LAMMPS but other libraries can be faster.
|
||||
LAMMPS can use them if they are available on your system.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
|
||||
-D FFT_SINGLE=value # yes or no (default), no = double precision
|
||||
-D FFT_PACK=value # array (default) or pointer or memcpy :pre
|
||||
|
||||
NOTE: The values for the FFT variable must be in upper-case. This is
|
||||
an exception to the rule that all CMake variables can be specified
|
||||
with lower-case values.
|
||||
|
||||
Usually these settings are all that is needed. If CMake cannot find
|
||||
the FFT library, you can set these variables:
|
||||
|
||||
-D FFTW3_INCLUDE_DIRS=path # path to FFTW3 include files
|
||||
-D FFTW3_LIBRARIES=path # path to FFTW3 libraries
|
||||
-D MKL_INCLUDE_DIRS=path # ditto for Intel MKL library
|
||||
-D MKL_LIBRARIES=path :pre
|
||||
|
||||
[Makefile.machine settings]:
|
||||
|
||||
FFT_INC = -DFFT_FFTW3 # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
|
||||
# default is KISS if not specified
|
||||
FFT_INC = -DFFT_SINGLE # do not specify for double precision
|
||||
FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY :pre
|
||||
# default is FFT_PACK_ARRAY if not specified
|
||||
|
||||
FFT_INC = -I/usr/local/include
|
||||
FFT_PATH = -L/usr/local/lib
|
||||
FFT_LIB = -lfftw3 # FFTW3 double precision
|
||||
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
|
||||
FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler
|
||||
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compier :pre
|
||||
|
||||
As with CMake, you do not need to set paths in FFT_INC or FFT_PATH, if
|
||||
make can find the FFT header and library files. You must specify
|
||||
FFT_LIB with the appropriate FFT libraries to include in the link.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
The "KISS FFT library"_http://kissfft.sf.net is included in the LAMMPS
|
||||
distribution. It is portable across all platforms. Depending on the
|
||||
size of the FFTs and the number of processors used, the other
|
||||
libraries listed here can be faster.
|
||||
|
||||
However, note that long-range Coulombics are only a portion of the
|
||||
per-timestep CPU cost, FFTs are only a portion of long-range
|
||||
Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
|
||||
communication can be costly). A breakdown of these timings is printed
|
||||
to the screen at the end of a run using the "kspace_style
|
||||
pppm"_kspace_style.html command. The "Run output"_doc page gives more
|
||||
details.
|
||||
|
||||
FFTW is a fast, portable FFT library that should also work on any
|
||||
platform and can be faster than the KISS FFT library. You can
|
||||
download it from "www.fftw.org"_http://www.fftw.org. LAMMPS requires
|
||||
version 3.X; the legacy version 2.1.X is no longer supported.
|
||||
|
||||
Building FFTW for your box should be as simple as ./configure; make;
|
||||
make install. The install command typically requires root privileges
|
||||
(e.g. invoke it via sudo), unless you specify a local directory with
|
||||
the "--prefix" option of configure. Type "./configure --help" to see
|
||||
various options.
|
||||
|
||||
The Intel MKL math library is part of the Intel compiler suite. It
|
||||
can be used with the Intel or GNU compiler (see FFT_LIB setting above).
|
||||
|
||||
Performing 3d FFTs in parallel can be time consuming due to data
|
||||
access and required communication. This cost can be reduced by
|
||||
performing single-precision FFTs instead of double precision. Single
|
||||
precision means the real and imaginary parts of a complex datum are
|
||||
4-byte floats. Double precesion means they are 8-byte doubles. Note
|
||||
that Fourier transform and related PPPM operations are somewhat less
|
||||
sensitive to floating point truncation errors and thus the resulting
|
||||
error is less than the difference in precision. Using the -DFFT_SINGLE
|
||||
setting trades off a little accuracy for reduced memory use and
|
||||
parallel communication costs for transposing 3d FFT data.
|
||||
|
||||
When using -DFFT_SINGLE with FFTW3 you may need to build the FFTW
|
||||
library a second time with support for single-precision.
|
||||
|
||||
For FFTW3, do the following, which should produce the additional
|
||||
library libfftw3f.a
|
||||
|
||||
make clean
|
||||
./configure --enable-single; make; make install :pre
|
||||
|
||||
Performing 3d FFTs requires communication to transpose the 3d FFT
|
||||
grid. The data packing/unpacking for this can be done in one of 3
|
||||
modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
|
||||
Depending on the machine, the size of the FFT grid, the number of
|
||||
processors used, one option may be slightly faster. The default is
|
||||
ARRAY mode.
|
||||
|
||||
:line
|
||||
|
||||
Size of LAMMPS data types :h4,link(size)
|
||||
|
||||
LAMMPS has a few integer data types which can be defined as 4-byte or
|
||||
8-byte integers. The default setting of "smallbig" is almost always
|
||||
adequate.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
|
||||
# default is LAMMMPS_SMALLBIG if not specified
|
||||
[CMake and make info]:
|
||||
|
||||
The default "smallbig" setting allows for simulations with:
|
||||
|
||||
total atom count = 2^63 atoms (about 9e18)
|
||||
total timesteps = 2^63 (about 9e18)
|
||||
atom IDs = 2^31 (about 2 billion)
|
||||
image flags = roll over at 512 :ul
|
||||
|
||||
The "bigbig" setting increases the latter two limits. It allows for:
|
||||
|
||||
total atom count = 2^63 atoms (about 9e18)
|
||||
total timesteps = 2^63 (about 9e18)
|
||||
atom IDs = 2^63 (about 9e18)
|
||||
image flags = roll over at about 1 million (2^20) :ul
|
||||
|
||||
The "smallsmall" setting is only needed if your machine does not
|
||||
support 8-byte integers. It allows for:
|
||||
|
||||
total atom count = 2^31 atoms (about 2 billion)
|
||||
total timesteps = 2^31 (about 2 billion)
|
||||
atom IDs = 2^31 (about 2 billion)
|
||||
image flags = roll over at 512 (2^9) :ul
|
||||
|
||||
Atom IDs are not required for atomic systems which do not store bond
|
||||
topology information, though IDs are enabled by default. The
|
||||
"atom_modify id no"_atom_modify.html command will turn them off. Atom
|
||||
IDs are required for molecular systems with bond topology (bonds,
|
||||
angles, dihedrals, etc). Thus if you model a molecular system with
|
||||
more than 2 billion atoms, you need the "bigbig" setting.
|
||||
|
||||
Image flags store 3 values per atom which count the number of times an
|
||||
atom has moved through the periodic box in each dimension. See the
|
||||
"dump"_dump.html doc page for a discussion. If an atom moves through
|
||||
the periodic box more than this limit, the value will "roll over",
|
||||
e.g. from 511 to -512, which can cause diagnostics like the
|
||||
mean-squared displacement, as calculated by the "compute
|
||||
msd"_compute_msd.html command, to be faulty.
|
||||
|
||||
Note that the USER-ATC package is not currently compatible with the
|
||||
"bigbig" setting.
|
||||
|
||||
Also note that the GPU package requires its lib/gpu library to be
|
||||
compiled with the same size setting, or the link will fail. A CMake
|
||||
build does this automatically. When building with make, the setting
|
||||
in whichever lib/gpu/Makefile is used must be the same as above.
|
||||
|
||||
:line
|
||||
|
||||
Output of JPG, PNG, and movie files :h4,link(graphics)
|
||||
|
||||
The "dump image"_dump_image.html command has options to output JPEG or
|
||||
PNG image files. Likewise the "dump movie"_dump_image.html command
|
||||
ouputs movie files in MPEG format. Using these options requires the
|
||||
following settings:
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D WITH_JPEG=value # yes or no
|
||||
# default = yes if CMake finds JPEG files, else no
|
||||
-D WITH_PNG=value # yes or no
|
||||
# default = yes if CMake finds PNG and ZLIB files, else no
|
||||
-D WITH_FFMPEG=value # yes or no
|
||||
# default = yes if CMake can find ffmpeg, else no :pre
|
||||
|
||||
Usually these settings are all that is needed. If CMake cannot find
|
||||
the graphics header, library, executuable files, you can set these
|
||||
variables:
|
||||
|
||||
-D JPEG_INCLUDE_DIR=path # path to jpeglib.h header file
|
||||
-D JPEG_LIBRARIES=path # path to libjpeg.a (.so) file
|
||||
-D PNG_INCLUDE_DIR=path # path to png.h header file
|
||||
-D PNG_LIBRARIES=path # path to libpng.a (.so) file
|
||||
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
|
||||
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
|
||||
-D FFMPEG_EXECUTABLE=path # path to ffmpeg executable :pre
|
||||
|
||||
[Makefile.machine settings]:
|
||||
|
||||
LMP_INC = -DLAMMPS_JPEG
|
||||
LMP_INC = -DLAMMPS_PNG
|
||||
LMP_INC = -DLAMMPS_FFMPEG :pre
|
||||
|
||||
JPG_INC = -I/usr/local/include # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
|
||||
JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
|
||||
JPG_LIB = -ljpeg -lpng -lz # library names :pre
|
||||
|
||||
As with CMake, you do not need to set JPG_INC or JPG_PATH, if make can
|
||||
find the graphics header and library files. You must specify JPG_LIB
|
||||
with a list of graphics libraries to include in the link. You must
|
||||
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
|
||||
i.e. a dir in your PATH environment variable.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
Using ffmpeg to output movie files requires that your machine
|
||||
supports the "popen" function in the standard runtime library.
|
||||
|
||||
NOTE: On some clusters with high-speed networks, using the fork()
|
||||
library calls (required by popen()) can interfere with the fast
|
||||
communication library and lead to simulations using ffmpeg to hang or
|
||||
crash.
|
||||
|
||||
:line
|
||||
|
||||
Read or write compressed files :h4,link(gzip)
|
||||
|
||||
If this option is enabled, large files can be read or written with
|
||||
gzip compression by several LAMMPS commands, including
|
||||
"read_data"_read_data.html, "rerun"_rerun.html, and "dump"_dump.html.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D WITH_GZIP=value # yes or no
|
||||
# default is yes if CMake can find gzip, else no
|
||||
-D GZIP_EXECUTABLE=path # path to gzip executable if CMake cannot find it :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_GZIP :pre
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
This option requires that your machine supports the "popen()" function
|
||||
in the standard runtime library and that a gzip executable can be
|
||||
found by LAMMPS during a run.
|
||||
|
||||
NOTE: On some clusters with high-speed networks, using the fork()
|
||||
library calls (required by popen()) can interfere with the fast
|
||||
communication library and lead to simulations using compressed output
|
||||
or input to hang or crash. For selected operations, compressed file
|
||||
I/O is also available using a compression library instead, which is
|
||||
what the "COMPRESS package"_Packages_details.html#PKG-COMPRESS enables.
|
||||
|
||||
:line
|
||||
|
||||
Memory allocation alignment :h4,link(align)
|
||||
|
||||
This setting enables the use of the posix_memalign() call instead of
|
||||
malloc() when LAMMPS allocates large chunks or memory. This can make
|
||||
vector instructions on CPUs more efficient, if dynamically allocated
|
||||
memory is aligned on larger-than-default byte boundaries.
|
||||
On most current systems, the malloc() implementation returns
|
||||
pointers that are aligned to 16-byte boundaries. Using SSE vector
|
||||
instructions efficiently, however, requires memory blocks being
|
||||
aligned on 64-byte boundaries.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default) :pre
|
||||
|
||||
Use a LAMMPS_MEMALIGN value of 0 to disable using posix_memalign()
|
||||
and revert to using the malloc() C-library function instead. When
|
||||
compiling LAMMPS for Windows systems, malloc() will always be used
|
||||
and this setting ignored.
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64 :pre
|
||||
|
||||
Do not set -DLAMMPS_MEMALIGN, if you want to have memory allocated
|
||||
with the malloc() function call instead. -DLAMMPS_MEMALIGN [cannot]
|
||||
be used on Windows, as it does use different function calls for
|
||||
allocating aligned memory, that are not compatible with how LAMMPS
|
||||
manages its dynamical memory.
|
||||
|
||||
:line
|
||||
|
||||
Workaround for long long integers :h4,link(longlong)
|
||||
|
||||
If your system or MPI version does not recognize "long long" data
|
||||
types, the following setting will be needed. It converts "long long"
|
||||
to a "long" data type, which should be the desired 8-byte integer on
|
||||
those systems:
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default) :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG :pre
|
||||
|
||||
:line
|
||||
|
||||
Exception handling when using LAMMPS as a library :h4,link(exceptions)
|
||||
|
||||
This setting is useful when external codes drive LAMMPS as a library.
|
||||
With this option enabled LAMMPS errors do not kill the caller.
|
||||
Instead, the call stack is unwound and control returns to the caller,
|
||||
e.g. to Python.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D LAMMPS_EXCEPTIONS=value # yes or no (default) :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_EXCEPTIONS :pre
|
||||
97
doc/src/Build_windows.txt
Normal file
@ -0,0 +1,97 @@
|
||||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Notes for building LAMMPS on Windows :h3
|
||||
|
||||
"General remarks"_#generic
|
||||
"Running Linux on Windows"_#linux
|
||||
"Using GNU GCC ported to Windows"_#gnu
|
||||
"Using a cross-compiler"_#cross :ul
|
||||
|
||||
:line
|
||||
|
||||
General remarks :h4,link(generic)
|
||||
|
||||
LAMMPS is developed and tested primarily on Linux machines. The vast
|
||||
majority of HPC clusters and supercomputers today runs on Linux as well.
|
||||
Thus portability to other platforms is desired, but not always achieved.
|
||||
The LAMMPS developers strongly rely on LAMMPS users giving feedback and
|
||||
providing assistance in resolving portability issues. This particularly
|
||||
true for compiling LAMMPS on Windows, since this platform has significant
|
||||
differences with some low-level functionality.
|
||||
|
||||
|
||||
Running Linux on Windows :h4,link(linux)
|
||||
|
||||
So before trying to build LAMMPS on Windows, please consider if using
|
||||
the pre-compiled Windows binary packages are sufficient for your needs
|
||||
(as an aside, those packages themselves are build on a Linux machine
|
||||
using cross-compilers). If it is necessary for your to compile LAMMPS
|
||||
on a Windows machine (e.g. because it is your main desktop), please also
|
||||
consider using a virtual machine software and run a Linux virtual machine,
|
||||
or - if have a recently updated Windows 10 installation - consider using
|
||||
the Windows subsystem for Linux, which allows to run a bash shell from
|
||||
Ubuntu and from there on, you can pretty much use that shell like you
|
||||
are running on an Ubuntu Linux machine (e.g. installing software via
|
||||
apt-get). For more details on that, please see "this tutorial"_Howto_bash.html
|
||||
|
||||
|
||||
Using GNU GCC ported to Windows :h4,link(gnu)
|
||||
|
||||
One option for compiling LAMMPS on Windows natively, that has been known
|
||||
to work in the past is to install a bash shell, unix shell utilities,
|
||||
perl, GNU make, and a GNU compiler ported to Windows. The Cygwin package
|
||||
provides a unix/linux interface to low-level Windows functions, so LAMMPS
|
||||
can be compiled on Windows. The necessary (minor) modifications to LAMMPS
|
||||
are included, but may not always up-to-date for recently added functionality
|
||||
and the corresponding new code. A machine makefile for using cygwin for
|
||||
the old build system is provided. The CMake build system is untested
|
||||
for this; you will have to request that makefiles are generated and
|
||||
manually set the compiler.
|
||||
|
||||
When compiling for Windows [not] set the -DLAMMPS_MEMALIGN define
|
||||
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
|
||||
flags in LIB makefile variable. Try adding -static-libgcc or -static or
|
||||
both to the linker flags when your resulting LAMMPS Windows executable
|
||||
complains about missing .dll files. The CMake configuration should set
|
||||
this up automatically, but is untested.
|
||||
|
||||
In case of problems, you are recommended to contact somebody with
|
||||
experience in using cygwin. If you do come across portability problems
|
||||
requiring changes to the LAMMPS source code, or figure out corrections
|
||||
yourself, please report them on the lammps-users mailing list, or file
|
||||
them as an issue or pull request on the LAMMPS github project.
|
||||
|
||||
|
||||
Using a cross-compiler :h4,link(cross)
|
||||
|
||||
If you need to provide custom LAMMPS binaries for Windows, but do not
|
||||
need to do the compilation on Windows, please consider using a Linux
|
||||
to Windows cross-compiler. This is how currently the Windows binary
|
||||
packages are created by the LAMMPS developers. Because of that, this is
|
||||
probably the currently best tested and supported way to build LAMMPS
|
||||
executables for Windows. There are makefiles provided for the
|
||||
traditional build system, but CMake has also been successfully tested
|
||||
using the mingw32-cmake and mingw64-cmake wrappers that are bundled
|
||||
with the cross-compiler environment on Fedora machines.
|
||||
|
||||
Please keep in mind, though, that this only applies to compiling LAMMPS.
|
||||
Whether the resulting binaries do work correctly is no tested by the
|
||||
LAMMPS developers. We instead rely on the feedback of the users
|
||||
of these precompiled LAMMPS packages for Windows. We will try to resolve
|
||||
issues to the best of our abilities if we become aware of them. However
|
||||
this is subject to time constraints and focus on HPC platforms.
|
||||
|
||||
|
||||
Native Visual C++ support :h4,link(native)
|
||||
|
||||
Support for the Visual C++ compilers is currently not available. The
|
||||
CMake build system is capable of creating suitable a Visual Studio
|
||||
style build environment, but the LAMMPS code itself is not fully ported
|
||||
to support Visual C++. Volunteers to take on this task are welcome.
|
||||
53
doc/src/Commands.txt
Normal file
@ -0,0 +1,53 @@
|
||||
"Previous Section"_Run_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Packages.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Commands :h2
|
||||
|
||||
These pages describe how a LAMMPS input script is formatted and the
|
||||
commands in it are used to define a LAMMPS simulation.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Commands_input
|
||||
Commands_parse
|
||||
Commands_structure
|
||||
Commands_category
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Commands_all
|
||||
Commands_fix
|
||||
Commands_compute
|
||||
Commands_pair
|
||||
Commands_bond
|
||||
Commands_kspace
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"LAMMPS input scripts"_Commands_input.html
|
||||
"Parsing rules for input scripts"_Commands_parse.html
|
||||
"Input script structure"_Commands_structure.html
|
||||
"Commands by category"_Commands_category.html :all(b)
|
||||
|
||||
"All commands"_Commands_all.html
|
||||
"Fix commands"_Commands_fix.html
|
||||
"Compute commands"_Commands_compute.html
|
||||
"Pair commands"_Commands_pair.html
|
||||
"Bond, angle, dihedral, improper commands"_Commands_bond.html
|
||||
"KSpace solvers"_Commands_kspace.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
128
doc/src/Commands_all.txt
Normal file
@ -0,0 +1,128 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
"Bond styles"_Commands_bond.html,
|
||||
"Angle styles"_Commands_bond.html#angle,
|
||||
"Dihedral styles"_Commands_bond.html#dihedral,
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
All commands :h3
|
||||
|
||||
An alphabetic list of all LAMMPS commmands.
|
||||
|
||||
"angle_coeff"_angle_coeff.html,
|
||||
"angle_style"_angle_style.html,
|
||||
"atom_modify"_atom_modify.html,
|
||||
"atom_style"_atom_style.html,
|
||||
"balance"_balance.html,
|
||||
"bond_coeff"_bond_coeff.html,
|
||||
"bond_style"_bond_style.html,
|
||||
"bond_write"_bond_write.html,
|
||||
"boundary"_boundary.html,
|
||||
"box"_box.html,
|
||||
"change_box"_change_box.html,
|
||||
"clear"_clear.html,
|
||||
"comm_modify"_comm_modify.html,
|
||||
"comm_style"_comm_style.html,
|
||||
"compute"_compute.html,
|
||||
"compute_modify"_compute_modify.html,
|
||||
"create_atoms"_create_atoms.html,
|
||||
"create_bonds"_create_bonds.html,
|
||||
"create_box"_create_box.html,
|
||||
"delete_atoms"_delete_atoms.html,
|
||||
"delete_bonds"_delete_bonds.html,
|
||||
"dielectric"_dielectric.html,
|
||||
"dihedral_coeff"_dihedral_coeff.html,
|
||||
"dihedral_style"_dihedral_style.html,
|
||||
"dimension"_dimension.html,
|
||||
"displace_atoms"_displace_atoms.html,
|
||||
"dump"_dump.html,
|
||||
"dump image"_dump_image.html,
|
||||
"dump_modify"_dump_modify.html,
|
||||
"dump movie"_dump_image.html,
|
||||
"dump netcdf"_dump_netcdf.html,
|
||||
"dump netcdf/mpiio"_dump_netcdf.html,
|
||||
"dump vtk"_dump_vtk.html,
|
||||
"echo"_echo.html,
|
||||
"fix"_fix.html,
|
||||
"fix_modify"_fix_modify.html,
|
||||
"group"_group.html,
|
||||
"group2ndx"_group2ndx.html,
|
||||
"if"_if.html,
|
||||
"info"_info.html,
|
||||
"improper_coeff"_improper_coeff.html,
|
||||
"improper_style"_improper_style.html,
|
||||
"include"_include.html,
|
||||
"jump"_jump.html,
|
||||
"kspace_modify"_kspace_modify.html,
|
||||
"kspace_style"_kspace_style.html,
|
||||
"label"_label.html,
|
||||
"lattice"_lattice.html,
|
||||
"log"_log.html,
|
||||
"mass"_mass.html,
|
||||
"minimize"_minimize.html,
|
||||
"min_modify"_min_modify.html,
|
||||
"min_style"_min_style.html,
|
||||
"molecule"_molecule.html,
|
||||
"ndx2group"_group2ndx.html,
|
||||
"neb"_neb.html,
|
||||
"neigh_modify"_neigh_modify.html,
|
||||
"neighbor"_neighbor.html,
|
||||
"newton"_newton.html,
|
||||
"next"_next.html,
|
||||
"package"_package.html,
|
||||
"pair_coeff"_pair_coeff.html,
|
||||
"pair_modify"_pair_modify.html,
|
||||
"pair_style"_pair_style.html,
|
||||
"pair_write"_pair_write.html,
|
||||
"partition"_partition.html,
|
||||
"prd"_prd.html,
|
||||
"print"_print.html,
|
||||
"processors"_processors.html,
|
||||
"python"_python.html,
|
||||
"quit"_quit.html,
|
||||
"read_data"_read_data.html,
|
||||
"read_dump"_read_dump.html,
|
||||
"read_restart"_read_restart.html,
|
||||
"region"_region.html,
|
||||
"replicate"_replicate.html,
|
||||
"rerun"_rerun.html,
|
||||
"reset_ids"_reset_ids.html,
|
||||
"reset_timestep"_reset_timestep.html,
|
||||
"restart"_restart.html,
|
||||
"run"_run.html,
|
||||
"run_style"_run_style.html,
|
||||
"set"_set.html,
|
||||
"shell"_shell.html,
|
||||
"special_bonds"_special_bonds.html,
|
||||
"suffix"_suffix.html,
|
||||
"tad"_tad.html,
|
||||
"temper"_temper.html,
|
||||
"temper/grem"_temper_grem.html,
|
||||
"temper/npt"_temper_npt.html,
|
||||
"thermo"_thermo.html,
|
||||
"thermo_modify"_thermo_modify.html,
|
||||
"thermo_style"_thermo_style.html,
|
||||
"timer"_timer.html,
|
||||
"timestep"_timestep.html,
|
||||
"uncompute"_uncompute.html,
|
||||
"undump"_undump.html,
|
||||
"unfix"_unfix.html,
|
||||
"units"_units.html,
|
||||
"variable"_variable.html,
|
||||
"velocity"_velocity.html,
|
||||
"write_coeff"_write_coeff.html,
|
||||
"write_data"_write_data.html,
|
||||
"write_dump"_write_dump.html,
|
||||
"write_restart"_write_restart.html :tb(c=6,ea=c)
|
||||
124
doc/src/Commands_bond.txt
Normal file
@ -0,0 +1,124 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
"Bond styles"_Commands_bond.html#bond,
|
||||
"Angle styles"_Commands_bond.html#angle,
|
||||
"Dihedral styles"_Commands_bond.html#dihedral,
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
Bond, angle, dihedral, and improper commands :h3
|
||||
|
||||
:line
|
||||
|
||||
Bond_style potentials :h3,link(bond)
|
||||
|
||||
All LAMMPS "bond_style"_bond_style.html commands. Some styles have
|
||||
accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"none"_bond_none.html,
|
||||
"zero"_bond_zero.html,
|
||||
"hybrid"_bond_hybrid.html :tb(c=3,ea=c)
|
||||
|
||||
"class2 (ko)"_bond_class2.html,
|
||||
"fene (iko)"_bond_fene.html,
|
||||
"fene/expand (o)"_bond_fene_expand.html,
|
||||
"gromos (o)"_bond_gromos.html,
|
||||
"harmonic (ko)"_bond_harmonic.html,
|
||||
"harmonic/shift (o)"_bond_harmonic_shift.html,
|
||||
"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
|
||||
"morse (o)"_bond_morse.html,
|
||||
"nonlinear (o)"_bond_nonlinear.html,
|
||||
"oxdna/fene"_bond_oxdna.html,
|
||||
"oxdna2/fene"_bond_oxdna.html,
|
||||
"quartic (o)"_bond_quartic.html,
|
||||
"table (o)"_bond_table.html :tb(c=4,ea=c)
|
||||
|
||||
:line
|
||||
|
||||
Angle_style potentials :h3,link(angle)
|
||||
|
||||
All LAMMPS "angle_style"_angle_style.html commands. Some styles have
|
||||
accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"none"_angle_none.html,
|
||||
"zero"_angle_zero.html,
|
||||
"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
|
||||
|
||||
"charmm (ko)"_angle_charmm.html,
|
||||
"class2 (ko)"_angle_class2.html,
|
||||
"cosine (o)"_angle_cosine.html,
|
||||
"cosine/delta (o)"_angle_cosine_delta.html,
|
||||
"cosine/periodic (o)"_angle_cosine_periodic.html,
|
||||
"cosine/shift (o)"_angle_cosine_shift.html,
|
||||
"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
|
||||
"cosine/squared (o)"_angle_cosine_squared.html,
|
||||
"dipole (o)"_angle_dipole.html,
|
||||
"fourier (o)"_angle_fourier.html,
|
||||
"fourier/simple (o)"_angle_fourier_simple.html,
|
||||
"harmonic (iko)"_angle_harmonic.html,
|
||||
"quartic (o)"_angle_quartic.html,
|
||||
"sdk"_angle_sdk.html,
|
||||
"table (o)"_angle_table.html :tb(c=4,ea=c)
|
||||
|
||||
:line
|
||||
|
||||
Dihedral_style potentials :h3,link(dihedral)
|
||||
|
||||
All LAMMPS "dihedral_style"_dihedral_style.html commands. Some styles
|
||||
have accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"none"_dihedral_none.html,
|
||||
"zero"_dihedral_zero.html,
|
||||
"hybrid"_dihedral_hybrid.html :tb(c=3,ea=c)
|
||||
|
||||
"charmm (iko)"_dihedral_charmm.html,
|
||||
"charmmfsw"_dihedral_charmm.html,
|
||||
"class2 (ko)"_dihedral_class2.html,
|
||||
"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
|
||||
"fourier (io)"_dihedral_fourier.html,
|
||||
"harmonic (io)"_dihedral_harmonic.html,
|
||||
"helix (o)"_dihedral_helix.html,
|
||||
"multi/harmonic (o)"_dihedral_multi_harmonic.html,
|
||||
"nharmonic (o)"_dihedral_nharmonic.html,
|
||||
"opls (iko)"_dihedral_opls.htm;,
|
||||
"quadratic (o)"_dihedral_quadratic.html,
|
||||
"spherical (o)"_dihedral_spherical.html,
|
||||
"table (o)"_dihedral_table.html,
|
||||
"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
|
||||
|
||||
:line
|
||||
|
||||
Improper_style potentials :h3,link(improper)
|
||||
|
||||
All LAMMPS "improper_style"_improper_style.html commands. Some styles
|
||||
have accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"none"_improper_none.html,
|
||||
"zero"_improper_zero.html,
|
||||
"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
|
||||
|
||||
"class2 (ko)"_improper_class2.html,
|
||||
"cossq (o)"_improper_cossq.html,
|
||||
"cvff (io)"_improper_cvff.html,
|
||||
"distance"_improper_distance.html,
|
||||
"fourier (o)"_improper_fourier.html,
|
||||
"harmonic (iko)"_improper_harmonic.html,
|
||||
"ring (o)"_improper_ring.html,
|
||||
"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)
|
||||
141
doc/src/Commands_category.txt
Normal file
@ -0,0 +1,141 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Commands by category :h3
|
||||
|
||||
This page lists most of the LAMMPS commands, grouped by category. The
|
||||
"Commands all"_Commands_all.html doc page lists all commands
|
||||
alphabetically. It also includes long lists of style options for
|
||||
entries that appear in the following categories as a single command
|
||||
(fix, compute, pair, etc).
|
||||
|
||||
Initialization:
|
||||
|
||||
"newton"_newton.html,
|
||||
"package"_package.html,
|
||||
"processors"_processors.html,
|
||||
"suffix"_suffix.html,
|
||||
"units"_units.html :ul
|
||||
|
||||
Setup simulation box:
|
||||
|
||||
"boundary"_boundary.html,
|
||||
"box"_box.html,
|
||||
"change_box"_change_box.html,
|
||||
"create_box"_create_box.html,
|
||||
"dimension"_dimension.html,
|
||||
"lattice"_lattice.html,
|
||||
"region"_region.html :ul
|
||||
|
||||
Setup atoms:
|
||||
|
||||
"atom_modify"_atom_modify.html,
|
||||
"atom_style"_atom_style.html,
|
||||
"balance"_balance.html,
|
||||
"create_atoms"_create_atoms.html,
|
||||
"create_bonds"_create_bonds.html,
|
||||
"delete_atoms"_delete_atoms.html,
|
||||
"delete_bonds"_delete_bonds.html,
|
||||
"displace_atoms"_displace_atoms.html,
|
||||
"group"_group.html,
|
||||
"mass"_mass.html,
|
||||
"molecule"_molecule.html,
|
||||
"read_data"_read_data.html,
|
||||
"read_dump"_read_dump.html,
|
||||
"read_restart"_read_restart.html,
|
||||
"replicate"_replicate.html,
|
||||
"set"_set.html,
|
||||
"velocity"_velocity.html :ul
|
||||
|
||||
Force fields:
|
||||
|
||||
"angle_coeff"_angle_coeff.html,
|
||||
"angle_style"_angle_style.html,
|
||||
"bond_coeff"_bond_coeff.html,
|
||||
"bond_style"_bond_style.html,
|
||||
"bond_write"_bond_write.html,
|
||||
"dielectric"_dielectric.html,
|
||||
"dihedral_coeff"_dihedral_coeff.html,
|
||||
"dihedral_style"_dihedral_style.html,
|
||||
"improper_coeff"_improper_coeff.html,
|
||||
"improper_style"_improper_style.html,
|
||||
"kspace_modify"_kspace_modify.html,
|
||||
"kspace_style"_kspace_style.html,
|
||||
"pair_coeff"_pair_coeff.html,
|
||||
"pair_modify"_pair_modify.html,
|
||||
"pair_style"_pair_style.html,
|
||||
"pair_write"_pair_write.html,
|
||||
"special_bonds"_special_bonds.html :ul
|
||||
|
||||
Settings:
|
||||
|
||||
"comm_modify"_comm_modify.html,
|
||||
"comm_style"_comm_style.html,
|
||||
"info"_info.html,
|
||||
"min_modify"_min_modify.html,
|
||||
"min_style"_min_style.html,
|
||||
"neigh_modify"_neigh_modify.html,
|
||||
"neighbor"_neighbor.html,
|
||||
"partition"_partition.html,
|
||||
"reset_timestep"_reset_timestep.html,
|
||||
"run_style"_run_style.html,
|
||||
"timer"_timer.html,
|
||||
"timestep"_timestep.html :ul
|
||||
|
||||
Operations within timestepping (fixes) and diagnostics (computes):
|
||||
|
||||
"compute"_compute.html,
|
||||
"compute_modify"_compute_modify.html,
|
||||
"fix"_fix.html,
|
||||
"fix_modify"_fix_modify.html,
|
||||
"uncompute"_uncompute.html,
|
||||
"unfix"_unfix.html :ul
|
||||
|
||||
Output:
|
||||
|
||||
"dump image"_dump_image.html,
|
||||
"dump movie"_dump_image.html,
|
||||
"dump"_dump.html,
|
||||
"dump_modify"_dump_modify.html,
|
||||
"restart"_restart.html,
|
||||
"thermo"_thermo.html,
|
||||
"thermo_modify"_thermo_modify.html,
|
||||
"thermo_style"_thermo_style.html,
|
||||
"undump"_undump.html,
|
||||
"write_coeff"_write_coeff.html,
|
||||
"write_data"_write_data.html,
|
||||
"write_dump"_write_dump.html,
|
||||
"write_restart"_write_restart.html :ul
|
||||
|
||||
Actions:
|
||||
|
||||
"minimize"_minimize.html,
|
||||
"neb"_neb.html,
|
||||
"prd"_prd.html,
|
||||
"rerun"_rerun.html,
|
||||
"run"_run.html,
|
||||
"tad"_tad.html,
|
||||
"temper"_temper.html :ul
|
||||
|
||||
Input script control:
|
||||
|
||||
"clear"_clear.html,
|
||||
"echo"_echo.html,
|
||||
"if"_if.html,
|
||||
"include"_include.html,
|
||||
"jump"_jump.html,
|
||||
"label"_label.html,
|
||||
"log"_log.html,
|
||||
"next"_next.html,
|
||||
"print"_print.html,
|
||||
"python"_python.html,
|
||||
"quit"_quit.html,
|
||||
"shell"_shell.html,
|
||||
"variable"_variable.html :ul
|
||||
|
||||
153
doc/src/Commands_compute.txt
Normal file
@ -0,0 +1,153 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
"Bond styles"_Commands_bond.html,
|
||||
"Angle styles"_Commands_bond.html#angle,
|
||||
"Dihedral styles"_Commands_bond.html#dihedral,
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
Compute commands :h3
|
||||
|
||||
An alphabetic list of all LAMMPS "compute"_compute.html commands.
|
||||
Some styles have accelerated versions. This is indicated by
|
||||
additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
|
||||
KOKKOS, o = USER-OMP, t = OPT.
|
||||
|
||||
"ackland/atom"_compute_ackland_atom.html,
|
||||
"aggregate/atom"_compute_cluster_atom.html,
|
||||
"angle"_compute_angle.html,
|
||||
"angle/local"_compute_angle_local.html,
|
||||
"angmom/chunk"_compute_angmom_chunk.html,
|
||||
"basal/atom"_compute_basal_atom.html,
|
||||
"body/local"_compute_body_local.html,
|
||||
"bond"_compute_bond.html,
|
||||
"bond/local"_compute_bond_local.html,
|
||||
"centro/atom"_compute_centro_atom.html,
|
||||
"chunk/atom"_compute_chunk_atom.html,
|
||||
"cluster/atom"_compute_cluster_atom.html,
|
||||
"cna/atom"_compute_cna_atom.html,
|
||||
"cnp/atom"_compute_cnp_atom.html,
|
||||
"com"_compute_com.html,
|
||||
"com/chunk"_compute_com_chunk.html,
|
||||
"contact/atom"_compute_contact_atom.html,
|
||||
"coord/atom"_compute_coord_atom.html,
|
||||
"damage/atom"_compute_damage_atom.html,
|
||||
"dihedral"_compute_dihedral.html,
|
||||
"dihedral/local"_compute_dihedral_local.html,
|
||||
"dilatation/atom"_compute_dilatation_atom.html,
|
||||
"dipole/chunk"_compute_dipole_chunk.html,
|
||||
"displace/atom"_compute_displace_atom.html,
|
||||
"dpd"_compute_dpd.html,
|
||||
"dpd/atom"_compute_dpd_atom.html,
|
||||
"edpd/temp/atom"_compute_edpd_temp_atom.html,
|
||||
"entropy/atom"_compute_entropy_atom.html,
|
||||
"erotate/asphere"_compute_erotate_asphere.html,
|
||||
"erotate/rigid"_compute_erotate_rigid.html,
|
||||
"erotate/sphere"_compute_erotate_sphere.html,
|
||||
"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
|
||||
"event/displace"_compute_event_displace.html,
|
||||
"fep"_compute_fep.html,
|
||||
"force/tally"_compute_tally.html,
|
||||
"fragment/atom"_compute_cluster_atom.html,
|
||||
"global/atom"_compute_global_atom.html,
|
||||
"group/group"_compute_group_group.html,
|
||||
"gyration"_compute_gyration.html,
|
||||
"gyration/chunk"_compute_gyration_chunk.html,
|
||||
"heat/flux"_compute_heat_flux.html,
|
||||
"heat/flux/tally"_compute_tally.html,
|
||||
"hexorder/atom"_compute_hexorder_atom.html,
|
||||
"improper"_compute_improper.html,
|
||||
"improper/local"_compute_improper_local.html,
|
||||
"inertia/chunk"_compute_inertia_chunk.html,
|
||||
"ke"_compute_ke.html,
|
||||
"ke/atom"_compute_ke_atom.html,
|
||||
"ke/atom/eff"_compute_ke_atom_eff.html,
|
||||
"ke/eff"_compute_ke_eff.html,
|
||||
"ke/rigid"_compute_ke_rigid.html,
|
||||
"meso/e/atom"_compute_meso_e_atom.html,
|
||||
"meso/rho/atom"_compute_meso_rho_atom.html,
|
||||
"meso/t/atom"_compute_meso_t_atom.html,
|
||||
"msd"_compute_msd.html,
|
||||
"msd/chunk"_compute_msd_chunk.html,
|
||||
"msd/nongauss"_compute_msd_nongauss.html,
|
||||
"omega/chunk"_compute_omega_chunk.html,
|
||||
"orientorder/atom"_compute_orientorder_atom.html,
|
||||
"pair"_compute_pair.html,
|
||||
"pair/local"_compute_pair_local.html,
|
||||
"pe"_compute_pe.html,
|
||||
"pe/atom"_compute_pe_atom.html,
|
||||
"pe/mol/tally"_compute_tally.html,
|
||||
"pe/tally"_compute_tally.html,
|
||||
"plasticity/atom"_compute_plasticity_atom.html,
|
||||
"pressure"_compute_pressure.html,
|
||||
"pressure/uef"_compute_pressure_uef.html,
|
||||
"property/atom"_compute_property_atom.html,
|
||||
"property/chunk"_compute_property_chunk.html,
|
||||
"property/local"_compute_property_local.html,
|
||||
"rdf"_compute_rdf.html,
|
||||
"reduce"_compute_reduce.html,
|
||||
"reduce/region"_compute_reduce.html,
|
||||
"rigid/local"_compute_rigid_local.html,
|
||||
"saed"_compute_saed.html,
|
||||
"slice"_compute_slice.html,
|
||||
"smd/contact/radius"_compute_smd_contact_radius.html,
|
||||
"smd/damage"_compute_smd_damage.html,
|
||||
"smd/hourglass/error"_compute_smd_hourglass_error.html,
|
||||
"smd/internal/energy"_compute_smd_internal_energy.html,
|
||||
"smd/plastic/strain"_compute_smd_plastic_strain.html,
|
||||
"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
|
||||
"smd/rho"_compute_smd_rho.html,
|
||||
"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
|
||||
"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
|
||||
"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
|
||||
"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
|
||||
"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
|
||||
"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
|
||||
"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
|
||||
"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
|
||||
"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
|
||||
"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
|
||||
"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
|
||||
"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
|
||||
"smd/vol"_compute_smd_vol.html,
|
||||
"sna/atom"_compute_sna_atom.html,
|
||||
"snad/atom"_compute_sna_atom.html,
|
||||
"snav/atom"_compute_sna_atom.html,
|
||||
"spin"_compute_spin.html,
|
||||
"stress/atom"_compute_stress_atom.html,
|
||||
"stress/tally"_compute_tally.html,
|
||||
"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
|
||||
"temp (k)"_compute_temp.html,
|
||||
"temp/asphere"_compute_temp_asphere.html,
|
||||
"temp/body"_compute_temp_body.html,
|
||||
"temp/chunk"_compute_temp_chunk.html,
|
||||
"temp/com"_compute_temp_com.html,
|
||||
"temp/deform"_compute_temp_deform.html,
|
||||
"temp/deform/eff"_compute_temp_deform_eff.html,
|
||||
"temp/drude"_compute_temp_drude.html,
|
||||
"temp/eff"_compute_temp_eff.html,
|
||||
"temp/partial"_compute_temp_partial.html,
|
||||
"temp/profile"_compute_temp_profile.html,
|
||||
"temp/ramp"_compute_temp_ramp.html,
|
||||
"temp/region"_compute_temp_region.html,
|
||||
"temp/region/eff"_compute_temp_region_eff.html,
|
||||
"temp/rotate"_compute_temp_rotate.html,
|
||||
"temp/sphere"_compute_temp_sphere.html,
|
||||
"temp/uef"_compute_temp_uef.html,
|
||||
"ti"_compute_ti.html,
|
||||
"torque/chunk"_compute_torque_chunk.html,
|
||||
"vacf"_compute_vacf.html,
|
||||
"vcm/chunk"_compute_vcm_chunk.html,
|
||||
"voronoi/atom"_compute_voronoi_atom.html,
|
||||
"xrd"_compute_xrd.html :tb(c=6,ea=c)
|
||||
229
doc/src/Commands_fix.txt
Normal file
@ -0,0 +1,229 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
"Bond styles"_Commands_bond.html,
|
||||
"Angle styles"_Commands_bond.html#angle,
|
||||
"Dihedral styles"_Commands_bond.html#dihedral,
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
Fix commands :h3
|
||||
|
||||
An alphabetic list of all LAMMPS "fix"_fix.html commands. Some styles
|
||||
have accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"adapt"_fix_adapt.html,
|
||||
"adapt/fep"_fix_adapt_fep.html,
|
||||
"addforce"_fix_addforce.html,
|
||||
"addtorque"_fix_addtorque.html,
|
||||
"append/atoms"_fix_append_atoms.html,
|
||||
"atc"_fix_atc.html,
|
||||
"atom/swap"_fix_atom_swap.html,
|
||||
"ave/atom"_fix_ave_atom.html,
|
||||
"ave/chunk"_fix_ave_chunk.html,
|
||||
"ave/correlate"_fix_ave_correlate.html,
|
||||
"ave/correlate/long"_fix_ave_correlate_long.html,
|
||||
"ave/histo"_fix_ave_histo.html,
|
||||
"ave/histo/weight"_fix_ave_histo.html,
|
||||
"ave/time"_fix_ave_time.html,
|
||||
"aveforce"_fix_aveforce.html,
|
||||
"balance"_fix_balance.html,
|
||||
"bond/break"_fix_bond_break.html,
|
||||
"bond/create"_fix_bond_create.html,
|
||||
"bond/react"_fix_bond_react.html,
|
||||
"bond/swap"_fix_bond_swap.html,
|
||||
"box/relax"_fix_box_relax.html,
|
||||
"cmap"_fix_cmap.html,
|
||||
"colvars"_fix_colvars.html,
|
||||
"controller"_fix_controller.html,
|
||||
"deform (k)"_fix_deform.html,
|
||||
"deposit"_fix_deposit.html,
|
||||
"dpd/energy (k)"_fix_dpd_energy.html,
|
||||
"drag"_fix_drag.html,
|
||||
"drude"_fix_drude.html,
|
||||
"drude/transform/direct"_fix_drude_transform.html,
|
||||
"drude/transform/reverse"_fix_drude_transform.html,
|
||||
"dt/reset"_fix_dt_reset.html,
|
||||
"edpd/source"_fix_dpd_source.html,
|
||||
"efield"_fix_efield.html,
|
||||
"ehex"_fix_ehex.html,
|
||||
"enforce2d (k)"_fix_enforce2d.html,
|
||||
"eos/cv"_fix_eos_cv.html,
|
||||
"eos/table"_fix_eos_table.html,
|
||||
"eos/table/rx (k)"_fix_eos_table_rx.html,
|
||||
"evaporate"_fix_evaporate.html,
|
||||
"external"_fix_external.html,
|
||||
"filter/corotate"_fix_filter_corotate.html,
|
||||
"flow/gauss"_fix_flow_gauss.html,
|
||||
"freeze"_fix_freeze.html,
|
||||
"gcmc"_fix_gcmc.html,
|
||||
"gld"_fix_gld.html,
|
||||
"gle"_fix_gle.html,
|
||||
"gravity (o)"_fix_gravity.html,
|
||||
"grem"_fix_grem.html,
|
||||
"halt"_fix_halt.html,
|
||||
"heat"_fix_heat.html,
|
||||
"imd"_fix_imd.html,
|
||||
"indent"_fix_indent.html,
|
||||
"ipi"_fix_ipi.html,
|
||||
"langevin (k)"_fix_langevin.html,
|
||||
"langevin/drude"_fix_langevin_drude.html,
|
||||
"langevin/eff"_fix_langevin_eff.html,
|
||||
"langevin/spin"_fix_langevin_spin.html,
|
||||
"latte"_fix_latte.html,
|
||||
"lb/fluid"_fix_lb_fluid.html,
|
||||
"lb/momentum"_fix_lb_momentum.html,
|
||||
"lb/pc"_fix_lb_pc.html,
|
||||
"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
|
||||
"lb/viscous"_fix_lb_viscous.html,
|
||||
"lineforce"_fix_lineforce.html,
|
||||
"manifoldforce"_fix_manifoldforce.html,
|
||||
"meso"_fix_meso.html,
|
||||
"meso/stationary"_fix_meso_stationary.html,
|
||||
"momentum (k)"_fix_momentum.html,
|
||||
"move"_fix_move.html,
|
||||
"mscg"_fix_mscg.html,
|
||||
"msst"_fix_msst.html,
|
||||
"mvv/dpd"_fix_mvv_dpd.html,
|
||||
"mvv/edpd"_fix_mvv_dpd.html,
|
||||
"mvv/tdpd"_fix_mvv_dpd.html,
|
||||
"neb"_fix_neb.html,
|
||||
"nph (ko)"_fix_nh.html,
|
||||
"nph/asphere (o)"_fix_nph_asphere.html,
|
||||
"nph/body"_fix_nph_body.html,
|
||||
"nph/eff"_fix_nh_eff.html,
|
||||
"nph/sphere (o)"_fix_nph_sphere.html,
|
||||
"nphug (o)"_fix_nphug.html,
|
||||
"npt (kio)"_fix_nh.html,
|
||||
"npt/asphere (o)"_fix_npt_asphere.html,
|
||||
"npt/body"_fix_npt_body.html,
|
||||
"npt/eff"_fix_nh_eff.html,
|
||||
"npt/sphere (o)"_fix_npt_sphere.html,
|
||||
"npt/uef"_fix_nh_uef.html,
|
||||
"nve (kio)"_fix_nve.html,
|
||||
"nve/asphere (i)"_fix_nve_asphere.html,
|
||||
"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
|
||||
"nve/body"_fix_nve_body.html,
|
||||
"nve/dot"_fix_nve_dot.html,
|
||||
"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
|
||||
"nve/eff"_fix_nve_eff.html,
|
||||
"nve/limit"_fix_nve_limit.html,
|
||||
"nve/line"_fix_nve_line.html,
|
||||
"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
|
||||
"nve/noforce"_fix_nve_noforce.html,
|
||||
"nve/sphere (o)"_fix_nve_sphere.html,
|
||||
"nve/spin"_fix_nve_spin.html,
|
||||
"nve/tri"_fix_nve_tri.html,
|
||||
"nvk"_fix_nvk.html,
|
||||
"nvt (iko)"_fix_nh.html,
|
||||
"nvt/asphere (o)"_fix_nvt_asphere.html,
|
||||
"nvt/body"_fix_nvt_body.html,
|
||||
"nvt/eff"_fix_nh_eff.html,
|
||||
"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
|
||||
"nvt/sllod (io)"_fix_nvt_sllod.html,
|
||||
"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
|
||||
"nvt/sphere (o)"_fix_nvt_sphere.html,
|
||||
"nvt/uef"_fix_nh_uef.html,
|
||||
"oneway"_fix_oneway.html,
|
||||
"orient/bcc"_fix_orient.html,
|
||||
"orient/fcc"_fix_orient.html,
|
||||
"phonon"_fix_phonon.html,
|
||||
"pimd"_fix_pimd.html,
|
||||
"planeforce"_fix_planeforce.html,
|
||||
"poems"_fix_poems.html,
|
||||
"pour"_fix_pour.html,
|
||||
"precession/spin"_fix_precession_spin.html,
|
||||
"press/berendsen"_fix_press_berendsen.html,
|
||||
"print"_fix_print.html,
|
||||
"property/atom (k)"_fix_property_atom.html,
|
||||
"python/invoke"_fix_python_invoke.html,
|
||||
"python/move"_fix_python_move.html,
|
||||
"qbmsst"_fix_qbmsst.html,
|
||||
"qeq/comb (o)"_fix_qeq_comb.html,
|
||||
"qeq/dynamic"_fix_qeq.html,
|
||||
"qeq/fire"_fix_qeq.html,
|
||||
"qeq/point"_fix_qeq.html,
|
||||
"qeq/reax (ko)"_fix_qeq_reax.html,
|
||||
"qeq/shielded"_fix_qeq.html,
|
||||
"qeq/slater"_fix_qeq.html,
|
||||
"qmmm"_fix_qmmm.html,
|
||||
"qtb"_fix_qtb.html,
|
||||
"rattle"_fix_shake.html,
|
||||
"reax/bonds"_fix_reax_bonds.html,
|
||||
"reax/c/bonds (k)"_fix_reax_bonds.html,
|
||||
"reax/c/species (k)"_fix_reaxc_species.html,
|
||||
"recenter"_fix_recenter.html,
|
||||
"restrain"_fix_restrain.html,
|
||||
"rhok"_fix_rhok.html,
|
||||
"rigid (o)"_fix_rigid.html,
|
||||
"rigid/nph (o)"_fix_rigid.html,
|
||||
"rigid/npt (o)"_fix_rigid.html,
|
||||
"rigid/nve (o)"_fix_rigid.html,
|
||||
"rigid/nvt (o)"_fix_rigid.html,
|
||||
"rigid/small (o)"_fix_rigid.html,
|
||||
"rigid/small/nph"_fix_rigid.html,
|
||||
"rigid/small/npt"_fix_rigid.html,
|
||||
"rigid/small/nve"_fix_rigid.html,
|
||||
"rigid/small/nvt"_fix_rigid.html,
|
||||
"rx (k)"_fix_rx.html,
|
||||
"saed/vtk"_fix_saed_vtk.html,
|
||||
"setforce (k)"_fix_setforce.html,
|
||||
"shake"_fix_shake.html,
|
||||
"shardlow (k)"_fix_shardlow.html,
|
||||
"smd"_fix_smd.html,
|
||||
"smd/adjust/dt"_fix_smd_adjust_dt.html,
|
||||
"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
|
||||
"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
|
||||
"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
|
||||
"smd/setvel"_fix_smd_setvel.html,
|
||||
"smd/wall/surface"_fix_smd_wall_surface.html,
|
||||
"spring"_fix_spring.html,
|
||||
"spring/chunk"_fix_spring_chunk.html,
|
||||
"spring/rg"_fix_spring_rg.html,
|
||||
"spring/self"_fix_spring_self.html,
|
||||
"srd"_fix_srd.html,
|
||||
"store/force"_fix_store_force.html,
|
||||
"store/state"_fix_store_state.html,
|
||||
"tdpd/source"_fix_dpd_source.html,
|
||||
"temp/berendsen"_fix_temp_berendsen.html,
|
||||
"temp/csld"_fix_temp_csvr.html,
|
||||
"temp/csvr"_fix_temp_csvr.html,
|
||||
"temp/rescale"_fix_temp_rescale.html,
|
||||
"temp/rescale/eff"_fix_temp_rescale_eff.html,
|
||||
"tfmc"_fix_tfmc.html,
|
||||
"thermal/conductivity"_fix_thermal_conductivity.html,
|
||||
"ti/spring"_fix_ti_spring.html,
|
||||
"tmd"_fix_tmd.html,
|
||||
"ttm"_fix_ttm.html,
|
||||
"ttm/mod"_fix_ttm.html,
|
||||
"tune/kspace"_fix_tune_kspace.html,
|
||||
"vector"_fix_vector.html,
|
||||
"viscosity"_fix_viscosity.html,
|
||||
"viscous"_fix_viscous.html,
|
||||
"wall/body/polygon"_fix_wall_body_polygon.html,
|
||||
"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
|
||||
"wall/colloid"_fix_wall.html,
|
||||
"wall/ees"_fix_wall_ees.html,
|
||||
"wall/gran"_fix_wall_gran.html,
|
||||
"wall/gran/region"_fix_wall_gran_region.html,
|
||||
"wall/harmonic"_fix_wall.html,
|
||||
"wall/lj1043"_fix_wall.html,
|
||||
"wall/lj126"_fix_wall.html,
|
||||
"wall/lj93 (k)"_fix_wall.html,
|
||||
"wall/piston"_fix_wall_piston.html,
|
||||
"wall/reflect (k)"_fix_wall_reflect.html,
|
||||
"wall/region"_fix_wall_region.html,
|
||||
"wall/region/ees"_fix_wall_ees.html,
|
||||
"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)
|
||||
60
doc/src/Commands_input.txt
Normal file
@ -0,0 +1,60 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
LAMMPS input scripts :h3
|
||||
|
||||
LAMMPS executes by reading commands from a input script (text file),
|
||||
one line at a time. When the input script ends, LAMMPS exits. Each
|
||||
command causes LAMMPS to take some action. It may set an internal
|
||||
variable, read in a file, or run a simulation. Most commands have
|
||||
default settings, which means you only need to use the command if you
|
||||
wish to change the default.
|
||||
|
||||
In many cases, the ordering of commands in an input script is not
|
||||
important. However the following rules apply:
|
||||
|
||||
(1) LAMMPS does not read your entire input script and then perform a
|
||||
simulation with all the settings. Rather, the input script is read
|
||||
one line at a time and each command takes effect when it is read.
|
||||
Thus this sequence of commands:
|
||||
|
||||
timestep 0.5
|
||||
run 100
|
||||
run 100 :pre
|
||||
|
||||
does something different than this sequence:
|
||||
|
||||
run 100
|
||||
timestep 0.5
|
||||
run 100 :pre
|
||||
|
||||
In the first case, the specified timestep (0.5 fs) is used for two
|
||||
simulations of 100 timesteps each. In the 2nd case, the default
|
||||
timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
|
||||
timestep is used for the 2nd one.
|
||||
|
||||
(2) Some commands are only valid when they follow other commands. For
|
||||
example you cannot set the temperature of a group of atoms until atoms
|
||||
have been defined and a group command is used to define which atoms
|
||||
belong to the group.
|
||||
|
||||
(3) Sometimes command B will use values that can be set by command A.
|
||||
This means command A must precede command B in the input script if it
|
||||
is to have the desired effect. For example, the
|
||||
"read_data"_read_data.html command initializes the system by setting
|
||||
up the simulation box and assigning atoms to processors. If default
|
||||
values are not desired, the "processors"_processors.html and
|
||||
"boundary"_boundary.html commands need to be used before read_data to
|
||||
tell LAMMPS how to map processors to the simulation box.
|
||||
|
||||
Many input script errors are detected by LAMMPS and an ERROR or
|
||||
WARNING message is printed. The "Errors"_Errors.html doc page gives
|
||||
more information on what errors mean. The documentation for each
|
||||
command lists restrictions on how the command can be used.
|
||||
|
||||
36
doc/src/Commands_kspace.txt
Normal file
@ -0,0 +1,36 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html)
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
"Bond styles"_Commands_bond.html,
|
||||
"Angle styles"_Commands_bond.html#angle,
|
||||
"Dihedral styles"_Commands_bond.html#dihedral,
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
KSpace solvers :h3
|
||||
|
||||
All LAMMPS "kspace_style"_kspace_style.html solvers. Some styles have
|
||||
accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"ewald (o)"_kspace_style.html,
|
||||
"ewald/disp"_kspace_style.html,
|
||||
"msm (o)"_kspace_style.html,
|
||||
"msm/cg (o)"_kspace_style.html,
|
||||
"pppm (gok)"_kspace_style.html,
|
||||
"pppm/cg (o)"_kspace_style.html,
|
||||
"pppm/disp (i)"_kspace_style.html,
|
||||
"pppm/disp/tip4p"_kspace_style.html,
|
||||
"pppm/stagger"_kspace_style.html,
|
||||
"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
|
||||
231
doc/src/Commands_pair.txt
Normal file
@ -0,0 +1,231 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
"Bond styles"_Commands_bond.html,
|
||||
"Angle styles"_Commands_bond.html#angle,
|
||||
"Dihedral styles"_Commands_bond.html#dihedral,
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
Pair_style potentials :h3
|
||||
|
||||
All LAMMPS "pair_style"_pair_style.html commands. Some styles have
|
||||
accelerated versions. This is indicated by additional letters in
|
||||
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
|
||||
OPT.
|
||||
|
||||
"none"_pair_none.html,
|
||||
"zero"_pair_zero.html,
|
||||
"hybrid"_pair_hybrid.html,
|
||||
"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
|
||||
|
||||
"adp (o)"_pair_adp.html,
|
||||
"agni (o)"_pair_agni.html,
|
||||
"airebo (oi)"_pair_airebo.html,
|
||||
"airebo/morse (oi)"_pair_airebo.html,
|
||||
"awpmd/cut"_pair_awpmd.html,
|
||||
"beck (go)"_pair_beck.html,
|
||||
"body/nparticle"_pair_body_nparticle.html,
|
||||
"body/rounded/polygon"_pair_body_rounded_polygon.html,
|
||||
"body/rounded/polyhedron"_pair_body_rounded_polyhedron.html,
|
||||
"bop"_pair_bop.html,
|
||||
"born (go)"_pair_born.html,
|
||||
"born/coul/dsf"_pair_born.html,
|
||||
"born/coul/dsf/cs"_pair_born.html,
|
||||
"born/coul/long (go)"_pair_born.html,
|
||||
"born/coul/long/cs"_pair_born.html,
|
||||
"born/coul/msm (o)"_pair_born.html,
|
||||
"born/coul/wolf (go)"_pair_born.html,
|
||||
"born/coul/wolf/cs"_pair_born.html,
|
||||
"brownian (o)"_pair_brownian.html,
|
||||
"brownian/poly (o)"_pair_brownian.html,
|
||||
"buck (giko)"_pair_buck.html,
|
||||
"buck/coul/cut (giko)"_pair_buck.html,
|
||||
"buck/coul/long (giko)"_pair_buck.html,
|
||||
"buck/coul/long/cs"_pair_buck.html,
|
||||
"buck/coul/msm (o)"_pair_buck.html,
|
||||
"buck/long/coul/long (o)"_pair_buck_long.html,
|
||||
"buck/mdf"_pair_mdf.html,
|
||||
"colloid (go)"_pair_colloid.html,
|
||||
"comb (o)"_pair_comb.html,
|
||||
"comb3"_pair_comb.html,
|
||||
"coul/cut (gko)"_pair_coul.html,
|
||||
"coul/cut/soft (o)"_pair_lj_soft.html,
|
||||
"coul/debye (gko)"_pair_coul.html,
|
||||
"coul/diel (o)"_pair_coul_diel.html,
|
||||
"coul/dsf (gko)"_pair_coul.html,
|
||||
"coul/long (gko)"_pair_coul.html,
|
||||
"coul/long/cs"_pair_coul.html,
|
||||
"coul/long/soft (o)"_pair_lj_soft.html,
|
||||
"coul/msm"_pair_coul.html,
|
||||
"coul/shield"_pair_coul_shield.html,
|
||||
"coul/streitz"_pair_coul.html,
|
||||
"coul/wolf (ko)"_pair_coul.html,
|
||||
"coul/wolf/cs"_pair_coul.html,
|
||||
"dpd (gio)"_pair_dpd.html,
|
||||
"dpd/fdt"_pair_dpd_fdt.html,
|
||||
"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
|
||||
"dpd/tstat (go)"_pair_dpd.html,
|
||||
"dsmc"_pair_dsmc.html,
|
||||
"eam (gikot)"_pair_eam.html,
|
||||
"eam/alloy (gikot)"_pair_eam.html,
|
||||
"eam/cd (o)"_pair_eam.html,
|
||||
"eam/fs (gikot)"_pair_eam.html,
|
||||
"edip (o)"_pair_edip.html,
|
||||
"edip/multi"_pair_edip.html,
|
||||
"edpd"_pair_meso.html,
|
||||
"eff/cut"_pair_eff.html,
|
||||
"eim (o)"_pair_eim.html,
|
||||
"exp6/rx (k)"_pair_exp6_rx.html,
|
||||
"extep"_pair_extep.html,
|
||||
"gauss (go)"_pair_gauss.html,
|
||||
"gauss/cut"_pair_gauss.html,
|
||||
"gayberne (gio)"_pair_gayberne.html,
|
||||
"gran/hertz/history (o)"_pair_gran.html,
|
||||
"gran/hooke (o)"_pair_gran.html,
|
||||
"gran/hooke/history (o)"_pair_gran.html,
|
||||
"gw"_pair_gw.html,
|
||||
"gw/zbl"_pair_gw.html,
|
||||
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
|
||||
"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
|
||||
"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
|
||||
"kim"_pair_kim.html,
|
||||
"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
|
||||
"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
|
||||
"lcbop"_pair_lcbop.html,
|
||||
"lennard/mdf"_pair_mdf.html,
|
||||
"line/lj"_pair_line_lj.html,
|
||||
"list"_pair_list.html,
|
||||
"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
|
||||
"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
|
||||
"lj/charmm/coul/long (giko)"_pair_charmm.html,
|
||||
"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
|
||||
"lj/charmm/coul/msm"_pair_charmm.html,
|
||||
"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
|
||||
"lj/charmmfsw/coul/long"_pair_charmm.html,
|
||||
"lj/class2 (gko)"_pair_class2.html,
|
||||
"lj/class2/coul/cut (ko)"_pair_class2.html,
|
||||
"lj/class2/coul/long (gko)"_pair_class2.html,
|
||||
"lj/cubic (go)"_pair_lj_cubic.html,
|
||||
"lj/cut (gikot)"_pair_lj.html,
|
||||
"lj/cut/coul/cut (gko)"_pair_lj.html,
|
||||
"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
|
||||
"lj/cut/coul/debye (gko)"_pair_lj.html,
|
||||
"lj/cut/coul/dsf (gko)"_pair_lj.html,
|
||||
"lj/cut/coul/long (gikot)"_pair_lj.html,
|
||||
"lj/cut/coul/long/cs"_pair_lj.html,
|
||||
"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
|
||||
"lj/cut/coul/msm (go)"_pair_lj.html,
|
||||
"lj/cut/coul/wolf (o)"_pair_lj.html,
|
||||
"lj/cut/dipole/cut (go)"_pair_dipole.html,
|
||||
"lj/cut/dipole/long"_pair_dipole.html,
|
||||
"lj/cut/dipole/sf (go)"_pair_dipole.html,
|
||||
"lj/cut/soft (o)"_pair_lj_soft.html,
|
||||
"lj/cut/thole/long (o)"_pair_thole.html,
|
||||
"lj/cut/tip4p/cut (o)"_pair_lj.html,
|
||||
"lj/cut/tip4p/long (ot)"_pair_lj.html,
|
||||
"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
|
||||
"lj/expand (gko)"_pair_lj_expand.html,
|
||||
"lj/gromacs (gko)"_pair_gromacs.html,
|
||||
"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
|
||||
"lj/long/coul/long (io)"_pair_lj_long.html,
|
||||
"lj/long/dipole/long"_pair_dipole.html,
|
||||
"lj/long/tip4p/long"_pair_lj_long.html,
|
||||
"lj/mdf"_pair_mdf.html,
|
||||
"lj/sdk (gko)"_pair_sdk.html,
|
||||
"lj/sdk/coul/long (go)"_pair_sdk.html,
|
||||
"lj/sdk/coul/msm (o)"_pair_sdk.html,
|
||||
"lj/smooth (o)"_pair_lj_smooth.html,
|
||||
"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
|
||||
"lj96/cut (go)"_pair_lj96.html,
|
||||
"lubricate (o)"_pair_lubricate.html,
|
||||
"lubricate/poly (o)"_pair_lubricate.html,
|
||||
"lubricateU"_pair_lubricateU.html,
|
||||
"lubricateU/poly"_pair_lubricateU.html,
|
||||
"mdpd"_pair_meso.html,
|
||||
"mdpd/rhosum"_pair_meso.html,
|
||||
"meam"_pair_meam.html,
|
||||
"meam/c"_pair_meam.html,
|
||||
"meam/spline (o)"_pair_meam_spline.html,
|
||||
"meam/sw/spline"_pair_meam_sw_spline.html,
|
||||
"mgpt"_pair_mgpt.html,
|
||||
"mie/cut (o)"_pair_mie.html,
|
||||
"momb"_pair_momb.html,
|
||||
"morse (gkot)"_pair_morse.html,
|
||||
"morse/smooth/linear"_pair_morse.html,
|
||||
"morse/soft"_pair_morse.html,
|
||||
"multi/lucy"_pair_multi_lucy.html,
|
||||
"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
|
||||
"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
|
||||
"nm/cut (o)"_pair_nm.html,
|
||||
"nm/cut/coul/cut (o)"_pair_nm.html,
|
||||
"nm/cut/coul/long (o)"_pair_nm.html,
|
||||
"oxdna/coaxstk"_pair_oxdna.html,
|
||||
"oxdna/excv"_pair_oxdna.html,
|
||||
"oxdna/hbond"_pair_oxdna.html,
|
||||
"oxdna/stk"_pair_oxdna.html,
|
||||
"oxdna/xstk"_pair_oxdna.html,
|
||||
"oxdna2/coaxstk"_pair_oxdna2.html,
|
||||
"oxdna2/dh"_pair_oxdna2.html,
|
||||
"oxdna2/excv"_pair_oxdna2.html,
|
||||
"oxdna2/stk"_pair_oxdna2.html,
|
||||
"peri/eps"_pair_peri.html,
|
||||
"peri/lps (o)"_pair_peri.html,
|
||||
"peri/pmb (o)"_pair_peri.html,
|
||||
"peri/ves"_pair_peri.html,
|
||||
"polymorphic"_pair_polymorphic.html,
|
||||
"python"_pair_python.html,
|
||||
"quip"_pair_quip.html,
|
||||
"reax"_pair_reax.html,
|
||||
"reax/c (ko)"_pair_reaxc.html,
|
||||
"rebo (oi)"_pair_airebo.html,
|
||||
"resquared (go)"_pair_resquared.html,
|
||||
"smd/hertz"_pair_smd_hertz.html,
|
||||
"smd/tlsph"_pair_smd_tlsph.html,
|
||||
"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
|
||||
"smd/ulsph"_pair_smd_ulsph.html,
|
||||
"smtbq"_pair_smtbq.html,
|
||||
"snap (k)"_pair_snap.html,
|
||||
"snap (k)"_pair_snap.html,
|
||||
"soft (go)"_pair_soft.html,
|
||||
"sph/heatconduction"_pair_sph_heatconduction.html,
|
||||
"sph/idealgas"_pair_sph_idealgas.html,
|
||||
"sph/lj"_pair_sph_lj.html,
|
||||
"sph/rhosum"_pair_sph_rhosum.html,
|
||||
"sph/taitwater"_pair_sph_taitwater.html,
|
||||
"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
|
||||
"spin/dmi"_pair_spin_dmi.html,
|
||||
"spin/exchange"_pair_spin_exchange.html,
|
||||
"spin/magelec"_pair_spin_magelec.html,
|
||||
"spin/neel"_pair_spin_neel.html,
|
||||
"srp"_pair_srp.html,
|
||||
"sw (giko)"_pair_sw.html,
|
||||
"table (gko)"_pair_table.html,
|
||||
"table/rx (k)"_pair_table_rx.html,
|
||||
"tdpd"_pair_meso.html,
|
||||
"tersoff (giko)"_pair_tersoff.html,
|
||||
"tersoff/mod (gko)"_pair_tersoff_mod.html,
|
||||
"tersoff/mod/c (o)"_pair_tersoff_mod.html,
|
||||
"tersoff/table (o)"_pair_tersoff.html,
|
||||
"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
|
||||
"thole"_pair_thole.html,
|
||||
"tip4p/cut (o)"_pair_coul.html,
|
||||
"tip4p/long (o)"_pair_coul.html,
|
||||
"tip4p/long/soft (o)"_pair_lj_soft.html,
|
||||
"tri/lj"_pair_tri_lj.html,
|
||||
"ufm (got)"_pair_ufm.html,
|
||||
"vashishta (ko)"_pair_vashishta.html,
|
||||
"vashishta/table (o)"_pair_vashishta.html,
|
||||
"yukawa (gok)"_pair_yukawa.html,
|
||||
"yukawa/colloid (go)"_pair_yukawa_colloid.html,
|
||||
"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)
|
||||
136
doc/src/Commands_parse.txt
Normal file
@ -0,0 +1,136 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Parsing rules for input scripts :h3
|
||||
|
||||
Each non-blank line in the input script is treated as a command.
|
||||
LAMMPS commands are case sensitive. Command names are lower-case, as
|
||||
are specified command arguments. Upper case letters may be used in
|
||||
file names or user-chosen ID strings.
|
||||
|
||||
Here are 6 rulse for how each line in the input script is parsed by
|
||||
LAMMPS:
|
||||
|
||||
(1) If the last printable character on the line is a "&" character,
|
||||
the command is assumed to continue on the next line. The next line is
|
||||
concatenated to the previous line by removing the "&" character and
|
||||
line break. This allows long commands to be continued across two or
|
||||
more lines. See the discussion of triple quotes in (6) for how to
|
||||
continue a command across multiple line without using "&" characters.
|
||||
|
||||
(2) All characters from the first "#" character onward are treated as
|
||||
comment and discarded. See an exception in (6). Note that a
|
||||
comment after a trailing "&" character will prevent the command from
|
||||
continuing on the next line. Also note that for multi-line commands a
|
||||
single leading "#" will comment out the entire command.
|
||||
|
||||
(3) The line is searched repeatedly for $ characters, which indicate
|
||||
variables that are replaced with a text string. See an exception in
|
||||
(6).
|
||||
|
||||
If the $ is followed by curly brackets, then the variable name is the
|
||||
text inside the curly brackets. If no curly brackets follow the $,
|
||||
then the variable name is the single character immediately following
|
||||
the $. Thus $\{myTemp\} and $x refer to variable names "myTemp" and
|
||||
"x".
|
||||
|
||||
How the variable is converted to a text string depends on what style
|
||||
of variable it is; see the "variable"_variable.html doc page for details.
|
||||
It can be a variable that stores multiple text strings, and return one
|
||||
of them. The returned text string can be multiple "words" (space
|
||||
separated) which will then be interpreted as multiple arguments in the
|
||||
input command. The variable can also store a numeric formula which
|
||||
will be evaluated and its numeric result returned as a string.
|
||||
|
||||
As a special case, if the $ is followed by parenthesis, then the text
|
||||
inside the parenthesis is treated as an "immediate" variable and
|
||||
evaluated as an "equal-style variable"_variable.html. This is a way
|
||||
to use numeric formulas in an input script without having to assign
|
||||
them to variable names. For example, these 3 input script lines:
|
||||
|
||||
variable X equal (xlo+xhi)/2+sqrt(v_area)
|
||||
region 1 block $X 2 INF INF EDGE EDGE
|
||||
variable X delete :pre
|
||||
|
||||
can be replaced by
|
||||
|
||||
region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
|
||||
|
||||
so that you do not have to define (or discard) a temporary variable X.
|
||||
|
||||
Additionally, the "immediate" variable expression may be followed by a
|
||||
colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
|
||||
The format string must be appropriate for a double-precision
|
||||
floating-point value. The format string is used to output the result
|
||||
of the variable expression evaluation. If a format string is not
|
||||
specified a high-precision "%.20g" is used as the default.
|
||||
|
||||
This can be useful for formatting print output to a desired precion:
|
||||
|
||||
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
|
||||
|
||||
Note that neither the curly-bracket or immediate form of variables can
|
||||
contain nested $ characters for other variables to substitute for.
|
||||
Thus you cannot do this:
|
||||
|
||||
variable a equal 2
|
||||
variable b2 equal 4
|
||||
print "B2 = $\{b$a\}" :pre
|
||||
|
||||
Nor can you specify this $($x-1.0) for an immediate variable, but
|
||||
you could use $(v_x-1.0), since the latter is valid syntax for an
|
||||
"equal-style variable"_variable.html.
|
||||
|
||||
See the "variable"_variable.html command for more details of how
|
||||
strings are assigned to variables and evaluated, and how they can be
|
||||
used in input script commands.
|
||||
|
||||
(4) The line is broken into "words" separated by whitespace (tabs,
|
||||
spaces). Note that words can thus contain letters, digits,
|
||||
underscores, or punctuation characters.
|
||||
|
||||
(5) The first word is the command name. All successive words in the
|
||||
line are arguments.
|
||||
|
||||
(6) If you want text with spaces to be treated as a single argument,
|
||||
it can be enclosed in either single or double or triple quotes. A
|
||||
long single argument enclosed in single or double quotes can span
|
||||
multiple lines if the "&" character is used, as described above. When
|
||||
the lines are concatenated together (and the "&" characters and line
|
||||
breaks removed), the text will become a single line. If you want
|
||||
multiple lines of an argument to retain their line breaks, the text
|
||||
can be enclosed in triple quotes, in which case "&" characters are not
|
||||
needed. For example:
|
||||
|
||||
print "Volume = $v"
|
||||
print 'Volume = $v'
|
||||
if "$\{steps\} > 1000" then quit
|
||||
variable a string "red green blue &
|
||||
purple orange cyan"
|
||||
print """
|
||||
System volume = $v
|
||||
System temperature = $t
|
||||
""" :pre
|
||||
|
||||
In each case, the single, double, or triple quotes are removed when
|
||||
the single argument they enclose is stored internally.
|
||||
|
||||
See the "dump modify format"_dump_modify.html, "print"_print.html,
|
||||
"if"_if.html, and "python"_python.html commands for examples.
|
||||
|
||||
A "#" or "$" character that is between quotes will not be treated as a
|
||||
comment indicator in (2) or substituted for as a variable in (3).
|
||||
|
||||
NOTE: If the argument is itself a command that requires a quoted
|
||||
argument (e.g. using a "print"_print.html command as part of an
|
||||
"if"_if.html or "run every"_run.html command), then single, double, or
|
||||
triple quotes can be nested in the usual manner. See the doc pages
|
||||
for those commands for examples. Only one of level of nesting is
|
||||
allowed, but that should be sufficient for most use cases.
|
||||
|
||||
95
doc/src/Commands_structure.txt
Normal file
@ -0,0 +1,95 @@
|
||||
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Input script structure :h3
|
||||
|
||||
This page describes the structure of a typical LAMMPS input script.
|
||||
The examples directory in the LAMMPS distribution contains many sample
|
||||
input scripts; it is discussed on the "Examples"_Examples.html doc
|
||||
page.
|
||||
|
||||
A LAMMPS input script typically has 4 parts:
|
||||
|
||||
Initialization
|
||||
Atom definition
|
||||
Settings
|
||||
Run a simulation :ol
|
||||
|
||||
The last 2 parts can be repeated as many times as desired. I.e. run a
|
||||
simulation, change some settings, run some more, etc. Each of the 4
|
||||
parts is now described in more detail. Remember that almost all
|
||||
commands need only be used if a non-default value is desired.
|
||||
|
||||
(1) Initialization
|
||||
|
||||
Set parameters that need to be defined before atoms are created or
|
||||
read-in from a file.
|
||||
|
||||
The relevant commands are "units"_units.html,
|
||||
"dimension"_dimension.html, "newton"_newton.html,
|
||||
"processors"_processors.html, "boundary"_boundary.html,
|
||||
"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
|
||||
|
||||
If force-field parameters appear in the files that will be read, these
|
||||
commands tell LAMMPS what kinds of force fields are being used:
|
||||
"pair_style"_pair_style.html, "bond_style"_bond_style.html,
|
||||
"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
|
||||
"improper_style"_improper_style.html.
|
||||
|
||||
(2) Atom definition
|
||||
|
||||
There are 3 ways to define atoms in LAMMPS. Read them in from a data
|
||||
or restart file via the "read_data"_read_data.html or
|
||||
"read_restart"_read_restart.html commands. These files can contain
|
||||
molecular topology information. Or create atoms on a lattice (with no
|
||||
molecular topology), using these commands: "lattice"_lattice.html,
|
||||
"region"_region.html, "create_box"_create_box.html,
|
||||
"create_atoms"_create_atoms.html. The entire set of atoms can be
|
||||
duplicated to make a larger simulation using the
|
||||
"replicate"_replicate.html command.
|
||||
|
||||
(3) Settings
|
||||
|
||||
Once atoms and molecular topology are defined, a variety of settings
|
||||
can be specified: force field coefficients, simulation parameters,
|
||||
output options, etc.
|
||||
|
||||
Force field coefficients are set by these commands (they can also be
|
||||
set in the read-in files): "pair_coeff"_pair_coeff.html,
|
||||
"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
|
||||
"dihedral_coeff"_dihedral_coeff.html,
|
||||
"improper_coeff"_improper_coeff.html,
|
||||
"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
|
||||
"special_bonds"_special_bonds.html.
|
||||
|
||||
Various simulation parameters are set by these commands:
|
||||
"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
|
||||
"group"_group.html, "timestep"_timestep.html,
|
||||
"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
|
||||
"min_style"_min_style.html, "min_modify"_min_modify.html.
|
||||
|
||||
Fixes impose a variety of boundary conditions, time integration, and
|
||||
diagnostic options. The "fix"_fix.html command comes in many flavors.
|
||||
|
||||
Various computations can be specified for execution during a
|
||||
simulation using the "compute"_compute.html,
|
||||
"compute_modify"_compute_modify.html, and "variable"_variable.html
|
||||
commands.
|
||||
|
||||
Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
|
||||
and "restart"_restart.html commands.
|
||||
|
||||
(4) Run a simulation
|
||||
|
||||
A molecular dynamics simulation is run using the "run"_run.html
|
||||
command. Energy minimization (molecular statics) is performed using
|
||||
the "minimize"_minimize.html command. A parallel tempering
|
||||
(replica-exchange) simulation can be run using the
|
||||
"temper"_temper.html command.
|
||||
|
||||
@ -449,15 +449,15 @@ Writing fixes is a flexible way of extending LAMMPS. Users can
|
||||
implement many things using fixes:
|
||||
|
||||
\begin{itemize}
|
||||
\item changing particles attributes (positions, velocities, forces, etc.).
|
||||
\item changing particles attributes (positions, velocities, forces, etc.).
|
||||
Example: FixFreeze.
|
||||
\item reading/writing data. Example: FixRestart.
|
||||
\item implementing boundary conditions. Example: FixWall.
|
||||
\item saving information about particles for future use (previous positions,
|
||||
\item saving information about particles for future use (previous positions,
|
||||
for instance). Example: FixStoreState.
|
||||
\end{itemize}
|
||||
|
||||
All fixes are derived from class Fix and must have constructor with the
|
||||
All fixes are derived from class Fix and must have constructor with the
|
||||
signature: FixMine(class LAMMPS *, int, char **).
|
||||
|
||||
Every fix must be registered in LAMMPS by writing the following lines
|
||||
@ -476,9 +476,9 @@ is the name of the class. This code allows LAMMPS to find your fix
|
||||
when it parses input script. In addition, your fix header must be
|
||||
included in the file "style\_fix.h". In case if you use LAMMPS make,
|
||||
this file is generated automatically - all files starting with prefix
|
||||
fix\_ are included, so call your header the same way. Otherwise, don<EFBFBD>t
|
||||
fix\_ are included, so call your header the same way. Otherwise, don't
|
||||
forget to add your include into "style\_fix.h".
|
||||
|
||||
|
||||
Let's write a simple fix which will print average velocity at the end
|
||||
of each timestep. First of all, implement a constructor:
|
||||
|
||||
@ -487,11 +487,11 @@ of each timestep. First of all, implement a constructor:
|
||||
FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
|
||||
: Fix(lmp, narg, arg)
|
||||
{
|
||||
if (narg < 4)
|
||||
if (narg < 4)
|
||||
error->all(FLERR,"Illegal fix print command");
|
||||
|
||||
|
||||
nevery = atoi(arg[3]);
|
||||
if (nevery <= 0)
|
||||
if (nevery <= 0)
|
||||
error->all(FLERR,"Illegal fix print command");
|
||||
}
|
||||
\end{verbatim}
|
||||
@ -545,7 +545,7 @@ void FixPrintVel::end_of_step()
|
||||
{
|
||||
// for add3, scale3
|
||||
using namespace MathExtra;
|
||||
|
||||
|
||||
double** v = atom->v;
|
||||
int nlocal = atom->nlocal;
|
||||
double localAvgVel[4]; // 4th element for particles count
|
||||
@ -559,7 +559,7 @@ void FixPrintVel::end_of_step()
|
||||
MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
|
||||
scale3(1.0 / globalAvgVel[3], globalAvgVel);
|
||||
if (comm->me == 0) {
|
||||
printf("\%e, \%e, \%e\n",
|
||||
printf("\%e, \%e, \%e\n",
|
||||
globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
|
||||
}
|
||||
}
|
||||
@ -607,14 +607,15 @@ this situation there are several methods which should be implemented:
|
||||
|
||||
\begin{itemize}
|
||||
\item \verb|double memory_usage| - return how much memory fix uses
|
||||
\item \verb|void grow_arrays(int)| - do reallocation of the per particle arrays
|
||||
\item \verb|void grow_arrays(int)| - do reallocation of the per particle arrays
|
||||
in your fix
|
||||
\item \verb|void copy_arrays(int i, int j)| - copy i-th per-particle information
|
||||
to j-th. Used when atoms sorting is performed
|
||||
\item \verb|void copy_arrays(int i, int j, int delflag)| - copy i-th per-particle
|
||||
information to j-th. Used when atoms sorting is performed. if delflag is set
|
||||
and atom j owns a body, move the body information to atom i.
|
||||
\item \verb|void set_arrays(int i)| - sets i-th particle related information to zero
|
||||
\end{itemize}
|
||||
|
||||
Note, that if your class implements these methods, it must call add calls of
|
||||
Note, that if your class implements these methods, it must call add calls of
|
||||
add\_callback and delete\_callback to constructor and destructor:
|
||||
|
||||
\begin{center}
|
||||
@ -654,7 +655,7 @@ void FixSavePos::grow_arrays(int nmax)
|
||||
memory->grow(this->x, nmax, 3, "FixSavePos:x");
|
||||
}
|
||||
|
||||
void FixSavePos::copy_arrays(int i, int j)
|
||||
void FixSavePos::copy_arrays(int i, int j, int delflag)
|
||||
{
|
||||
memcpy(this->x[j], this->x[i], sizeof(double) * 3);
|
||||
}
|
||||
@ -670,7 +671,7 @@ int FixSavePos::pack_exchange(int i, double *buf)
|
||||
buf[m++] = x[i][0];
|
||||
buf[m++] = x[i][1];
|
||||
buf[m++] = x[i][2];
|
||||
|
||||
|
||||
return m;
|
||||
}
|
||||
|
||||
|
||||
BIN
doc/src/Eqs/dihedral_table_cut.jpg
Normal file
|
After Width: | Height: | Size: 30 KiB |
11
doc/src/Eqs/dihedral_table_cut.tex
Normal file
@ -0,0 +1,11 @@
|
||||
\documentclass[12pt]{article}
|
||||
\pagestyle{empty}
|
||||
\begin{document}
|
||||
|
||||
\begin{eqnarray*}
|
||||
f(\theta) & = & K \qquad\qquad\qquad\qquad\qquad\qquad \theta < \theta_1 \\
|
||||
f(\theta) & = & K \left(1-\frac{(\theta - \theta_1)^2}{(\theta_2 - \theta_1)^2}\right) \qquad \theta_1 < \theta < \theta_2
|
||||
\end{eqnarray*}
|
||||
|
||||
\end{document}
|
||||
|
||||
BIN
doc/src/Eqs/fix_integration_spin_stdecomposition.jpg
Normal file
|
After Width: | Height: | Size: 50 KiB |
40
doc/src/Eqs/fix_integration_spin_stdecomposition.tex
Normal file
@ -0,0 +1,40 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm,tikz}
|
||||
\usetikzlibrary{automata,arrows,shapes,snakes}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{tikzpicture}
|
||||
|
||||
%Global
|
||||
\node (v1) at (0,6.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{v} \leftarrow \bm{v}+L_v.\Delta t/2$ };
|
||||
\node (s1) at (0,4.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{s} \leftarrow \bm{s}+L_s.\Delta t/2$ };
|
||||
\node (r) at (0,3.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{r} \leftarrow \bm{r}+L_r.\Delta t$ };
|
||||
\node (s2) at (0,1.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{s} \leftarrow \bm{s}+L_s.\Delta t/2$ };
|
||||
\node (v2) at (0,0.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{v} \leftarrow \bm{v}+L_v.\Delta t/2$ };
|
||||
|
||||
\draw[line width=2pt, ->] (v1) -- (s1);
|
||||
\draw[line width=2pt, ->] (s1) -- (r);
|
||||
\draw[line width=2pt, ->] (r) -- (s2);
|
||||
\draw[line width=2pt, ->] (s2) -- (v2);
|
||||
|
||||
%Spin
|
||||
\node (s01) at (6,6.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_0 \leftarrow \bm{s}_0+L_{s_0}.\Delta t/4$ };
|
||||
\node (sN1) at (6,4.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N-1}\leftarrow\bm{s}_{\rm N-1}+L_{s_{\rm N-1}}.\Delta t/4$};
|
||||
\node (sN) at (6,3.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N} \leftarrow \bm{s}_{\rm N}+L_{s_{\rm N}}.\Delta t/2$ };
|
||||
\node (sN2) at (6,1.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N-1}\leftarrow\bm{s}_{\rm N-1}+L_{s_{\rm N-1}}.\Delta t/4$};
|
||||
\node (s02) at (6,0.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_0 \leftarrow \bm{s}_0+L_{s_0}.\Delta t/4$ };
|
||||
|
||||
\draw[line width=2pt,dashed, ->] (s01) -- (sN1);
|
||||
\draw[line width=2pt, ->] (sN1) -- (sN);
|
||||
\draw[line width=2pt, ->] (sN) -- (sN2);
|
||||
\draw[line width=2pt,dashed, ->] (sN2) -- (s02);
|
||||
|
||||
%from Global to Spin
|
||||
\draw[line width=2pt, dashed, ->] (s1) -- (s01.west);
|
||||
\draw[line width=2pt, dashed, ->] (s1) -- (s02.west);
|
||||
|
||||
\end{tikzpicture}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/fix_langevin_spin_sLLG.jpg
Normal file
|
After Width: | Height: | Size: 8.9 KiB |
14
doc/src/Eqs/fix_langevin_spin_sLLG.tex
Normal file
@ -0,0 +1,14 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath, amssymb, graphics, setspace}
|
||||
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\frac{d \vec{s}_{i}}{dt} = \frac{1}{\left(1+\lambda^2 \right)} \left( \left(
|
||||
\vec{\omega}_{i} +\vec{\eta} \right) \times \vec{s}_{i} + \lambda\, \vec{s}_{i}
|
||||
\times\left( \vec{\omega}_{i} \times\vec{s}_{i} \right) \right), \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/force_spin_aniso.jpg
Normal file
|
After Width: | Height: | Size: 5.9 KiB |
11
doc/src/Eqs/force_spin_aniso.tex
Normal file
@ -0,0 +1,11 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\bm{H}_{aniso} = -\sum_{{ i}=1}^{N} K_{an}(\bm{r}_{i})\, \left( \vec{s}_{i} \cdot \vec{n}_{i} \right)^2, \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/force_spin_zeeman.jpg
Normal file
|
After Width: | Height: | Size: 6.4 KiB |
11
doc/src/Eqs/force_spin_zeeman.tex
Normal file
@ -0,0 +1,11 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\bm{H}_{zeeman} = -\mu_{B}\mu_0\sum_{i=0}^{N}g_{i} \vec{s}_{i} \cdot \vec{H}_{ext} \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_body_rounded.jpg
Normal file
|
After Width: | Height: | Size: 144 KiB |
13
doc/src/Eqs/pair_body_rounded.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentstyle[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\begin{eqnarray*}
|
||||
F_n &=& k_n \delta_n - c_n v_n, \qquad \delta_n \le 0 \\
|
||||
&=& -k_{na} \delta_n - c_n v_n, \qquad 0 < \delta_n \le r_c \\
|
||||
&=& 0 \qquad \qquad \qquad \qquad \delta_n > r_c \\
|
||||
F_t &=& \mu k_n \delta_n - c_t v_t, \qquad \delta_n \le 0 \\
|
||||
&=& 0 \qquad \qquad \qquad \qquad \delta_n > 0
|
||||
\end{eqnarray*}
|
||||
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_entropy.jpg
Normal file
|
After Width: | Height: | Size: 8.7 KiB |
10
doc/src/Eqs/pair_entropy.tex
Normal file
@ -0,0 +1,10 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
\thispagestyle{empty}
|
||||
|
||||
$$
|
||||
s_S^i=-2\pi\rho k_B \int\limits_0^{r_m} \left [ g(r) \ln g(r) - g(r) + 1 \right ] r^2 dr ,
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_entropy2.jpg
Normal file
|
After Width: | Height: | Size: 8.3 KiB |
10
doc/src/Eqs/pair_entropy2.tex
Normal file
@ -0,0 +1,10 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
\thispagestyle{empty}
|
||||
|
||||
$$
|
||||
g_m^i(r) = \frac{1}{4 \pi \rho r^2} \sum\limits_{j} \frac{1}{\sqrt{2 \pi \sigma^2}} e^{-(r-r_{ij})^2/(2\sigma^2)} ,
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_entropy3.jpg
Normal file
|
After Width: | Height: | Size: 5.6 KiB |
10
doc/src/Eqs/pair_entropy3.tex
Normal file
@ -0,0 +1,10 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
\thispagestyle{empty}
|
||||
|
||||
$$
|
||||
\bar{s}_S^i = \frac{\sum_j s_S^j + s_S^i}{N + 1} ,
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_dmi_forces.jpg
Normal file
|
After Width: | Height: | Size: 13 KiB |
14
doc/src/Eqs/pair_spin_dmi_forces.tex
Normal file
@ -0,0 +1,14 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times \left(\vec{e}_{ij}\times \vec{D} \right)
|
||||
~~{\rm and}~~
|
||||
\vec{F}_i = -\sum_{j}^{Neighb} \frac{1}{r_{ij}} \vec{D} \times \left( \vec{s}_{i}\times \vec{s}_{j} \right)
|
||||
, \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_dmi_interaction.jpg
Normal file
|
After Width: | Height: | Size: 7.7 KiB |
16
doc/src/Eqs/pair_spin_dmi_interaction.tex
Normal file
@ -0,0 +1,16 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\bm{H}_{dm} = \sum_{{ i,j}=1,i\neq j}^{N}
|
||||
\left( \vec{e}_{ij} \times \vec{D} \right)
|
||||
\cdot\left(\vec{s}_{i}\times \vec{s}_{j}\right),
|
||||
\nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
\vec{D}\left(r_{ij}\right)
|
||||
{\rm ~and~} \vec{D}\left(r_{ij}\right) = \vec{e}_{ij} \times \vec{D}
|
||||
BIN
doc/src/Eqs/pair_spin_exchange_forces.jpg
Normal file
|
After Width: | Height: | Size: 13 KiB |
16
doc/src/Eqs/pair_spin_exchange_forces.tex
Normal file
@ -0,0 +1,16 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
|
||||
\left(r_{ij} \right)\,\vec{s}_{j}
|
||||
~~{\rm and}~~
|
||||
\vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
|
||||
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
|
||||
\nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_exchange_function.jpg
Normal file
|
After Width: | Height: | Size: 10 KiB |
13
doc/src/Eqs/pair_spin_exchange_function.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath, amssymb, graphics, setspace}
|
||||
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
{J}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d} \right)^2 \left( 1 - b \left( \frac{r_{ij}}{d} \right)^2 \right) e^{-\left( \frac{r_{ij}}{d}
|
||||
\right)^2 }\Theta (R_c - r_{ij}) \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_exchange_interaction.jpg
Normal file
|
After Width: | Height: | Size: 5.8 KiB |
11
doc/src/Eqs/pair_spin_exchange_interaction.tex
Normal file
@ -0,0 +1,11 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\bm{H}_{ex} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_me_forces.jpg
Normal file
|
After Width: | Height: | Size: 13 KiB |
13
doc/src/Eqs/pair_spin_me_forces.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\vec{F}^{i} = -\sum_{j}^{Neighbor} \left( \vec{s}_{i}\times \vec{s}_{j} \right)
|
||||
\times \vec{E} ~~{\rm and}~~ \vec{\omega}^{i} = -\frac{1}{\hbar}
|
||||
\sum_{j}^{Neighbor} \vec{s}_j \times \left(\vec{E}\times r_{ij} \right),\nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_me_interaction.jpg
Normal file
|
After Width: | Height: | Size: 10 KiB |
12
doc/src/Eqs/pair_spin_me_interaction.tex
Normal file
@ -0,0 +1,12 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times\vec{D}(r_{ij}) ~~{\rm and}~~
|
||||
\vec{F}_i = -\sum_{j}^{Neighb} \frac{\partial D(r_{ij})}{\partial r_{ij}} \left(\vec{s}_{i}\times \vec{s}_{j} \right) \cdot \vec{r}_{ij}, \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_neel_functions.jpg
Normal file
|
After Width: | Height: | Size: 5.8 KiB |
13
doc/src/Eqs/pair_spin_neel_functions.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{eqnarray}
|
||||
g_1(r_{ij}) &=& g(r_{ij}) + \frac{12}{35} q(r_{ij}) \nonumber \\
|
||||
q_1(r_{ij}) &=& \frac{9}{5} q(r_{ij}) \nonumber \\
|
||||
q_2(r_{ij}) &=& - \frac{2}{5} q(r_{ij}) \nonumber
|
||||
\end{eqnarray}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/pair_spin_neel_interaction.jpg
Normal file
|
After Width: | Height: | Size: 11 KiB |
16
doc/src/Eqs/pair_spin_neel_interaction.tex
Normal file
@ -0,0 +1,16 @@
|
||||
\documentclass[preview]{standalone}
|
||||
\usepackage{varwidth}
|
||||
\usepackage[utf8x]{inputenc}
|
||||
\usepackage{amsmath,amssymb,amsthm,bm}
|
||||
\begin{document}
|
||||
\begin{varwidth}{50in}
|
||||
\begin{equation}
|
||||
\mathcal{H}_{N\acute{e}el}=-\sum_{{ i,j=1,i\neq j}}^N g_1(r_{ij})\left(({\bm e}_{ij}\cdot {\bm s}_{i})({\bm e}_{ij}
|
||||
\cdot {\bm s}_{j})-\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3} \right)
|
||||
+q_1(r_{ij})\left( ({\bm e}_{ij}\cdot {\bm s}_{i})^2 -\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3}\right)
|
||||
\left( ({\bm e}_{ij}\cdot {\bm s}_{i})^2 -\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3} \right)
|
||||
+ q_2(r_{ij}) \Big( ({\bm e}_{ij}\cdot {\bm s}_{i}) ({\bm e}_{ij}\cdot {\bm s}_{j})^3 + ({\bm e}_{ij}\cdot
|
||||
{\bm s}_{j}) ({\bm e}_{ij}\cdot {\bm s}_{i})^3\Big) \nonumber
|
||||
\end{equation}
|
||||
\end{varwidth}
|
||||
\end{document}
|
||||
38
doc/src/Errors.txt
Normal file
@ -0,0 +1,38 @@
|
||||
"Previous Section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Manual.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Errors :h2
|
||||
|
||||
These doc pages describe the errors you can encounter when using
|
||||
LAMMPS. The common problems include conceptual issues. The messages
|
||||
and warnings doc pages give complete lists of all the messages the
|
||||
code may generate (except those generated by USER packages), with
|
||||
additional details for many of them.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Errors_common
|
||||
Errors_bugs
|
||||
Errors_messages
|
||||
Errors_warnings
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Common problems"_Errors_common.html
|
||||
"Reporting bugs"_Errors_bugs.html
|
||||
"Error messages"_Errors_messages.html
|
||||
"Warning messages"_Errors_warnings.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
35
doc/src/Errors_bugs.txt
Normal file
@ -0,0 +1,35 @@
|
||||
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Reporting bugs :h3
|
||||
|
||||
If you are confident that you have found a bug in LAMMPS, follow these
|
||||
steps.
|
||||
|
||||
Check the "New features and bug
|
||||
fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
|
||||
site"_lws to see if the bug has already been reported or fixed or the
|
||||
"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
|
||||
pending.
|
||||
|
||||
Check the "mailing list"_http://lammps.sandia.gov/mail.html to see if
|
||||
it has been discussed before.
|
||||
|
||||
If not, send an email to the mailing list describing the problem with
|
||||
any ideas you have as to what is causing it or where in the code the
|
||||
problem might be. The developers will ask for more info if needed,
|
||||
such as an input script or data files.
|
||||
|
||||
The most useful thing you can do to help us fix the bug is to isolate
|
||||
the problem. Run it on the smallest number of atoms and fewest number
|
||||
of processors and with the simplest input script that reproduces the
|
||||
bug and try to identify what command or combination of commands is
|
||||
causing the problem.
|
||||
|
||||
NOTE: this page needs to have GitHub issues info added
|
||||
123
doc/src/Errors_common.txt
Normal file
@ -0,0 +1,123 @@
|
||||
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Common problems :h3
|
||||
|
||||
If two LAMMPS runs do not produce the exact same answer on different
|
||||
machines or different numbers of processors, this is typically not a
|
||||
bug. In theory you should get identical answers on any number of
|
||||
processors and on any machine. In practice, numerical round-off can
|
||||
cause slight differences and eventual divergence of molecular dynamics
|
||||
phase space trajectories within a few 100s or few 1000s of timesteps.
|
||||
However, the statistical properties of the two runs (e.g. average
|
||||
energy or temperature) should still be the same.
|
||||
|
||||
If the "velocity"_velocity.html command is used to set initial atom
|
||||
velocities, a particular atom can be assigned a different velocity
|
||||
when the problem is run on a different number of processors or on
|
||||
different machines. If this happens, the phase space trajectories of
|
||||
the two simulations will rapidly diverge. See the discussion of the
|
||||
{loop} option in the "velocity"_velocity.html command for details and
|
||||
options that avoid this issue.
|
||||
|
||||
Similarly, the "create_atoms"_create_atoms.html command generates a
|
||||
lattice of atoms. For the same physical system, the ordering and
|
||||
numbering of atoms by atom ID may be different depending on the number
|
||||
of processors.
|
||||
|
||||
Some commands use random number generators which may be setup to
|
||||
produce different random number streams on each processor and hence
|
||||
will produce different effects when run on different numbers of
|
||||
processors. A commonly-used example is the "fix
|
||||
langevin"_fix_langevin.html command for thermostatting.
|
||||
|
||||
A LAMMPS simulation typically has two stages, setup and run. Most
|
||||
LAMMPS errors are detected at setup time; others like a bond
|
||||
stretching too far may not occur until the middle of a run.
|
||||
|
||||
LAMMPS tries to flag errors and print informative error messages so
|
||||
you can fix the problem. For most errors it will also print the last
|
||||
input script command that it was processing. Of course, LAMMPS cannot
|
||||
figure out your physics or numerical mistakes, like choosing too big a
|
||||
timestep, specifying erroneous force field coefficients, or putting 2
|
||||
atoms on top of each other! If you run into errors that LAMMPS
|
||||
doesn't catch that you think it should flag, please send an email to
|
||||
the "developers"_http://lammps.sandia.gov/authors.html.
|
||||
|
||||
If you get an error message about an invalid command in your input
|
||||
script, you can determine what command is causing the problem by
|
||||
looking in the log.lammps file or using the "echo command"_echo.html
|
||||
to see it on the screen. If you get an error like "Invalid ...
|
||||
style", with ... being fix, compute, pair, etc, it means that you
|
||||
mistyped the style name or that the command is part of an optional
|
||||
package which was not compiled into your executable. The list of
|
||||
available styles in your executable can be listed by using "the -h
|
||||
command-line swith"_Run_options.html. The installation and
|
||||
compilation of optional packages is explained on the "Build
|
||||
packages"_Build_package.html doc page.
|
||||
|
||||
For a given command, LAMMPS expects certain arguments in a specified
|
||||
order. If you mess this up, LAMMPS will often flag the error, but it
|
||||
may also simply read a bogus argument and assign a value that is
|
||||
valid, but not what you wanted. E.g. trying to read the string "abc"
|
||||
as an integer value of 0. Careful reading of the associated doc page
|
||||
for the command should allow you to fix these problems. In most cases,
|
||||
where LAMMPS expects to read a number, either integer or floating point,
|
||||
it performs a stringent test on whether the provided input actually
|
||||
is an integer or floating-point number, respectively, and reject the
|
||||
input with an error message (for instance, when an integer is required,
|
||||
but a floating-point number 1.0 is provided):
|
||||
|
||||
ERROR: Expected integer parameter in input script or data file :pre
|
||||
|
||||
Some commands allow for using variable references in place of numeric
|
||||
constants so that the value can be evaluated and may change over the
|
||||
course of a run. This is typically done with the syntax {v_name} for a
|
||||
parameter, where name is the name of the variable. On the other hand,
|
||||
immediate variable expansion with the syntax ${name} is performed while
|
||||
reading the input and before parsing commands,
|
||||
|
||||
NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
|
||||
the documentation of the corresponding command explicitly says it is.
|
||||
|
||||
Generally, LAMMPS will print a message to the screen and logfile and
|
||||
exit gracefully when it encounters a fatal error. Sometimes it will
|
||||
print a WARNING to the screen and logfile and continue on; you can
|
||||
decide if the WARNING is important or not. A WARNING message that is
|
||||
generated in the middle of a run is only printed to the screen, not to
|
||||
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
|
||||
crashes or hangs without spitting out an error message first then it
|
||||
could be a bug (see "this section"_Errors_bugs.html) or one of the following
|
||||
cases:
|
||||
|
||||
LAMMPS runs in the available memory a processor allows to be
|
||||
allocated. Most reasonable MD runs are compute limited, not memory
|
||||
limited, so this shouldn't be a bottleneck on most platforms. Almost
|
||||
all large memory allocations in the code are done via C-style malloc's
|
||||
which will generate an error message if you run out of memory.
|
||||
Smaller chunks of memory are allocated via C++ "new" statements. If
|
||||
you are unlucky you could run out of memory just when one of these
|
||||
small requests is made, in which case the code will crash or hang (in
|
||||
parallel), since LAMMPS doesn't trap on those errors.
|
||||
|
||||
Illegal arithmetic can cause LAMMPS to run slow or crash. This is
|
||||
typically due to invalid physics and numerics that your simulation is
|
||||
computing. If you see wild thermodynamic values or NaN values in your
|
||||
LAMMPS output, something is wrong with your simulation. If you
|
||||
suspect this is happening, it is a good idea to print out
|
||||
thermodynamic info frequently (e.g. every timestep) via the
|
||||
"thermo"_thermo.html so you can monitor what is happening.
|
||||
Visualizing the atom movement is also a good idea to insure your model
|
||||
is behaving as you expect.
|
||||
|
||||
In parallel, one way LAMMPS can hang is due to how different MPI
|
||||
implementations handle buffering of messages. If the code hangs
|
||||
without an error message, it may be that you need to specify an MPI
|
||||
setting or two (usually via an environment variable) to enable
|
||||
buffering or boost the sizes of messages that can be buffered.
|
||||
934
doc/src/Errors_warnings.txt
Normal file
@ -0,0 +1,934 @@
|
||||
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Warning messages :h3
|
||||
|
||||
This is an alphabetic list of the WARNING messages LAMMPS prints out
|
||||
and the reason why. If the explanation here is not sufficient, the
|
||||
documentation for the offending command may help. Warning messages
|
||||
also list the source file and line number where the warning was
|
||||
generated. For example, a message lile this:
|
||||
|
||||
WARNING: Bond atom missing in box size check (domain.cpp:187) :pre
|
||||
|
||||
means that line #187 in the file src/domain.cpp generated the error.
|
||||
Looking in the source code may help you figure out what went wrong.
|
||||
|
||||
Note that warning messages from "user-contributed
|
||||
packages"_Packages_user.html are not listed here. If such a warning
|
||||
occurs and is not self-explanatory, you'll need to look in the source
|
||||
code or contact the author of the package.
|
||||
|
||||
Doc page with "ERROR messages"_Errors_messages.html
|
||||
|
||||
:line
|
||||
|
||||
:dlb
|
||||
|
||||
{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
|
||||
|
||||
The adjust/cutoff command is turned on and the Coulombic cutoff has been
|
||||
adjusted to match the user-specified accuracy. :dd
|
||||
|
||||
{Angle atoms missing at step %ld} :dt
|
||||
|
||||
One or more of 3 atoms needed to compute a particular angle are
|
||||
missing on this processor. Typically this is because the pairwise
|
||||
cutoff is set too short or the angle has blown apart and an atom is
|
||||
too far away. :dd
|
||||
|
||||
{Angle style in data file differs from currently defined angle style} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Atom style in data file differs from currently defined atom style} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Bond atom missing in box size check} :dt
|
||||
|
||||
The 2nd atoms needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away. :dd
|
||||
|
||||
{Bond atom missing in image check} :dt
|
||||
|
||||
The 2nd atom in a particular bond is missing on this processor.
|
||||
Typically this is because the pairwise cutoff is set too short or the
|
||||
bond has blown apart and an atom is too far away. :dd
|
||||
|
||||
{Bond atoms missing at step %ld} :dt
|
||||
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away. :dd
|
||||
|
||||
{Bond style in data file differs from currently defined bond style} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Bond/angle/dihedral extent > half of periodic box length} :dt
|
||||
|
||||
This is a restriction because LAMMPS can be confused about which image
|
||||
of an atom in the bonded interaction is the correct one to use.
|
||||
"Extent" in this context means the maximum end-to-end length of the
|
||||
bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
|
||||
length, multiplying by the number of bonds in the interaction (e.g. 3
|
||||
for a dihedral) and adding a small amount of stretch. :dd
|
||||
|
||||
{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Calling write_dump before a full system init.} :dt
|
||||
|
||||
The write_dump command is used before the system has been fully
|
||||
initialized as part of a 'run' or 'minimize' command. Not all dump
|
||||
styles and features are fully supported at this point and thus the
|
||||
command may fail or produce incomplete or incorrect output. Insert
|
||||
a "run 0" command, if a full system init is required. :dd
|
||||
|
||||
{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
|
||||
|
||||
This means the temperature associated with the rigid bodies may be
|
||||
incorrect on this timestep. :dd
|
||||
|
||||
{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
|
||||
|
||||
This means the temperature associated with the rigid bodies may be
|
||||
incorrect on this timestep. :dd
|
||||
|
||||
{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Charges are set, but coulombic solver is not used} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Charges did not converge at step %ld: %lg} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
|
||||
|
||||
The neighbor cutoff used may not encompass enough ghost atoms
|
||||
to perform this operation correctly. :dd
|
||||
|
||||
{Computing temperature of portions of rigid bodies} :dt
|
||||
|
||||
The group defined by the temperature compute does not encompass all
|
||||
the atoms in one or more rigid bodies, so the change in
|
||||
degrees-of-freedom for the atoms in those partial rigid bodies will
|
||||
not be accounted for. :dd
|
||||
|
||||
{Create_bonds max distance > minimum neighbor cutoff} :dt
|
||||
|
||||
This means atom pairs for some atom types may not be in the neighbor
|
||||
list and thus no bond can be created between them. :dd
|
||||
|
||||
{Delete_atoms cutoff > minimum neighbor cutoff} :dt
|
||||
|
||||
This means atom pairs for some atom types may not be in the neighbor
|
||||
list and thus an atom in that pair cannot be deleted. :dd
|
||||
|
||||
{Dihedral atoms missing at step %ld} :dt
|
||||
|
||||
One or more of 4 atoms needed to compute a particular dihedral are
|
||||
missing on this processor. Typically this is because the pairwise
|
||||
cutoff is set too short or the dihedral has blown apart and an atom is
|
||||
too far away. :dd
|
||||
|
||||
{Dihedral problem} :dt
|
||||
|
||||
Conformation of the 4 listed dihedral atoms is extreme; you may want
|
||||
to check your simulation geometry. :dd
|
||||
|
||||
{Dihedral problem: %d %ld %d %d %d %d} :dt
|
||||
|
||||
Conformation of the 4 listed dihedral atoms is extreme; you may want
|
||||
to check your simulation geometry. :dd
|
||||
|
||||
{Dihedral style in data file differs from currently defined dihedral style} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
|
||||
|
||||
If the fix changes the timestep, the dump dcd file will not
|
||||
reflect the change. :dd
|
||||
|
||||
{Energy due to X extra global DOFs will be included in minimizer energies} :dt
|
||||
|
||||
When using fixes like box/relax, the potential energy used by the minimizer
|
||||
is augmented by an additional energy provided by the fix. Thus the printed
|
||||
converged energy may be different from the total potential energy. :dd
|
||||
|
||||
{Energy tally does not account for 'zero yes'} :dt
|
||||
|
||||
The energy removed by using the 'zero yes' flag is not accounted
|
||||
for in the energy tally and thus energy conservation cannot be
|
||||
monitored in this case. :dd
|
||||
|
||||
{Estimated error in splitting of dispersion coeffs is %g} :dt
|
||||
|
||||
Error is greater than 0.0001 percent. :dd
|
||||
|
||||
{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
|
||||
|
||||
Self-explanatory. Choosing a different cutoff value may help. :dd
|
||||
|
||||
{FENE bond too long} :dt
|
||||
|
||||
A FENE bond has stretched dangerously far. It's interaction strength
|
||||
will be truncated to attempt to prevent the bond from blowing up. :dd
|
||||
|
||||
{FENE bond too long: %ld %d %d %g} :dt
|
||||
|
||||
A FENE bond has stretched dangerously far. It's interaction strength
|
||||
will be truncated to attempt to prevent the bond from blowing up. :dd
|
||||
|
||||
{FENE bond too long: %ld %g} :dt
|
||||
|
||||
A FENE bond has stretched dangerously far. It's interaction strength
|
||||
will be truncated to attempt to prevent the bond from blowing up. :dd
|
||||
|
||||
{Fix SRD walls overlap but fix srd overlap not set} :dt
|
||||
|
||||
You likely want to set this in your input script. :dd
|
||||
|
||||
{Fix bond/swap will ignore defined angles} :dt
|
||||
|
||||
See the doc page for fix bond/swap for more info on this
|
||||
restriction. :dd
|
||||
|
||||
{Fix deposit near setting < possible overlap separation %g} :dt
|
||||
|
||||
This test is performed for finite size particles with a diameter, not
|
||||
for point particles. The near setting is smaller than the particle
|
||||
diameter which can lead to overlaps. :dd
|
||||
|
||||
{Fix evaporate may delete atom with non-zero molecule ID} :dt
|
||||
|
||||
This is probably an error, since you should not delete only one atom
|
||||
of a molecule. :dd
|
||||
|
||||
{Fix gcmc using full_energy option} :dt
|
||||
|
||||
Fix gcmc has automatically turned on the full_energy option since it
|
||||
is required for systems like the one specified by the user. User input
|
||||
included one or more of the following: kspace, triclinic, a hybrid
|
||||
pair style, an eam pair style, or no "single" function for the pair
|
||||
style. :dd
|
||||
|
||||
{Fix property/atom mol or charge w/out ghost communication} :dt
|
||||
|
||||
A model typically needs these properties defined for ghost atoms. :dd
|
||||
|
||||
{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Fix qeq has non-zero lower Taper radius cutoff} :dt
|
||||
|
||||
Absolute value must be <= 0.01. :dd
|
||||
|
||||
{Fix qeq has very low Taper radius cutoff} :dt
|
||||
|
||||
Value should typically be >= 5.0. :dd
|
||||
|
||||
{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Fix qeq/fire tolerance may be too small for damped fires} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Fix rattle should come after all other integration fixes} :dt
|
||||
|
||||
This fix is designed to work after all other integration fixes change
|
||||
atom positions. Thus it should be the last integration fix specified.
|
||||
If not, it will not satisfy the desired constraints as well as it
|
||||
otherwise would. :dd
|
||||
|
||||
{Fix recenter should come after all other integration fixes} :dt
|
||||
|
||||
Other fixes may change the position of the center-of-mass, so
|
||||
fix recenter should come last. :dd
|
||||
|
||||
{Fix srd SRD moves may trigger frequent reneighboring} :dt
|
||||
|
||||
This is because the SRD particles may move long distances. :dd
|
||||
|
||||
{Fix srd grid size > 1/4 of big particle diameter} :dt
|
||||
|
||||
This may cause accuracy problems. :dd
|
||||
|
||||
{Fix srd particle moved outside valid domain} :dt
|
||||
|
||||
This may indicate a problem with your simulation parameters. :dd
|
||||
|
||||
{Fix srd particles may move > big particle diameter} :dt
|
||||
|
||||
This may cause accuracy problems. :dd
|
||||
|
||||
{Fix srd viscosity < 0.0 due to low SRD density} :dt
|
||||
|
||||
This may cause accuracy problems. :dd
|
||||
|
||||
{Fix thermal/conductivity comes before fix ave/spatial} :dt
|
||||
|
||||
The order of these 2 fixes in your input script is such that fix
|
||||
thermal/conductivity comes first. If you are using fix ave/spatial to
|
||||
measure the temperature profile induced by fix viscosity, then this
|
||||
may cause a glitch in the profile since you are averaging immediately
|
||||
after swaps have occurred. Flipping the order of the 2 fixes
|
||||
typically helps. :dd
|
||||
|
||||
{Fix viscosity comes before fix ave/spatial} :dt
|
||||
|
||||
The order of these 2 fixes in your input script is such that
|
||||
fix viscosity comes first. If you are using fix ave/spatial
|
||||
to measure the velocity profile induced by fix viscosity, then
|
||||
this may cause a glitch in the profile since you are averaging
|
||||
immediately after swaps have occurred. Flipping the order
|
||||
of the 2 fixes typically helps. :dd
|
||||
|
||||
{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
|
||||
|
||||
This is current restriction with Kokkos. :dd
|
||||
|
||||
{For better accuracy use 'pair_modify table 0'} :dt
|
||||
|
||||
The user-specified force accuracy cannot be achieved unless the table
|
||||
feature is disabled by using 'pair_modify table 0'. :dd
|
||||
|
||||
{Geometric mixing assumed for 1/r^6 coefficients} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Group for fix_modify temp != fix group} :dt
|
||||
|
||||
The fix_modify command is specifying a temperature computation that
|
||||
computes a temperature on a different group of atoms than the fix
|
||||
itself operates on. This is probably not what you want to do. :dd
|
||||
|
||||
{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
|
||||
|
||||
This is the size of the matrix. :dd
|
||||
|
||||
{Ignoring unknown or incorrect info command flag} :dt
|
||||
|
||||
Self-explanatory. An unknown argument was given to the info command.
|
||||
Compare your input with the documentation. :dd
|
||||
|
||||
{Improper atoms missing at step %ld} :dt
|
||||
|
||||
One or more of 4 atoms needed to compute a particular improper are
|
||||
missing on this processor. Typically this is because the pairwise
|
||||
cutoff is set too short or the improper has blown apart and an atom is
|
||||
too far away. :dd
|
||||
|
||||
{Improper problem: %d %ld %d %d %d %d} :dt
|
||||
|
||||
Conformation of the 4 listed improper atoms is extreme; you may want
|
||||
to check your simulation geometry. :dd
|
||||
|
||||
{Improper style in data file differs from currently defined improper style} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Inconsistent image flags} :dt
|
||||
|
||||
The image flags for a pair on bonded atoms appear to be inconsistent.
|
||||
Inconsistent means that when the coordinates of the two atoms are
|
||||
unwrapped using the image flags, the two atoms are far apart.
|
||||
Specifically they are further apart than half a periodic box length.
|
||||
Or they are more than a box length apart in a non-periodic dimension.
|
||||
This is usually due to the initial data file not having correct image
|
||||
flags for the 2 atoms in a bond that straddles a periodic boundary.
|
||||
They should be different by 1 in that case. This is a warning because
|
||||
inconsistent image flags will not cause problems for dynamics or most
|
||||
LAMMPS simulations. However they can cause problems when such atoms
|
||||
are used with the fix rigid or replicate commands. Note that if you
|
||||
have an infinite periodic crystal with bonds then it is impossible to
|
||||
have fully consistent image flags, since some bonds will cross
|
||||
periodic boundaries and connect two atoms with the same image
|
||||
flag. :dd
|
||||
|
||||
{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{KIM Model does not provide 'forces'; Forces will be zero} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
|
||||
|
||||
The kspace_modify slab parameter should be larger to insure periodic
|
||||
grids padded with empty space do not overlap. :dd
|
||||
|
||||
{Less insertions than requested} :dt
|
||||
|
||||
The fix pour command was unsuccessful at finding open space
|
||||
for as many particles as it tried to insert. :dd
|
||||
|
||||
{Library error in lammps_gather_atoms} :dt
|
||||
|
||||
This library function cannot be used if atom IDs are not defined
|
||||
or are not consecutively numbered. :dd
|
||||
|
||||
{Library error in lammps_scatter_atoms} :dt
|
||||
|
||||
This library function cannot be used if atom IDs are not defined or
|
||||
are not consecutively numbered, or if no atom map is defined. See the
|
||||
atom_modify command for details about atom maps. :dd
|
||||
|
||||
{Lost atoms via change_box: original %ld current %ld} :dt
|
||||
|
||||
The command options you have used caused atoms to be lost. :dd
|
||||
|
||||
{Lost atoms via displace_atoms: original %ld current %ld} :dt
|
||||
|
||||
The command options you have used caused atoms to be lost. :dd
|
||||
|
||||
{Lost atoms: original %ld current %ld} :dt
|
||||
|
||||
Lost atoms are checked for each time thermo output is done. See the
|
||||
thermo_modify lost command for options. Lost atoms usually indicate
|
||||
bad dynamics, e.g. atoms have been blown far out of the simulation
|
||||
box, or moved further than one processor's sub-domain away before
|
||||
reneighboring. :dd
|
||||
|
||||
{MSM mesh too small, increasing to 2 points in each direction} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Mismatch between velocity and compute groups} :dt
|
||||
|
||||
The temperature computation used by the velocity command will not be
|
||||
on the same group of atoms that velocities are being set for. :dd
|
||||
|
||||
{Mixing forced for lj coefficients} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Molecule attributes do not match system attributes} :dt
|
||||
|
||||
An attribute is specified (e.g. diameter, charge) that is
|
||||
not defined for the specified atom style. :dd
|
||||
|
||||
{Molecule has bond topology but no special bond settings} :dt
|
||||
|
||||
This means the bonded atoms will not be excluded in pair-wise
|
||||
interactions. :dd
|
||||
|
||||
{Molecule template for create_atoms has multiple molecules} :dt
|
||||
|
||||
The create_atoms command will only create molecules of a single type,
|
||||
i.e. the first molecule in the template. :dd
|
||||
|
||||
{Molecule template for fix gcmc has multiple molecules} :dt
|
||||
|
||||
The fix gcmc command will only create molecules of a single type,
|
||||
i.e. the first molecule in the template. :dd
|
||||
|
||||
{Molecule template for fix shake has multiple molecules} :dt
|
||||
|
||||
The fix shake command will only recognize molecules of a single
|
||||
type, i.e. the first molecule in the template. :dd
|
||||
|
||||
{More than one compute centro/atom} :dt
|
||||
|
||||
It is not efficient to use compute centro/atom more than once. :dd
|
||||
|
||||
{More than one compute cluster/atom} :dt
|
||||
|
||||
It is not efficient to use compute cluster/atom more than once. :dd
|
||||
|
||||
{More than one compute cna/atom defined} :dt
|
||||
|
||||
It is not efficient to use compute cna/atom more than once. :dd
|
||||
|
||||
{More than one compute contact/atom} :dt
|
||||
|
||||
It is not efficient to use compute contact/atom more than once. :dd
|
||||
|
||||
{More than one compute coord/atom} :dt
|
||||
|
||||
It is not efficient to use compute coord/atom more than once. :dd
|
||||
|
||||
{More than one compute damage/atom} :dt
|
||||
|
||||
It is not efficient to use compute ke/atom more than once. :dd
|
||||
|
||||
{More than one compute dilatation/atom} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{More than one compute erotate/sphere/atom} :dt
|
||||
|
||||
It is not efficient to use compute erorate/sphere/atom more than once. :dd
|
||||
|
||||
{More than one compute hexorder/atom} :dt
|
||||
|
||||
It is not efficient to use compute hexorder/atom more than once. :dd
|
||||
|
||||
{More than one compute ke/atom} :dt
|
||||
|
||||
It is not efficient to use compute ke/atom more than once. :dd
|
||||
|
||||
{More than one compute orientorder/atom} :dt
|
||||
|
||||
It is not efficient to use compute orientorder/atom more than once. :dd
|
||||
|
||||
{More than one compute plasticity/atom} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{More than one compute sna/atom} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{More than one compute snad/atom} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{More than one compute snav/atom} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{More than one fix poems} :dt
|
||||
|
||||
It is not efficient to use fix poems more than once. :dd
|
||||
|
||||
{More than one fix rigid} :dt
|
||||
|
||||
It is not efficient to use fix rigid more than once. :dd
|
||||
|
||||
{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
|
||||
|
||||
This is because excluding specific pair interactions also excludes
|
||||
them from long-range interactions which may not be the desired effect.
|
||||
The special_bonds command handles this consistently by insuring
|
||||
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
|
||||
consistently by both the short-range pair style and the long-range
|
||||
solver. This is not done for exclusions of charged atom pairs via the
|
||||
neigh_modify exclude command. :dd
|
||||
|
||||
{New thermo_style command, previous thermo_modify settings will be lost} :dt
|
||||
|
||||
If a thermo_style command is used after a thermo_modify command, the
|
||||
settings changed by the thermo_modify command will be reset to their
|
||||
default values. This is because the thermo_modify command acts on
|
||||
the currently defined thermo style, and a thermo_style command creates
|
||||
a new style. :dd
|
||||
|
||||
{No Kspace calculation with verlet/split} :dt
|
||||
|
||||
The 2nd partition performs a kspace calculation so the kspace_style
|
||||
command must be used. :dd
|
||||
|
||||
{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
|
||||
|
||||
This means no scaling will be performed. :dd
|
||||
|
||||
{No fixes defined, atoms won't move} :dt
|
||||
|
||||
If you are not using a fix like nve, nvt, npt then atom velocities and
|
||||
coordinates will not be updated during timestepping. :dd
|
||||
|
||||
{No joints between rigid bodies, use fix rigid instead} :dt
|
||||
|
||||
The bodies defined by fix poems are not connected by joints. POEMS
|
||||
will integrate the body motion, but it would be more efficient to use
|
||||
fix rigid. :dd
|
||||
|
||||
{Not using real units with pair reax} :dt
|
||||
|
||||
This is most likely an error, unless you have created your own ReaxFF
|
||||
parameter file in a different set of units. :dd
|
||||
|
||||
{Number of MSM mesh points changed to be a multiple of 2} :dt
|
||||
|
||||
MSM requires that the number of grid points in each direction be a multiple
|
||||
of two and the number of grid points in one or more directions have been
|
||||
adjusted to meet this requirement. :dd
|
||||
|
||||
{OMP_NUM_THREADS environment is not set.} :dt
|
||||
|
||||
This environment variable must be set appropriately to use the
|
||||
USER-OMP package. :dd
|
||||
|
||||
{One or more atoms are time integrated more than once} :dt
|
||||
|
||||
This is probably an error since you typically do not want to
|
||||
advance the positions or velocities of an atom more than once
|
||||
per timestep. :dd
|
||||
|
||||
{One or more chunks do not contain all atoms in molecule} :dt
|
||||
|
||||
This may not be what you intended. :dd
|
||||
|
||||
{One or more dynamic groups may not be updated at correct point in timestep} :dt
|
||||
|
||||
If there are other fixes that act immediately after the initial stage
|
||||
of time integration within a timestep (i.e. after atoms move), then
|
||||
the command that sets up the dynamic group should appear after those
|
||||
fixes. This will insure that dynamic group assignments are made
|
||||
after all atoms have moved. :dd
|
||||
|
||||
{One or more respa levels compute no forces} :dt
|
||||
|
||||
This is computationally inefficient. :dd
|
||||
|
||||
{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
|
||||
|
||||
Something is possibly wrong with your model. :dd
|
||||
|
||||
{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
|
||||
|
||||
Something is possibly wrong with your model. :dd
|
||||
|
||||
{Pair brownian needs newton pair on for momentum conservation} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Pair dpd needs newton pair on for momentum conservation} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Pair dsmc: num_of_collisions > number_of_A} :dt
|
||||
|
||||
Collision model in DSMC is breaking down. :dd
|
||||
|
||||
{Pair dsmc: num_of_collisions > number_of_B} :dt
|
||||
|
||||
Collision model in DSMC is breaking down. :dd
|
||||
|
||||
{Pair style in data file differs from currently defined pair style} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Pair style restartinfo set but has no restart support} :dt
|
||||
|
||||
This pair style has a bug, where it does not support reading and
|
||||
writing information to a restart file, but does not set the member
|
||||
variable "restartinfo" to 0 as required in that case. :dd
|
||||
|
||||
{Particle deposition was unsuccessful} :dt
|
||||
|
||||
The fix deposit command was not able to insert as many atoms as
|
||||
needed. The requested volume fraction may be too high, or other atoms
|
||||
may be in the insertion region. :dd
|
||||
|
||||
{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
|
||||
|
||||
The decomposition of the physical domain (likely due to load
|
||||
balancing) has led to a processor's sub-domain being smaller than the
|
||||
neighbor skin in one or more dimensions. Since reneighboring is
|
||||
triggered by atoms moving the skin distance, this may lead to lost
|
||||
atoms, if an atom moves all the way across a neighboring processor's
|
||||
sub-domain before reneighboring is triggered. :dd
|
||||
|
||||
{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
|
||||
|
||||
This may lead to a larger grid than desired. See the kspace_modify overlap
|
||||
command to prevent changing of the PPPM order. :dd
|
||||
|
||||
{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
|
||||
|
||||
This may lead to a larger grid than desired. See the kspace_modify overlap
|
||||
command to prevent changing of the PPPM order. :dd
|
||||
|
||||
{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
|
||||
|
||||
This may lead to a larger grid than desired. See the kspace_modify overlap
|
||||
command to prevent changing of the PPPM order. :dd
|
||||
|
||||
{Replacing a fix, but new group != old group} :dt
|
||||
|
||||
The ID and style of a fix match for a fix you are changing with a fix
|
||||
command, but the new group you are specifying does not match the old
|
||||
group. :dd
|
||||
|
||||
{Replicating in a non-periodic dimension} :dt
|
||||
|
||||
The parameters for a replicate command will cause a non-periodic
|
||||
dimension to be replicated; this may cause unwanted behavior. :dd
|
||||
|
||||
{Resetting reneighboring criteria during PRD} :dt
|
||||
|
||||
A PRD simulation requires that neigh_modify settings be delay = 0,
|
||||
every = 1, check = yes. Since these settings were not in place,
|
||||
LAMMPS changed them and will restore them to their original values
|
||||
after the PRD simulation. :dd
|
||||
|
||||
{Resetting reneighboring criteria during TAD} :dt
|
||||
|
||||
A TAD simulation requires that neigh_modify settings be delay = 0,
|
||||
every = 1, check = yes. Since these settings were not in place,
|
||||
LAMMPS changed them and will restore them to their original values
|
||||
after the PRD simulation. :dd
|
||||
|
||||
{Resetting reneighboring criteria during minimization} :dt
|
||||
|
||||
Minimization requires that neigh_modify settings be delay = 0, every =
|
||||
1, check = yes. Since these settings were not in place, LAMMPS
|
||||
changed them and will restore them to their original values after the
|
||||
minimization. :dd
|
||||
|
||||
{Restart file used different # of processors} :dt
|
||||
|
||||
The restart file was written out by a LAMMPS simulation running on a
|
||||
different number of processors. Due to round-off, the trajectories of
|
||||
your restarted simulation may diverge a little more quickly than if
|
||||
you ran on the same # of processors. :dd
|
||||
|
||||
{Restart file used different 3d processor grid} :dt
|
||||
|
||||
The restart file was written out by a LAMMPS simulation running on a
|
||||
different 3d grid of processors. Due to round-off, the trajectories
|
||||
of your restarted simulation may diverge a little more quickly than if
|
||||
you ran on the same # of processors. :dd
|
||||
|
||||
{Restart file used different boundary settings, using restart file values} :dt
|
||||
|
||||
Your input script cannot change these restart file settings. :dd
|
||||
|
||||
{Restart file used different newton bond setting, using restart file value} :dt
|
||||
|
||||
The restart file value will override the setting in the input script. :dd
|
||||
|
||||
{Restart file used different newton pair setting, using input script value} :dt
|
||||
|
||||
The input script value will override the setting in the restart file. :dd
|
||||
|
||||
{Restrain problem: %d %ld %d %d %d %d} :dt
|
||||
|
||||
Conformation of the 4 listed dihedral atoms is extreme; you may want
|
||||
to check your simulation geometry. :dd
|
||||
|
||||
{Running PRD with only one replica} :dt
|
||||
|
||||
This is allowed, but you will get no parallel speed-up. :dd
|
||||
|
||||
{SRD bin shifting turned on due to small lamda} :dt
|
||||
|
||||
This is done to try to preserve accuracy. :dd
|
||||
|
||||
{SRD bin size for fix srd differs from user request} :dt
|
||||
|
||||
Fix SRD had to adjust the bin size to fit the simulation box. See the
|
||||
cubic keyword if you want this message to be an error vs warning. :dd
|
||||
|
||||
{SRD bins for fix srd are not cubic enough} :dt
|
||||
|
||||
The bin shape is not within tolerance of cubic. See the cubic
|
||||
keyword if you want this message to be an error vs warning. :dd
|
||||
|
||||
{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
|
||||
|
||||
See the inside keyword if you want this message to be an error vs
|
||||
warning. :dd
|
||||
|
||||
{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
|
||||
|
||||
See the inside keyword if you want this message to be an error vs
|
||||
warning. :dd
|
||||
|
||||
{Shake determinant < 0.0} :dt
|
||||
|
||||
The determinant of the quadratic equation being solved for a single
|
||||
cluster specified by the fix shake command is numerically suspect. LAMMPS
|
||||
will set it to 0.0 and continue. :dd
|
||||
|
||||
{Shell command '%s' failed with error '%s'} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Shell command returned with non-zero status} :dt
|
||||
|
||||
This may indicate the shell command did not operate as expected. :dd
|
||||
|
||||
{Should not allow rigid bodies to bounce off relecting walls} :dt
|
||||
|
||||
LAMMPS allows this, but their dynamics are not computed correctly. :dd
|
||||
|
||||
{Should not use fix nve/limit with fix shake or fix rattle} :dt
|
||||
|
||||
This will lead to invalid constraint forces in the SHAKE/RATTLE
|
||||
computation. :dd
|
||||
|
||||
{Simulations might be very slow because of large number of structure factors} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Slab correction not needed for MSM} :dt
|
||||
|
||||
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
|
||||
|
||||
{System is not charge neutral, net charge = %g} :dt
|
||||
|
||||
The total charge on all atoms on the system is not 0.0.
|
||||
For some KSpace solvers this is only a warning. :dd
|
||||
|
||||
{Table inner cutoff >= outer cutoff} :dt
|
||||
|
||||
You specified an inner cutoff for a Coulombic table that is longer
|
||||
than the global cutoff. Probably not what you wanted. :dd
|
||||
|
||||
{Temperature for MSST is not for group all} :dt
|
||||
|
||||
User-assigned temperature to MSST fix does not compute temperature for
|
||||
all atoms. Since MSST computes a global pressure, the kinetic energy
|
||||
contribution from the temperature is assumed to also be for all atoms.
|
||||
Thus the pressure used by MSST could be inaccurate. :dd
|
||||
|
||||
{Temperature for NPT is not for group all} :dt
|
||||
|
||||
User-assigned temperature to NPT fix does not compute temperature for
|
||||
all atoms. Since NPT computes a global pressure, the kinetic energy
|
||||
contribution from the temperature is assumed to also be for all atoms.
|
||||
Thus the pressure used by NPT could be inaccurate. :dd
|
||||
|
||||
{Temperature for fix modify is not for group all} :dt
|
||||
|
||||
The temperature compute is being used with a pressure calculation
|
||||
which does operate on group all, so this may be inconsistent. :dd
|
||||
|
||||
{Temperature for thermo pressure is not for group all} :dt
|
||||
|
||||
User-assigned temperature to thermo via the thermo_modify command does
|
||||
not compute temperature for all atoms. Since thermo computes a global
|
||||
pressure, the kinetic energy contribution from the temperature is
|
||||
assumed to also be for all atoms. Thus the pressure printed by thermo
|
||||
could be inaccurate. :dd
|
||||
|
||||
{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{The minimizer does not re-orient dipoles when using fix efield} :dt
|
||||
|
||||
This means that only the atom coordinates will be minimized,
|
||||
not the orientation of the dipoles. :dd
|
||||
|
||||
{Too many common neighbors in CNA %d times} :dt
|
||||
|
||||
More than the maximum # of neighbors was found multiple times. This
|
||||
was unexpected. :dd
|
||||
|
||||
{Too many inner timesteps in fix ttm} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Too many neighbors in CNA for %d atoms} :dt
|
||||
|
||||
More than the maximum # of neighbors was found multiple times. This
|
||||
was unexpected. :dd
|
||||
|
||||
{Triclinic box skew is large} :dt
|
||||
|
||||
The displacement in a skewed direction is normally required to be less
|
||||
than half the box length in that dimension. E.g. the xy tilt must be
|
||||
between -half and +half of the x box length. You have relaxed the
|
||||
constraint using the box tilt command, but the warning means that a
|
||||
LAMMPS simulation may be inefficient as a result. :dd
|
||||
|
||||
{Use special bonds = 0,1,1 with bond style fene} :dt
|
||||
|
||||
Most FENE models need this setting for the special_bonds command. :dd
|
||||
|
||||
{Use special bonds = 0,1,1 with bond style fene/expand} :dt
|
||||
|
||||
Most FENE models need this setting for the special_bonds command. :dd
|
||||
|
||||
{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
|
||||
|
||||
This is likely not what you want to do. The exclusion settings will
|
||||
eliminate neighbors in the neighbor list, which the manybody potential
|
||||
needs to calculated its terms correctly. :dd
|
||||
|
||||
{Using compute temp/deform with inconsistent fix deform remap option} :dt
|
||||
|
||||
Fix nvt/sllod assumes deforming atoms have a velocity profile provided
|
||||
by "remap v" or "remap none" as a fix deform option. :dd
|
||||
|
||||
{Using compute temp/deform with no fix deform defined} :dt
|
||||
|
||||
This is probably an error, since it makes little sense to use
|
||||
compute temp/deform in this case. :dd
|
||||
|
||||
{Using fix srd with box deformation but no SRD thermostat} :dt
|
||||
|
||||
The deformation will heat the SRD particles so this can
|
||||
be dangerous. :dd
|
||||
|
||||
{Using kspace solver on system with no charge} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Using largest cut-off for lj/long/dipole/long long long} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Using largest cutoff for buck/long/coul/long} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Using largest cutoff for lj/long/coul/long} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Using package gpu without any pair style defined} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Using pair potential shift with pair_modify compute no} :dt
|
||||
|
||||
The shift effects will thus not be computed. :dd
|
||||
|
||||
{Using pair tail corrections with nonperiodic system} :dt
|
||||
|
||||
This is probably a bogus thing to do, since tail corrections are
|
||||
computed by integrating the density of a periodic system out to
|
||||
infinity. :dd
|
||||
|
||||
{Using pair tail corrections with pair_modify compute no} :dt
|
||||
|
||||
The tail corrections will thus not be computed. :dd
|
||||
|
||||
{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
:dle
|
||||
@ -1,12 +1,14 @@
|
||||
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
|
||||
"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Tools.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
7. Example problems :h2
|
||||
Example scripts :h3
|
||||
|
||||
The LAMMPS distribution includes an examples sub-directory with many
|
||||
sample problems. Many are 2d models that run quickly are are
|
||||
@ -46,7 +48,7 @@ Lists of both kinds of directories are given below.
|
||||
|
||||
:line
|
||||
|
||||
Lowercase directories :h3
|
||||
Lowercase directories :h4
|
||||
|
||||
accelerate: run with various acceleration options (OpenMP, GPU, Phi)
|
||||
airebo: polyethylene with AIREBO potential
|
||||
@ -110,10 +112,10 @@ web site.
|
||||
|
||||
If you uncomment the "dump image"_dump_image.html line(s) in the input
|
||||
script a series of JPG images will be produced by the run (assuming
|
||||
you built LAMMPS with JPG support; see "Section
|
||||
2.2"_Section_start.html#start_2 for details). These can be viewed
|
||||
individually or turned into a movie or animated by tools like
|
||||
ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
you built LAMMPS with JPG support; see the
|
||||
"Build_settings"_Build_settings.html doc page for details). These can
|
||||
be viewed individually or turned into a movie or animated by tools
|
||||
like ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
"dump image"_dump_image.html doc page for more details. E.g. this
|
||||
Imagemagick command would create a GIF file suitable for viewing in a
|
||||
browser.
|
||||
@ -122,7 +124,7 @@ browser.
|
||||
|
||||
:line
|
||||
|
||||
Uppercase directories :h3
|
||||
Uppercase directories :h4
|
||||
|
||||
ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
|
||||
COUPLE: examples of how to use LAMMPS as a library
|
||||
@ -141,5 +143,5 @@ The USER directory has a large number of sub-directories which
|
||||
correspond by name to a USER package. They contain scripts that
|
||||
illustrate how to use the command(s) provided in that package. Many
|
||||
of the sub-directories have their own README files which give further
|
||||
instructions. See the "Section 4"_Section_packages.html doc
|
||||
instructions. See the "Packages_details"_Packages_details.html doc
|
||||
page for more info on specific USER packages.
|
||||
189
doc/src/Howto.txt
Normal file
@ -0,0 +1,189 @@
|
||||
"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Examples.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Howto discussions :h2
|
||||
|
||||
These doc pages describe how to perform various tasks with LAMMPS,
|
||||
both for users and developers. The
|
||||
"glossary"_http://lammps.sandia.gov website page also lists MD
|
||||
terminology with links to corresponding LAMMPS manual pages. The
|
||||
example input scripts included in the examples dir of the LAMMPS
|
||||
distribution and highlighted on the "Examples"_Examples.html doc page
|
||||
also show how to setup and run various kinds of simulations.
|
||||
|
||||
Tutorials howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: tutorials
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_github
|
||||
Howto_pylammps
|
||||
Howto_bash
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Using GitHub with LAMMPS"_Howto_github.html
|
||||
"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
|
||||
"Using LAMMPS with bash on Windows"_Howto_bash.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
General howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: general
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_restart
|
||||
Howto_viz
|
||||
Howto_multiple
|
||||
Howto_replica
|
||||
Howto_library
|
||||
Howto_couple
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Restart a simulation"_Howto_restart.html
|
||||
"Visualize LAMMPS snapshots"_Howto_viz.html
|
||||
"Run multiple simulations from one input script"_Howto_multiple.html
|
||||
"Multi-replica simulations"_Howto_replica.html
|
||||
"Library interface to LAMMPS"_Howto_library.html
|
||||
"Couple LAMMPS to other codes"_Howto_couple.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
Settings howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: settings
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_2d
|
||||
Howto_triclinic
|
||||
Howto_thermostat
|
||||
Howto_barostat
|
||||
Howto_walls
|
||||
Howto_nemd
|
||||
Howto_dispersion
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"2d simulations"_Howto_2d.html
|
||||
"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
|
||||
"Thermostats"_Howto_thermostat.html
|
||||
"Barostats"_Howto_barostat.html
|
||||
"Walls"_Howto_walls.html
|
||||
"NEMD simulations"_Howto_nemd.html
|
||||
"Long-range dispersion settings"_Howto_dispersion.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
|
||||
Analysis howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: analysis
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_output
|
||||
Howto_chunk
|
||||
Howto_temperature
|
||||
Howto_elastic
|
||||
Howto_kappa
|
||||
Howto_viscosity
|
||||
Howto_diffusion
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
|
||||
"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
|
||||
"Calculate temperature"_Howto_temperature.html
|
||||
"Calculate elastic constants"_Howto_elastic.html
|
||||
"Calculate thermal conductivity"_Howto_kappa.html
|
||||
"Calculate viscosity"_Howto_viscosity.html
|
||||
"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
Force fields howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: force
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_bioFF
|
||||
Howto_tip3p
|
||||
Howto_tip4p
|
||||
Howto_spc
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
|
||||
"TIP3P water model"_Howto_tip3p.html
|
||||
"TIP4P water model"_Howto_tip4p.html
|
||||
"SPC water model"_Howto_spc.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
Packages howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: packages
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_spherical
|
||||
Howto_granular
|
||||
Howto_body
|
||||
Howto_polarizable
|
||||
Howto_coreshell
|
||||
Howto_drude
|
||||
Howto_drude2
|
||||
Howto_manifold
|
||||
Howto_spins
|
||||
|
||||
END_RST -->
|
||||
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Finite-size spherical and aspherical particles"_Howto_spherical.html
|
||||
"Granular models"_Howto_granular.html
|
||||
"Body style particles"_Howto_body.html
|
||||
"Polarizable models"_Howto_polarizable.html
|
||||
"Adiabatic core/shell model"_Howto_coreshell.html
|
||||
"Drude induced dipoles"_Howto_drude.html
|
||||
"Drude induced dipoles (extended)"_Howto_drude2.html
|
||||
"Manifolds (surfaces)"_Howto_manifold.html
|
||||
"Magnetic spins"_Howto_spins.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
48
doc/src/Howto_2d.txt
Normal file
@ -0,0 +1,48 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
2d simulations :h3
|
||||
|
||||
Use the "dimension"_dimension.html command to specify a 2d simulation.
|
||||
|
||||
Make the simulation box periodic in z via the "boundary"_boundary.html
|
||||
command. This is the default.
|
||||
|
||||
If using the "create box"_create_box.html command to define a
|
||||
simulation box, set the z dimensions narrow, but finite, so that the
|
||||
create_atoms command will tile the 3d simulation box with a single z
|
||||
plane of atoms - e.g.
|
||||
|
||||
"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
|
||||
|
||||
If using the "read data"_read_data.html command to read in a file of
|
||||
atom coordinates, set the "zlo zhi" values to be finite but narrow,
|
||||
similar to the create_box command settings just described. For each
|
||||
atom in the file, assign a z coordinate so it falls inside the
|
||||
z-boundaries of the box - e.g. 0.0.
|
||||
|
||||
Use the "fix enforce2d"_fix_enforce2d.html command as the last
|
||||
defined fix to insure that the z-components of velocities and forces
|
||||
are zeroed out every timestep. The reason to make it the last fix is
|
||||
so that any forces induced by other fixes will be zeroed out.
|
||||
|
||||
Many of the example input scripts included in the LAMMPS distribution
|
||||
are for 2d models.
|
||||
|
||||
NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
|
||||
opposed to point particles. See the "atom_style
|
||||
sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
|
||||
commands for details. By default, for 2d simulations, such particles
|
||||
will still be modeled as 3d spheres, not 2d discs (circles), meaning
|
||||
their moment of inertia will be that of a sphere. If you wish to
|
||||
model them as 2d discs, see the "set density/disc"_set.html command
|
||||
and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
|
||||
"fix nvt/sphere"_fix_nvt_sphere.html, "fix
|
||||
nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
|
||||
commands.
|
||||
75
doc/src/Howto_barostat.txt
Normal file
@ -0,0 +1,75 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Barostats :h3
|
||||
|
||||
Barostatting means controlling the pressure in an MD simulation.
|
||||
"Thermostatting"_Howto_thermostat.html means controlling the
|
||||
temperature of the particles. Since the pressure includes a kinetic
|
||||
component due to particle velocities, both these operations require
|
||||
calculation of the temperature. Typically a target temperature (T)
|
||||
and/or pressure (P) is specified by the user, and the thermostat or
|
||||
barostat attempts to equilibrate the system to the requested T and/or
|
||||
P.
|
||||
|
||||
Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
|
||||
barosttating methods are currently available: Nose-Hoover (npt and
|
||||
nph) and Berendsen:
|
||||
|
||||
"fix npt"_fix_nh.html
|
||||
"fix npt/sphere"_fix_npt_sphere.html
|
||||
"fix npt/asphere"_fix_npt_asphere.html
|
||||
"fix nph"_fix_nh.html
|
||||
"fix press/berendsen"_fix_press_berendsen.html :ul
|
||||
|
||||
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
|
||||
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
|
||||
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
|
||||
press/berendsen"_fix_press_berendsen.html can be used in conjunction
|
||||
with any of the thermostatting fixes.
|
||||
|
||||
As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
|
||||
and "fix nph"_fix_nh.html only use translational motion of the
|
||||
particles in computing T and P and performing thermo/barostatting.
|
||||
"Fix npt/sphere"_fix_npt_sphere.html and "fix
|
||||
npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
|
||||
translation velocities but also rotational velocities for spherical
|
||||
and aspherical particles.
|
||||
|
||||
All of the barostatting fixes use the "compute
|
||||
pressure"_compute_pressure.html compute to calculate a current
|
||||
pressure. By default, this compute is created with a simple "compute
|
||||
temp"_compute_temp.html (see the last argument of the "compute
|
||||
pressure"_compute_pressure.html command), which is used to calculated
|
||||
the kinetic component of the pressure. The barostatting fixes can
|
||||
also use temperature computes that remove bias for the purpose of
|
||||
computing the kinetic component which contributes to the current
|
||||
pressure. See the doc pages for the individual fixes and for the
|
||||
"fix_modify"_fix_modify.html command for instructions on how to assign
|
||||
a temperature or pressure compute to a barostatting fix.
|
||||
|
||||
NOTE: As with the thermostats, the Nose/Hoover methods ("fix
|
||||
npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
|
||||
"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
|
||||
be used with one of the constant NVE fixes or with one of the NVT
|
||||
fixes.
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
"thermo_style"_thermo_style.html command, often includes pressure
|
||||
values. As explained on the doc page for the
|
||||
"thermo_style"_thermo_style.html command, the default pressure is
|
||||
setup by the thermo command itself. It is NOT the presure associated
|
||||
with any barostatting fix you have defined or with any compute you
|
||||
have defined that calculates a presure. The doc pages for the
|
||||
barostatting fixes explain the ID of the pressure compute they create.
|
||||
Thus if you want to view these pressurse, you need to specify them
|
||||
explicitly via the "thermo_style custom"_thermo_style.html command.
|
||||
Or you can use the "thermo_modify"_thermo_modify.html command to
|
||||
re-define what pressure compute is used for default thermodynamic
|
||||
output.
|
||||
3
doc/src/tutorial_bash_on_windows.txt → doc/src/Howto_bash.txt
Normal file → Executable file
@ -2,7 +2,7 @@
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
@ -10,6 +10,7 @@ Using LAMMPS with Bash on Windows :h3
|
||||
[written by Richard Berger]
|
||||
|
||||
:line
|
||||
|
||||
Starting with Windows 10 you can install Linux tools directly in Windows. This
|
||||
allows you to compile LAMMPS following the same procedure as on a real Ubuntu
|
||||
Linux installation. Software can be easily installed using the package manager
|
||||
105
doc/src/Howto_bioFF.txt
Normal file
@ -0,0 +1,105 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
CHARMM, AMBER, and DREIDING force fields :h3
|
||||
|
||||
A force field has 2 parts: the formulas that define it and the
|
||||
coefficients used for a particular system. Here we only discuss
|
||||
formulas implemented in LAMMPS that correspond to formulas commonly
|
||||
used in the CHARMM, AMBER, and DREIDING force fields. Setting
|
||||
coefficients is done in the input data file via the
|
||||
"read_data"_read_data.html command or in the input script with
|
||||
commands like "pair_coeff"_pair_coeff.html or
|
||||
"bond_coeff"_bond_coeff.html. See the "Tools"_Tools.html doc page for
|
||||
additional tools that can use CHARMM or AMBER to assign force field
|
||||
coefficients and convert their output into LAMMPS input.
|
||||
|
||||
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
|
||||
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
|
||||
field.
|
||||
|
||||
:link(charmm,http://www.scripps.edu/brooks)
|
||||
:link(amber,http://amber.scripps.edu)
|
||||
|
||||
These style choices compute force field formulas that are consistent
|
||||
with common options in CHARMM or AMBER. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
"angle_style"_angle_charmm.html charmm
|
||||
"dihedral_style"_dihedral_charmm.html charmmfsh
|
||||
"dihedral_style"_dihedral_charmm.html charmm
|
||||
"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
|
||||
"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/charmm
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
|
||||
|
||||
"special_bonds"_special_bonds.html charmm
|
||||
"special_bonds"_special_bonds.html amber :ul
|
||||
|
||||
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
|
||||
released in March 2017. We recommend they be used instead of the
|
||||
older {charmm} styles. See discussion of the differences on the "pair
|
||||
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
|
||||
doc pages.
|
||||
|
||||
DREIDING is a generic force field developed by the "Goddard
|
||||
group"_http://www.wag.caltech.edu at Caltech and is useful for
|
||||
predicting structures and dynamics of organic, biological and
|
||||
main-group inorganic molecules. The philosophy in DREIDING is to use
|
||||
general force constants and geometry parameters based on simple
|
||||
hybridization considerations, rather than individual force constants
|
||||
and geometric parameters that depend on the particular combinations of
|
||||
atoms involved in the bond, angle, or torsion terms. DREIDING has an
|
||||
"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
|
||||
interactions involving a hydrogen atom on very electronegative atoms
|
||||
(N, O, F).
|
||||
|
||||
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
|
||||
|
||||
These style choices compute force field formulas that are consistent
|
||||
with the DREIDING force field. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
"bond_style"_bond_morse.html morse :ul
|
||||
|
||||
"angle_style"_angle_harmonic.html harmonic
|
||||
"angle_style"_angle_cosine.html cosine
|
||||
"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
|
||||
|
||||
"dihedral_style"_dihedral_charmm.html charmm
|
||||
"improper_style"_improper_umbrella.html umbrella :ul
|
||||
|
||||
"pair_style"_pair_buck.html buck
|
||||
"pair_style"_pair_buck.html buck/coul/cut
|
||||
"pair_style"_pair_buck.html buck/coul/long
|
||||
"pair_style"_pair_lj.html lj/cut
|
||||
"pair_style"_pair_lj.html lj/cut/coul/cut
|
||||
"pair_style"_pair_lj.html lj/cut/coul/long :ul
|
||||
|
||||
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
|
||||
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
|
||||
|
||||
"special_bonds"_special_bonds.html dreiding :ul
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-MacKerell)
|
||||
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
:link(howto-Cornell)
|
||||
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
|
||||
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
|
||||
|
||||
:link(howto-Mayo)
|
||||
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).
|
||||
@ -1,24 +1,24 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Body particles :h2
|
||||
Body particles :h3
|
||||
|
||||
[Overview:]
|
||||
|
||||
This doc page is not about a LAMMPS input script command, but about
|
||||
body particles, which are generalized finite-size particles.
|
||||
In LAMMPS, body particles are generalized finite-size particles.
|
||||
Individual body particles can represent complex entities, such as
|
||||
surface meshes of discrete points, collections of sub-particles,
|
||||
deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities that body particles. See "Section
|
||||
6.14"_Section_howto.html#howto_14 for a general overview of all
|
||||
simpler entities that body particles. See the "Howto
|
||||
spherical"_Howto_spherical.html doc page for a general overview of all
|
||||
these particle types.
|
||||
|
||||
Body particles are used via the "atom_style body"_atom_style.html
|
||||
@ -27,19 +27,17 @@ styles supported by LAMMPS are as follows. The name in the first
|
||||
column is used as the {bstyle} argument for the "atom_style
|
||||
body"_atom_style.html command.
|
||||
|
||||
{nparticle} | rigid body with N sub-particles |
|
||||
{rounded/polygon} | 2d convex polygon with N vertices :tb(c=2,s=|)
|
||||
{nparticle} : rigid body with N sub-particles
|
||||
{rounded/polygon} : 2d polygons with N vertices
|
||||
{rounded/polyhedron} : 3d polyhedra with N vertices, E edges and F faces :tb(s=:)
|
||||
|
||||
The body style determines what attributes are stored for each body and
|
||||
thus how they can be used to compute pairwise body/body or
|
||||
bond/non-body (point particle) interactions. More details of each
|
||||
style are described below.
|
||||
|
||||
NOTE: The rounded/polygon style listed in the table above and
|
||||
described below has not yet been relesed in LAMMPS. It will be soon.
|
||||
|
||||
We hope to add more styles in the future. See "Section
|
||||
10.12"_Section_modify.html#mod_12 for details on how to add a new body
|
||||
More styles may be added in the future. See the "Modify
|
||||
body"_Modify_body.html doc page for details on how to add a new body
|
||||
style to the code.
|
||||
|
||||
:line
|
||||
@ -61,7 +59,7 @@ the simple particles.
|
||||
By contrast, when body particles are used, LAMMPS treats an entire
|
||||
body as a single particle for purposes of computing pairwise
|
||||
interactions, building neighbor lists, migrating particles between
|
||||
processors, outputting particles to a dump file, etc. This means that
|
||||
processors, output of particles to a dump file, etc. This means that
|
||||
interactions between pairs of bodies or between a body and non-body
|
||||
(point) particle need to be encoded in an appropriate pair style. If
|
||||
such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
|
||||
@ -72,17 +70,20 @@ single body/body interaction was computed.
|
||||
Thus it only makes sense to use body particles and develop such a pair
|
||||
style, when particle/particle interactions are more complex than what
|
||||
the "fix rigid"_fix_rigid.html command can already calculate. For
|
||||
example, if particles have one or more of the following attributes:
|
||||
example, consider particles with one or more of the following
|
||||
attributes:
|
||||
|
||||
represented by a surface mesh
|
||||
represented by a collection of geometric entities (e.g. planes + spheres)
|
||||
deformable
|
||||
internal stress that induces fragmentation :ul
|
||||
|
||||
then the interaction between pairs of particles is likely to be more
|
||||
complex than the summation of simple sub-particle interactions. An
|
||||
example is contact or frictional forces between particles with planar
|
||||
surfaces that inter-penetrate.
|
||||
For these models, the interaction between pairs of particles is likely
|
||||
to be more complex than the summation of simple pairwise interactions.
|
||||
An example is contact or frictional forces between particles with
|
||||
planar surfaces that inter-penetrate. Likewise, the body particle may
|
||||
store internal state, such as a stress tensor used to compute a
|
||||
fracture criterion.
|
||||
|
||||
These are additional LAMMPS commands that can be used with body
|
||||
particles of different styles
|
||||
@ -130,7 +131,9 @@ x1 y1 z1
|
||||
...
|
||||
xN yN zN :pre
|
||||
|
||||
N is the number of sub-particles in the body particle. M = 6 + 3*N.
|
||||
where M = 6 + 3*N, and N is the number of sub-particles in the body
|
||||
particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
sub-particles (x1 to zN) as 3N values. These values can be listed on
|
||||
@ -148,8 +151,8 @@ center-of-mass position of the particle is specified by the x,y,z
|
||||
values in the {Atoms} section of the data file, as is the total mass
|
||||
of the body particle.
|
||||
|
||||
The "pair_style body"_pair_body.html command can be used with this
|
||||
body style to compute body/body and body/non-body interactions.
|
||||
The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
|
||||
with this body style to compute body/body and body/non-body interactions.
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
@ -175,15 +178,18 @@ The {bflag2} argument is ignored.
|
||||
|
||||
[Specifics of body style rounded/polygon:]
|
||||
|
||||
NOTE: Aug 2016 - This body style has not yet been added to LAMMPS.
|
||||
The info below is a placeholder.
|
||||
The {rounded/polygon} body style represents body particles as a 2d
|
||||
polygon with a variable number of N vertices. This style can only be
|
||||
used for 2d models; see the "boundary"_boundary.html command. See the
|
||||
"pair_style body/rounded/polygon" doc page for a diagram of two
|
||||
squares with rounded circles at the vertices. Special cases for N = 1
|
||||
(circle) and N = 2 (rod with rounded ends) can also be specified.
|
||||
|
||||
The {rounded/polygon} body style represents body particles as a convex
|
||||
polygon with a variable number N > 2 of vertices, which can only be
|
||||
used for 2d models. One example use of this body style is for 2d
|
||||
discrete element models, as described in "Fraige"_#Fraige. Similar to
|
||||
body style {nparticle}, the atom_style body command for this body
|
||||
style takes two additional arguments:
|
||||
One use of this body style is for 2d discrete element models, as
|
||||
described in "Fraige"_#body-Fraige.
|
||||
|
||||
Similar to body style {nparticle}, the atom_style body command for
|
||||
this body style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polygon Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
@ -203,17 +209,20 @@ x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
i j j k k ...
|
||||
radius :pre
|
||||
diameter :pre
|
||||
|
||||
N is the number of vertices in the body particle. M = 6 + 3*N + 2*N +
|
||||
1. The integer line has a single value N. The floating point line(s)
|
||||
where M = 6 + 3*N + 2*N + 1, and N is the number of vertices in the
|
||||
body particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
vertices (x1 to zN) as 3N values, followed by 2N vertex indices
|
||||
corresponding to the end points of the N edges, followed by a single
|
||||
radius value = the smallest circle encompassing the polygon. That
|
||||
last value is used to facilitate the body/body contact detection.
|
||||
These floating-point values can be listed on as many lines as you
|
||||
wish; see the "read_data"_read_data.html command for more details.
|
||||
vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
|
||||
2N vertex indices corresponding to the end points of the N edges,
|
||||
followed by a single diameter value = the rounded diameter of the
|
||||
circle that surrounds each vertex. The diameter value can be different
|
||||
for each body particle. These floating-point values can be listed on
|
||||
as many lines as you wish; see the "read_data"_read_data.html command
|
||||
for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
@ -225,8 +234,11 @@ from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a square
|
||||
particles whose edge length is sqrt(2):
|
||||
For example, the following information would specify a square particle
|
||||
whose edge length is sqrt(2) and rounded diameter is 1.0. The
|
||||
orientation of the square is aligned with the xy coordinate axes which
|
||||
is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
|
||||
1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
|
||||
|
||||
3 1 27
|
||||
4
|
||||
@ -235,12 +247,178 @@ particles whose edge length is sqrt(2):
|
||||
-0.7071 0.7071 0
|
||||
0.7071 0.7071 0
|
||||
0.7071 -0.7071 0
|
||||
0 1 1 2 2 3 3 0
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
3 0
|
||||
1.0 :pre
|
||||
|
||||
A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
1 1 13
|
||||
2
|
||||
1 1 1.33333 0 0 0
|
||||
-2 0 0
|
||||
2 0 0
|
||||
0.5 :pre
|
||||
|
||||
A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
|
||||
|
||||
1 1 10
|
||||
1
|
||||
1 1 4.5 0 0 0
|
||||
0 0 0
|
||||
3.0 :pre
|
||||
|
||||
The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html
|
||||
command can be used with this body style to compute body/body
|
||||
interactions.
|
||||
interactions. The "fix wall/body/polygon"_fix_wall_body_polygon.html
|
||||
command can be used with this body style to compute the interaction of
|
||||
body particles with a wall.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style rounded/polyhedron:]
|
||||
|
||||
The {rounded/polyhedron} body style represents body particles as a 3d
|
||||
polyhedron with a variable number of N vertices, E edges and F faces.
|
||||
This style can only be used for 3d models; see the
|
||||
"boundary"_boundary.html command. See the "pair_style
|
||||
body/rounded/polygon" doc page for a diagram of a two 2d squares with
|
||||
rounded circles at the vertices. A 3d cube with rounded spheres at
|
||||
the 8 vertices and 12 rounded edges would be similar. Special cases
|
||||
for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
|
||||
specified.
|
||||
|
||||
This body style is for 3d discrete element models, as described in
|
||||
"Wang"_#body-Wang.
|
||||
|
||||
Similar to body style {rounded/polygon}, the atom_style body command
|
||||
for this body style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polyhedron Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 3 M
|
||||
N E F
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
...
|
||||
0 1 2 -1
|
||||
0 2 3 -1
|
||||
...
|
||||
1 2 3 4
|
||||
diameter :pre
|
||||
|
||||
where M = 6 + 3*N + 2*E + 4*F + 1, and N is the number of vertices in
|
||||
the body particle, E = number of edges, F = number of faces.
|
||||
|
||||
The integer line has three values: number of vertices (N), number of
|
||||
edges (E) and number of faces (F). The floating point line(s) list 6
|
||||
moments of inertia followed by the coordinates of the N vertices (x1
|
||||
to zN) as 3N values, followed by 2N vertex indices corresponding to
|
||||
the end points of the E edges, then 4*F vertex indices defining F
|
||||
faces. The last value is the diameter value = the rounded diameter of
|
||||
the sphere that surrounds each vertex. The diameter value can be
|
||||
different for each body particle. These floating-point values can be
|
||||
listed on as many lines as you wish; see the
|
||||
"read_data"_read_data.html command for more details. Because the
|
||||
maxmimum vertices per face is hard-coded to be 4
|
||||
(i.e. quadrilaterals), faces with more than 4 vertices need to be
|
||||
split into triangles or quadrilaterals. For triangular faces, the
|
||||
last vertex index should be set to -1.
|
||||
|
||||
The ordering of the 4 vertices within a face should follow
|
||||
the right-hand rule so that the normal vector of the face points
|
||||
outwards from the center of mass.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a cubic particle
|
||||
whose edge length is 2.0 and rounded diameter is 0.5.
|
||||
The orientation of the cube is aligned with the xyz coordinate axes
|
||||
which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
|
||||
iyz = 0.667 0.667 0.667 0 0 0.
|
||||
|
||||
1 3 79
|
||||
8 12 6
|
||||
0.667 0.667 0.667 0 0 0
|
||||
1 1 1
|
||||
1 -1 1
|
||||
-1 -1 1
|
||||
-1 1 1
|
||||
1 1 -1
|
||||
1 -1 -1
|
||||
-1 -1 -1
|
||||
-1 1 -1
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
3 0
|
||||
4 5
|
||||
5 6
|
||||
6 7
|
||||
7 4
|
||||
0 4
|
||||
1 5
|
||||
2 6
|
||||
3 7
|
||||
0 1 2 3
|
||||
4 5 6 7
|
||||
0 1 5 4
|
||||
1 2 6 5
|
||||
2 3 7 6
|
||||
3 0 4 7
|
||||
0.5 :pre
|
||||
|
||||
A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
1 1 13
|
||||
2
|
||||
0 1.33333 1.33333 0 0 0
|
||||
-2 0 0
|
||||
2 0 0
|
||||
0.5 :pre
|
||||
|
||||
A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
|
||||
|
||||
1 1 10
|
||||
1
|
||||
0.9 0.9 0.9 0 0 0
|
||||
0 0 0
|
||||
3.0 :pre
|
||||
|
||||
The "pair_style
|
||||
body/rounded/polhedron"_pair_body_rounded_polyhedron.html command can
|
||||
be used with this body style to compute body/body interactions. The
|
||||
"fix wall/body/polyhedron"_fix_wall_body_polygon.html command can be
|
||||
used with this body style to compute the interaction of body particles
|
||||
with a wall.
|
||||
|
||||
:line
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
@ -257,10 +435,10 @@ the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a convex
|
||||
polygon consisting of N line segments. Note that the line segments
|
||||
are drawn between the N vertices, which does not correspond exactly to
|
||||
the physical extent of the body (because the "pair_style
|
||||
{body} keyword is set, then each body particle is drawn as a polygon
|
||||
consisting of N line segments. Note that the line segments are drawn
|
||||
between the N vertices, which does not correspond exactly to the
|
||||
physical extent of the body (because the "pair_style
|
||||
rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
|
||||
spheres at those point and the line segments between the spheres are
|
||||
tangent to the spheres). The drawn diameter of each line segment is
|
||||
@ -269,6 +447,10 @@ determined by the {bflag1} parameter for the {body} keyword. The
|
||||
|
||||
:line
|
||||
|
||||
:link(Fraige)
|
||||
:link(body-Fraige)
|
||||
[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
|
||||
Particuology, 6, 455 (2008).
|
||||
|
||||
:link(body-Wang)
|
||||
[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
|
||||
Matter, 13, 1 (2011).
|
||||
166
doc/src/Howto_chunk.txt
Normal file
@ -0,0 +1,166 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Use chunks to calculate system properties :h3
|
||||
|
||||
In LAMMS, "chunks" are collections of atoms, as defined by the
|
||||
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
|
||||
each atom to a chunk ID (or to no chunk at all). The number of chunks
|
||||
and the assignment of chunk IDs to atoms can be static or change over
|
||||
time. Examples of "chunks" are molecules or spatial bins or atoms
|
||||
with similar values (e.g. coordination number or potential energy).
|
||||
|
||||
The per-atom chunk IDs can be used as input to two other kinds of
|
||||
commands, to calculate various properties of a system:
|
||||
|
||||
"fix ave/chunk"_fix_ave_chunk.html
|
||||
any of the "compute */chunk"_compute.html commands :ul
|
||||
|
||||
Here, each of the 3 kinds of chunk-related commands is briefly
|
||||
overviewed. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
|
||||
Compute chunk/atom command: :h4
|
||||
|
||||
This compute can assign atoms to chunks of various styles. Only atoms
|
||||
in the specified group and optional specified region are assigned to a
|
||||
chunk. Here are some possible chunk definitions:
|
||||
|
||||
atoms in same molecule | chunk ID = molecule ID |
|
||||
atoms of same atom type | chunk ID = atom type |
|
||||
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
|
||||
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
|
||||
atoms in same spatial bin | chunk ID = bin ID |
|
||||
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
|
||||
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
|
||||
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
|
||||
|
||||
Note that chunk IDs are integer values, so for atom properties or
|
||||
computes that produce a floating point value, they will be truncated
|
||||
to an integer. You could also use the compute in a variable that
|
||||
scales the floating point value to spread it across multiple integers.
|
||||
|
||||
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
|
||||
This compute also calculates the number of chunks {Nchunk}, which is
|
||||
used by other commands to tally per-chunk data. {Nchunk} can be a
|
||||
static value or change over time (e.g. the number of clusters). The
|
||||
chunk ID for an individual atom can also be static (e.g. a molecule
|
||||
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
|
||||
|
||||
Note that this compute allows the per-atom output of other
|
||||
"computes"_compute.html, "fixes"_fix.html, and
|
||||
"variables"_variable.html to be used to define chunk IDs for each
|
||||
atom. This means you can write your own compute or fix to output a
|
||||
per-atom quantity to use as chunk ID. See the "Modify"_Modify.html
|
||||
doc pages for info on how to do this. You can also define a "per-atom
|
||||
variable"_variable.html in the input script that uses a formula to
|
||||
generate a chunk ID for each atom.
|
||||
|
||||
Fix ave/chunk command: :h4
|
||||
|
||||
This fix takes the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
|
||||
it then sums one or more specified per-atom values over the atoms in
|
||||
each chunk. The per-atom values can be any atom property, such as
|
||||
velocity, force, charge, potential energy, kinetic energy, stress,
|
||||
etc. Additional keywords are defined for per-chunk properties like
|
||||
density and temperature. More generally any per-atom value generated
|
||||
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
|
||||
variables"_variable.html, can be summed over atoms in each chunk.
|
||||
|
||||
Similar to other averaging fixes, this fix allows the summed per-chunk
|
||||
values to be time-averaged in various ways, and output to a file. The
|
||||
fix produces a global array as output with one row of values per
|
||||
chunk.
|
||||
|
||||
Compute */chunk commands: :h4
|
||||
|
||||
Currently the following computes operate on chunks of atoms to produce
|
||||
per-chunk values.
|
||||
|
||||
"compute com/chunk"_compute_com_chunk.html
|
||||
"compute gyration/chunk"_compute_gyration_chunk.html
|
||||
"compute inertia/chunk"_compute_inertia_chunk.html
|
||||
"compute msd/chunk"_compute_msd_chunk.html
|
||||
"compute property/chunk"_compute_property_chunk.html
|
||||
"compute temp/chunk"_compute_temp_chunk.html
|
||||
"compute torque/chunk"_compute_vcm_chunk.html
|
||||
"compute vcm/chunk"_compute_vcm_chunk.html :ul
|
||||
|
||||
They each take the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. As their names
|
||||
indicate, they calculate the center-of-mass, radius of gyration,
|
||||
moments of inertia, mean-squared displacement, temperature, torque,
|
||||
and velocity of center-of-mass for each chunk of atoms. The "compute
|
||||
property/chunk"_compute_property_chunk.html command can tally the
|
||||
count of atoms in each chunk and extract other per-chunk properties.
|
||||
|
||||
The reason these various calculations are not part of the "fix
|
||||
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
|
||||
complicated operation than simply summing and averaging over per-atom
|
||||
values in each chunk. For example, many of them require calculation
|
||||
of a center of mass, which requires summing mass*position over the
|
||||
atoms and then dividing by summed mass.
|
||||
|
||||
All of these computes produce a global vector or global array as
|
||||
output, wih one or more values per chunk. They can be used
|
||||
in various ways:
|
||||
|
||||
As input to the "fix ave/time"_fix_ave_time.html command, which can
|
||||
write the values to a file and optionally time average them. :ulb,l
|
||||
|
||||
As input to the "fix ave/histo"_fix_ave_histo.html command to
|
||||
histogram values across chunks. E.g. a histogram of cluster sizes or
|
||||
molecule diffusion rates. :l
|
||||
|
||||
As input to special functions of "equal-style
|
||||
variables"_variable.html, like sum() and max(). E.g. to find the
|
||||
largest cluster or fastest diffusing molecule. :l
|
||||
:ule
|
||||
|
||||
Example calculations with chunks :h4
|
||||
|
||||
Here are examples using chunk commands to calculate various
|
||||
properties:
|
||||
|
||||
(1) Average velocity in each of 1000 2d spatial bins:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
|
||||
|
||||
(2) Temperature in each spatial bin, after subtracting a flow
|
||||
velocity:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
|
||||
compute vbias all temp/profile 1 0 0 y 10
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
|
||||
|
||||
(3) Center of mass of each molecule:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
|
||||
|
||||
(4) Total force on each molecule and ave/max across all molecules:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
|
||||
variable xave equal ave(f_1\[2\])
|
||||
variable xmax equal max(f_1\[2\])
|
||||
thermo 1000
|
||||
thermo_style custom step temp v_xave v_xmax :pre
|
||||
|
||||
(5) Histogram of cluster sizes:
|
||||
|
||||
compute cluster all cluster/atom 1.0
|
||||
compute cc1 all chunk/atom c_cluster compress yes
|
||||
compute size all property/chunk cc1 count
|
||||
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
|
||||
253
doc/src/Howto_coreshell.txt
Normal file
@ -0,0 +1,253 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Adiabatic core/shell model :h3
|
||||
|
||||
The adiabatic core-shell model by "Mitchell and
|
||||
Fincham"_#MitchellFincham is a simple method for adding polarizability
|
||||
to a system. In order to mimic the electron shell of an ion, a
|
||||
satellite particle is attached to it. This way the ions are split into
|
||||
a core and a shell where the latter is meant to react to the
|
||||
electrostatic environment inducing polarizability. See the "Howto
|
||||
polarizable"_Howto_polarizable.html doc page for a discussion of all
|
||||
the polarizable models available in LAMMPS.
|
||||
|
||||
Technically, shells are attached to the cores by a spring force f =
|
||||
k*r where k is a parametrized spring constant and r is the distance
|
||||
between the core and the shell. The charges of the core and the shell
|
||||
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
|
||||
setup introduces the ion polarizability (alpha) given by
|
||||
alpha = q(shell)^2 / k. In a
|
||||
similar fashion the mass of the ion is distributed on the core and the
|
||||
shell with the core having the larger mass.
|
||||
|
||||
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
|
||||
be used since atom charge and bonds are needed. Each kind of
|
||||
core/shell pair requires two atom types and a bond type. The core and
|
||||
shell of a core/shell pair should be bonded to each other with a
|
||||
harmonic bond that provides the spring force. For example, a data file
|
||||
for NaCl, as found in examples/coreshell, has this format:
|
||||
|
||||
432 atoms # core and shell atoms
|
||||
216 bonds # number of core/shell springs :pre
|
||||
|
||||
4 atom types # 2 cores and 2 shells for Na and Cl
|
||||
2 bond types :pre
|
||||
|
||||
0.0 24.09597 xlo xhi
|
||||
0.0 24.09597 ylo yhi
|
||||
0.0 24.09597 zlo zhi :pre
|
||||
|
||||
Masses # core/shell mass ratio = 0.1 :pre
|
||||
|
||||
1 20.690784 # Na core
|
||||
2 31.90500 # Cl core
|
||||
3 2.298976 # Na shell
|
||||
4 3.54500 # Cl shell :pre
|
||||
|
||||
Atoms :pre
|
||||
|
||||
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
|
||||
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
|
||||
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
|
||||
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Bonds # Bond topology for spring forces :pre
|
||||
|
||||
1 2 1 2 # spring for core/shell pair 1
|
||||
2 2 3 4 # spring for core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
|
||||
defined between the shells. Coulombic interactions are defined
|
||||
between all cores and shells. If desired, additional bonds can be
|
||||
specified between cores.
|
||||
|
||||
The "special_bonds"_special_bonds.html command should be used to
|
||||
turn-off the Coulombic interaction within core/shell pairs, since that
|
||||
interaction is set by the bond spring. This is done using the
|
||||
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
|
||||
which is the default value. It needs to be considered whether one has
|
||||
to adjust the "special_bonds"_special_bonds.html weighting according
|
||||
to the molecular topology since the interactions of the shells are
|
||||
bypassed over an extra bond.
|
||||
|
||||
Note that this core/shell implementation does not require all ions to
|
||||
be polarized. One can mix core/shell pairs and ions without a
|
||||
satellite particle if desired.
|
||||
|
||||
Since the core/shell model permits distances of r = 0.0 between the
|
||||
core and shell, a pair style with a "cs" suffix needs to be used to
|
||||
implement a valid long-range Coulombic correction. Several such pair
|
||||
styles are provided in the CORESHELL package. See "this doc
|
||||
page"_pair_cs.html for details. All of the core/shell enabled pair
|
||||
styles require the use of a long-range Coulombic solver, as specified
|
||||
by the "kspace_style"_kspace_style.html command. Either the PPPM or
|
||||
Ewald solvers can be used.
|
||||
|
||||
For the NaCL example problem, these pair style and bond style settings
|
||||
are used:
|
||||
|
||||
pair_style born/coul/long/cs 20.0 20.0
|
||||
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
|
||||
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
|
||||
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
|
||||
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
|
||||
|
||||
bond_style harmonic
|
||||
bond_coeff 1 63.014 0.0
|
||||
bond_coeff 2 25.724 0.0 :pre
|
||||
|
||||
When running dynamics with the adiabatic core/shell model, the
|
||||
following issues should be considered. The relative motion of
|
||||
the core and shell particles corresponds to the polarization,
|
||||
hereby an instantaneous relaxation of the shells is approximated
|
||||
and a fast core/shell spring frequency ensures a nearly constant
|
||||
internal kinetic energy during the simulation.
|
||||
Thermostats can alter this polarization behaviour, by scaling the
|
||||
internal kinetic energy, meaning the shell will not react freely to
|
||||
its electrostatic environment.
|
||||
Therefore it is typically desirable to decouple the relative motion of
|
||||
the core/shell pair, which is an imaginary degree of freedom, from the
|
||||
real physical system. To do that, the "compute
|
||||
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
|
||||
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
|
||||
langevin"_fix_langevin.html. This compute uses the center-of-mass velocity
|
||||
of the core/shell pairs to calculate a temperature, and insures that
|
||||
velocity is what is rescaled for thermostatting purposes. This
|
||||
compute also works for a system with both core/shell pairs and
|
||||
non-polarized ions (ions without an attached satellite particle). The
|
||||
"compute temp/cs"_compute_temp_cs.html command requires input of two
|
||||
groups, one for the core atoms, another for the shell atoms.
|
||||
Non-polarized ions which might also be included in the treated system
|
||||
should not be included into either of these groups, they are taken
|
||||
into account by the {group-ID} (2nd argument) of the compute. The
|
||||
groups can be defined using the "group {type}"_group.html command.
|
||||
Note that to perform thermostatting using this definition of
|
||||
temperature, the "fix modify temp"_fix_modify.html command should be
|
||||
used to assign the compute to the thermostat fix. Likewise the
|
||||
"thermo_modify temp"_thermo_modify.html command can be used to make
|
||||
this temperature be output for the overall system.
|
||||
|
||||
For the NaCl example, this can be done as follows:
|
||||
|
||||
group cores type 1 2
|
||||
group shells type 3 4
|
||||
compute CSequ all temp/cs cores shells
|
||||
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
|
||||
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
|
||||
fix_modify thermoberendsen temp CSequ
|
||||
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
|
||||
|
||||
The pressure for the core/shell system is computed via the regular
|
||||
LAMMPS convention by "treating the cores and shells as individual
|
||||
particles"_#MitchellFincham2. For the thermo output of the pressure
|
||||
as well as for the application of a barostat, it is necessary to
|
||||
use an additional "pressure"_compute_pressure.html compute based on
|
||||
the default "temperature"_compute_temp.html and specifying it as a
|
||||
second argument in "fix modify"_fix_modify.html and
|
||||
"thermo_modify"_thermo_modify.html resulting in:
|
||||
|
||||
(...)
|
||||
compute CSequ all temp/cs cores shells
|
||||
compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
|
||||
thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
|
||||
fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
|
||||
fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
|
||||
|
||||
If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
|
||||
relative motion of the core and the shell should in theory be
|
||||
stable. However numerical fluctuation can introduce a small
|
||||
momentum to the system, which is noticable over long trajectories.
|
||||
Therefore it is recommendable to use the "fix
|
||||
momentum"_fix_momentum.html command in combination with "compute
|
||||
temp/cs"_compute_temp_cs.html when equilibrating the system to
|
||||
prevent any drift.
|
||||
|
||||
When initializing the velocities of a system with core/shell pairs, it
|
||||
is also desirable to not introduce energy into the relative motion of
|
||||
the core/shell particles, but only assign a center-of-mass velocity to
|
||||
the pairs. This can be done by using the {bias} keyword of the
|
||||
"velocity create"_velocity.html command and assigning the "compute
|
||||
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
|
||||
"velocity"_velocity.html command, e.g.
|
||||
|
||||
velocity all create 1427 134 bias yes temp CSequ
|
||||
velocity all scale 1427 temp CSequ :pre
|
||||
|
||||
To maintain the correct polarizability of the core/shell pairs, the
|
||||
kinetic energy of the internal motion shall remain nearly constant.
|
||||
Therefore the choice of spring force and mass ratio need to ensure
|
||||
much faster relative motion of the 2 atoms within the core/shell pair
|
||||
than their center-of-mass velocity. This allows the shells to
|
||||
effectively react instantaneously to the electrostatic environment and
|
||||
limits energy transfer to or from the core/shell oscillators.
|
||||
This fast movement also dictates the timestep that can be used.
|
||||
|
||||
The primary literature of the adiabatic core/shell model suggests that
|
||||
the fast relative motion of the core/shell pairs only allows negligible
|
||||
energy transfer to the environment.
|
||||
The mentioned energy transfer will typically lead to a small drift
|
||||
in total energy over time. This internal energy can be monitored
|
||||
using the "compute chunk/atom"_compute_chunk_atom.html and "compute
|
||||
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
|
||||
energies of each core/shell pair can then be summed using the sum()
|
||||
special function of the "variable"_variable.html command. Or they can
|
||||
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
|
||||
command. To use these commands, each core/shell pair must be defined
|
||||
as a "chunk". If each core/shell pair is defined as its own molecule,
|
||||
the molecule ID can be used to define the chunks. If cores are bonded
|
||||
to each other to form larger molecules, the chunks can be identified
|
||||
by the "fix property/atom"_fix_property_atom.html via assigning a
|
||||
core/shell ID to each atom using a special field in the data file read
|
||||
by the "read_data"_read_data.html command. This field can then be
|
||||
accessed by the "compute property/atom"_compute_property_atom.html
|
||||
command, to use as input to the "compute
|
||||
chunk/atom"_compute_chunk_atom.html command to define the core/shell
|
||||
pairs as chunks.
|
||||
|
||||
For example if core/shell pairs are the only molecules:
|
||||
|
||||
read_data NaCl_CS_x0.1_prop.data
|
||||
compute prop all property/atom molecule
|
||||
compute cs_chunk all chunk/atom c_prop
|
||||
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
|
||||
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
|
||||
|
||||
For example if core/shell pairs and other molecules are present:
|
||||
|
||||
fix csinfo all property/atom i_CSID # property/atom command
|
||||
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
|
||||
compute prop all property/atom i_CSID
|
||||
(...) :pre
|
||||
|
||||
The additional section in the date file would be formatted like this:
|
||||
|
||||
CS-Info # header of additional section :pre
|
||||
|
||||
1 1 # column 1 = atom ID, column 2 = core/shell ID
|
||||
2 1
|
||||
3 2
|
||||
4 2
|
||||
5 3
|
||||
6 3
|
||||
7 4
|
||||
8 4
|
||||
(...) :pre
|
||||
|
||||
:line
|
||||
|
||||
:link(MitchellFincham)
|
||||
[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
|
||||
5, 1031-1038 (1993).
|
||||
|
||||
:link(MitchellFincham2)
|
||||
[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
|
||||
6, 393-404 (1994).
|
||||
104
doc/src/Howto_couple.txt
Normal file
@ -0,0 +1,104 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Coupling LAMMPS to other codes :h3
|
||||
|
||||
LAMMPS is designed to allow it to be coupled to other codes. For
|
||||
example, a quantum mechanics code might compute forces on a subset of
|
||||
atoms and pass those forces to LAMMPS. Or a continuum finite element
|
||||
(FE) simulation might use atom positions as boundary conditions on FE
|
||||
nodal points, compute a FE solution, and return interpolated forces on
|
||||
MD atoms.
|
||||
|
||||
LAMMPS can be coupled to other codes in at least 3 ways. Each has
|
||||
advantages and disadvantages, which you'll have to think about in the
|
||||
context of your application.
|
||||
|
||||
(1) Define a new "fix"_fix.html command that calls the other code. In
|
||||
this scenario, LAMMPS is the driver code. During its timestepping,
|
||||
the fix is invoked, and can make library calls to the other code,
|
||||
which has been linked to LAMMPS as a library. This is the way the
|
||||
"POEMS"_poems package that performs constrained rigid-body motion on
|
||||
groups of atoms is hooked to LAMMPS. See the "fix
|
||||
poems"_fix_poems.html command for more details. See the
|
||||
"Modify"_Modify.html doc pages for info on how to add a new fix to
|
||||
LAMMPS.
|
||||
|
||||
:link(poems,http://www.rpi.edu/~anderk5/lab)
|
||||
|
||||
(2) Define a new LAMMPS command that calls the other code. This is
|
||||
conceptually similar to method (1), but in this case LAMMPS and the
|
||||
other code are on a more equal footing. Note that now the other code
|
||||
is not called during the timestepping of a LAMMPS run, but between
|
||||
runs. The LAMMPS input script can be used to alternate LAMMPS runs
|
||||
with calls to the other code, invoked via the new command. The
|
||||
"run"_run.html command facilitates this with its {every} option, which
|
||||
makes it easy to run a few steps, invoke the command, run a few steps,
|
||||
invoke the command, etc.
|
||||
|
||||
In this scenario, the other code can be called as a library, as in
|
||||
(1), or it could be a stand-alone code, invoked by a system() call
|
||||
made by the command (assuming your parallel machine allows one or more
|
||||
processors to start up another program). In the latter case the
|
||||
stand-alone code could communicate with LAMMPS thru files that the
|
||||
command writes and reads.
|
||||
|
||||
See the "Modify command"_Modify_command.html doc page for info on how
|
||||
to add a new command to LAMMPS.
|
||||
|
||||
(3) Use LAMMPS as a library called by another code. In this case the
|
||||
other code is the driver and calls LAMMPS as needed. Or a wrapper
|
||||
code could link and call both LAMMPS and another code as libraries.
|
||||
Again, the "run"_run.html command has options that allow it to be
|
||||
invoked with minimal overhead (no setup or clean-up) if you wish to do
|
||||
multiple short runs, driven by another program.
|
||||
|
||||
Examples of driver codes that call LAMMPS as a library are included in
|
||||
the examples/COUPLE directory of the LAMMPS distribution; see
|
||||
examples/COUPLE/README for more details:
|
||||
|
||||
simple: simple driver programs in C++ and C which invoke LAMMPS as a
|
||||
library :ulb,l
|
||||
|
||||
lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
|
||||
MD with quantum forces calculated by a density functional code :l
|
||||
|
||||
lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
|
||||
a kinetic Monte Carlo model for grain growth using MD to calculate
|
||||
strain induced across grain boundaries :l
|
||||
:ule
|
||||
|
||||
:link(quest,http://dft.sandia.gov/Quest)
|
||||
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
|
||||
|
||||
The "Build basics"_Build_basics.html doc page describes how to build
|
||||
LAMMPS as a library. Once this is done, you can interface with LAMMPS
|
||||
either via C++, C, Fortran, or Python (or any other language that
|
||||
supports a vanilla C-like interface). For example, from C++ you could
|
||||
create one (or more) "instances" of LAMMPS, pass it an input script to
|
||||
process, or execute individual commands, all by invoking the correct
|
||||
class methods in LAMMPS. From C or Fortran you can make function
|
||||
calls to do the same things. See the "Python"_Python_head.html doc
|
||||
pages for a description of the Python wrapper provided with LAMMPS
|
||||
that operates through the LAMMPS library interface.
|
||||
|
||||
The files src/library.cpp and library.h contain the C-style interface
|
||||
to LAMMPS. See the "Howto library"_Howto_library.html doc page for a
|
||||
description of the interface and how to extend it for your needs.
|
||||
|
||||
Note that the lammps_open() function that creates an instance of
|
||||
LAMMPS takes an MPI communicator as an argument. This means that
|
||||
instance of LAMMPS will run on the set of processors in the
|
||||
communicator. Thus the calling code can run LAMMPS on all or a subset
|
||||
of processors. For example, a wrapper script might decide to
|
||||
alternate between LAMMPS and another code, allowing them both to run
|
||||
on all the processors. Or it might allocate half the processors to
|
||||
LAMMPS and half to the other code and run both codes simultaneously
|
||||
before syncing them up periodically. Or it might instantiate multiple
|
||||
instances of LAMMPS to perform different calculations.
|
||||
31
doc/src/Howto_diffusion.txt
Normal file
@ -0,0 +1,31 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate diffusion coefficients :h3
|
||||
|
||||
The diffusion coefficient D of a material can be measured in at least
|
||||
2 ways using various options in LAMMPS. See the examples/DIFFUSE
|
||||
directory for scripts that implement the 2 methods discussed here for
|
||||
a simple Lennard-Jones fluid model.
|
||||
|
||||
The first method is to measure the mean-squared displacement (MSD) of
|
||||
the system, via the "compute msd"_compute_msd.html command. The slope
|
||||
of the MSD versus time is proportional to the diffusion coefficient.
|
||||
The instantaneous MSD values can be accumulated in a vector via the
|
||||
"fix vector"_fix_vector.html command, and a line fit to the vector to
|
||||
compute its slope via the "variable slope"_variable.html function, and
|
||||
thus extract D.
|
||||
|
||||
The second method is to measure the velocity auto-correlation function
|
||||
(VACF) of the system, via the "compute vacf"_compute_vacf.html
|
||||
command. The time-integral of the VACF is proportional to the
|
||||
diffusion coefficient. The instantaneous VACF values can be
|
||||
accumulated in a vector via the "fix vector"_fix_vector.html command,
|
||||
and time integrated via the "variable trap"_variable.html function,
|
||||
and thus extract D.
|
||||
108
doc/src/Howto_dispersion.txt
Normal file
@ -0,0 +1,108 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Long-range dispersion settings :h3
|
||||
|
||||
The PPPM method computes interactions by splitting the pair potential
|
||||
into two parts, one of which is computed in a normal pairwise fashion,
|
||||
the so-called real-space part, and one of which is computed using the
|
||||
Fourier transform, the so called reciprocal-space or kspace part. For
|
||||
both parts, the potential is not computed exactly but is approximated.
|
||||
Thus, there is an error in both parts of the computation, the
|
||||
real-space and the kspace error. The just mentioned facts are true
|
||||
both for the PPPM for Coulomb as well as dispersion interactions. The
|
||||
deciding difference - and also the reason why the parameters for
|
||||
pppm/disp have to be selected with more care - is the impact of the
|
||||
errors on the results: The kspace error of the PPPM for Coulomb and
|
||||
dispersion interaction and the real-space error of the PPPM for
|
||||
Coulomb interaction have the character of noise. In contrast, the
|
||||
real-space error of the PPPM for dispersion has a clear physical
|
||||
interpretation: the underprediction of cohesion. As a consequence, the
|
||||
real-space error has a much stronger effect than the kspace error on
|
||||
simulation results for pppm/disp. Parameters must thus be chosen in a
|
||||
way that this error is much smaller than the kspace error.
|
||||
|
||||
When using pppm/disp and not making any specifications on the PPPM
|
||||
parameters via the kspace modify command, parameters will be tuned
|
||||
such that the real-space error and the kspace error are equal. This
|
||||
will result in simulations that are either inaccurate or slow, both of
|
||||
which is not desirable. For selecting parameters for the pppm/disp
|
||||
that provide fast and accurate simulations, there are two approaches,
|
||||
which both have their up- and downsides.
|
||||
|
||||
The first approach is to set desired real-space an kspace accuracies
|
||||
via the {kspace_modify force/disp/real} and {kspace_modify
|
||||
force/disp/kspace} commands. Note that the accuracies have to be
|
||||
specified in force units and are thus dependent on the chosen unit
|
||||
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
|
||||
accurate and efficient computations for the real-space and kspace
|
||||
accuracies. 0.002 and 0.05 work well for most systems using lj
|
||||
units. PPPM parameters will be generated based on the desired
|
||||
accuracies. The upside of this approach is that it usually provides a
|
||||
good set of parameters and will work for both the {kspace_modify diff
|
||||
ad} and {kspace_modify diff ik} options. The downside of the method
|
||||
is that setting the PPPM parameters will take some time during the
|
||||
initialization of the simulation.
|
||||
|
||||
The second approach is to set the parameters for the pppm/disp
|
||||
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
|
||||
order/disp}, and {kspace_modify gewald/disp} commands. This approach
|
||||
requires a more experienced user who understands well the impact of
|
||||
the choice of parameters on the simulation accuracy and
|
||||
performance. This approach provides a fast initialization of the
|
||||
simulation. However, it is sensitive to errors: A combination of
|
||||
parameters that will perform well for one system might result in
|
||||
far-from-optimal conditions for other simulations. For example,
|
||||
parameters that provide accurate and fast computations for
|
||||
all-atomistic force fields can provide insufficient accuracy or
|
||||
united-atomistic force fields (which is related to that the latter
|
||||
typically have larger dispersion coefficients).
|
||||
|
||||
To avoid inaccurate or inefficient simulations, the pppm/disp stops
|
||||
simulations with an error message if no action is taken to control the
|
||||
PPPM parameters. If the automatic parameter generation is desired and
|
||||
real-space and kspace accuracies are desired to be equal, this error
|
||||
message can be suppressed using the {kspace_modify disp/auto yes}
|
||||
command.
|
||||
|
||||
A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the {kspace_modify force/disp/real} and
|
||||
{kspace_modify force/disp/kspace} commands, write down the PPPM
|
||||
parameters from the outut, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
||||
Concerning the performance of the pppm/disp there are two more things
|
||||
to consider. The first is that when using the pppm/disp, the cutoff
|
||||
parameter does no longer affect the accuracy of the simulation
|
||||
(subject to that gewald/disp is adjusted when changing the cutoff).
|
||||
The performance can thus be increased by examining different values
|
||||
for the cutoff parameter. A lower bound for the cutoff is only set by
|
||||
the truncation error of the repulsive term of pair potentials.
|
||||
|
||||
The second is that the mixing rule of the pair style has an impact on
|
||||
the computation time when using the pppm/disp. Fastest computations
|
||||
are achieved when using the geometric mixing rule. Using the
|
||||
arithmetic mixing rule substantially increases the computational cost.
|
||||
The computational overhead can be reduced using the {kspace_modify
|
||||
mix/disp geom} and {kspace_modify splittol} commands. The first
|
||||
command simply enforces geometric mixing of the dispersion
|
||||
coefficients in kspace computations. This introduces some error in
|
||||
the computations but will also significantly speed-up the
|
||||
simulations. The second keyword sets the accuracy with which the
|
||||
dispersion coefficients are approximated using a matrix factorization
|
||||
approach. This may result in better accuracy then using the first
|
||||
command, but will usually also not provide an equally good increase of
|
||||
efficiency.
|
||||
|
||||
Finally, pppm/disp can also be used when no mixing rules apply.
|
||||
This can be achieved using the {kspace_modify mix/disp none} command.
|
||||
Note that the code does not check automatically whether any mixing
|
||||
rule is fulfilled. If mixing rules do not apply, the user will have
|
||||
to specify this command explicitly.
|
||||
77
doc/src/Howto_drude.txt
Normal file
@ -0,0 +1,77 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Drude induced dipoles :h3
|
||||
|
||||
The thermalized Drude model represents induced dipoles by a pair of
|
||||
charges (the core atom and the Drude particle) connected by a harmonic
|
||||
spring. See the "Howto polarizable"_Howto_polarizable.html doc page
|
||||
for a discussion of all the polarizable models available in LAMMPS.
|
||||
|
||||
The Drude model has a number of features aimed at its use in
|
||||
molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
|
||||
|
||||
Thermostating of the additional degrees of freedom associated with the
|
||||
induced dipoles at very low temperature, in terms of the reduced
|
||||
coordinates of the Drude particles with respect to their cores. This
|
||||
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
|
||||
|
||||
Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
|
||||
pair represents a single (polarizable) atom, so the special screening
|
||||
factors in a covalent structure should be the same for the core and
|
||||
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
|
||||
special neighbor relations from their respective cores. :l
|
||||
|
||||
Stabilization of the interactions between induced dipoles. Drude
|
||||
dipoles on covalently bonded atoms interact too strongly due to the
|
||||
short distances, so an atom may capture the Drude particle of a
|
||||
neighbor, or the induced dipoles within the same molecule may align
|
||||
too much. To avoid this, damping at short range can be done by Thole
|
||||
functions (for which there are physical grounds). This Thole damping
|
||||
is applied to the point charges composing the induced dipole (the
|
||||
charge of the Drude particle and the opposite charge on the core, not
|
||||
to the total charge of the core atom). :l,ule
|
||||
|
||||
A detailed tutorial covering the usage of Drude induced dipoles in
|
||||
LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
|
||||
|
||||
As with the core-shell model, the cores and Drude particles should
|
||||
appear in the data file as standard atoms. The same holds for the
|
||||
springs between them, which are described by standard harmonic bonds.
|
||||
The nature of the atoms (core, Drude particle or non-polarizable) is
|
||||
specified via the "fix drude"_fix_drude.html command. The special
|
||||
list of neighbors is automatically refactored to account for the
|
||||
equivalence of core and Drude particles as regards special 1-2 to 1-4
|
||||
screening. It may be necessary to use the {extra/special/per/atom}
|
||||
keyword of the "read_data"_read_data.html command. If using "fix
|
||||
shake"_fix_shake.html, make sure no Drude particle is in this fix
|
||||
group.
|
||||
|
||||
There are two ways to thermostat the Drude particles at a low
|
||||
temperature: use either "fix langevin/drude"_fix_langevin_drude.html
|
||||
for a Langevin thermostat, or "fix
|
||||
drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
|
||||
thermostat. The former requires use of the command "comm_modify vel
|
||||
yes"_comm_modify.html. The latter requires two separate integration
|
||||
fixes like {nvt} or {npt}. The correct temperatures of the reduced
|
||||
degrees of freedom can be calculated using the "compute
|
||||
temp/drude"_compute_temp_drude.html. This requires also to use the
|
||||
command {comm_modify vel yes}.
|
||||
|
||||
Short-range damping of the induced dipole interactions can be achieved
|
||||
using Thole functions through the "pair style
|
||||
thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
|
||||
with a Coulomb pair style. It may be useful to use {coul/long/cs} or
|
||||
similar from the CORESHELL package if the core and Drude particle come
|
||||
too close, which can cause numerical issues.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Lamoureux)
|
||||
[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
|
||||
@ -9,7 +9,7 @@
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
47
doc/src/Howto_elastic.txt
Normal file
@ -0,0 +1,47 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate elastic constants :h3
|
||||
|
||||
Elastic constants characterize the stiffness of a material. The formal
|
||||
definition is provided by the linear relation that holds between the
|
||||
stress and strain tensors in the limit of infinitesimal deformation.
|
||||
In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
|
||||
the repeated indices imply summation. s_ij are the elements of the
|
||||
symmetric stress tensor. e_kl are the elements of the symmetric strain
|
||||
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
|
||||
constants. In three dimensions, this tensor has 3^4=81 elements. Using
|
||||
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
|
||||
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
|
||||
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
|
||||
most 7*6/2 = 21 distinct elements.
|
||||
|
||||
At zero temperature, it is easy to estimate these derivatives by
|
||||
deforming the simulation box in one of the six directions using the
|
||||
"change_box"_change_box.html command and measuring the change in the
|
||||
stress tensor. A general-purpose script that does this is given in the
|
||||
examples/elastic directory described on the "Examples"_Examples.html
|
||||
doc page.
|
||||
|
||||
Calculating elastic constants at finite temperature is more
|
||||
challenging, because it is necessary to run a simulation that perfoms
|
||||
time averages of differential properties. One way to do this is to
|
||||
measure the change in average stress tensor in an NVT simulations when
|
||||
the cell volume undergoes a finite deformation. In order to balance
|
||||
the systematic and statistical errors in this method, the magnitude of
|
||||
the deformation must be chosen judiciously, and care must be taken to
|
||||
fully equilibrate the deformed cell before sampling the stress
|
||||
tensor. Another approach is to sample the triclinic cell fluctuations
|
||||
that occur in an NPT simulation. This method can also be slow to
|
||||
converge and requires careful post-processing "(Shinoda)"_#Shinoda1
|
||||
|
||||
:line
|
||||
|
||||
:link(Shinoda1)
|
||||
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
@ -26,7 +26,7 @@ work required by the LAMMPS developers. Consequently, creating a pull
|
||||
request will increase your chances to have your contribution included
|
||||
and will reduce the time until the integration is complete. For more
|
||||
information on the requirements to have your code included into LAMMPS
|
||||
please see "Section 10.15"_Section_modify.html#mod_15
|
||||
please see the "Modify contribute"_Modify_contribute.html doc page.
|
||||
|
||||
:line
|
||||
|
||||
@ -124,7 +124,7 @@ unrelated feature, you should switch branches!
|
||||
|
||||
After everything is done, add the files to the branch and commit them:
|
||||
|
||||
$ git add doc/src/tutorial_github.txt
|
||||
$ git add doc/src/Howto_github.txt
|
||||
$ git add doc/src/JPG/tutorial*.png :pre
|
||||
|
||||
IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}). The -a
|
||||
@ -318,7 +318,7 @@ Because the changes are OK with us, we are going to merge by clicking on
|
||||
Now, since in the meantime our local text for the tutorial also changed,
|
||||
we need to pull Axel's change back into our branch, and merge them:
|
||||
|
||||
$ git add tutorial_github.txt
|
||||
$ git add Howto_github.txt
|
||||
$ git add JPG/tutorial_reverse_pull_request*.png
|
||||
$ git commit -m "Updated text and images on reverse pull requests"
|
||||
$ git pull :pre
|
||||
@ -331,7 +331,7 @@ With Axel's changes merged in and some final text updates, our feature
|
||||
branch is now perfect as far as we are concerned, so we are going to
|
||||
commit and push again:
|
||||
|
||||
$ git add tutorial_github.txt
|
||||
$ git add Howto_github.txt
|
||||
$ git add JPG/tutorial_reverse_pull_request6.png
|
||||
$ git commit -m "Merged Axel's suggestions and updated text"
|
||||
$ git push git@github.com:Pakketeretet2/lammps :pre
|
||||
57
doc/src/Howto_granular.txt
Normal file
@ -0,0 +1,57 @@
|
||||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Granular models :h3
|
||||
|
||||
Granular system are composed of spherical particles with a diameter,
|
||||
as opposed to point particles. This means they have an angular
|
||||
velocity and torque can be imparted to them to cause them to rotate.
|
||||
|
||||
To run a simulation of a granular model, you will want to use
|
||||
the following commands:
|
||||
|
||||
"atom_style sphere"_atom_style.html
|
||||
"fix nve/sphere"_fix_nve_sphere.html
|
||||
"fix gravity"_fix_gravity.html :ul
|
||||
|
||||
This compute
|
||||
|
||||
"compute erotate/sphere"_compute_erotate_sphere.html :ul
|
||||
|
||||
calculates rotational kinetic energy which can be "output with
|
||||
thermodynamic info"_Howto_output.html.
|
||||
|
||||
Use one of these 3 pair potentials, which compute forces and torques
|
||||
between interacting pairs of particles:
|
||||
|
||||
"pair_style"_pair_style.html gran/history
|
||||
"pair_style"_pair_style.html gran/no_history
|
||||
"pair_style"_pair_style.html gran/hertzian :ul
|
||||
|
||||
These commands implement fix options specific to granular systems:
|
||||
|
||||
"fix freeze"_fix_freeze.html
|
||||
"fix pour"_fix_pour.html
|
||||
"fix viscous"_fix_viscous.html
|
||||
"fix wall/gran"_fix_wall_gran.html :ul
|
||||
|
||||
The fix style {freeze} zeroes both the force and torque of frozen
|
||||
atoms, and should be used for granular system instead of the fix style
|
||||
{setforce}.
|
||||
|
||||
For computational efficiency, you can eliminate needless pairwise
|
||||
computations between frozen atoms by using this command:
|
||||
|
||||
"neigh_modify"_neigh_modify.html exclude :ul
|
||||
|
||||
NOTE: By default, for 2d systems, granular particles are still modeled
|
||||
as 3d spheres, not 2d discs (circles), meaning their moment of inertia
|
||||
will be the same as in 3d. If you wish to model granular particles in
|
||||
2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d.html
|
||||
doc page, where 2d simulations are discussed.
|
||||