[[Image:ff settings.png|thumb|left|150px|Adding an RCS observable for the Mirage project]]
===Observables===
First, we create an RCS observable with one degree increments in both phi and theta directions. Although increasing the angular resolution of our farfield will significantly increase simulation time, The RCS of electrically large structures tend to have very narrow peaks and nulls, so the resolution is required.
We also create two field sensors -- one with a z-normal underneath the aircraft, and another with an x-normal along the length of the aircraft. The nearfields are not the prime observable for this project, but they may add insight into the simulation, and do not add much overhead to the simulation.
===Planewave Source===
Since we're computing a Radar Cross Section, we also need to add a planewave source. For this example, we will specify a TMz planewave with k = sqrt(2)/2 x - sqrt(2)/2 z, or theta = 135 degrees, phi = 0 degrees.
[[Image:Large struct article mesh detail.pngâ|thumb|left|200px|Mesh detail near the cockpit region of the aircraft.]]
===Mesh Settings===
For the mesh, we use the "Fast Run/Low Memory Settings" preset. This will set the minimum mesh rate at 15 cells per lambda, and permits grid adaptation only where necessary. This preset provides slightly less accuracy than the "High Precision Mesh Settings" preset, but results in smaller meshes, and therefore shorter run times.
At 850 MHz, the resulting FDTD mesh is about 270 million cells. With mesh-mode on in [[EM.Cube]], we can visually inspect the mesh.  ===Engine Settings===For the engine settings, we use the default settings, except for "Thread Factor". The "Thread Factor" setting essentially tells the FDTD engine how many CPU threads to use during the time-marching loop. For a given system, some experimentation may be needed to determine the best number of threads to use. In many cases, using half of the available hardware concurrency works well. This comes as a result of there often being two cores per memory port on many modern processors. In other words, for many problems, the FDTD solver cannot load and store data from CPU memory quickly enough to use all available threads or hardware concurrency. The extra threads are idling waiting for data, and a performance hit is incurred due to increased thread context switching. Also,  After the sources, observables, and mesh are set up, the simulation is ready to be run.
<br clear="all" />