하드웨어 편집기
OghmaNano를 포함한 모든 컴퓨터 프로그램은 물리적 컴퓨팅 하드웨어에서 실행됩니다. 어떤 컴퓨터든 하드웨어 조합은 매우 다양할 수 있으며, 어떤 컴퓨터는 많은 수의 CPU 코어를 가지고 있고 다른 컴퓨터는 하나만 가집니다. 마찬가지로 컴퓨터마다 메모리, 하드 디스크 공간 및 GPU의 양이 다릅니다. 사용자가 OghmaNano를 최대한 활용할 수 있도록 OghmaNano가 특정 컴퓨터에서 어떻게 동작할지를 구성할 수 있는 하드웨어 편집기가 있습니다. 이는 simulation tab window를 통해 접근할 수 있습니다 (??).
이를 클릭하면 하드웨어 편집기 창이 열립니다 (??).
하드웨어 창은 사용자가 구성을 편집하고 또한 자신의 장치를 벤치마크할 수 있도록 하는 다양한 탭으로 구성되어 있습니다.
CPU/GPU 구성 탭
이 탭은 OghmaNano가 GPU 및 CPU와 어떻게 상호작용하는지 구성하는 데 사용되며 아래 표에 설명되어 있습니다. 이 매뉴얼의 다른 부분에서 자세히 설명했듯이 OghmaNano는 두 부분으로 이루어져 있습니다. 계산 백엔드인 oghma_core.exe와 그래픽 사용자 인터페이스인 oghma_gui.exe입니다. 모델의 이 두 부분이 어떻게 동작하는지 여기서 미세 조정할 수 있습니다.
- 백엔드에서 사용하는 스레드 수: 이것은 OghmaNano oghma_core.exe가 사용할 수 있는 최대 스레드 수입니다. 이는 다음을 결정합니다: 동시에 실행 가능한 fit의 수; 동시에 실행 가능한 optimization simulation의 최대 수; FDTD 시뮬레이션에 사용되는 최대 스레드 수; 동시에 생성 가능한 DoS cache 파일의 최대 수; 동시에 실행할 수 있는 frequency domain point의 수.
- 최대 코어 인스턴스 수: 이것은 GUI가 시작할 수 있는 oghma_core.exe 인스턴스의 최대 수를 설정합니다. parameter scan을 실행하는 경우 동시에 수행할 수 있는 simulation의 최대 수를 제어합니다. 백엔드에서 사용하는 스레드 수의 값이 4로 설정되어 있고 FDTD simulation을 실행 중이라고 가정해 봅시다. 이때 최대 코어 인스턴스 수를 8로 설정하면 GUI는 각각 4개의 스레드를 사용하는 8개의 oghma_core.exe 인스턴스를 생성하므로, 32개의 CPU 코어가 필요하게 됩니다.
- 정지 시간: 때때로 OghmaNano를 슈퍼컴퓨터에서 무인으로 실행할 때 실행이 멈출 수 있으며, 이는 IO 오류나 네트워크 오류 때문일 수 있습니다. 이 옵션은 단일 simulation의 최대 길이를 설정하는 데 사용할 수 있습니다. 단일 simulation이란 단일 JV 곡선, 단일 time domain simulation 또는 단일 frequency domain simulation을 의미하며, 수천 개의 개별 simulation을 포함하는 전체 fit을 의미하는 것은 아닙니다.) 따라서 값이 2000초이면 예를 들어 단일 JV simulation이 2000초보다 오래 걸릴 경우 solver가 종료됩니다. 실제로는 어떤 개별 simulation도 몇 초 정도만 걸려야 하므로, 이 옵션은 무언가가 매우 잘못되었을 때를 위한 강제적인 안전장치 역할을 합니다.
- 최대 fit 실행 시간: 이것은 oghma_core.exe가 메모리에 상주할 수 있는 최대 시간입니다. 어떤 simulation이나 fit이 이 값보다 오래 걸리면 종료되며, 이것 역시 simulation이 영원히 실행되는 것을 방지하기 위한 안전장치입니다. 기본값은 4일입니다.
- CPU 훔치기: 때때로 공유 PC에서 OghmaNano를 실행할 때, 다른 사용자가 상당한 수의 코어를 사용하고 있는 동안 simulation을 시작하게 됩니다. 시간이 지나면 다른 사용자의 simulation이 끝나면서 컴퓨터에 유휴 CPU가 남게 됩니다. 이 옵션을 True로 설정하면 OghmaNano가 사용 가능한 CPU 수를 모니터링하고 더 많은 CPU가 उपलब्ध해지면 그것들을 사용합니다.
- 최소 CPU: 위의 CPU 훔치기 옵션과 함께 사용되어 사용할 최소 CPU 수를 설정합니다.
- DoS를 디스크에 저장: OghmaNano는 simulation 속도를 높이기 위해 lookup table을 디스크에 저장합니다. 이 옵션이 false로 설정되면 이러한 lookup table은 저장되지 않습니다.
- OpenCL GPU 가속: GPU 가속을 활성화하거나 비활성화합니다. 이는 주로 FDTD simulation 중에 사용됩니다.
- GPU 이름: 사용할 GPU를 선택합니다.
Newton 캐시
많은 수의 ODE가 포함된 simulation을 실행할 때, 예를 들어 트랩 상태가 많고 공간 점이 많은 1D 소자나 2D OFET simulation을 실행할 때 각 전압 step을 계산하는 데 시간이 걸릴 수 있습니다. 이것은 solver가 수렴할 때까지 Newton 방법을 사용하여 각 전압 step을 풀어야 하기 때문입니다. 각 solver step마다 Jacobian을 구성하고, 행렬을 역행렬화한 뒤 residual과 곱하고, 모든 solver 변수에 대한 업데이트를 계산해야 합니다. 이 과정은 step당 상당한 시간(2000ms)이 걸릴 수 있습니다. 이 접근을 우회하는 방법은 이전에 계산된 답을 디스크에 저장해 두고, 사용자가 이미 계산된 문제를 다시 계산해 달라고 요청할 때 재계산 대신 그 답을 불러오는 것입니다. 이것은 소자의 광학 구조를 최적화하려고 하지만 전기 구조는 변경하지 않는 OLED 설계에서 매우 유용합니다. 이미 미리 계산된 전기 해를 사용하여 새로운 광 시뮬레이션을 실행할 수 있습니다. 구성 옵션은 아래 표에 표시되어 있습니다.
Newton Cache를 사용하는 데는 오버헤드가 있으므로, 전기 문제를 푸는 속도가 매우 느린 경우에만 이를 권장합니다. 기술적으로 Newton cache는 Fermi-level과 potential의 MD5 합을 취하여 전기 문제의 hash를 생성하는 방식으로 작동합니다. 그런 다음 이것을 디스크에 존재하는 내용과 비교합니다. 미리 계산된 답이 발견되면 Fermi-level/potential은 디스크에서 찾은 값으로 업데이트됩니다. 캐시는 oghma_local cache에 저장되며, 각 사전 계산된 해는 새로운 바이너리 파일로 저장됩니다. 각 simulation 실행은 해당 simulation의 모든 MD5 합이 저장된 index 파일을 생성합니다. 캐시가 가득 차면 OghmaNano는 index 파일을 기준으로 묶음 단위로 simulation 결과를 삭제합니다.
- 최대 캐시 크기: 캐시의 최대 크기를 Mb 단위로 설정합니다. 약 1Gb를 권장합니다.
- 최소 디스크 여유 공간: 캐시를 사용하기 위해 필요한 최소 디스크 공간을 설정합니다. 이 옵션은 캐시가 디스크를 가득 채우는 것을 방지하도록 설계되었으며 약 5Gb로 설정하는 것이 좋습니다.
- 유지할 simulation 수: 유지할 simulation 실행의 최대 수를 설정합니다. 20에서 100 사이로 설정하는 것을 권장합니다.
- 캐시 활성화: Newton Cache를 활성화하거나 비활성화합니다. 기본값이자 권장 옵션은 False입니다.
하드웨어 벤치마크
하드웨어 창의 왼쪽 상단에는 (??) Hardware benchmark라는 버튼이 있습니다. 이것을 클릭하면 OghmaNano가 사용자의 하드웨어를 벤치마크하며, 그 결과는 (??)에서 볼 수 있습니다. 이것은 CPU의 sin,exp 계산 능력과 메모리를 블록 단위로 할당/해제하는 능력을 벤치마크합니다. 몇 천 번의 연산을 수행하는 데 걸린 시간과 함께 R (즉 Roderick) 값을 표시합니다. 이는 R=당신의 PC에서 계산하는 데 걸린 시간/내 PC에서 계산하는 데 걸린 시간으로 정의됩니다. 따라서 값이 작을수록 당신의 PC가 내 것보다 빠르다는 뜻입니다. 내 PC는 2017 Lenovo thinkpad의 Intel(R) Core(TM) i7-4900MQ CPU @ 2.80GHz입니다. 따라서 대부분의 최신 컴퓨터는 더 빨라야 합니다. 만약 CPU 성능이 충분한데도 simulation이 내 YouTube 동영상보다 느리게 실행된다면, 이는 거의 항상 바이러스 백신, OneDrive에 simulation 저장, 네트워크 드라이브 사용, 느린 USB 저장장치 사용 등으로 인한 나쁜 IO 속도 때문입니다.