My initial thoughts on these questions:

range check direction
prototype written (range_check_wind_direction) but need to verify Y param and -3.0 special case with Line

I do not understand this either. Y wind speed? What is special with -3.0?? Maybe PiM knows who to ask?

logger_t
what is this??? the code looks like it checks control info and a bunch of special values, but it has a comment that says it's a range check?

This should just be our special_values_check, right? Maybe it says so since it is using the same flag, fr/controlinfo(1). I find explanations like "Gjoer tester paa 9999-verdier og returner en ny verdi for grenseverdi-flagg" and "fr=7 Kontrollert. Funnet å svare til spesialverdi som betyr manglende")
From the code it looks like Øystein Lie is the person to ask for more info.

min_gt
prototype written (aggregate_less_than_set) but the test seems flawed to me. I don't think it should be able to pass the aggregate if there are missing values in the set (should be at best DataMissing), and if the condition fails, I think it should fail all elems of the set that fail the condition, not just the lowest. Also what is the adjustment? Where does that magic number come from?

I do not understand this after the first quick look.

geonor_drift
No explanation at all for this test. it checks if a set of 25 values are monotonically increasing, and if the difference between the first and last is in a hardcoded range. Struggling to see the rationale behind this one. Additionally why does it have 4 different flags in the log, when the linked code only returns 1 possible flag, and has no parameters

Geonor should be the precip buckets that fills with water as it rains. They are continuously weighed to measure the precipitation. -> values should be monotonically increasing. During the summer I guess some water can evaporate away. I do not know way they use an extra range check here. I can only see 1 flag in the log, not 4.

On the consistency checks (badweather_highvisibility, mediumclouds_low, cloudbase_hi, lt_eq, gt_eq, maxtemp_nosign, range_max_min):
I agree that these checks do not seem to look at pressure!
These seem to be consistency checks that have names that uses numbers equal to the paramids used by pressure variables:

consistency checks clouds uses 170, 171, 172, 173, and 175:
50 QC1-2-170 - nolowclouds_lowcloudheight2
445 QC1-2-171 - Cu_low
253 QC1-2-172 - mediumclouds_low
55 QC1-2-173 - cloudbase_hi
113 QC1-2-175 - lt_eq

and this one related to seatemp uses 179:
822 QC1-2-179 - flowrate_for_seatemp

and something related to temp uses 177 and 178 in the naming:
1 QC1-2-177b - maxtemp_nosign
1 QC1-2-177 - maxtemp_nosign
18 QC1-2-178 - range_max_min

also visibility/weather uses 176:
14737 QC1-6-176 - gt_eq

Here I find the consistency checks for pressure variables:
https://gitlab.met.no/groups/met/obsklim/bakkeobservasjoner/data-og-kvalitet/kvalobs/-/wikis/kvalobs/qc12#air-pressure
And this is the related statistics from the kvalobs log files (the gt_eq test are in fact used, but now with more relevant input):
58096 CHECK: QC1-2-21 - pressure_nottendency (AA = null & PP ≥ 0)
254 CHECK: QC1-2-22 - tendency_notpressure (AA = 4 & PP ≠ 0)
23262 CHECK: QC1-2-23 - gt_eq (AA = 4 & PP ≠ 0)
537 CHECK: QC1-2-24 - eq_between (PP = 0 & 1 ≤ AA ≤ 3)
1619 CHECK: QC1-2-25 - eq_between (PP = 0 & 6 ≤ AA ≤ 8)
0 CHECK: QC1-2-26 - pressurereduction
(Check on station pressure reduction. The check only applies to stations where reduction is calculated manually and 950 hPa ≤ PR ≤ 1050 hPa. The inconsistency is: | PR-P1 | > ε, where ε is instrument specific)
(125783 FLAG=1, 143487 EMPTY RESULTS)
73298 CHECK: QC1-2-27.b - tendency (abs( PP - |PO - PO(-3h)| ) > 0.3 hPa)

@linebaserud

I do not understand this either. Y wind speed? What is special with -3.0?? Maybe PiM knows who to ask?

I think Y is wind speed, since it makes sense that wind direction would become meaningless when wind speed is 0, but it's not mentioned in the description. As for the -3.0 it seems like special handling for some specific sensor?

I do not understand this after the first quick look.

I think this is maybe easier to explain in person and with a diagram, we can bring it up at the next meeting

I can only see 1 flag in the log, not 4.

I meant that in your document it is listed as 4 entries:

263 	1719 		QC1-3a-104drift.501 - geonor_drift
295 	1012 		QC1-3a-104drift.502 - geonor_drift
373 	176 		QC1-3a-104drift.330 - geonor_drift
...
466 	24 		QC1-3a-104drift.342 - geonor_drift

But it's unclear to me what (if any) difference there could be between these checks, as the linked code has only 1 function which does not take in any params

I agree that these checks do not seem to look at pressure!
These seem to be consistency checks that have names that uses numbers equal to the paramids used by pressure variables:

Ok so those tests leaked into the list because the regex you used on the logs wasn't quite right? Or is it a mistake that they're named like that? In that case it seems like I shouldn't implement them, right? I feel kind of sad that I spent so long puzzling about this when it never made sense.

You linked the new set of consistency checks that actually are used for pressure, do you want me to implement these? are they actually flagging anything?

@intarga

I do not understand this either. Y wind speed? What is special with -3.0?? Maybe PiM knows who to ask?

I think Y is wind speed, since it makes sense that wind direction would become meaningless when wind speed is 0, but it's not mentioned in the description. As for the -3.0 it seems like special handling for some specific sensor?

Sounds reasonable. I will put it on my list to try to ask some people to verify.

I do not understand this after the first quick look.

I think this is maybe easier to explain in person and with a diagram, we can bring it up at the next meeting

Perfect. It is now in the agenda for the next meeting.

I can only see 1 flag in the log, not 4.

I meant that in your document it is listed as 4 entries:
263 1719 QC1-3a-104drift.501 - geonor_drift
295 1012 QC1-3a-104drift.502 - geonor_drift
373 176 QC1-3a-104drift.330 - geonor_drift
...
466 24 QC1-3a-104drift.342 - geonor_drift
But it's unclear to me what (if any) difference there could be between these checks, as the linked code has only 1 function which does not take in any params

It should be the same test (https://gitlab.met.no/met/obsklim/bakkeobservasjoner/data-og-kvalitet/kvalobs/kvoss_intern/-/blob/master/kvmeta/algorithms/geonor_drift.pl?ref_type=heads), but run for the different typeids (501,502,330,...,342).

I agree that these checks do not seem to look at pressure!
These seem to be consistency checks that have names that uses numbers equal to the paramids used by pressure variables:

Ok so those tests leaked into the list because the regex you used on the logs wasn't quite right? Or is it a mistake that they're named like that? In that case it seems like I shouldn't implement them, right? I feel kind of sad that I spent so long puzzling about this when it never made sense.

You linked the new set of consistency checks that actually are used for pressure, do you want me to implement these? are they actually flagging anything?

Correct, leaked in w/ the regex. Maybe that is showing us that naming most of the tests with the paramid, but also naming lists of tests with the same numbers can be confusing...
We should not implement them for pressure, however, these consistency tests do flag observations so we will need them for checking the cloud observations etc. The document I made for you shows the kvalobs checks for the main parameters (temperature, precip, wind, rh, pressure) that we wanted to start with, but in the end we need to check also all the other observations that kvalobs checks.
The new set is flagging, except for CHECK: QC1-2-26 - pressurereduction. The number of flagged observations is the number just before each test that I listed in my previous comment.