Update some defaults in LDASsa_DEFAULT_inputs_*.nml files

[gmao-rreichle]

Some of the default values for obs parameters and forcing perturbations in the LDASsa_DEFAULT_inputs_*.nml were out of sync with the values used in the latest SMAP L4_SM Version 8 algorithm. This PR updates the default values to match those in L4_SM.

[gmao-rreichle]

@gmao-qliu, @amfox37 : I started this PR in an attempt to clean up the default values of the obs parameters. Ideally, users only need to turn on/off the "getinnov", "scale", and "assim" flags and don't have to worry about the nitty-gritty settings.
@amfox37 : Please take a look at the SMAP Tb species parameters and compare to what you use for SMOS assimilation. We probably need to update the SMOS parameters accordingly.
@gmao-qliu : For SMOS ("fit"), what is the correct RTM_id? Should we use RTM_id=2 or 3?

! %RTM_ID         = ID of radiative transfer model to use for Tb forward modeling
!                   (subroutine get_obs_pred()) 
!                     0 = none
!                     1 = L-band tau-omega model as in De Lannoy et al. 2013 (doi:10.1175/JHM-D-12-092.1) (SMOS)
!                     2 = same as 1 but without Pellarin atm corr (SMAP)
!                     3 = same as 1 but with Mironov and SMAP L2_SM pol mixing (SMOS)
!                     4 = same as 3 but without Pellarin atm corr (targeted for SMAP L4_SM Version 8)

[amfox37]

For the SMOS ("fit") values I used the values that I think @gmao-qliu suggested having used them in her previous testing 6 months ago, which are very like the SMAP values. I don't recall making any changes myself, and I must admit I hadn't looked at the previous default values until just now. If we should be using RTM_id 2 or 3 then I've been using the wrong one as I've used 4. Also, the errstd I've used is 4 and more than double than the previous default (1.5)...

If these updated values I have just used are the settings that we actually want, the changes required to the default look like:

%RTM_ID = 2 changes to = 4
%coarsen_pert = .false. changes to =.true.
%errstd = 1.5 changes to =4.0
%path = '/discover/nobackup/projects/gmao/ssd/land/l_data/SMOS/EASEv2/ESA_REPR/SMOS_M36_SCLF1C_fit_nosky_noatm_v620_ESA_v102/SMOS_fit_poly2/' changes to = '/discover/nobackup/projects/gmao/smap/SMAP_Nature/SMOS/EASEv2/ESA/SMOS_M36_SCLF1C_fit_nosky_noatm_v724 _ESA_v102/SMOS_fit_poly2/'

[gmao-qliu]

I think it makes sense to use the same RTM_ID setting for SMOS as for SMAP, since we only use one set of mwRTM.

[gmao-rreichle]

I think it makes sense to use the same RTM_ID setting for SMOS as for SMAP, since we only use one set of mwRTM.

There are two things going on here:

1. If the scaling parameters are done separately, we could use different RTM_ids for SMOS and SMAP without making an obvious error. One of the two will then not have what we currently consider the "best" RTM, but that's not necessarily a mistake. It would be a major mistake if we use only 1 set of scaling params (derived from either one or both datasets) but are using two different RTM_ids. Having said that, I now think that the OmF std-dev for SMOS is larger than for SMAP in the M21C-Land sweeper run simply because of the difference in RTM_id in the config -- it's like comparing SMAP OmFs between L4_SM Versions 7 and 8. So the larger OmF std-devs in the sweeper run shouldn't be blamed on SMOS obs. Rather, they're caused by our choice of RTM_id. (Contrary to what I presented at the workshop yesterday...) Going forward, we need to use the Mironov model for both.
2. In the past, SMOS and SMAP L-band Tbs had one key difference. For SMOS, the TB was top-of-the-atmosphere while for SMAP, it was top-of-vegetation. I can't remember if we changed this in our SMOS preprocessing. Depending on what it is, we need RTM_id=3 or RTM_id=4 for SMOS. Not getting this right would be a minor error.

[gmao-qliu]

We always have separate observation scaling parameters for each SMOS and SMAP species. The SMOS preprocessing handles the atmospheric correction, so we don't need to use RTM_ID 1 or 3 in GEOSldas. RTM_ID 2 uses WANG and LAI-based vegetation opacity, while RTM_ID 4 uses MIRONOV and retrieval-based vegetation opacity. We can use different RTM_IDs (2 vs 4) for SMOS and SMAP, but only if we run separate DA experiments, because mwRTM for RTM_ID=4 doesn't work for RTM_ID=2, and vice versa.

[amfox37]

To clarify - in the sweeper run I used RTM_id = 4 for both SMOS and SMAP, and separate scaling parameters derived for each.

[gmao-rreichle]

@gmao-qliu @amfox37 : Many thanks for clarifying. Here are some updates:

The SMOS preprocessing handles the atmospheric correction

Thanks for the confirmation! I agree that we should then use RTM_id=4 for SMOS as well. It's our best RTM. I'm glad to hear that the relatively larger OmF std-dev for SMOS wasn't the result of an unintentional config.

the errstd I've used is 4 and more than double than the previous default (1.5)...

Nominally, a (single-angle) SMOS Tb obs and a SMAP Tb obs should have comparable err std per the mission specs. Because of the interpolation across several single-angle measurements, the "fit" SMOS obs should have lower error than the individual single-angle measurements. The original 1.5 number was overly optimistic, and SMOS Tb turned out to be less accurate than we had thought. We found that 4.0 for the SMOS "fit" works.

We can use different RTM_IDs (2 vs 4) for SMOS and SMAP, but only if we run separate DA experiments, because mwRTM for RTM_ID=4 doesn't work for RTM_ID=2, and vice versa.

I forgot that we intentionally created the new mwRTM files with veg opacity from SMAP L2_SM data in such a way that they would not work for the old RTM_id=2, which computes the veg opacity from the LAI. This is smart because it avoids accidentally setting of RTM_id=2 with the new mwRTM files. However, it wouldn't be difficult to create mwRTM params that support multiple RTM_IDs, if we ever wanted to, which what got me confused. Of course, using RTM_id=2 now would be a questionable choice, given that RTM_id=4 turned out to be clearly superior in the L4_SM product.

I updated the SMOS species accordingly, and I also updated "coarsen_pert" for ASCAT (d7058b2).

@gmao-qliu @amfox37 : When you get a chance, please verify the latest version of the LDASsa_DEFAULT_inputs*.nml files and let me know if anything else needs changing. Andy: Please also compare the ASCAT and MODIS settings with what you have in the M21C-Land sweeper run (or point me to your nml input files). While you're at it, maybe also the CYGNSS settings. Thanks!

[amfox37]

I can confirm that the default setting here match what was used in the land sweeper runs for MODIS scf and ASCAT sfds - with the minor exception that I was using incorrect orbit flags for ASCAT. It should be 3 (asc and desc) as per the default. But I believe these aren't actually used at any stage in the reading/scaling/assimilation of the ASCAT obs so won't have impacted anything.
The CYGNSS values agree with what I've been using in testing at this stage.

[gmao-qliu]

I can also confirm that the updated DEFAULT input files are good.