Hardware editor

All computer programs including OghmaNano run on physical computing hardware. There are may combinations of hardware that can be in any computer, some computes have a large number of CPU cores while others only have one. Likewise computers come with differing amounts of memory, hard disk space and GPUs. To help the user get the best out of OghmaNano, there is a hardware editor where the user can configure how OghmaNano behaves on any given computer. This can be accessed through the simulation tab window see Figure 4.17.

If you click on this it will bring up the hardware editor window which can be seen in Figure 4.18

The hardware window is comprised of various tabs which enable the user to edit the configuration and also benchmark your device.

CPU/GPU configuration tab

This tab is used to configure how OghmaNano interacts with the GPU and CPU it is described in the table below. As described in other parts of this manual in detail there are two parts to OghmaNano there is oghma_core.exe which is the computational back end and there is oghma_gui.exe which is the graphical user interface, how both these parts of the model behave can be fine tuned here.

• Number of threads used by the backend: This is the maximum number of threads OghmaNano oghma_core.exe can use. This dictates; the number of simultaneous fits that can be run; the maximum number of optimization simulations that can be run at the same time; the maximum number of threads that are used for FDTD simulations; maximum number of of DoS cache files can generated at the same time; number of frequency domain points that can be run at the same time.

• Maximum number of core instances: This sets the maximum number of oghma_core.exe instances that can be started by the GUI. If one is running a parameter scan then this will control the maximum number of simultaneous simulations that can be performed at the same time. If the values of Number of threads used by the backend has been set to 4 and one is performing an FDTD simulation, then one sets Maximum number of core instances to 8, then the GUI will spawn 8 instances of oghma_core.exe each using 4 threads, thus 32 CPU cores will be needed.

• Stall time: Sometimes when running OghmaNano on a supercomputer unattended it can stop running, possibly because of an IO error or network error. This option can be used to set the maximum length of a single simulation. By single simulation I mean a single JV curve, single time domain simulation or single frequency domain simulation, but not a whole fit which will involve running thousands if individual simulations.). So with a value of 2000 seconds the solver will exit, if for example a single JV simulation takes longer than 2000 seconds. In reality any individual simulation should take only a few seconds, so this option acts as a hard backstop if something has gone very wrong.

• Max fit run time: This is the maximum time oghma_core.exe can reside in memory. If any simulation or fit takes longer than this value it will be terminated, again this is a backstop to prevent simulations running forever. The default value is 4 days.

• Steel CPUs: Sometimes when running OghmaNano on a shared PC one will set a simulation running when another user is using a significant number of cores. After a while the other user’s simulations will finish running leaving the computer with idling CPUs. If this option is set to True, then OghmaNano will monitor the number of free CPUs and if more become available it will use them.

• Min CPUs: Used with the option above Steel CPUs to set the minimum number of CPUs that will be used.

• Store DoS on disk: OghmaNano stores lookup tables on disk to speed up simulations, if this option is set to false these lookup tables will not be stored.

• OpenCL GPU acceleration: This enables or disables GPU acceleration, this is used mainly during the FDTD simulations.

• GPU name: Selects the GPU to use.

Newton cache

When running simulations with a significant number of ODEs, such as 1D devices with a lot of trap states and a lot of spatial points, or when running 2D OFET simulations each voltage step can take a while to compute. This is because the solver must solve each voltage step using Newton’s method until it converges. For each each solver step the Jacobian must be built, the matrix inverted multiplied by the residuals and updates to all solver variables calculated. This can take a significant amount of time per step (2000ms). An approach to side step this approach is to store previously calculated answers on disk and then when the user asks the solver to calculated an already calculated problem the answer can be recalled rather than recalculated. This is very useful in OLED design where one is trying to optimise the optical structure of the device but leaves the electrical structure unchanged. One can run new optical simulations with already pre-calcualted electrical solutions. Configuration options are displayed in the table below.

There is an overhead to using the Newton Cache, so I would only recommend it when solving the electrical problem is very slow indeed. Technically the Newton cache works by taking the MD5 sum of the Fermi-levels and the potentials to generate a hash of the electrical problem. This is then compared to what exists on disk. If a precalculated answer is found, the Fermi-levels/potentials are updated to the values found on disk. The cache is stored in oghma_local
cache, each pre solvedsolution is stored as a new binary file. Each simulation run generates an index file where all MD5 sums from that simulation are stored. Once the cache becomes full OghmaNano deletes simulation results in batches based on the index files.

• Maximum cache size: Sets the maximum size of the cache in Mb. I would recommend around 1Gb.

• Minimum disk free: Sets the minimum amount of disk space needed to use the cache, this option is designe dto prevent the cache filling the disk I would set it to around 5Gb.

• Number of simulations to keep: This will set the maximum number of simulation runs to keep, I would set it to between 20 and 100.

• Enable cache: This enables or disables the Newton Cache, the default and recommended option is False.

Hardware benchmark

In the top left of hardware window 4.19 there is a button called Hardware benchmark. If this is clicked then OghmaNano will benchmark your hardware, the result of such a benchmark can be seen in 4.20. This runs benchmarks your CPUs ability to calculate sin,exp and allocate/deallocate memory in blocks. It displays how long it took to do a few thousand operations as well as an R (aka Roderick) value. This is defined as R=Time taken to do the calculation on your PC/The time take to do the calculation on my PC. Thus smaller values mean your PC is faster than mine. My PC is a Intel(R) Core(TM) i7-4900MQ CPU @ 2.80GHz in a 2017 Lenovo thinkpad. So most modern computers should be faster. If you have good CPU performance but your simulations are running slower than my YouTube videos then this is invariably due to bad IO speed, caused by virus killers, storing the simulations on OneDrive, using networked drives, using slow USB storage etc.