Topics

1

General Questions and Answers / Quantifying Memory Requirements for a Parallelized Job

« on: June 16, 2022, 19:09 »

I would like to quantify the actual memory requirements for a parallelized job on a cluster since some jobs have run out of memory in the past due to insufficient RAM from each node. How can we calculate the memory requirements for an entire job calculation (how do we quantifiably determine it from the *.log file where it provides memory per k-pt, per dense matrix dimension, and per real-space grid)? A snippet of the memory requirement from a previous *.log file is shown below:

+------------------------------------------------------------------------------+
| K-point grid: 4 x 4 x 4                                                      |
| Number of irreducible k-points: 32                                           |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| Real space grid sampling is (209, 209, 209) in a, b, and c directions.       |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| Memory requirements for the calculation                                      |
+------------------------------------------------------------------------------+
| Dense matrices: 1.52 GB per matrix [Matrix dimensions 9984 x 9984]           |
| Total memory required per k-point: 4.56 GB                                   |
|                                                                              |
| Storage of real-space orbitals: Enabled                                      |
| Storage requires 306 MB                                                      |
|                                                                              |
| Total memory required per real-space grid: 139 MB                            |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| SCF History                                                                  |
+------------------------------------------------------------------------------+
| Memory required to store SCF history: 10.02 GB                               |
| Number of history steps: 20                                                  |
+------------------------------------------------------------------------------+

2

General Questions and Answers / Quantitative Analysis of Total Interface Trap Density

« on: August 2, 2021, 07:35 »

Hello QuantumATK Staff,

I am interested in determining the total interface trap density at a given interface using the LDOS (eV^-1* Ang^-3) results (please see "ldos_example_interface_states.png" below). I have tried to integrate the LDOS with respect to energy at the interface region (Z - Z_int = 0 Angstroms, blue rectangular region)  across a 10 Angstrom region along with a unit conversion to cm^-2, but I always seem to get a value that is > 1e14 cm^-2. This is far too high in comparison to outside literature. I wanted to ask if the LDOS magnitudes are quantitatively meaningful to perform integration on them or if I should avoid doing this? I notice that when I evaluate the LDOS magnitudes at Z - Z_int = 0 Angstroms (please see "ldos_example_z_slice_z_zint_0.png"), the magnitude is between 1e18 to 1e23 eV^-1* cm^-3 which is really high. Looking at the LDOS magnitudes 200 Angstroms to the left of the interface region shows a floor value around 1e16 to 1e17 eV^-1* cm^-3 (please see "ldos_example_z_slice_z_zint_n200.png"). If integration for obtaining the total interface trap density is valid, I am not sure if I simply subtract the LDOS magnitude of the -200 Angstrom position from the LDOS magnitude of the 0 Angstrom position, shift the LDOS magnitude to start at 1e16 eV^-1* cm^-3 , or just normalize the magnitude? I can provide any other files and clarify my question(s) if necessary. Thank you in advance.