- This topic has 5 replies, 2 voices, and was last updated 2 years, 9 months ago by
.
-
Posts
-
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.
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
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..!
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
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
- You must be logged in to reply to this topic.