RAM and Memory¶

SIMION can be a memory intensive application. Each grid point requires approximately 8 bytes (on disk) or 10 bytes (in RAM). So, a 300x300x300 3D array with no symmetry requires 300x300x300x10 bytes = ~270MB RAM. Multi-electrode PA# files or multiple PAs may require more. 2D simulations can require much less. 2D simulations can require much less. Many examples run within a few MB to a few hundred MB of RAM, though higher accuracy simulations can require gigabytes of RAM.

Memory usage should be balanced with your Accuracy requirements and permitted Calculation Time.

Factors affecting available RAM¶

The following main factors determine how much memory SIMION can use:

Amount of physical RAM installed in your system. You may be able to install additional RAM fairly cheaply (see “installing more RAM” below), but this depends on the slots available on your motherboard.
CPU type. Intel or AMD x86-64 (i.e. 64-bit CPU support) compatible CPU’s are required to access more than 4 GB RAM. Older or lower-end x86-only (i.e. 32-bit) CPU’s traditionally support 4 GB RAM maximum.
Operating system. 64-bit Professional editions of Windows 7 support up to ~190 GB for example, though some Home editions support less. 32-bit operating systems support only 2-3 GB. See “Operating System Limitations” below for details as well as Linux/Mac notes.
SIMION version being used. SIMION® 8.1 includes a 64-bit executable, which can utilize up to about 190 GB RAM. 32-bit executables (including SIMION® 8.0) support no more than 2-3.5 GB.

If you might need to go above 4 GB RAM, note that the CPU, operating system, and SIMION must all be 64-bit (which is typically ensured by the computer manufacturer you purchase from). For example, a 64-bit CPU, motherboard having more than 4 GB RAM (or at least supporting such expansion in the future), a 64-bit Windows 7 Professional Edition OS, and SIMION® 8.1 (which includes a 64-bit executable) would be one reasonable choice. Such a system could support up to ~190 GB RAM (~20 billion points) or more depending on the RAM slots available. See also 64-bit CPU support concerning 64-bit large RAM support added in SIMION 8.1.

SIMION Version Limitations¶

SIMION® 8.1 versions 8.1.0.30 and above (using the included 64-bit SIMION executable), support up to 20 billion points (~190 GB RAM) on Win7 Pro. (In theory, newer or server versions may support beyond 190 GB, but it hasn’t been tested.)
SIMION® 8.1 versions 8.1.0.18-8.1.0.22 (prior to the 8.1.0.30 update) support ~190 GB RAM but only 16 GB per PA file (~1.6 billion points).
SIMION® 8.0 (versions 8.0.x.x), as well as the 32-bit executable included in SIMION 8.1, support 2 GB on 32-bit OS’s, 3 GB on 32-bit Windows with the /3GB switch (see below), or ~3.5 GB on 64-bit OS’s. However, they are restricted to about 2 GB per PA, and the --reserved-memory switch (see below) may be needed to exceed ~1.5 GB per PA.
SIMION versions 7.0.x support 2 GB on 32-bit OS’s (and perhaps 3-4 GB like in 8.0.x.x) but are limited to ~480 MB per PA (50 million points).
(Merely of historical interest, SIMION 6.0 (old DOS version) supported 8 or > 16 MB (~64 MB), depending on virtual extender used, though limited to 10 million points per PA. SIMION 4.0 was limited to the 640 KB of DOS (2D). A pre-2.0 version for the PDP-11 supported 24 KB or 5000 points.)

The 64-bit executables can only be run on 64-bit operating systems, but 32-bit executables may be run on both 32-bit and 64-bit operating systems. See 64-bit CPU support.

Operating System Limitations¶

Your operating system itself imposes RAM limits. A 64-bit operating system with SIMION 8.1 (using 64-bit executable) will be generally be limited only by the operating system. But a 32-bit operating system or 32-bit SIMION executable limits you to 2-3 GB RAM (the operating system reserves 1-2 GB of the 4 GB for itself).

Windows version limits:

Below are RAM limits for various versions of Windows:

Windows 10: 2048 GB (Pro/Educational/Enterprise, 64-bit), 128 GB (Home, 64-bit), 4 GB (all, 32-bit)
Windows 8: 512 GB (Pro/Enterprise 64-bit), 128 GB (Home 64-bit), 4 GB (all, 32-bit)
Windows 7: 192 GB (Pro/Enterpise/Ultimate, 64-bit), 16 GB (Home Premium, 64-bit), 8 GB (Home Basic, 64-bit), 4 GB (all except Starter, 32-bit), 2 GB (Starter, 32-bit)
Windows Vista: 128 GB (Business/Enterprise/Ultimate, 64-bit), 16 GB (Home Premium, 64-bit), 8 GB (Home Basic, 64-bit), 4 GB (all except Starter, 32-bit), 1 GB (Starter, 32-bit)
Windows XP: 128 GB (64-bit), 4 GB (32-bit), 512 MB (Starter, 32-bit)
Windows Server 2012 (64-bit): 4096 GB (Standard/Datacenter/Storage Standard), 64 GB (Essentials), 32 GB (Foundation/Storage Workgroup)
Windows Server 2008 R2 (64-bit): 2048 GB (Enterprise/Datacenter), 32 GB (Standard), 8 GB (Foundation), 128 GB (HP Server), 32 GB (Web Server)
Windows Server 2008: 1024 GB (Enterprise/Datacenter), 128 GB (HPC), 32 GB (Standard/Small Business/Web Server), 4 GB (all 32-bit) (64 GB on 32-bit Datacenter/Enterprise not supported)
See also Memory Limits for Windows Releases for other versions of Windows.

Recommendations: As of June 2016, for users desiring a Windows OS, the 64-bit Windows 10 or Windows 7 Pro (or Home Premium) would be preferable for most power users, though other users can do fine with less. Windows 8 is planned soon and should also make a good option.

Upgrading Windows editions: If you have a Home edition and install more than 16 GB RAM, you may use Windows Anytime Upgrade to upgrade to the Professional edition to access that RAM. However, upgrading from 32-bit to 64-bit apparently requires an OS reinstall.

Pushing RAM on 32-bit OS’s: With 32-bit SIMION executables, the maximum memory usage per SIMION process (holding all PAs and particles) is limited to ~2 GB, ~3 GB using the /3GB switch (see below), or about 3.5 GB when running 32-bit executables in a 64-bit OS.

Linux and Mac OS X notes:

64-bit is fully supported on 64-bit Windows (or 64-bit Windows running in a virtual machine on Linux or Mac OS X). Running 64-bit SIMION on Linux via Wine64 is experimentally supported (see Linux). A non-GUI native 64-bit Linux build of SIMION is increasingly closer to reality, so let us know if you want that to be a higher priority. A (64-bit) Wine64 version of CrossOver Mac is not available at the time of this writing. Another alternative to Wine64 is to run 64-bit SIMION on 64-bit version of Windows virtualized in Mac or Linux. See also System Requirements.

32-bit operating systems (as well as 32-bit Wine/CrossOver on Linux and Mac OS X) require using a 32-bit version of SIMION. The 32-bit executable of SIMION 8.1.0 has the same PA size limit as 8.0, but you’ll still be able to take advantage of other Refine enhancements (like Multicore CPU support).

Hard Disk¶

For hard disk size, you need enough hard disk space to store your PA files (except if those PA files are never saved). You may wish to compress your .PA# files to conserve disk space (right click in Windows Explorer and select Advanced, Compress), but this is not useful for other PA types.

Hard disk speed is normally much less important than RAM speed. Hard disk speed will affect how fast PA’s are read and written from disk, though this is typically relatively small (though not negligible) compared to other factors. Most of the Refine time is spent with the data in RAM, when hard disk speed will have no effect. There is, however, a relatively smaller but not insignificant amount of time spent writing sequentially to disk after each electrode is Refined. The “Fast Adjust” button from the GUI, which streams from disk, probably uses disk the most (note: in contrast, fast adjusting from user programs typically keeps arrays in memory). As of March 2012, fast hard drives and controllers can do sustained reads/writes above 100 MB/sec. Solid state drives (SSD) are not typically recommended at this time: solid state drives (SSD) excel at fast random read/write (low latency), but that is not the typical workload in SIMION. Although SSD’s can be a couple times faster than traditional drives on typical SIMION workloads of sustained reads/writes (100-500 MB/sec) based on reported specs, that may not be worth the much higher cost. (Another option for high performance is a RAID-0 array of traditional 15K RPM drives, which has a higher failure rate, though that is ok for temporary storage.) Again, RAM is typilcally much more important than the hard disk. discussion.

Virtual memory: Modern operating systems typically allow programs to exceed physical RAM by using virtual memory allocated from a hard disk swap file (sometimes twice the size of physical RAM), but for SIMION’s purposes only physical memory is really useful due to slowness of disk access.

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 programming tricks to reduce the number of PA’s or PA points needed). See e.g. the ion jumping tricks sometimes used to simulate grids.
Install more physical RAM. To go above ~ 2 GB, you will need to upgrade to SIMION 8.1.0 or above.
Increase your available virtual memory (not normally recommended). 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.
Use SIMION on Amazon EC2, which currently has up to 68 GB RAM, which SIMION >= 8.1.0.30 can fully utilize.
Improve memory usage of fast adjustable electrodes. Generally. each electrode fast adjusted from a user program (i.e. via the fast_adjust or init_p_values segment in a user program rather than via the “Fast Adjust” button from the GUI) will result in an electrode solution array being loaded into RAM. So, you want to minimize this. See also Additional Fast Proportional Scaling Solutions and the “Additional Notes on Fast Adjusting and Memory Usage” below.
If particles only fly within a small volume of your PA, you can “Crop” (Issue-I 313) the refined .PA0 or .PA file and add that cropped PA to your workbench to fly in. This assumes you had enough memory to refine the .PA# or .PA file prior to this crop procedure though.
Use the experimental Electrode Surface Enhancement / Fractional Grid Units feature in SIMION 8.1. This improves accuracy, without increasing memory usage, in the case of electrode surfaces not being perfectly aligned to grid cell vertices (as often is the case for curved surfaces).

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 . As of March 2012, tens of GB of RAM is not cost prohibitive.

Pushing the 2 GB per PA limit in 32-bit Executables¶

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 operating systems 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-3.5 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 mileage may vary. The reason we can slightly exceed ~ 2 GB is because only 8 of the 10 bytes per point in the array need to be contiguous.

There is no reason to use this switch on 64-bit versions of Windows.

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).

Additional Notes on Fast Adjusting and Memory Usage¶

The following is a discussion on memory usage for fast adjust arrays (.PA#/.PA0 files), which may require more memory than basic arrays (.PA files).

If you refine a PA# file with, say, six electrodes, it will generate six electrode solution files (.pa1 through .pa6) as well as the base solution array (.pa0). (For details, see Potential Array File Types (Comparison).) The .pa0 will get loaded into RAM, and for certain types of fast adjusting, some or all of the electrode solution files may also get loaded into RAM.

You may also want to ask whether you really need all six electrode voltages to be independently adjustable. If there are linear dependencies in some of these voltages, then you can merge electrodes into a single solution array (noted in Additional Fast Proportional Scaling Solutions). Perhaps then you will only need to generate 1-5 such files, which also reduces disk usage and Refine time proportionately. On the extreme end, you might even just use a single basic array (.pa file), which will take about 1/6th the time to refine and 1/7th the disk usage but won’t allow any fast adjusting other than proportional rescaling of all electrode voltages.

Whether all these solution arrays are loaded into RAM depends how you fast adjust it (see How does fast_adjust differ from init_p_values and the Fast Adjust button?.

The Fast Adjust button in the SIMION GUI basically streams each solution array (.PA1,.PA2,.PA3,etc.) from disk during the fast adjust process without keep these arrays in RAM (or only a small portion of them). So, RAM Usage is little more than the size of a .PA0 file.
If you have a workbench user program with a fast_adjust or init_p_values segment, which can be required for a Time-Dependent Field, these will load the entire solution arrays into memory (permitting quick access), though only for electrodes actually adjusted in these segments. Any electrode solutions loaded into memory at any time from init_p_values or fast_adjust will remain in memory until the next Fly’m. Since that can multiply RAM usage, you may want to only fast adjust electrodes from the user program only when necessary. If some electrodes are static DC (rather than RF time-dependent), then instead of touching them in the fast_adjust segment, you can use the Fast Adjust button or the Lua PA API simion.pas pa:fast_adjust().
Calling simion.pas pa:fast_adjust() (added in SIMION 8.1) can achieve a similar effect to init_p_values but avoids loading the solution arrays into RAM, and this function can be called at nearly any time, including from other_actions, initialize/initialize_run, and init_p_values segments.
```
-- SIMION 8.1.
simion.workbench_program()
function segment.init_p_values()
  -- fast adjusts electrodes 1-3 in workbench instance #1 PA,
  -- without retaining solution arrays in RAM.
  simion.wb.instances[1].pa:fast_adjust{[1]=100, [2]=-100, [3]=500}
end
```
simion.pas pa:field_vc() and simion.pas pa:potential_vc(), which can query PA fields, have a t parameter that behaves similar to the fast_adjust segment, and this will load solutions arrays into RAM.

PA Crop¶

You may also consider using the Modify screen “Crop” function (Issue-I 313) on the refined .PA0 file if particles only fly in some subregion of the PA. It may be that you have enough RAM to refine the electrode solution arrays individual but not load them all into RAM simultaneously unless you crop the refined arrays. Also available via simion.pas pa:crop().

PA File Size¶

When a PA is written to disk, it uses 8 bytes per point, plus a small header. When a PA is loaded into memory, SIMION uses an extra 2 bytes per point. Don’t forget 1 killobyte is 2^10 (i.e. 1024) bytes not 1000 bytes.

Allocation Speed¶

On some systems, allocating large multi-GB blocks of RAM near your RAM limit may take more than a couple seconds in Windows due to Windows behavior. You can observe this by enabling the various memory related columns (e.g. Virtual memory) in the Windows Task Manager process list. When SIMION allocates a new array (as most clearly observed just by doing New), you may see the memory for simion.exe increase very slowly while barely using the CPU.

Measuring RAM Usage¶

Here’s some tips for determining why SIMION uses RAM or how RAM inceases over time.

Some sources of RAM usage:

PA’s loaded in RAM (seen on main screen) and to a much lesser extent trajectories.
fast_adjust/init_p_values segments - increase RAM by size and number of PA solution files loaded.
Lua code - not likely but possible if your code creates huge tables.

This function:

print(simion.debug.memory_dump)

prints all memory used by PAs as well as listing various Windows memory stats:

memory_dump = {
  all_size = 20477.62, all_free = 8158.73,
  physical_size = 10237.62, physical_free = 1629.76,
  virtual_size = 134217727.88, virtual_free = 134217431.95,
  virtual_reserved_size = 0.00, virtual_reserved_free = 0.00,
  process_working_set_size = 50.55, process_commit_size = 23.67,
  lua = 0.571289,
  blocks = {
    {first=1774776.19, last=1774776.96, size=0.76, state="used"},
    {first=1774776.96, last=1774777.15, size=0.19, state="used"},
  },
  blocks_used = 0.95
}

There’s different types of memory:

physical size is the amount of physical RAM (10 GB in above example), and you don’t want run out of that.
process sizes are the amount of RAM used by the current simion.exe process (and there are two types: working set and commit). The “blocks” are the blocks of RAM used for PA objects, which make up most of the process size.
lua is the amount of RAM used only by Lua within the simion.exe process. It is usually a small number unless your Lua code creates massive Lua tables. This number does not include SIMION objects like PA’s. print(collectgarbage("count")) reports this same number but in killobytes.

You can even add pauses in the simulation:

print 'I am here'; simion.sleep(5)

which allows you some time to check Windows Task Manager to see when the memory increases.


[Optional] Your name:	email:	phone: