|
|
|
|
|
The code is designed to be autonomous and self-aware. It should explain if something goes wrong. There are generally two sources of problems - the path does not properly point to the data directory or the code was compiled with aggressive optimization.
|
|
|
|
|
|
First run a [smoke test](http://www.computer-dictionary-online.org/index.asp?q=smoke+test) to see if the code works. Execute the code with the single command "test". To do this, if the executable is called "cloudy.exe" and a carriage return is "<cr>", type
|
|
|
|
|
|
```
|
|
|
./cloudy.exe <cr>
|
|
|
test <cr>
|
|
|
<cr>
|
|
|
```
|
|
|
|
|
|
You could also create a file ("test.in") and enter the word "test" as the first and only line in the file. Then execute the code by typing
|
|
|
|
|
|
```
|
|
|
./cloudy.exe -r test <cr>
|
|
|
```
|
|
|
|
|
|
the file `test.out` will be created.
|
|
|
Have a look at the output. It is described in detail in a chapter in Part 3 of Hazy. This test passed if the last line of output says the following:
|
|
|
|
|
|
```
|
|
|
[Stop in main() at .maincl.cpp:331, Cloudy exited OK]
|
|
|
```
|
|
|
|
|
|
|
|
|
## If the smoke test goes up in flames
|
|
|
|
|
|
There are two reasons the test could fail, the path has not been set properly and compiler bugs.
|
|
|
|
|
|
If the path has not been set properly then the code will not be able to find its data files. It will say so, and explain what path was used. Review the instructions for setting the path (see the page EditPath), fix it, recompile the code, and try again.
|
|
|
|
|
|
It is also possible that the compiler did not produce correct code. Cloudy is designed to be autonomous and self aware. If it fails any of its internal sanity checks then it will exit with an error condition, most likely a thrown assert. For serious compiler bugs there may be a hardware exception (computer-ese for, "it crashes"). This is almost always caused by compiler bugs. Turn down the level of optimization (with the `-O0` option on most compilers), recompile the entire code, and try again. See the CompileCode page for notes on aggressive optimization.
|
|
|
|
|
|
If even a non-optimized run crashes then it is likely that the compiler has not been set up properly on your system. Create a
|
|
|
[hello world](http://en.wikipedia.org/wiki/Hello_world) program to see if anything works. Create a file called `hello.cpp` and enter the following into it
|
|
|
|
|
|
```
|
|
|
#include <stdio.h>
|
|
|
int main()
|
|
|
{
|
|
|
printf ("Hello World!\
|
|
|
");
|
|
|
}
|
|
|
```
|
|
|
|
|
|
Compile `hello.cpp` and run it. If this crashes your compiler is broken. Talk to your system administrator.
|
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
|
# Check that it crashes on errors
|
|
|
|
|
|
It would be good if the code crashed on divide by zero, overflow,
|
|
|
using [NaN](http://www.computer-dictionary-online.org/?q=Not-a-Number),
|
|
|
and (for the debug compile) a failed assert.
|
|
|
The *crash* subdirectory in the test suite directory includes input scripts that should cause
|
|
|
the code to crash.
|
|
|
Or you can simply run the following four tests to check that the code does crash.
|
|
|
|
|
|
```
|
|
|
title confirm it crashes on overflow
|
|
|
crash overflow
|
|
|
|
|
|
title confirm it crashes on divide by zero
|
|
|
crash zero
|
|
|
|
|
|
title confirm it crashes when using NaN (not a number)
|
|
|
crash NaN
|
|
|
|
|
|
title confirm it crashes with a failed assert
|
|
|
crash assert
|
|
|
|
|
|
```
|
|
|
|
|
|
This uses the *crash* command, which is implemented in routine `ParseCrashDo`, to confirm that the code will crash on division by zero, overflow, use of NaN, the ASSERT macro used for internal code consistency checks, and array bounds checking.
|
|
|
|
|
|
In some compilers the routine `ParseCrashDo` will not work properly unless it is compiled without optimization since the compiler may detect that the results of the unsafe code are not used elsewhere in Cloudy, and simply not do the evaluation. With icc and the native SGI compiler you need to explicitly include the -O0 command line option to achieve this since optimization is the default. This could also apply to other compilers that we haven't tested. This is only to confirm that the crash will occur with the crash command, with these compilers safe code (code that will crash after a floating point error) is still produced with higher optimization, but the crash command itself will be optimized away.
|
|
|
|
|
|
Crash assert is a special case. It might only fail when the code is compiled in debug mode since asserts may not exist in optimized code. If the code is compiled correctly and the asserts are working, then the calculation will end with statements saying that something bad has happened. This is the normal termination for a crash due to a failed assert and means that everything is fine.
|
|
|
|
|
|
If the code does not crash on each of these tests then your system is quite happy with bad floating point math or failed asserts. It is quite possible that you will not be able to get your system to crash on floating point errors. (This seems to get harder every year.) This is not a major problem but is something that should be kept in mind.
|
|
|
|
|
|
------
|
|
|
|
|
|
Next step, [RunCode](RunCode), explains how to run the code
|
|
|
|
|
|
Return to [StepByStep](StepByStep) instructions
|
|
|
|
|
|
----- |