Troubleshooting

First, check the consistence of your input meteo data. Best you watch the whole timeline and follow the guideline from Snowpack in Snowpack's documentation

Arithmetic exception

In numerical models such as Alpine3D, there is a risk of performing invalid arithmetics such as arithmetics with very small or very large numbers of even divisions by zero (although these should have been identified in the code before attempting the division, bugs happen!). Instead of running as if nothing happened, Alpine3D has been configured by default to throw an exception when running on Linux (see the line feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW ); in AlpineMain.cc). Of course, this can be turned off in CMake by setting DEBUG_ARITHM to false. But this feature is very valuable in order to produce better quality simulations (since invalid arithmetics tends to produce numerical noise in the final results).

So, when a simulation has stopped with an arithmetic exception, follow these steps (obviously step 1. should best be done before even running your simulation):

1. enable core dumps on your system
   • sudo systemctl disable apport for Ubuntu since Ubuntu has its own apport system to process core dumps
   • sudo sysctl -w kernel.core_pattern=/tmp/core-%u so core files will appear in /tmp as "core.{userid}"
   • ulimit -c unknown in the shell where you will run your simulation in order to allow unlimited core sizes (the core file could get as big as your system memory, so you'd better clean these once you're done!)
2. run your simulation until the exception is thrown
3. open the core file to retrieve the information (if we assume that Alpine3D was compiled with g++)
   • run gdb {alpine3d binary with path} /tmp/core-{userid}
   • show the backtrace by typing bt (or bt full) at gdb's command prompt. Now you see exactly where the arithmetic exception occured
   • print the value of variables by typing print {var} at gdb's command prompt
   • you can move up/down the call stack by typing frame {frame number} at gdb's command prompt
   • quit gdb by typing quit at gdb's command prompt
4. either fix the problem your self or contact Alpine3D's developers with your findings (and at least a copy of the backtrace)

There is an example session using gdb to look at core files here.

Meteo input check

Next you check which data Alpine3D gets as input for a given time step. The sensor names show here are the name used by Alpine3D: meteo_reading date (with date as an ISO Timestring, e.g. 2013-03-18T21:00)

sample output:

    5 stations with an average sampling rate of 0.000661461 or 1 point every 25.1967 minutes
    ---------- Station: 1 / 5
    <meteo>
    <station>
    <Coords>
    Altitude    2441.26
    Lat/Long    (46°19'14.676351" , 7°21'59.677976")
    Lat/Long    (46.3207 , 7.36658)
    X/Y_coords  (594450 , 129930)
    I/J_indices (-999 , -999)
    Projection  CH1903 
    EPSG        21781
    </Coords>
    ID:    VDS2
    Name:  Schneestation - VDLS2
    Slope: -999 bearing: -999
    </station>
    2013-03-18T21:00 (2456370.375) GMT+1
          TA:         263.55
          RH:           0.98
         TSS:         263.65
          HS:           2.94
          VW:            1.5
          DW:            340
      VW_MAX:            8.2
        PSUM:              0
        RSWR:              0
         TS0:         273.15
         TS1:         272.85
         TS3:         270.95
    </meteo>

In this example, the precipitation is called in the meteo data PINT but meteoIO transforms it into PSUM. This need to get excluded because for IMIS meteo stations where this value is underestimated in winter due to the lack of a internal heating of the rain gauge. The exclusion must be made in IO.INI file with the alpine3D field name (or both field names...):

    [InputEditing]
    VDS2::EDIT1 = EXCLUDE
    VDS2::ARG1::PARAMS = PSUM

Gradient check

Check that the gradient is correctly for a given timestring 2D_interpolations 2013-03-18T21:00

(Tip: set up grid output to PNG to get images for easy displaying by writing the following in your IO.INI after regular GRID2D = ...

    ; write PNG for '2d_interpolation'
    GRID2D      = PNG
    GRID2DPATH      = ./
    PNG_MIN_SIZE    = 1500x1500

The output will be .png images of the domain with the parameters defined in 2D_interpolations.

Output definitions in 2D_interpolations will look like:

    ...
    //performing spatial interpolations
    Grid2DObject param;
    io.getMeteoData(d1, dem, MeteoData::TA, param);
    io.write2DGrid(param, MeteoGrids::TA, d1);
    io.getMeteoData(d1, dem, MeteoData::HNW, param);
    io.write2DGrid(param, MeteoGrids::HNW, d1);
    io.getMeteoData(d1, dem, MeteoData::RH, param);
    io.write2DGrid(param, MeteoGrids::RH, d1);
    io.getMeteoData(d1, dem, MeteoData::ILWR, param);
    io.write2DGrid(param, MeteoGrids::ILWR, d1);
    io.getMeteoData(d1, dem, MeteoData::VW, param);
    io.write2DGrid(param, MeteoGrids::VW, d1);
    io.getMeteoData(d1, dem, MeteoData::DW, param);
    io.write2DGrid(param, MeteoGrids::DW, d1);
    ...

That will produce a .PNG file for each TA, HNW, RH, ILWR, VW, DW, as well as some standarts to the DEM like slope, elevation and exposition.