Hi devs 
The last couple of days Yann has helped me to understand a problem that arose with QC bands in MOD11A2 product (maybe applies to other MOD11). I’m just sharing what we learnt.
The problem arises because MOD11 products have 0 as no-data value (which is reasonable given that temperature is in °K) and r.in.gdal automatically reads that pre-defined no-data value and converts it into grass NULL [0].
The problem is that also QC bands appear with 0 as no-data (try gdalinfo with the QC_band) - Maybe that’s a problem of gdal, dunno… given that in the Layers section of MOD11A2 [1], there’s the following note:
NOTE: there is no FillValue for the QC SDS. This SDS should be used together with the LST SDS. If LST has FillValue 0, the 0-1 bits in QC have values of 10 or 11, other bit fields with 0 are undefined.
Anyway, my workflow was as follows:
(pymodis to download, select bands, reproject and convert to tiff)
modis_convert.py -s “( 1 1 0 0 0 0 0 0 0 0 0 0 )” -o MOD11A2.A2015001_h12v11 -e 4326 MOD11A2.A2015001.h12v11.005.2015010065120.hdf
gdalinfo MOD11A2.A2015001_h12v11_QC_Day.tif
…
Lower Right ( -53.2090984, -30.0015506) ( 53d12’32.75"W, 30d 0’ 5.58"S)
Center ( -61.2455654, -25.0007753) ( 61d14’44.04"W, 25d 0’ 2.79"S)
Band 1 Block=2327x3 Type=Byte, ColorInterp=Gray
NoData Value=0 <<<----- here!
then,
r.in.gdal
i.modis.qc
… and so on…
So, when you intend to use i.modis.qc with mandatory_qa_11A2, for example… you don’t get zero in that QC band but the range goes from 1 to 3 (it should be 0-3).
The solution then would be, rather you keep LST pixels where mandatory_qa_11A2 is null, or set null to 0 in QC band before using i.modis.qc
Maybe using some tool other than GDAL to extract bands from MODIS HDF files gives a different result (?).
Any other insights/suggestions are welcome
Cheers!
Vero
[0] https://grass.osgeo.org/grass73/manuals/r.in.gdal.html#NOTES
[1] https://lpdaac.usgs.gov/dataset_discovery/modis/modis_products_table/mod11a2