When you come upon something that might be a bug, there are some extra steps you can do up-front that will help us to more quickly determine the root-cause of the bug and fix it.
- Collect relevant data
- Program output -- what output files were your trying to create, where are they, how big are they, how big did you expect them to be; in most cases, we don't need to see the entire output file, but output from '
ls -l' might be useful
- Program-version output -- re-run the code with '
showversion=yes' to get the version info for all the modules used in the simulator; you can also try running the Unix command 'grep RCSID *.c *.h'
- Screen output -- note that even if you capture the output of your program into a file, you may miss std-error output; always include the screen output in your bug report
- Input file -- it is always useful to include segments of, or even the entire, input file that you used
- Memory usage -- try running '
top' or 'ps' to find out how much memory was being used near the time when the bug shows up; is memory use continuing to grow as the program runs?
- Other environmental factors -- try running '
ps -Af' or 'ps -a' to see what other programs are running when yours crashed; were other programs using up large amounts of memory?
- Re-run the code with the same input
- If a different error/bug appears, or it happens at a later point (e.g. the output files are a different size than the first run), then there might be a "race condition" in the parallel code
- If the exact same bug happens again, then it is a bug in the "sequential" part of the code
- Note: If a bug only shows up intermittently, it may still be a bug, and you should still report it -- just let us know that it is intermittent and see if you can qualify or quantify how the environment is different when it works versus when it breaks
- If possible, re-run the code with slightly different inputs
- Comparison to Previous Simulators -- often, people will develop a simple simulation first, then add in complexity one module at a time; if so, what modules have you added since the last known-good run?
- Stimulus Module -- very large stimuli can cause numerical issues, try running with a zero-strength stimulus (this means that there is a stimulus, so all parts of the code get exercised, but it applies zero-current so no numeric problems should occur)
- Membrane Modules -- many membrane modules contain code that can be numerically "fickle"; if you changed "G_na" from the default parameter, let us know
- Decrease delta-t -- probably more than any other factor, decreasing the delta-t of a simulator can often reduce the effects of numerical instabilities; of course, it means your code takes longer to run; try cutting delta-t in half or even by 10
