Order of HIRS channels (possibly) swapped for the channel quality flag

Satellite Application Facility for Numerical Weather Prediction Forums AAPP AAPP General Discussion Order of HIRS channels (possibly) swapped for the channel quality flag

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #46539
    Paul PoliPaul Poli
    Participant

    Hello, inside routine h_uphrs1bcommon1_algoV4.F, hchqualflg and linechquality follow the same channel orders (l1c order in both cases). Yet, in output, one expects linechquality to be in l1c order, and hchqualflg to be in l1b order. My impression is there is one step missing, to remap the channel order of array hchqualflg into the l1b channel order. This l1b order is indeed the order assumed when writing the files, and when reading them later. Without that (missing) step, and as it stands presently, when the data produced in this fashion are read later by inhget.F, the data in hchqualflg (assumed to be in the l1b order) are applied a l1b to l1c channel order conversion, which leads to an order of channels for this QC flags, when written out in the end, which is neither l1b, nor l1c, but another channel order. Of course I may I have missed something, but this is consistent with behavior observed here. Thanks for your point of view on this one.

    #46541
    Nigel AtkinsonNigel Atkinson
    Moderator

    Dear Paul,

    As I understand it, most of the arrays in hirscl_algoV4 use l1b order, i.e. the order of the channels is 1, 17, 2, 3, 13, 4, 18, 11, 19, 7, 8, 20, 10, 14, 6, 5, 15, 12, 16, 9. This includes hchqualflg and linechquality (i.e. I think your first sentence is not correct). The linechquality is an internal variable, it has no output in the level 1b. The hchqualflg gets copied to hrs_chqualflg0 in hl1bwrt_algoV4.F, and hence to the 1b output file.

    In the routine h_uphrs1bcommon1_algoV4.F, the only variables not in l1b order are avgslope, stdevavgslope, b1mn, b1std. There is an array l1border that allows them to be converted to l1b order (variables avgslope00, stdevavgslope00, b1mn0, b1std0). Other routines use the same l1border to do conversions.

    So I don’t see an inconsistency. You say “consistent with behavior observed here” … do you mean that you are getting unexpected values in the 1b file? Can you give details?

    Regards,

    Nigel

    #46557
    Paul PoliPaul Poli
    Participant

    Hello Nigel and thanks for your time on this one!

    Yes I do have some example seen here on the data produced in test reprocessing but maybe there’s a clear case with the code… You’ll tell me, there it is:

    First, I agree with your understanding that hirscl_algoV4 presents all these arrays as being in l1b order.

    Second, “linechquality”, while being an internal variable, matters because it determines whether or not the bits 1 to 5 of “hchqualflg” are set in routine “h_uphrs1bcommon1_algoV4.F”. So my first sentence was more about the channel order these data are in, when they actually get to that routine.

    In routine “h_cntmn_algoV4.F”, which is called before (both routines are called from “hirscl_algoV4.F”), the following seems to happen (working my way *backwards* from where linechquality is set):

    – last step: linechquality is set using information derived from “counts”.

    – last step minus 1: This variable “counts” is obtained before from array “chcounts”.

    – last step minus 2: That array “chcounts” is obtained from
    “CALL h_orderch_algoV4(inputch,chcounts,hrs_mxchn,hrs_mxpix,0)”
    This call, with the last argument being 0, takes the input values (“inputch”) in the l1b order and swaps them to produce “chcounts” in the l1c order.

    So, all this would produce an array “linechquality” that is in the l1c order — and not l1b — and flows, unaltered, to h_uphrs1bcommon1_algoV4.F, and then onwards to the hchqualflg data written out to file.

    …That is, unless I missed something… Thanks again for your time..!

    #46566
    Nigel AtkinsonNigel Atkinson
    Moderator

    I see what you mean. We will look into it.

    Regards,

    Nigel

    #46568
    Nigel AtkinsonNigel Atkinson
    Moderator

    I did an experiment in which the counts for the second slot (channel 17) are all set to zero in hgetl1belement_algoV4.F. After running the calibration, the second slot in calcof was correctly set to missing but it was the 17th slot in chqualflg that was non-zero. This is not correct – as you have indicated.

    A similar test for the old (hirscl) calibration algorithm does not set chqualflg at all. There is no code present for setting this variable.

    I tried modifying h_uphrs1bcommon1_algoV4 to re-order the values of hchqualflg and that appeared to fix it. But need to consult with colleagues in case we missed something, hopefully next week.

    Nigel

    #46569
    Nigel AtkinsonNigel Atkinson
    Moderator

    I’ve put the modified h_uphrs1bcommon1_algoV4.F here: https://nwp-saf.eumetsat.int/downloads/aapp_data_files/miscellaneous/h_uphrs1bcommon1_algoV4.F. Does this look OK to you? If so, we will include in update 8.8.

    Nigel

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.