SIMION®
The field and particle trajectory simulator
Industry standard charged particle optics software
Refine your design: model > simulate > view > analyze > program > optimize it.
SIMION v8.1.3.0-TEST posted.
About | Documentation | Community/Support | Downloads | Ordering

Calculation Time

SIMION calculation time mainly involves the time to calculate fields and trajectories. Typically the fields take much longer to calculate (refine) unless, for example, if you’re simulating millions of trajectories in a statistical experiment.

Calculation time should be balanced with your Accuracy requirements.

Field Calculation Time

Field calculation time (SIMION Refine) depends on a number of factors:

  1. Number of grid points.
  2. Speed and quantity of physical RAM.
  3. Number of “fast adjustable” electrodes (if using PA# files).
  4. Nature and complexity of the field.
  5. Convergence limit (specified in the SIMION Refine screen).
  6. Other refine parameters (specified in the SIMION Refine screen).
  7. Computer system.

In more detail:

  1. Number of grid points. The calculation time is roughly linear with the number of grid points used ‘’provided’’ the PA can fit entirely in physical RAM (see point #2). SIMION uses a fairly complex implementation to achieve this linear scaling. A “large” array (e.g. hundreds of millions of points) may take some fraction or multiple of an hour depending on other conditions. Smaller arrays can take minutes or seconds.
  2. Speed and quantity of physical RAM. As noted, #1 is only true if you have sufficient free physical RAM to hold your entire PA, otherwise calculation likely will be ‘’much’’ slower (due to virtual, disk, memory usage), in which case you should consider a RAM upgrade or model your simulation differently. See RAM and Memory. The speed of RAM (how fast you computer can access the RAM) is also important, and that may be improved, for example, by using a moderately high-end computer with a fast memory bus.
  3. Number of “fast adjustable” electrode solution (if using PA# files). The initial calculation time is very roughly linear with the number of fast adjustable solution arrays created. Each fast adjustable electrode actually uses a separate Refine calculation (and could even be done on different computers – Issue-I503). So, don’t use more fast adjustable electrodes than you need to. For example, if two electrodes always have the same voltage, you can express both with the same fast adjustable electrode. If potentials of some electrodes never change or are proportional, consider using fast scaling electrodes (electrodes that are not fast adjustable). If you have resistor chains or linear dependencies between electrode potential (e.g. SIMION Example: ionfunnel), the Additional Fast Proportional Scaling Solutions can help a lot. The advantage of fasting is that you can change electrode potentials relatively quickly without refining the PA again, and it allows things like RF voltage oscillations on electrodes to be very practical.
  4. Nature and complexity of the field. If the field is quite uniform or smooth, the calculation may proceed quickly. More complex or contorted fields can take much longer. This is due to the nature of the SIMION Refine process, which is aggressive in some cases but less aggressive in others. It’s not a hard science.
  5. Convergence limit and other refine parameters. The convergence limit (specified in potential, e.g. V) determines when the results are sufficiently precise to stop the calculation. If the potentials don’t change more than this limit in an iteration, then the calculation is ended. Therefore this parameter greatly affects the calculation time. The default convergence limit is 5.0E-3 V but can be specified down to 1.0E-7 V. Only refine down to the limit you may need, otherwise it’s just a waste of time. For example, try the default convergence limit, then maybe decrease it by a factor of 10 or 100 and see if this affects your results outside an acceptable margin of error–if not, there’s no need to decrease the limit any further in future similar calculations, and you might even be able to increase it. Also, you might increase this limit during initial calculations to get a rough estimate and then decrease it when doing the final calculations.
  6. Other refine parameters. This includes the max over-relaxation factor, historical memory factor, and skipped point refining. Changes to these parameters may decrease the calculation time or may significantly increase it, so it’s recommended that you don’t change these unless you know what you’re doing (see SIMION manual). Generally, use the convergence limit instead.
  7. Computer system. SIMION® 8.1 can utilize multiple CPU cores, if available on your system, to speed up the Refine. Furthermore, RAM memory access speed can affect the Refine speed. Refines are even faster if the PA fits entirely inside the L2 or L3 CPU cache (which as of 2012 may range from a fraction of a MB to tens of MB’s in size).

Some other tricks to improve refine speed include using Multiple PAs.

Trajectory Calculation Time

Trajectory calculation time (Fly’m) mainly depends on these factors:

  1. The size of the time-steps. This greatly affects the calculation time. The calculation time would be roughly proportional to the number of time-steps (or inversely proportional to their size). Time-step size is mainly controlled by the trajectory quality factor, which is the “T.Qual” parameter on the View screen Particles tab (in SIMION 7.0, it’s a purple box on the PAs tab). The default value is +3 (or 0 when Grouped flying is enabled to avoid one particle slowing down the pack). See the Computational Methods appendix of the printed manual for details on the meaning of this parameters. A value of 0 is the fastest and least accurate, while accuracy increases with higher negative or positive values. Time-step size can also be affected (typically reduced) as well by user programming (e.g. tstep_adjust segment), time markers (see particles tab), and data recording. Note that if you’re doing oscillating voltages (RF), you’ll likely want the time-step size to be no larger than some fraction of the oscillation period (see Time-Dependent Field).
  2. Viewing and Retaining of trajectories options. These determine whether trajectories are written to the screen or disk respectively. Viewing and retaining can slow down the simulation, so if you’re simulating a large number of trajectories, you may want to disable these options. These options are normally enabled but can be disabled by unchecking the “View” and “Retain” checkboxes on the View screen Particles tab (“V” and “R” buttons on PAs tab in SIMION 7.0). Retain is effectively disabled anyway if Rerun’s are enabled though. Turning off Retaining will prevent trajectories being saved to disk. The traj***.tmp file will then no longer be created, and you can use the data recording or user programming features to record only the data you need. Disabling this also means that if you do anything that will lead to redrawing the graphics (e.g. rotating or zooming), the trajectories will no longer display unless you Fly’m again. (The size of the trj***.tmp file might be an additional concern on some older file systems, OSs, and programming libraries have a 4GB file size limit.) Turning off View prevents trajectories from even being drawn. This speeds up long calculations and may be suitable for non-interactive operation. Viewing and retaining of trajectories can also be controlled via user programming (sim_trajectory_image_control). It may be useful to disable retaining trajectories in only certain runs, particles, or regions of volume (an example is in Workbench Program Extensions in SIMION 8.1).
  3. User programs. These can slow down the calculation, particularly if they use segments that are called frequently, one or more times per time-step, such as tstep_adjust, fast_adjust, efield_adjust, mfield_adjust, accel_adjust, and other_actions. Consider moving computationally intensive code out of these segments. For example, if possible use init_p_values instead of fast_adjust or initialize variables in initialize or initialize_run. A conditional that gets executed only once can also help:
-- test.lua
simion.workbench_program()
local first = 1

function segment.other_actions()
  if first == 1 then
    -- ... add really expensive code here ...
    -- ... which will be called only once ...
    first = 0
  end
end
  1. Grouped flying. This may be slower than flying with the Grouped checkbox disabled (the default). Particularly, with charge repulsion enabled (which requires Grouped flying, the runtime scales with the square of the number of particles flown (unless special techniques are used for O(N log N)), so only a couple hundred or thousand particles may be practical with charge repulsion. You may want to consider the Poisson Solver in SIMION instead of the charge repulsion method since this allows handling space-charge in a way that scales linearly with the number of particles (though has a higher fixed cost).

Other notes for improving speed:

  • If you are simulating a large number of particles (e.g. perhaps millions), it is possible to partition the particles into multiple sets of particles, which will be run on different instances of SIMION, on the same or different computers. You’ll unlikely benefit if you run more simulations on a computer than the number of CPU cores on that computer.

  • In cases where particles fly continually (e.g. Ion Trap simulations), you may want to limit the total run time. One way is with a user program like this:

    simion.workbench_program()
    adjustable max_time = 10  -- microseconds
    function segment.other_actions()
      if ion_time_of_flight > max_time then ion_splat = 1 end
    end
    

Display Performance

Display performance can also be a factor. For a large PA, you might keep the display quality factor (“D.Qual” parameter on the View screen) low, such as near 3 and no higher than 7-8. rgenius et al Drawing trajectories can also take time, but you can reduce the drawing–see “Viewing and Retaining of trajectories” above. You can cancel SIMION drawing at any time by pressing the ESC key, which is helpful if drawing is taking a long time.

A good 3D graphics card can help with the 3D OpenGL viewing in SL Tools and SIMION 8.0/8.1 “Modify 3D” views but will not affect other views. In SIMION® 8.1, Multicore CPU support parallelizes the rendering of the other views some.

RAM and Disk Speed

See RAM and Memory for some notes about RAM and hard disk speeds. RAM speed is important (see cache notes above); hard disk speed typically less so.

Performance Improvements in SIMION 8.1 from 8.0

See SIMION® 8.1 for details. Areas include in particular Multicore CPU support.

Performance Improvements in SIMION 8.0 from 7.0

Initial measurements showed SIMION 8.0beta having refine and fly times reduced at least ~20-40% from 7.0. A more recent report by Theo was 2.5x faster fly times. This improvement was largely due to new compiler technology/optimizations and improved display optimizations. More exact benchmarks still need to be done, but SIMION 8 is markedly faster.

Viewing PAs (e.g. rotating/zooming) can be significantly faster in SIMION 8.0 Modify Screen “3D” view (or SL Tools 1.1.0) due to the optimized OpenGL viewing, especially if you have a reasonable 3D graphics card.

Any comments on this web page? (will be sent to SIS SIMION Support)
[Optional] Your name: email: phone/fax: