Differences

LDAP: couldn't connect to LDAP server

This shows you the differences between two versions of the page.

--- kvalobs:kvoss:system:qc2:flag:specification [2010-03-06 15:25:08]
paule
+++ kvalobs:kvoss:system:qc2:flag:specification [2022-05-31 09:29:32] (current)
@@ Line 23: / Line 23: @@
-<code>
+==== Regression testing to-do ====
-Dear Pål,
-I respond to your two emails from the 17 February here together.
->Here you need to alter the check for flag f_fs being set into checking
+**Observation**
->for the specific values of f_s which QC2 alone is able to set. fs=1,2,3
->should not imply qc2dDone=true, because fs=1,2,3 is set by QC1, not QC2.
->Similarly for the flag f_fd in qc2mDone.
-Thank you for this input. I will include this in my branch of the kvalobs library code after which I will redo the regression testing etc, to see the effect on the flag generation.
+Under https://kvalobs.wiki.met.no/doku.php?id=kvoss:system:qc2:flag:regression
+there are a lot of observations where useinfo(7) has been changed from a
-> I guess you have done some kind of resetting of useinfo flags before
+positive value (3 or 4 - observasjon er meldt for tidlig/sent) into 0.
-> running "setUseFlags(const kvControlInfo& cinfo) with the existing Qc2
-> logic turned on"? If so, useinfo(7)=3,4 should not be reset, because the
-> only place where these values are set is when decoding the original
-> message (the values are set by the decoder).
-Yes this explains a lot! I was just giving setUseFlags the value of the controlinfo and seeing what useinfo was generated without any prior initialisation of the useinfo. When I rerun the regression tests I will do something about this ... and maybe then the results will all be the same and it will be easier to later approve the update of the working libraries.
-Thank you very much for the help.
-Best regards, Paul
------ Original Message -----
-Fra: "Pål Sannes" <Pal.Sannes@met.no>
-Til: "Paul Emils Eglitis" <paule@met.no>
-Kopi: "Lars Andresen" <larsa@met.no>, "Gabriel Kielland" <gabrielk@met.no>
-Sendt: 17. februar 2010 16:26:37
-Emne: Flag Testing for useinfo(7)
-Pål Sannes wrote:
-> Then at
+**Analysis**
-> https://kvalobs.wiki.met.no/doku.php?id=kvoss:system:qc2:flag:regression
-> there are a lot of observations where useinfo(7) has been changed from a
-> positive value (3 or 4 - observasjon er meldt for tidlig/sent) into 0.
-> This looks like a bug to me.
-I guess you have done some kind of resetting of useinfo flags before
+Assumed that some kind of resetting of useinfo flags has occurred before
 running "setUseFlags(const kvControlInfo& cinfo) with the existing Qc2
 logic turned on"? If so, useinfo(7)=3,4 should not be reset, because the
@@ Line 70: / Line 40: @@
 message (the values are set by the decoder).
-The only values I have found for useinfo(7) in the Kvalobs database is
+The only values for useinfo(7) in the Kvalobs database are
 , 3 and 4.
-Pål
+**Confirmation**
------ Videresent Melding -----
+Yes ... the input to setUseFlags in the tests was
-Fra: "Pål Sannes" <Pal.Sannes@met.no>
+the value of the controlinfo in order to see what useinfo was
-Til: "Paul Emils Eglitis" <paule@met.no>
+generated without any prior initialisation of the useinfo.
-Kopi: "Lars Andresen" <larsa@met.no>, "Gabriel Kielland" <gabrielk@met.no>, "Solfrid Agersten" <solfrid.agersten@met.no>
-Sendt: 17. februar 2010 12:56:28
-Emne: Re: Qc2 Flag and Cfailed settings - Flag Testing
-Hi Paul,
+**Next Step**
-I will update Flaggdokumentet with the new values for fw soon, but since
+Rerun the regression tests with initialised valid useinfo ... and then compare the results with
-this will imply changes in setting of useinfo(2) also, I prefer to wait
+previous data.
-with this until Vegard has implemented bug 1272 (I don't want to confuse
-him with another unrelated change for useinfo(2)=2).
-Regarding the last question in your email of 3 February, I noticed this
+==== setUseFlags code change ====
-section in
-https://kvalobs.wiki.met.no/doku.php?id=kvoss:system:qc2:flag:analysis
-"The setUseFlags already anticipates the setting of user flags in
-response to QC2 controls. However, most of the logic is commented out in
+Regarding the setUseFlags anticipation of the setting of user flags in
+response to QC2 controls, most of the logic is commented out in
 the operational code, as indicated below:
+<code>
 bool kvControlInfo::qc2dDone() const
 {
@@ Line 110: / Line 76: @@
 }
 "
+</code>
-Here you need to alter the check for flag f_fs being set into checking
+**Additional Code Change Required**
+An additional change is to alter the check for flag f_fs being set into checking
 for the specific values of f_s which QC2 alone is able to set. fs=1,2,3
 should not imply qc2dDone=true, because fs=1,2,3 is set by QC1, not QC2.
 Similarly for the flag f_fd in qc2mDone.
-Then at
-https://kvalobs.wiki.met.no/doku.php?id=kvoss:system:qc2:flag:regression
-there are a lot of observations where useinfo(7) has been changed from a
-positive value (3 or 4 - observasjon er meldt for tidlig/sent) into 0.
-This looks like a bug to me.
-Pål
+==== Working Note ====
+The Flaggdokumentet update with the new values for fw implies changes
+in setting of useinfo(2) also and will therefore take place after
+the implementation of 1272 that also involves useinfo(2).
------ Original Message -----
+==== Other raw feedback ... ====
-Fra: "Pål Sannes" <Pal.Sannes@met.no>
-Til: "Paul Emils Eglitis" <paule@met.no>
-Kopi: "Lars Andresen" <larsa@met.no>, "Gabriel Kielland" <gabrielk@met.no>
-Sendt: 17. februar 2010 16:26:37
-Emne: Flag Testing for useinfo(7)
+... fw flags will satisfy our need for flagging spatial analysis of the available observation data. Here are the not yet official explanation of the flags:
+fw=0 Ikke kontrollert
+fw=1 Kontrollert. Funnet i orden
+fw=2 Kontrollert. Observert verdis avvik fra beregnet verdi er større enn høy testverdi
+fw=3 Kontrollert. Observert verdis avvik fra beregnet verdi er mindre enn lav testverdi
+fw=4 Kontrollert. Observert verdis avvik fra beregnet verdi er større enn høyeste testverdi
+fw=5 Kontrollert. Observert verdis avvik fra beregnet verdi er mindre enn laveste testverdi
+fw=6 Original verdi mangler eller er forkastet av en annen QC2-kontroll. Interpolert/korrigert med beregnet verdi
-Pål Sannes wrote:
+(fw=7 Vi vil vurdere om interpolasjonsmetodikken (fw-kontrollen) selv kan forkaste en verdi. Foreløpig er vi litt tvilende til det, men holder muligheten åpen.)
-> Then at
+With "beregnet verdi" we mean the spatial QC2 interpolation method you are developing.
-> https://kvalobs.wiki.met.no/doku.php?id=kvoss:system:qc2:flag:regression
+We didn't discuss the future but I think that a more sophisticated algorithm in the future with radar/satellite/PROFF information should be able to use the same fw flags. But the test values for setting the flags may be different.
-> there are a lot of observations where useinfo(7) has been changed from a
-> positive value (3 or 4 - observasjon er meldt for tidlig/sent) into 0.
-> This looks like a bug to me.
-I guess you have done some kind of resetting of useinfo flags before
+Comments to the results presented in the mail below.
-running "setUseFlags(const kvControlInfo& cinfo) with the existing Qc2
-logic turned on"? If so, useinfo(7)=3,4 should not be reset, because the
+I comment only useinfo(0-4).
-only place where these values are set is when decoding the original
+Concerning u.info(0) I interpret "Ikke hele QC2" as "Ikke alle eksisterende QC2-kontroller". As existing QC2 checks we can define fs=5-A (QC2d-1), ftime=0-3 (QC2d-2), fw=0-6 (QC2d-3) and fd=7-B (QC2m-2), but this last one is not a QC2m, but rather a QC2d. I propose to skip fstat=0-2 (QC2d-4) and fclim=0-3 (QC2m-1), because these checks will take a lot of time to implement. I think those will be postponed until the other are implemented and work well. With "QC1 er gjennomført" I understand this as "Minst en QC1-kontroll gjennomført".
-message (the values are set by the decoder).
-The only values I have found for useinfo(7) in the Kvalobs database is
-, 3 and 4.
-Pål
+Concerning u.info(4) it is possible to interpret spatial QC2 interpolation as "5: Romkontroll, basert på observasjonsdata". I prefer this instead of "7: Romkontroll, basert på modelldata".
-</code>
+"6: Romkontroll, basert på tidsserier" means e.g. Akima interpolation method, which utilize neighbour time series. If interpolation from the candidate timeseries alone, it is better with "4: Konsistenskontroll i forhold til tidligere/senere observasjonsterminer (mer enn én parameter).
+For me it should be reasonable to do the flagging like this:
+  * 1. RR24. We have no QC1, only QC2 (fd=7). Then u.info(0)=6. I prefer u.info(4)=5. u.info=68965.
+  * 2. RR24. We have QC1 (fr=1, fcc=4) and QC2 (fd=7). u.info=58965.
+  * 3. ftime (TAN/TAX). We have no QC1. fr=6 indicates that original is rejected (and corrected), but this must be due to inconsistence discovered and corrected in QC2 (ftime=1). With this new fw-flag we should have had c.info=1000000160000000 and u.info=60334.
+  * 4. ftime. Corresponding to 3. c.info=1000000260000000 and u.info=60334.
+  * 5. ftime. This time ftime=3 (ikke korrigert pga uegnet metode). I interpret this as "original value rejected". c.info=1000002300000000 and u.info=60389. If original value is kept uncorrected, we have c.info=1000000300000000 and u.info=60309.
+  * 6. This is fnum, not ftime.
+  * I skip all fnum, because we have chosen fw. I skip all fclim (see above).
+  * 13. fw. We have QC1 and QC2 (fw=1). Then u.info is OK.
+  * 14. fw. We have QC1 and QC2 (fw=2). Then u.info is OK.
+  * 15. fw. We have QC1 and QC2 (fw=3). Then u.info=50105.
+  * 16. fw. We have QC1 and QC2 (fw=4). Then u.info=50205.
+  * 17. fw. We have QC1 and QC2 (fw=5). Then u.info=50205.
+  * 18. fw. We have QC1 and QC2, but fw=8 is not defined.
+  * 19. No QC2. We have QC1. Then u.info=70000
+  * 20. No QC2. We have QC1. Then u.info=70000
+  * 21. No QC2. We have no QC1. Original value is missing. Then u.info is OK.
+And then to your email of 3 February.
+  * 1. fcp=3 which means "Originalverdi svært mistenkelig). fhqc=1 (OK) Then u.info is OK.
+  * 2. We have QC1 (fpre=6). fmis=2 (original value rejected). Then u.info=7?38900?00000XX1.
+It may happen that u.info(1)=1 but I don't know if this is usual in combination with fpre=6. If correct it is difficult to decide if u.info(7)=4 or 3 or another value. I understand that with QC2 on u.info(7) becomes like 0, which may be OK in real life?