Desktop Client: Are there limits built into the Simulator? (Out of Memory Errors)

This article applies to iGrafx Process and iGrafx Process for Six Sigma Client tools

The simulator does not design in any limits, except for the limits imposed by being a 32-bit application.

There is a limit to the amount of memory you can use on any given Operating System (o/s), Machine, and particular Software application such as iGrafx. A 32-bit o/s (like Windows XP; or Windows Vista or Windows 7 32-bit versions) has a maximum addressable memory (e.g. about 3.2 GB) that may be smaller than the needs of the simulator, particularly with millions of active transactions. In addition, iGrafx is currently a 32-bit application, so even if you are running on a 64-bit operating system (like Windows 7 64-bit) with a large amount of Random Access Memory (e.g. 4GB or more of RAM), this will not help the memory limitations because iGrafx can only use the equivalent memory of a 32-bit operating system.

If you exceed the capabilities of the machine to handle the amount of transactions you are trying to simulate, you may receive 'out of memory' errors from the operating system or from iGrafx. In addition, iGrafx may appear to 'hang' (stop responding) while it tries to negotiate for more memory from the computer, or do internal 'housekeeping' while tracking many (e.g. millions of) transactions. These are limitations of the operating system and machine, until you reach the limits of addressable memory in a 32-bit application such as iGrafx, and then iGrafx will limit the capabilities of your simulation and may run out of the amount of memory (RAM) it can use.

If you reach the limits of the application and/or operating system, then please consider alternate modeling approaches that give the simulator less work to do. For example:

1. Change what objects (how much work) each transaction represents. One method to do this is to have each transaction represent 10 (or 100 or 1000) items of work, and scale the time it takes to process that amount of work accordingly; e.g. instead of 1 transaction taking 5 seconds, 1 transaction takes 50 seconds and represents a collection of 10 work items processed in serial (interruptions or breaks can still be modeled with resource schedules and other methods). 
2. Run simulation for a shorter time and extrapolate the answer over a longer period of time; e.g. consider simulation a statistical sample that you can derive performance from.
3. If you are batching many transactions, and don't need the unique characteristics of each transaction to be saved, then consider doing a 'Join' and then later 'Duplicate' the joined transaction into the same number of transactions that were previously joined. It is possible to run the simulator out of memory if you doing batches of batches of thousands (e.g. hundreds of thousands) of transactions.