nlesc / enram Goto Github PK

License: Apache License 2.0

C 3.43% MATLAB 0.23% Java 2.12% Shell 0.42% IDL 83.02% Prolog 10.78% Makefile 0.01%

enram's Introduction

This repository contains all the source code that is necessary to read and process radar data from various European weather radars

enram's People

Contributors

Stargazers

Watchers

Forkers

adokter jquistiano vrnvikas marwa19ahmed ahmed-andalib jiongxiao ntung hubaka kousai1 joinalahmed

enram's Issues

there are many common blocks that should hold the same information...

but don't

see e.g.:

bird_call.pro (enram/src/vol2bird)
get_bird_ppi.pro (enram/src/visualisation/map)
get_ppi.pro (enram/src/visualisation/map)
get_prof.pro (enram/src/visualisation/map)
vol2ppi.pro (enram/src/visualisation/map)
vol2ppi.pro (enram/visualisation/map/
get_prof.pro (enram/visualisation/map/)
get_bird_ppi.pro (enram/visualisation/map/)
get_ppi.pro (enram/visualisation/map/)

bug in updatemap due to inline changing of array elements

|---|---|---|---|
|3|3|3|3|

error with IEDUB, IESHA stations

I'm getting this message in standard error log:

mv: cannot move â€˜/home/wbouten/enram/testdata/harmonized/odim/IE_dub/20110816/T_PAGZ41_C_EIDB_20110816190600.h5â€™ to â€˜/usr/people/graafdem/FLYSAFE/process/data/odim/IE_b/2/quarantined/â€™: No such file or directory

Makes sense that I can't move the files, since the target directory doesn't exist, but why would you want to move those files anyway? Not clear to me.

HDF5 error in histogram.pro with stations CZBRD and CZSKA

IDL Version 8.2.3 (linux x86_64 m64). (c) 2013, Exelis Visual Information Solutions, Inc.
Installation number: 88800.
Licensed for use by: University of Amsterdam

% Compiled module: $MAIN$.
% Compiled module: READSTATIONLIST.
% Compiled module: RADAR_NAMES.
% Compiled module: COMMON_DEFINITION.
% Compiled module: RADAR_DEFINITIONS.
% Compiled module: JULDAY.
% Compiled module: VOL2BIRD_CZ_ODIMHDF5.
% Compiled module: CALDAT.
% Compiled module: STATISTICS.
% Loaded DLM: HDF5.
% H5F_OPEN: unable to open file: Object Name:"/home/wbouten/enram/testdata/harm
onized/odim/CZ_brd/20110815/T_PAHZ60_C_OKPR_20110815000447.hdf"
% Execution halted at: VOL2BIRD_CZ_ODIMHDF5_READ_SCAN 298
/home/wbouten/enram/src/io/vol2bird_cz_odimhdf5.pro
% STATISTICS 94
/home/wbouten/enram/src/process/statistics.pro
% $MAIN$ 187
/home/wbouten/enram/src/process/histogram.pro

radar_names.pro does not check for erroneous labels

although it does check for an empty list of stations.

local copies exist of variables from the COMMON block...with local modifications (of course)

the local DBZFACTOR is set to 335.4, effectively making the DBZFACTOR from the COMMON block useless.
e.g. in
src/visualisation/map/get_bird_ppi.pro

but in all likelihood also in many other files

possible bug in updatemap: nCellsValid does not check for cellProp[].drop

    /*Sort the cells by minCellArea and determine number of valid cells*/
    sortcells(cellProp,nCells,BYAREA);

    while (nCellsValid>0 && cellProp[nCellsValid-1].area<minCellArea){

        // FIXME possible error: the condition above does not
        // take into account the value of cellProp[].drop
        nCellsValid--;
    }

tex initialized with unexpected value in calcTexture -- why?

In calcTexture,

tex = texOffset; // FIXME why does this variable have a value at this point?

possible bug in analysecells

In this piece of code from analysecells(),

    /*Determine which cells to drop from map based on low mean dBZ / high stdev /
     * small area / high percentage clutter*/
    for (iCell = 0; iCell < nCells; iCell++) {
        if (dualpolflag == 1){
            if (cellProp[iCell].area < areaMin) {
                cellProp[iCell].drop = 1;
            }
        }
        else {
            if (cellProp[iCell].area < areaMin ||
                (cellProp[iCell].dbzAvg < cellDbzMin &&
                 cellProp[iCell].texAvg > cellStdDevMax &&
                 (cellProp[iCell].clutterArea / cellProp[iCell].area) < cellClutterFraction )) {
                // FIXME I don't see how this condition is correct -- why are terms 2,3 and
                // 4 combined with &&
                cellProp[iCell].drop = 1;
            }
        }
    }

it seems more logical to combine the terms in the last if statement using || rather than &&, since any clause is sufficient to drop the cell.

PDF figures near the end of the readme.pdf need to be updated

what is the meaning of rCellMax?

What is the meaning and unit of rCellMax?

if ((iRang + 1) * texRangeScale > rCellMax) {
    // FIXME the left hand side of the condition above is a distance; the
    // right hand side's data type suggests a number of array elements
    continue;
}

unsigned v. signed integer in HDF5 files

when I compare

/home/wbouten/enram/testdata/harmonized/cluttermaps/FR_abb/RAD_FR_abb_CLT_15082011_PRC0.h5
the corresponding file that martin generated

I have 16-bit unsigned integers while martin has 16-bit signed integers in dataset1/data1

I want to make them to be equal, because then its easier to test for equality using h5diff

add const where applicable in the c code

error in histogram.pro for station HRBIL

IDL Version 8.2.3 (linux x86_64 m64). (c) 2013, Exelis Visual Information Solutions, Inc.
Installation number: 88800.
Licensed for use by: University of Amsterdam

% Compiled module: $MAIN$.
% Compiled module: READSTATIONLIST.
% Compiled module: RADAR_NAMES.
% Variable is undefined: .
% Execution halted at: $MAIN$ 24
/home/wbouten/enram/src/process/histogram.pro

duplicate visualization routines?

what is the difference between

enram/src/visualization/multi_prof.pro
and
enram/src/visualization/multi_prof_2.pro

calculation of indexes in local neighborhood wrong

(commit e5218e0)

The local index calculation does not always yield the right values. Below is an overview for a small data set with 3 rows (nAzim) and 4 cols (nRang); the dimensions of the neighborhood are 3x3. Remember that

iAzim=nAzim-1 is in fact adjacent to iAzim=0 due to polar coordinates;
iRang=0 is most certainly not adjacent to iRang = nRang-1.

The table specifies which parts of the array are affected:

	iRang = 0	iRang = 3
iAzim = 0	1	1
iAzim = 1	1	1
iAzim = 2	1	1

This bug affects the calculation of texture, as well as most other functions.

iAzim=0,iRang=0,iNeighborhood=0;iAzimLocal=2,iRangLocal=-1:iLocal=7
iAzim=0,iRang=0,iNeighborhood=1;iAzimLocal=2,iRangLocal=0:iLocal=8
iAzim=0,iRang=0,iNeighborhood=2;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=0,iRang=0,iNeighborhood=3;iAzimLocal=0,iRangLocal=-1:iLocal=-1
iAzim=0,iRang=0,iNeighborhood=4;iAzimLocal=0,iRangLocal=0:iLocal=0
iAzim=0,iRang=0,iNeighborhood=5;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=0,iRang=0,iNeighborhood=6;iAzimLocal=1,iRangLocal=-1:iLocal=3
iAzim=0,iRang=0,iNeighborhood=7;iAzimLocal=1,iRangLocal=0:iLocal=4
iAzim=0,iRang=0,iNeighborhood=8;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=0,iRang=1,iNeighborhood=0;iAzimLocal=2,iRangLocal=0:iLocal=8
iAzim=0,iRang=1,iNeighborhood=1;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=0,iRang=1,iNeighborhood=2;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=0,iRang=1,iNeighborhood=3;iAzimLocal=0,iRangLocal=0:iLocal=0
iAzim=0,iRang=1,iNeighborhood=4;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=0,iRang=1,iNeighborhood=5;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=0,iRang=1,iNeighborhood=6;iAzimLocal=1,iRangLocal=0:iLocal=4
iAzim=0,iRang=1,iNeighborhood=7;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=0,iRang=1,iNeighborhood=8;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=0,iRang=2,iNeighborhood=0;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=0,iRang=2,iNeighborhood=1;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=0,iRang=2,iNeighborhood=2;iAzimLocal=2,iRangLocal=3:iLocal=11
iAzim=0,iRang=2,iNeighborhood=3;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=0,iRang=2,iNeighborhood=4;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=0,iRang=2,iNeighborhood=5;iAzimLocal=0,iRangLocal=3:iLocal=3
iAzim=0,iRang=2,iNeighborhood=6;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=0,iRang=2,iNeighborhood=7;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=0,iRang=2,iNeighborhood=8;iAzimLocal=1,iRangLocal=3:iLocal=7
iAzim=0,iRang=3,iNeighborhood=0;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=0,iRang=3,iNeighborhood=1;iAzimLocal=2,iRangLocal=3:iLocal=11
iAzim=0,iRang=3,iNeighborhood=2;iAzimLocal=2,iRangLocal=4:iLocal=12
iAzim=0,iRang=3,iNeighborhood=3;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=0,iRang=3,iNeighborhood=4;iAzimLocal=0,iRangLocal=3:iLocal=3
iAzim=0,iRang=3,iNeighborhood=5;iAzimLocal=0,iRangLocal=4:iLocal=4
iAzim=0,iRang=3,iNeighborhood=6;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=0,iRang=3,iNeighborhood=7;iAzimLocal=1,iRangLocal=3:iLocal=7
iAzim=0,iRang=3,iNeighborhood=8;iAzimLocal=1,iRangLocal=4:iLocal=8
iAzim=1,iRang=0,iNeighborhood=0;iAzimLocal=0,iRangLocal=-1:iLocal=-1
iAzim=1,iRang=0,iNeighborhood=1;iAzimLocal=0,iRangLocal=0:iLocal=0
iAzim=1,iRang=0,iNeighborhood=2;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=1,iRang=0,iNeighborhood=3;iAzimLocal=1,iRangLocal=-1:iLocal=3
iAzim=1,iRang=0,iNeighborhood=4;iAzimLocal=1,iRangLocal=0:iLocal=4
iAzim=1,iRang=0,iNeighborhood=5;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=1,iRang=0,iNeighborhood=6;iAzimLocal=2,iRangLocal=-1:iLocal=7
iAzim=1,iRang=0,iNeighborhood=7;iAzimLocal=2,iRangLocal=0:iLocal=8
iAzim=1,iRang=0,iNeighborhood=8;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=1,iRang=1,iNeighborhood=0;iAzimLocal=0,iRangLocal=0:iLocal=0
iAzim=1,iRang=1,iNeighborhood=1;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=1,iRang=1,iNeighborhood=2;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=1,iRang=1,iNeighborhood=3;iAzimLocal=1,iRangLocal=0:iLocal=4
iAzim=1,iRang=1,iNeighborhood=4;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=1,iRang=1,iNeighborhood=5;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=1,iRang=1,iNeighborhood=6;iAzimLocal=2,iRangLocal=0:iLocal=8
iAzim=1,iRang=1,iNeighborhood=7;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=1,iRang=1,iNeighborhood=8;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=1,iRang=2,iNeighborhood=0;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=1,iRang=2,iNeighborhood=1;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=1,iRang=2,iNeighborhood=2;iAzimLocal=0,iRangLocal=3:iLocal=3
iAzim=1,iRang=2,iNeighborhood=3;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=1,iRang=2,iNeighborhood=4;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=1,iRang=2,iNeighborhood=5;iAzimLocal=1,iRangLocal=3:iLocal=7
iAzim=1,iRang=2,iNeighborhood=6;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=1,iRang=2,iNeighborhood=7;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=1,iRang=2,iNeighborhood=8;iAzimLocal=2,iRangLocal=3:iLocal=11
iAzim=1,iRang=3,iNeighborhood=0;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=1,iRang=3,iNeighborhood=1;iAzimLocal=0,iRangLocal=3:iLocal=3
iAzim=1,iRang=3,iNeighborhood=2;iAzimLocal=0,iRangLocal=4:iLocal=4
iAzim=1,iRang=3,iNeighborhood=3;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=1,iRang=3,iNeighborhood=4;iAzimLocal=1,iRangLocal=3:iLocal=7
iAzim=1,iRang=3,iNeighborhood=5;iAzimLocal=1,iRangLocal=4:iLocal=8
iAzim=1,iRang=3,iNeighborhood=6;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=1,iRang=3,iNeighborhood=7;iAzimLocal=2,iRangLocal=3:iLocal=11
iAzim=1,iRang=3,iNeighborhood=8;iAzimLocal=2,iRangLocal=4:iLocal=12
iAzim=2,iRang=0,iNeighborhood=0;iAzimLocal=1,iRangLocal=-1:iLocal=3
iAzim=2,iRang=0,iNeighborhood=1;iAzimLocal=1,iRangLocal=0:iLocal=4
iAzim=2,iRang=0,iNeighborhood=2;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=2,iRang=0,iNeighborhood=3;iAzimLocal=2,iRangLocal=-1:iLocal=7
iAzim=2,iRang=0,iNeighborhood=4;iAzimLocal=2,iRangLocal=0:iLocal=8
iAzim=2,iRang=0,iNeighborhood=5;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=2,iRang=0,iNeighborhood=6;iAzimLocal=0,iRangLocal=-1:iLocal=-1
iAzim=2,iRang=0,iNeighborhood=7;iAzimLocal=0,iRangLocal=0:iLocal=0
iAzim=2,iRang=0,iNeighborhood=8;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=2,iRang=1,iNeighborhood=0;iAzimLocal=1,iRangLocal=0:iLocal=4
iAzim=2,iRang=1,iNeighborhood=1;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=2,iRang=1,iNeighborhood=2;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=2,iRang=1,iNeighborhood=3;iAzimLocal=2,iRangLocal=0:iLocal=8
iAzim=2,iRang=1,iNeighborhood=4;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=2,iRang=1,iNeighborhood=5;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=2,iRang=1,iNeighborhood=6;iAzimLocal=0,iRangLocal=0:iLocal=0
iAzim=2,iRang=1,iNeighborhood=7;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=2,iRang=1,iNeighborhood=8;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=2,iRang=2,iNeighborhood=0;iAzimLocal=1,iRangLocal=1:iLocal=5
iAzim=2,iRang=2,iNeighborhood=1;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=2,iRang=2,iNeighborhood=2;iAzimLocal=1,iRangLocal=3:iLocal=7
iAzim=2,iRang=2,iNeighborhood=3;iAzimLocal=2,iRangLocal=1:iLocal=9
iAzim=2,iRang=2,iNeighborhood=4;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=2,iRang=2,iNeighborhood=5;iAzimLocal=2,iRangLocal=3:iLocal=11
iAzim=2,iRang=2,iNeighborhood=6;iAzimLocal=0,iRangLocal=1:iLocal=1
iAzim=2,iRang=2,iNeighborhood=7;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=2,iRang=2,iNeighborhood=8;iAzimLocal=0,iRangLocal=3:iLocal=3
iAzim=2,iRang=3,iNeighborhood=0;iAzimLocal=1,iRangLocal=2:iLocal=6
iAzim=2,iRang=3,iNeighborhood=1;iAzimLocal=1,iRangLocal=3:iLocal=7
iAzim=2,iRang=3,iNeighborhood=2;iAzimLocal=1,iRangLocal=4:iLocal=8
iAzim=2,iRang=3,iNeighborhood=3;iAzimLocal=2,iRangLocal=2:iLocal=10
iAzim=2,iRang=3,iNeighborhood=4;iAzimLocal=2,iRangLocal=3:iLocal=11
iAzim=2,iRang=3,iNeighborhood=5;iAzimLocal=2,iRangLocal=4:iLocal=12
iAzim=2,iRang=3,iNeighborhood=6;iAzimLocal=0,iRangLocal=2:iLocal=2
iAzim=2,iRang=3,iNeighborhood=7;iAzimLocal=0,iRangLocal=3:iLocal=3
iAzim=2,iRang=3,iNeighborhood=8;iAzimLocal=0,iRangLocal=4:iLocal=4

analyzeCells hangs sometimes

when I run the unit test for analyzeCells, it hangs sometimes. The JNI coupling does not seem to be the culprit, because if I comment out the call to analyzeCells in libvol2bird, then recompile, and re-run the unit test, it does work. So apparently there's still a bug in libvol2bird/analyzeCells.

can i delete any dual polarity flags related stuff

since we're not using that at the moment, only Doppler

cleanup contents of src/visualisation/map

done.

dbz value at iGlobal counted double

excerpt from calcTexture

            iGlobal = iRang + iAzim * nRang;

            /* count number of direct neighbours above threshold */
            count = 0;
            vmoment1 = 0;
            vmoment2 = 0;

            dbz = dbzOffset + dbzScale * dbzImage[iGlobal];

            for (iNeighborhood = 0; iNeighborhood < nNeighborhood; iNeighborhood++) {

                iLocal = findNearbyGateIndex(nAzim,nRang,iGlobal,nAzimNeighborhood,nRangNeighborhood,iNeighborhood);

                if (iLocal < 0) {
                    // iLocal less than zero are error codes
                    continue;
                }

                if (vradImage[iLocal] == missingValue || dbzImage[iLocal] == missingValue) {
                    continue;
                }

                vRadDiff = vradOffset + vradScale * (vradImage[iGlobal] - vradImage[iLocal]);
                vmoment1 += vRadDiff;
                vmoment2 += SQUARE(vRadDiff);

                // FIXME double counted dbz when iLocal == iGlobal
                dbz += dbzOffset + dbzScale * dbzImage[iLocal];

                count++;

            }

            vmoment1 /= count;
            vmoment2 /= count;
            dbz /= count;

As far as I can tell, this means that the dbz value at index iGlobal is counted double when iLocal == iGlobal.

not all station names can be run successfully

why can't stationnames.txt not simply be
ALL

Instead, it seems I can only run

FRBOU
FRCAE
FRCHE
FRCOL
FRGRE
FRMOM
FRMTC
FRMCL
FRNAN
FRNIM
NLDBL
NLDHL
NOAND
NOBML
NOHAS
NOHGB
NOHUR
NORSA
NORST
NOSTA
PLBRZ
PLGDA
PLLEG
PLPAS
PLPOZ
PLRAM
PLRZE
PLSWI
SEVIL
SEVAR
SEOVI
SEOSU
SELUL
SELEK
SEKKR
SEKIR
SEHUD
SEASE
SEARL
SEANG
SILIS
SKMAJ
SKKOH
FIKOR
FIKUO
FILUO
FIUTA
FIVIM
FRABB
FRALE
FRTRO
FRAVE
FRBLA
FRBOL
FRBOR
CZBRD
CZSKA
IEDUB
IESHA

but not

FIANJ
FIIKA
FIVAN
HRBIL

I'm currently in the process of separating the issues associated with each station, see e.g. issue #13, #15, #16 and #18.

keep a record of what information is where

...such that you can plot something like a timeline for each station, with 2 lines for each station, representing at least reflectivity, VRAD, maybe some other stuff. And then on top of these lines, use colored thicker lines to indicate time intervals for which data is available (in any of the scan elevations). You could then construct a combination of time interval, station, and variable of interest, and build some function that returns a list of relevant file names/addresses and perhaps dataset location within the file.This list could then be fed to RadarScan when the scanData is needed. Maybe it's even possible to not have a local copy of all the data files, but instead use OpeNDAP to connect to Reading, or wherever the OPERA data are stored, and use the netcdf library to download en process (parts of) the data on the fly.

add raw-to-odimhdf5 conversion tools to /src

and some example data to /testdata

why is clutter_sensitivity based on one specific day (september 1)

clutter_sensitivity.pro reads the same file n times

i/o is slow, it would be quicker to just read once

apples and oranges (tex v dbz) in findcells

In findCells(), texImage[iGlobal] is compared to dbzThresMin. This seems a case of apples and oranges. Perhaps it is an error?

equivalent line in Adriaan's code is (line 1039)

teximage[i+j*nrang]>=dbzmin

wrong calculation of cellProp[].cv

In this piece of code from analysecells(),

    for (iCell = 0; iCell < nCells; iCell++) {
        validArea = cellProp[iCell].area - cellProp[iCell].clutterArea;
        if (validArea > 0){
            cellProp[iCell].dbzAvg /= validArea;
            cellProp[iCell].texAvg /= validArea;
            // FIXME why have this calculation two times
            cellProp[iCell].cv = 10 * log10(cellProp[iCell].texAvg) - cellProp[iCell].dbzAvg;
            cellProp[iCell].cv = cellProp[iCell].texAvg / cellProp[iCell].dbzAvg;
        }
    }

cellProp's cv attribute is calculated twice, using different methods, but only the latter is actually used.

bug in updatemap due to inline changing of array elements

Consider this cellImage

 3  3 -1 -1
 3  3  3 -1
-1  3 -1 -1
-1 -1 -1  2
 4  4 -1 -1

with this cellProp:

cellProp[0].area = 1.0f
cellProp[0].index = 2
cellProp[0].drop = 0

cellProp[1].area = 6.0f
cellProp[1].index = 3
cellProp[1].drop = 0

cellProp[2].area = 2.0f
cellProp[2].index = 4
cellProp[2].drop = 0

after the sortcells() (sort descending by area) in updatemap, this becomes:

cellProp[0].area = 6.0f
cellProp[0].index = 3
cellProp[0].drop = 0

cellProp[1].area = 2.0f
cellProp[1].index = 4
cellProp[1].drop = 0

cellProp[2].area = 1.0f
cellProp[2].index = 2
cellProp[2].drop = 0

Now let's see what happens when we inline-change array elements as per:

    /*reindex the map*/
    for (iCellValid = 0; iCellValid < nCellsValid; iCellValid++) {
        for (iGlobal = 0; iGlobal < nGlobal; iGlobal++) {
            // FIXME: inline changing of array elements...very flaky
            if (cellImage[iGlobal] == cellProp[iCellValid].index) {
                cellImage[iGlobal] = iCellValid + 1;
            }
        }
    }

First find all values 3 (cell with largest area) in cellImage, replace by 1:

 1  1 -1 -1
 1  1  1 -1
-1  1 -1 -1
-1 -1 -1  2
 4  4 -1 -1

All good so far.

Now find all values 2 (the cell with the next highest area) in cellImage, and replace by 2:

 1  1 -1 -1
 1  1  1 -1
-1  1 -1 -1
-1 -1 -1  2
 2  2 -1 -1

Can you spot the problem?

add c-library for bird density, speed, and direction using java native interface

unexpected number of neighbors (4 instead of 9) in findCells

for (iNeighborhood = 0; iNeighborhood < 4; iNeighborhood++) {

Is this because you only need to look at the cells to your upper left (0), above you (1), upper right (2), and to your left (3), but repeat the procedure starting from one cell to the right?

couple of unresolved dependencies

SHOWPS, PSTRACKER, COLORDIVBAR are referenced by some of the visualization routines, but the references cannot be resolved due to missing files

possible bug in analysecells --determining the index

if (dbzValue > cellProp[iCell].dbzMax) {
    cellProp[iCell].dbzMax = dbzValue;
    cellProp[iCell].iRangOfMax = iGlobal%nAzim; // FIXME mod nAzim? I expected nRang
    cellProp[iCell].iAzimOfMax = iGlobal/nAzim; // FIXME div by nAzim? I expected nRang
}

distance calculation in libdist.c wrong

The distance calculation in the C code for dist() seems to output the wrong numbers. I've created a bunch of unit tests in [develop]/ncradar/test/src/nl/esciencecenter/ncradar/TestJNIMethodsVol2BirdDist.java.

If this is incorrect, it could affect any density calculations later.

I've included what I think is the correct calculation as doc/polar-plot-distance.pdf

bird_ppi_loop.pro accasionally loads wrong files?

Example output from bird_ppi_loop.pro

Plotting rain ppi on 20110815:0110

#Opening of HDF5 radar input file : RAD_NO_and_PRF_20110815011851.h5
#Opening of HDF5 radar input file : RAD_NO_bml_PRF_20110815013510.h5
#Opening of HDF5 radar input file : RAD_NO_has_PRF_20110815011812.h5
#Opening of HDF5 radar input file : RAD_NO_hgb_PRF_20110815013544.h5
#Opening of HDF5 radar input file : RAD_NO_hur_PRF_20110815011928.h5
#Opening of HDF5 radar input file : RAD_NO_rsa_PRF_20110815013556.h5
#Opening of HDF5 radar input file : RAD_NO_rst_PRF_20110815011858.h5
#Opening of HDF5 radar input file : RAD_NO_sta_PRF_20110815011930.h5
Plotting rain ppi on 20110815:0120

#Opening of HDF5 radar input file : RAD_NO_and_PRF_20110815013351.h5
#Opening of HDF5 radar input file : RAD_NO_bml_PRF_20110815012010.h5
#Opening of HDF5 radar input file : RAD_NO_has_PRF_20110815013311.h5
#Opening of HDF5 radar input file : RAD_NO_hgb_PRF_20110815012042.h5
#Opening of HDF5 radar input file : RAD_NO_hur_PRF_20110815013432.h5
#Opening of HDF5 radar input file : RAD_NO_rsa_PRF_20110815012059.h5
#Opening of HDF5 radar input file : RAD_NO_rst_PRF_20110815013357.h5
#Opening of HDF5 radar input file : RAD_NO_sta_PRF_20110815013429.h5
Plotting rain ppi on 20110815:0130

possible bug in updatemap

there may be a bug in this part of updatemap in libvol2bird.c:

    for (iGlobal=0; iGlobal<nGlobal; iGlobal++) {

        if (cellImage[iGlobal] == -1) {
            continue;
        }
        cellImageValue = cellImage[iGlobal];
        if (cellProp[cellImageValue].drop) {
            cellImage[iGlobal] = -1;
        }
    }

cellImageValue is read from cellImage, and is then used as an index into cellProp[]. I imagine the cellProp array starts at index 0, which should contain
the properties of the cell which is identifiable in cellImage by its value...2! (0 and 1 are reserved for other stuff, it seems).

output faces and vertices

add method to RadarScan that outputs directly the faces and vertices (easier for MATLAB plotting later, better for performance too)

what is the meaning of the first argument into findcells

texImage suggests it is a texture (i.e. the local standard deviation of vrad), but judging by what type of argument goes in, I think it is in fact dbzImage. This may explain issue #43, but raises questions about what the meaning is of other input arguments, specifially texMeta, texThresMin, and dbzThresMin.

function interface:

int findCells(unsigned char *texImage, unsigned char *rhoImage,
        unsigned char *zdrImage, int *cellImage, SCANMETA *texMeta,
        SCANMETA *rhoMeta, SCANMETA *zdrMeta, float texThresMin,
        float rhoThresMin, float zdrThresMin, float dbzThresMin,
        float rCellMax, char sign)

decibel scale correct?

it's now often calculated as 10 * log(10) * someValue
shouldnt it be 10 * log10(someValue)

see for instance classification method:

zdata[1+llayer] += exp(0.1*log(10)*dbzValue);

set up testing environment in Jenkins/SonarQube/what have you

do it

messy interface of 'classification' method

void classification(SCANMETA dbzMeta, SCANMETA vradMeta, SCANMETA uzmeta,
        SCANMETA clutterMeta,int *cellmap,
        unsigned char *zscan,unsigned char *vscan,
        unsigned char *uzscan,unsigned char *cmscan,
        float *zdata,int *nzdata,
        float *fracclut,float *fracrain,float *fracbird, float *fracfringe,
        float rminscan,float rmaxscan,float HLAYER,float XOFFSET,
        float XSCALE,float XMEAN,float height,
        float amin,float amax,float vmin,float dbzclutter,float dBZmin,
        float dBZx,float DBZNOISE,int NGAPMIN,int NGAPBIN,int NDBZMIN,
        int layer,int id,int *np,int *Npntp,int *Npntallp,int *Npntclutp,
        int *Npntrainp,int *NpntrainNoFringep,
        unsigned char cmflag,unsigned char uzflag,unsigned char xflag)
// FIXME *nzdata unused
// FIXME *fracclut  unused
// FIXME *fracrain  unused
// FIXME *fracbird  unused
// FIXME *fracfringe  unused
// FIXME HLAYER suggests preprocessor but isn't
// FIXME XOFFSET suggests preprocessor but isn't
// FIXME XSCALE suggests preprocessor but isn't
// FIXME XMEAN suggests preprocessor but isn't
// FIXME DBZNOISE suggests preprocessor but isn't
// FIXME NGAPMIN suggests preprocessor but isn't
// FIXME NGAPBIN suggests preprocessor but isn't
// FIXME NDBZMIN suggests preprocessor but isn't
// FIXME id unused

unexpected comparison texOffset in calcTexture()

In calcTexture, there's this strange comparison

if (tex < texOffset + texScale) { // FIXME tex < texOffset would make more sense
    tex = texOffset + texScale;
}

Shouldn't it be:

if (tex < texOffset) {
    tex = texOffset;
}

src/visualization/functions/readvp2.pro needs missing binary file

Apparently, Martin loaded some stuff from '~/IDL/flysafe/templates.sav'.

almost exact copies of a program exist

enram/src/visualization/map_sweu.pro
enram/src/visualization/map_centraleu.pro
enram/src/visualization/map_scandinavia.pro

are the same, except for the radar station IDs, and the plot's bounding box in terms of latitude and longitude. It would be better to have just one map_whatever program that can be configured differently.

perform linear transform of scanData

java class RadarScan does not perform a linear transform yet. The necessary parameters should be read from noffset and nscale HDF5 parameters of the scan

I'm currently using a different atan2 function than Martin was

not sure what the difference is, or if there is in fact a difference to speak of

many local copies of COMMON variables in /src/visualization

e.g.

functions/plotprof_day.pro
functions/map_prof.pro
functions/get_prof.pro

maybe replace with references to 1 common block

empty array error in histogram.pro for stations FIANJ, FIIKA, FIVAN

IDL Version 8.2.3 (linux x86_64 m64). (c) 2013, Exelis Visual Information Solutions, Inc.
Installation number: 88800.
Licensed for use by: University of Amsterdam

% Compiled module: $MAIN$.
% Compiled module: READSTATIONLIST.
% Compiled module: RADAR_NAMES.
% Compiled module: COMMON_DEFINITION.
% Compiled module: RADAR_DEFINITIONS.
% Compiled module: JULDAY.
% Compiled module: VOL2BIRD_FI_ODIMHDF5.
% Compiled module: CALDAT.
% Compiled module: STATISTICS.
% Loaded DLM: HDF5.
% Array dimensions must be greater than 0.
% Execution halted at: STATISTICS 135
/home/wbouten/enram/src/process/statistics.pro
% $MAIN$ 187
/home/wbouten/enram/src/process/histogram.pro

nlesc / enram Goto Github PK

enram's Introduction

enram's People

Contributors

Stargazers

Watchers

Forkers

enram's Issues

Recommend Projects

Recommend Topics

Recommend Org