Mod14 Fire Detection issue

[egarbi]

We have installed dbvm on a real machine since Oct 2010, all goes fine except fire detection, we are not able to get mod14.hdf at all, when we try to do it manually, running, "ie: ./mod14 tCv a1.10314.1659.1000m.hdf a1.10314.1659.geo.hdf a1.10314.1659.mod14.hdf", mod14.hdf file is created, but fire_mask pixel class equals 3 (which is water!!) for all of the pixels in it, obviously that is wrong because the image shows much more than just water.mod14.hdf.

Sound familiar this for anyone of you?

Let us know if you need something else in order to help us to track this issue.

Thanks in Advance
Enrique Garbi
CONAE - Argentina

[gumley]

Hello Enrique,

So just to confirm:

1. mod14 does not work at al when it is executed automatically as part of the IMAPP VA processing, and
2. mod14 does execute when you run it from the command line, but all pixels are classified as water.

I have not seen this behavior before. However, it would be helpful if you could show us

a) the contents .log and .err files for the case where mod14 runs inside the IMAPP VA (they should be in the dbvm/errors directory), and
b) the standard output from mod14 when you run it manually.

Do you get the same results for every Terra and Aqua pass you have processed, or only a few passes?

Regards,
Liam.

[egarbi]

Hello Enrique,
So just to confirm:
1. mod14 does not work at all when it is executed automatically as part of the IMAPP VA processing, and
2. mod14 does execute when you run it from the command line, but all pixels are classified as water.

I made some changes and now mod14 run always, either automatically and manually, but all pixes are classified as water, no matter how we run it, take a look on attributes of this mod14.hdf file for example:
Global attributes: 20
FirePix: 0
MissingPix: 2278
LandPix: 0
WaterPix: 7173922
WaterAdjacentFirePix: 0
CloudAdjacentFirePix: 0
UnknownPix: 0
LandCloudPix: 0
WaterCloudPix: 0
GlintPix: 0
GlintRejectedPix: 0
CoastRejectedPix: 0
HotSurfRejectedPix: 0
DayPix: 0
NightPix: 7176200
Satellite: Terra5.0.1/cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.1000m.hdf/cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.geo.hdfLinux castor 2.6.32-25-server #45-Ubuntu SMP Sat Oct 16 20:06:58 UTC 2010 x86_6

I have not seen this behavior before. However, it would be helpful if you could show us
a) the contents .log and .err files for the case where mod14 runs inside the IMAPP VA (they should be in the dbvm/errors directory), and
b) the standard output from mod14 when you run it manually.

because of my replay to item 1 and 2, logs and std output are very similar, this is that logs of "run_modis_land.bash" shows:
----------------------------------------------------------------------------------------------------
run_modis_land.bash /cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.1000m.hdf

Creating MODIS Level 2 land products; started at Thu Nov 11 02:46:30 UTC 2010

Input Level 1B 1KM file: /cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.1000m.hdf

(Starting MOD14 fire detection processing)
/cuss_systems/foreing/dbvm/apps/mod14/mod14 -tvC /cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.1000m.hdf /cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.geo.hdf t1.10315.0223.mod14.hdf
/cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.1000m.hdf
/cuss_systems/var_dirs/dbvm/level1/t1.10315.0223.geo.hdf
t1.10315.0223.mod14.hdf
name = EV_1KM_Emissive, rank = 3, data type = 23 dims: 16 5300 1354
name = EV_250_Aggr1km_RefSB, rank = 3, data type = 23 dims: 2 5300 1354
name = EV_500_Aggr1km_RefSB, rank = 3, data type = 23 dims: 5 5300 1354
name = Dead Detector List, data type = 20 n_values: 490
band 21, 22, 31, 32 dead detector list
0 0 0 0 0
1 0 0 0 0
2 0 0 0 0
3 0 0 0 0
4 0 0 0 0
5 0 0 0 0
6 0 0 0 0
7 0 0 0 0
8 0 0 0 0
9 0 0 0 0

name = Latitude, rank = 2, data type = 5 dims: 5300 1354
name = Longitude, rank = 2, data type = 5 dims: 5300 1354
name = SensorZenith, rank = 2, data type = 22 dims: 5300 1354
name = SolarZenith, rank = 2, data type = 22 dims: 5300 1354
name = SensorAzimuth, rank = 2, data type = 22 dims: 5300 1354
name = SolarAzimuth, rank = 2, data type = 22 dims: 5300 1354
name = Land/SeaMask, rank = 2, data type = 21 dims: 5300 1354
radiance scales and offsets:
0 6.262399e-05 2.730583e+03
1 3.149510e-03 2.730583e+03
2 6.921598e-05 2.730583e+03
3 7.910397e-05 2.730583e+03
4 3.155614e-05 1.077445e+03
5 5.639821e-05 1.560333e+03
6 1.175573e-04 2.730583e+03
7 1.924497e-04 2.317489e+03
8 5.324869e-04 2.730583e+03
9 4.063234e-04 1.560333e+03
10 8.400220e-04 1.577340e+03
11 7.296976e-04 1.658221e+03
12 2.622639e-04 2.501298e+03
13 2.006958e-04 2.501298e+03
14 1.767083e-04 2.501298e+03
15 1.183386e-04 2.501298e+03
16 2.730583e+03 4.963469e-05
17 2.730583e+03 3.019898e-05
18 2.730583e+03 -0.000000e+00
19 2.730583e+03 -0.000000e+00
20 1.077445e+03 4.909670e-05
21 1.560333e+03 3.752919e-05
22 2.730583e+03 3.775870e-05
23 2.317489e+03 3.387274e-05
24 2.730583e+03 2.745764e-05
25 1.560333e+03 -0.000000e+00
26 1.577340e+03 -0.000000e+00
27 1.658221e+03 -0.000000e+00
28 2.501298e+03 -0.000000e+00
29 2.501298e+03 -0.000000e+00
30 2.501298e+03 0.000000e+00
31 2.501298e+03 0.000000e+00
32 4.963469e-05 0.000000e+00
33 3.019898e-05 0.000000e+00
34 -0.000000e+00 0.000000e+00
35 -0.000000e+00 0.000000e+00
nscans = 530
Fire: 0
Unknown: 0
(Finishing MOD14 processing)
------------------------------------------------------------------------------------------------------------------

Do you get the same results for every Terra and Aqua pass you have processed, or only a few passes?

Yes, we do. same results for all pass

Regards,
Enrique Garbi

[egarbi]

I made some more research on it and I found some more helpful data, processing as an example pass (12 Nov 2010 03:06 UTC Terra) on other hardware and old software version, I got:

X86_64 - Linux Ubuntu Server - IMAPP VA attributes of mod14 file obtained:
Global attributes: 20
FirePix: 0
MissingPix: 90
LandPix: 0
WaterPix: 7311510
WaterAdjacentFirePix: 0
CloudAdjacentFirePix: 0
UnknownPix: 0
LandCloudPix: 0
WaterCloudPix: 0
GlintPix: 0
GlintRejectedPix: 0
CoastRejectedPix: 0
HotSurfRejectedPix: 0
DayPix: 0
NightPix: 7311600
Satellite: Terra5.0.1/cuss_systems/var_dirs/dbvm/level1/t1.10316.0306.1000m.hdf/cuss_systems/var_dirs/dbvm/level1/t1.10316.0306.geo.hdfLinux castor 2.6.32-25-server #45-Ubuntu SMP Sat Oct 16 20:06:58 UTC 2010 x86_64

SGI IRIX 6.5 - seadas 4 and mod14 attributes showed:
Global attributes: 16
FirePix: 76
MissingPix: 13540
LandPix: 3985583
WaterPix: 3217697
WaterAdjacentFirePix: 0
CloudAdjacentFirePix: 0
UnknownPix: 11
LandCloudPix: 616950
WaterCloudPix: 3217697
GlintPix: 0
GlintRejectedFirePix: 0
DayPix: 0
NightPix: 113

ProcessVersionNumber: 3.1.6/disk18/productos/TER_12-NOV-2010_57984_030627_L1b_1000m.hdf/disk18/productos/TER_12-NOV-2010_57984_030627_geo.hdf

X86_64 - Linux Ubuntu - Seadas 6.1 instead of IMAPP VA (MODISl1DB 1.6) and I got:
Global attributes: 20
FirePix: 116
MissingPix: 0
LandPix: 4030482
WaterPix: 2631198
WaterAdjacentFirePix: 1
CloudAdjacentFirePix: 1
UnknownPix: 0
LandCloudPix: 635055
WaterCloudPix: 0
GlintPix: 0
GlintRejectedPix: 0
CoastRejectedPix: 0
HotSurfRejectedPix: 0
DayPix: 0
NightPix: 6661680

Satellite: Terra5.0.1/cuss_systems/var_dirs/modis.seadas.L1A.L1B/outbox/terra_20101112_030627.l1b.1km.hdf/cuss_systems/var_dirs/modis.seadas.L1A.L1B/inbox/terra_20101112_030627.geo.hdfLinux castor 2.6.32-25-server #45-Ubuntu SMP Sat Oct 16 20:06:58 UTC 2010 x86_64

Regards,
Enrique Garbi

[gumley]

Enrique,

I can't imagine why the MOD14 results would be so different. I suspect there is something wrong with the Level 1B data on your DBVM system.

Would you be able to upload the L1B 1KM and GEO files from your DBVM system to our anonymous FTP site at

ftp://ftp.ssec.wisc.edu/pub/incoming/

so I can take a look at them? It would also be very helpful if you could upload the log file from the L1B processing for this case.

Regards,
Liam.

[egarbi]

Liam, Problem is solved.
Following your suspect, I analyzed logs from level1 on dbvm system, and I found this:

WARNING: Could not locate MODIS digital elevation maps directory:
'/cuss_systems/foreing/dbvm/apps/modisl1db/data/modis/dem/'.

*TERRAIN CORRECTION DISABLED*

so, I fixed it doing a symbolic lynk to dem files, after that fire detection worked fine.

I suspect that dem files (seadas_dem_modis.tar.gz) are being extracted in a wrong location by installation script "install_level1.bash", or maybe I missed some configuration step when I read installation instruction, I don't know.
I don't remember neither have read that Modis Correction has to be "ON" in order to fire have successfully detected.

Thanks a lot for you help
Regards,
Enrique

[gumley]

Enrique,

Thanks for the good news. I checked your suggestion in my local copy of the IMAPP VA version 1.0, and the behavior is exactly as you described. When the IMAPP VA setup file dbvm/scripts/dbvm_env.bash contains the lines

export DBVM_LAND="YES"
export DBVM_DEM="NO"

and you run the install script install_dbvm.bash, then MODIS Land processing will be installed, but not the DEM files. As a result, the MOD14 fire detection algorithm says every pixel is water, and no fires are detected. To correct this problem, you must change dbvm_env.bash to read

export DBVM_LAND="YES"
export DBVM_DEM="YES"

and then run the install script install_dbvm.bash. This was not explained in the IMAPP VA version 1.0 documentation, so I will add it to the new version.

Regards,
Liam.

[iamzakaria]

Hello Enrique,

So just to confirm:

1. mod14 does not work at al when it is executed automatstomach pain after eating, and
2. mod14 does execute when you run it from the command line, but all pixels are classified as water.

I have not seen this behavior before. However, it would be helpful if you could show us

a) the contents .log and .err files for the case where mod14 runs inside the IMAPP VA (they should be in the dbvm/errors directory), and
b) the standard output from mod14 when you run it manually.

Do you get the same results for every Terra and Aqua pass you have processed, or only a few passes?

Regards,
Liam.

1 +