GitLab

Table of contents

• Table of contents
• Details
• Keywords
  • The MEM Keyword
  • The NSMP Keyword
• Example
  • Large memory, large number of threads
  • Small memory footprint, serial

Details

The MISC section controls miscellaneous options connected to computational infrastructure. This section controls the amount of resources per MPI process.

Keywords

The MEM Keyword

The MEM keyword controls the maximum amount of memory per process. ChronusQ utilizes a custom built memory manager for all major memory allocations. This is done for a number of reasons:

1. Pool memory allocation is often much more efficient than dynamic allocation from the operating system. The ChronusQ memory manager allocates a large pool of memory (of specified length), and then performs subsequent memory allocations through a segregation of that memory allocation. Thus ChronusQ only asks for a large amount of memory from the operating system once, and then performs all allocations out of that allocation internally. This does mean there may be a long allocation period at the beginning of ChronusQ if asking for a very large maximum memory, but this cost is amortized over the internal allocations.
2. Although the cluster computing paradigm allows for other-user-agnostic calculations (i.e. the resources allocated for that user are allocated for that user alone, without the risk of other users' jobs interfering), dynamic memory allocation can be a problem on shared research/development machines on which many people are working. The reason for this is as such: quantum chemical calculations are often not memory intensive at the beginning of a calculation and become much more so (i.e. post-SCF, etc) later in the calculation. In the case of complete, dynamic memory allocation, there may be enough memory for a user's job when the SCF runs, but then when the user's job asks for more memory later in the calculation, there may not be enough memory on the system for the subsequent calculations, especially if other user's are running jobs with similar memory requirements. Thus pool memory allocation overcomes this hurdle by allocating all of the memory up front, so if there is enough memory allocation for the maximum memory requirement of the job, that job is guaranteed to not run out of memory due to the presence of other calculations on the same machine. Thus, as ChronusQ is meant to run on both clusters and development machines, we have chosen a Pool memory allocation paradigm.

The format for the MEM keyword is:

Mem = N <B/KB/MB/GB/TB>

The NSMP Keyword

The NSMP keyword determines the number of shared memory threads that run within each process. By default, ChronusQ uses a single thread. (serial)

Example

Large memory, large number of threads

[Misc]
Mem = 1TB
NSMP = 40

Small memory footprint, serial

[Misc]
Mem = 50 MB
NSMP = 1