| 11 | | In order to pin down exactly what the problem is, you can recompile ORCHIDEE with debug flags. These flags enable extra checks on code execution to identify unwanted behavior. |
| 12 | | |
| 13 | | ''DSG_review: the following paragraph on background information should be (re)moved to somewhere else '' |
| 14 | | |
| 15 | | Why aren't these checks enabled by default? Speed. If you make certain assumptions, things will go much faster. For example, let's say we have a one-dimensional array with ten elements: ARRAY(1:10). Asking the question, "Are we correctly accessing this array?" is not too difficult to ask (checking to see if the element number we are trying to access is between 1 and 10), and Fortran is actually ahead of other languages here in requiring that each element of the array be within bounds (See Section 6.5.3 of the Fortran 2008 standard, for example: "The value of a subscript in an array element shall be within the bounds for its dimension."). Fortran should die with a segmentation fault if you have an array A(1:10,1:5) and you try to access A(11,1), while other languages will accept it because the offset of that address is still within the memory allocated for the array. In general, checks like this take time, in particular if you want to know exactly which line number is causing the crash. |
| 16 | | |
| 17 | | ''DSG_review: the following paragraph: it isn't clear what the shortest time possible is referring to (maybe one could link to the other wiki pages which describe (reducing nproc, etc) '' |
| 18 | | |
| 19 | | To turn on all these checks, we change the compiler flags. Adding these checks can make your code run 10 times slower, so after turning on these flags, the first step is often to find the conditions that reproduce your crash in the shortest time possible (reducing the number of processors, reducing the spatial domain or using restart files to start the simulation the day before the crash). |
| | 11 | In order to pin down exactly what and where the problem is, you can recompile ORCHIDEE with debug flags. These flags enable extra checks on code execution to identify unwanted behavior. |
| 22 | | |
| | 14 | |
| | 15 | '''Why aren't these checks enabled by default? Speed'''. For example, let's say we have a one-dimensional array with ten elements: ARRAY(1:10). Asking the question, "Are we correctly accessing this array?" is not too difficult to ask (checking to see if the element number we are trying to access is between 1 and 10), and Fortran is actually ahead of other languages here in requiring that each element of the array be within bounds (See Section 6.5.3 of the Fortran 2008 standard, for example: "The value of a subscript in an array element shall be within the bounds for its dimension."). Fortran should die with a segmentation fault if you have an array A(1:10,1:5) and you try to access A(11,1), while other languages will accept it because the offset of that address is still within the memory allocated for the array. In general, checks like this take time, in particular if you want to know exactly which line number is causing the crash. So you should not be surprised if execution is much slower in debug mode, possibly by a factor 10! |
| | 16 | |
| | 17 | '''Therefore, the first step is often to define conditions that reproduce your crash in the shortest CPU time possible''', by reducing the spatial domain and using restart files to start the simulation the day before the crash. It also allows you to use high frequency output, to look at what happens before the problem, and to reduce the number of processors, as it makes everything easier. |
| | 18 | |
| | 19 | To achieve this, adapt your config.card file following http://forge.ipsl.jussieu.fr/igcmg_doc/wiki/Doc/Setup#config.card and http://forge.ipsl.jussieu.fr/igcmg_doc/wiki/Doc/Setup#Setupinitialstateforthesimulation |
| | 20 | |
| | 21 | When your proble is solved, don't forget to remove the debug argument or your run will take forever! |
