RAM and Memory¶

SIMION can be a memory intensive application. Each grid point requires approx. 8 or 10 bytes of memory. So, a 300x300x300 3D array with no symmetry requires 300x300x300x10 bytes = ~270MB RAM. Multi-electrode PA# files or multiple PAs may require more.

Subject to the amount of RAM on your system, the maximum number of points per PA is about 20 billion (190 GB) in SIMION 8.1.0.30 (using the 64-bit version). It is about 1.6 billion (16 GB) in 8.1.0.18 (using the 64-bit version). It is almost 200 million (~1.86GB) in SIMION 8.0 (or 32-bit SIMION 8.1 executables). It is 50 million (~480 MB) in SIMION 7.0.

The maximum memory usage per SIMION process (holding all PAs and particles) is limited to ~2 GB in 32-bit SIMION executables (including SIMION 8.0 and previous versions), as imposed by standard 32-bit operating systems (or a bit more via the /3GB or about 3.5 GB when running 32-bit executables in a 64-bit OS). There is no limit other than the OS limit in 64-bit SIMION 8.1 (e.g ~192 GB in 64-bit Windows 7).

See also 64-bit CPU support concerning 64-bit large RAM support added in SIMION 8.1.

SIMION Error Messages¶

When SIMION runs out of free voltage memory, you may get errors such as “Out of Heap Space - PA Block”, “Heap Allocation Problems”, (SIMION 7.0.x-8.0.1) or “Virtual memory not available to allocate %u contiguous bytes for %s” (SIMION 8.0.2). Such messages refer to a failure by SIMION to allocate memory from your operating system’s pool of free memory (which includes both physical RAM and virtual disk space on your hard disk).

Solutions to Memory Issues¶

Some ways to overcome memory limitations are given below:

Shutdown any other running programs that are memory intensive and not needed. This should increase the proportion of memory that is free.
Reduce the memory requirements of your simulation. For example, reduce the number of points in the PA, make use of symmetry, combine electrodes in a PA# file, split the system into multiple PAs (See Multiple PAs), or use various PRG tricks to reduce the number of PA’s or PA points needed). See e.g. the ion jumping tricks sometimes used to simulate grids.
Increase your available virtual memory. You may need to increase your system’s “page file” size. The page file is huge file on your hard disk that Windows resorts to if it runs out of physical RAM. Before doing this, check that you actually do have free disk space on the disk drive on which the page file is stored (typically C:). If you have close to zero bytes free, Windows will have problems, and you’ll need to free up some hard disk space (e.g. delete temporary files). Beware: hard disks are vastly slower than physical RAM, so it pays to have physical RAM whenever possible.
Install more physical RAM. To go above ~ 2 GB, you will need to upgrade to SIMION 8.1.0 or above.
Use SIMION on Amazon EC2, which currently has up to 68 GB RAM, which SIMION >= 8.1.0.30 can fully utilize.

Checking Free RAM on Your System¶

To check the amount of free volatile memory on your system, use the Windows Task Manager (press CTRL+ALT+DEL). Examine how much “memory usage” and “virtual memory (VM) usage” are listed on the simion.exe processes (you may need to “View | Select Columns...”) and compare this to the amount of free physical RAM (total physical RAM minus the amount used by other programs and the operating system). For a global view, see the Performance Tab. The Performance Tab is a little bit complicated to interpret due to how virtual memory works, but basically the “Available” physical memory + system cache is the amount of free physical RAM. When physical RAM starts getting exhausted, the OS starts heavily swapping to disk, and the disk then becomes a huge bottleneck. (If the amount of RAM is a bottleneck, you should only run a single instance of SIMION at a time for this reason.) See the following reference for details on interpreting the memory statistics in the Windows Task Manager (see here).

Installing More RAM¶

For adding more RAM to existing systems, SIS has had success with these people: www.crucial.com .

Pushing the 2 GB per PA limit in SIMION 8.0¶

As of SIMION 8.0, the --reserved-memory command-line switch is provided. This reserves a certain number of bytes of contiguous memory for SIMION PAs before SIMION starts, thereby preventing memory fragmentation and likely increasing the maximum PA size limit you can use. For example, to reserve 1.85 GB RAM for PAs (close to 200 million points), start up SIMION was follows:

simion.exe --reserved-memory 1.85G

If you want to change your Windows shortcut to do this, do the following under Windows XP (other versions of Windows could differ slightly). Right click on the “SIMION 8.0” program icon in the Windows task bar (which you usually start SIMION with) and click “Properties”. In “Target” append the text --reserved-memory 1.85G to it. You may need to decrease the 1.85 number slightly depending on your system so that SIMION will still run (unfortunately, there is no known way to reliably automate the selection of the optimal reserve limit).

The --reserved-memory option may be unnecessary for 32-bit simion.exe on 64-bit Vista since from what has been observed DLLs don’t load themselves at low (~1-1.5 GB) addresses as they can on 32-bit XP.

There is no need to use this switch on 64-bit SIMION executables (available in 8.1.0 and above).

Pushing the 2-4 GB limit in 32-bit Executables¶

A 32-bit SIMION running under 64-bit Windows or the /3GB (details) 32-bit Windows startup option can utilize some of the 2-4 GB memory region. This doesn’t allow creating a 4 GB array, but at least under 64-bit windows it allows loading two nearly 2 GB arrays or a single roughly 2.4 GB array. Your milage may vary. The reason we can slightly slightly exceed ~ 2 GB is because only 8 of the 10 bytes per point in the array need to be contiguous.

Microsoft Hyper-V with Dynamic Memory¶

Those using SIMION 8.1 in a 64-bit virtual machine under Microsoft Hyper-V with the “Dynamic Memory” feature may need to take some extra care to avoid memory allocation failures for large arrays exceeding the Startup RAM setting.

Hyper-V Dynamic Memory behaves differently than VMWare memory overcommit. VMWare memory overcommit behaves somewhat like airline overbooking: the host tells the guests that they have some amount of RAM whose total exceeds the amount of RAM actually on the host, under the assumption that not all guests will use all the host RAM at the same time. Hyper-V Dynamic Memory, on the other hand, assigns guests a certain guaranteed amount of RAM (Startup RAM) and uses Windows performance counters to over time monitor memory usage of the guests and automatically “hot add” unused RAM to the guests whose memory gets low. Although Dynamic Memory doesn’t support the analogous “hot remove” of RAM (i.e. without restarting the guest), it does support something similar called “ballooning”, where it reserves some block of RAM in a guest (which other processes on that guest can thereby no longer allocate from) to permit hot adding that RAM to other guests, thereby allowing RAM to be assigned to the guests that utilize it the most.

One implication of this is that, for example, if the VM containing SIMION currently has 2 GB RAM and you attempt to allocate a 16 GB array in SIMION, this will likely fail no matter how many times you try. The “hot add” is not performed immediately but rather when the host sees that the guest RAM is low, but the guest RAM never gets low because the allocation of 16 GB never succeeds.

One obvious solution is to just adjust the default guest memory allocations on the host, particularly increasing the Hyper-V Startup RAM (and/or memory buffer). This also means that your VM may be wasting RAM when it is running but not running large simulations, so this might not be practical.

One way to work around the problem is to force hot adds of memory by pasting a command like this in the bottom SIMION command bar:

for i=1,16 do local pa = simion.pas:open(); pa:size(1024,1024,1024/10); simion.sleep(1.0) end; simion.pas:close()

(If that fails, repeat it again until it works.) The above slowly allocates 16 GB RAM in smaller 1 GB chunks, waiting 1 second between allocations to give the host some time to do the hot add. If that succeeds, your VM now has at least 16 GB RAM available, and subsequent allocation of a 16 GB array in SIMION will now succeed.

For convenience, you can also add that to your SIMION “startup file” (see the “User Programming” appendix of the SIMION 8.0/8.1 user manual) or you can add a function like this to your startup file:

function hotadd(gb)
  for i=1,gb do
    local pa = simion.pas:open()
    pa:size(1024,1024,1024/10)
    simion.sleep(1.0)
  end
simion.pas:close()

so that you can then just enter hotadd(16) into the command-bar anytime you need 16 GB RAM.

One problem, however, is that if you don’t keep the 16 GB array open but use “Remove All PAs from RAM” and wait a few minutes, the host will see that the guest is no longer using that RAM and it may do ballooning. Therefore, subsequent attempts to allocate the 16 GB array again may fail. The moral is that you should force the hot add prior to any attempt to run a large simulation.

Future updates to SIMION 8.1 may make improvements in this regard. Let us know if you are interested in this so we know how important this is. Note that the --reserved-memory option does not help here (and generally is not useful for 64-bit SIMION builds).

Navigation