Segmentation fault on occultations with data at very high altitude

[Stig Syndergaard]

Happens rarely (one case found) where apparantly an array becomes too large (perhaps some internal stack overflow) because of a very large occ input file:

ropp_pp_occ_tool occ_20140705_064620_C005_G014_O_2200.nc -o atm_20140705_064620_C005_G014_O_2200.nc -c /home/ssy/dvl/ropp/trunk/ropp_pp/debian/etc/cosmic_pp_dmi.cf

trunk was dmi_tag_7.1_GPAC_0.4.0. The problem is in line 534 of bangle/ropp_pp_dct.f90 where UH(:) is of size ~2000000 compared to normally less than 200000 (10 times smaller). This occultation starts at 360 km, which is quite atypical.

Perhaps the problem should just be fixed by including better checks on the extreme altitudes Pmin and Pmax in ropp_pp_occ_tool. Setting an upper limit would exclude this occultation from being processed, although it might in principle be okay. There are other limits in ROPP such as the dtime limited to 240 s, which seems to have resulted in a cut off of the lower part. So perhaps there also needs to be a height limit in ucar2ropp or it should perhaps be run with no-ranchk.

Investigate more an fix it.

[Stig Syndergaard]

input occ file

[Stig Syndergaard]

ucar2ropp with -u ensures that dtime is not limited to 240 s. To be implemented in GPAC 2.3.0 profile chain.