New flag for satellite processing

[rrbuchholz]

Changing the satellite code to be more general and flexible, we would like to add in flags to determine what methhod is being used when pairing the model with satellite observations:

We currently have under the obs class in the driver:

obs_type:
sat_swath_clm - satellite l2 column products
sat_grid_clm - satellite l3 column products
Here there is room to add profile products at a later date.

sat_type:
replace tags with <instrument>_<data type>
for example: tropomi_l2_no2 would become tropomi_l2
Question: do we need the l2 and l3 as they seem to be defined above in obs_type? Could we just have the satellite type here? Is it a mistake to get rid of the species definition here (no2, co, hcho etc)?

NEW FLAG
sat_method:
apply_ak - regrid model to measurement space and apply averaging kernel
replace_apriori - replace the a priori in the retrieval
no_smoothing/raw_model - do not apply any sensitivity considerations to the model, only sample the model at satellite observation locations

When choosing flag names, we want the balance of succinct with information. Will a user understand no_smoothing enough?

[sylvesterkaczmarek]

Good direction. I’d keep level only in obs_type to avoid drift, and make sat_type the instrument only (tropomi, omi), with species in the variable name.

For sat_method, no_smoothing is ambiguous; suggest sample_only or no_ak to mean ‘sample model at obs locations with no AK or a priori replacement.’ This keeps flags orthogonal and scales cleanly to profiles later.

[sylvesterkaczmarek]

Example for clarity ->
obs_type=sat_l2_clm, sat_type=tropomi, variable=no2, sat_method=sample_only.

Also, should sat_method stay single-choice, or do you want to allow combos later (e.g., apply_ak+replace_apriori)?

[blychs]

Example for clarity -> obs_type=sat_l2_clm, sat_type=tropomi, variable=no2, sat_method=sample_only.

Also, should sat_method stay single-choice, or do you want to allow combos later (e.g., apply_ak+replace_apriori)?

Although I think this is generally a good idea, it is a little bit tricky, in the sense that the different satellite products (i. e., the different variables of interest) have different structure, and can require different processing. The user might want other variables from the satellite products, e.g., cloud_cover, etc.

I agree that having sat_method be single choice is probably the right way to go.

[rrbuchholz]

sat_type: We think using the species in the sat_type_ is less confusing for users, because there may be different methodologies for different retrievals.

sat_method: More ideas for not applying AK smoothing flags:
untransformed, horizontal_sample, 2D_matching, no_transform, no_ak
We think something like no_ak AND horizontal_regrid_only are both needed because they are different methodologies (No AK may still require column calculations, while something like AOD is written out from the model).