The Visual Setup makes setting up simulations much simpler than writing an input
file, but the output messages when a simulation crashes can be mysterious. If a
simulation crashes before the engine takes the first step, it is more than likely
that there is an error in the .sdf
file. Documented below are some common
errors, and the output messages they will create at runtime. If your simulation is
crashing before the first step, take a look to see if any of the error messages
shown below matches yours.
If your error message is NOT below, send an email to support@txcorp.com
and an Application Engineer will take a look at your simulation, and maybe your
error will show up in the documentation for the next release!
.in
file for any unevaluated expressions..sdf
file. Either a variable used in the
simulation isn’t present or is miss-named, or an attribute isn’t set/is left blank. Try
to figure out what the “%%%%%%” object is in the simulation then figure out what is missing.
See below for some specific examples the examples.The following error was created in a simulation that had a constant named BEAM_RADIUS but had a SpaceTimeFunction that used “BEAMRADIUS”.
Here, the unknown expression (“undefined symbol”) was printed out, providing an avenue for beginning the debugging process.
This error was from the same simulation as the error above. A history to count the number of physical particles was added, but the species was left blank.
Unlike the error above, there is no “ERROR: …” statement printed out. The nature of the error has been highlighted in the image below for visibility. Sometimes, the nature of the error can be buried in the output, so keep a sharp eye out for statements like the one below, because it does (indirectly) point to the cause of the crash.
This error is very similar to the one above (History Attribute Not Set). In this case a Dirichlet boundary condition named “dirichlet1” was added to the simulation, but a surface for the boundary condition was not specified.
The name of the boundary condition that was added was “dirichlet1”. In the image below, notice that this name appears in the error message (“Object dirichlet1Filler …”).
This error arose when two, overlapping CSG geometry objects were used to set the voltage on a region in the simulation, so the voltage was over-specified.
Depending on which electrostatic solver is being used, a different message will be output. The first error message below was the result when using the “superLU” direct solver:
This message was output when using the “gmres” iterative solver:
This is an example of an error where the printed error statement provided little to no help in debugging, unless you are deeply familiar with matrix solver packages (Epetra constructs matrices and is the part of the Trilinos Library which is used by VSim).
The cause of this error is that there are insufficient boundary conditions resulting in an in complete matrix. If you see this error, adjust your boundary conditions to make sure boundary conditions are completely set on all boundaries of the simulation Note: geometries cannot be used to set boundary conditions on the walls/boundaries (lower x, upper x, lower y, etc.) of a simulation.
Below is an example of what happens when a particle loader is not setup correctly. This is another more mysterious error message, since after the “ERROR: In Setting up simulation” there is very little to indicate the location of the bug. However, notice that the last thing printed before the error was “Sources are: /n particleLoader0”. This is a hint as to where to check your input file.