added matlab reader for mwRTM vegopacity file (read_vegopacity.m)

[gmao-rreichle]

No description provided.

[gmao-rreichle]

@gmao-qliu :
Anthony ran into a problem with the vegopacity file in his coupled land-atm DAS experiment. It turned out that he was using an outdated vegopacity file. Specifically, he was using the c90 and c360 files ending in ".missingpart" and ".missingheader" in stored here:
/discover/nobackup/projects/gmao/smap/SMAP_Nature/bcs/RTM_params/RTMParam_L2DCA_R19/CF*/

I wrote the Matlab reader of the present PR to debug the issue and verify that we can just replace Anthony's bad vegopacity files with the correct files from the aforementioned directories.

In doing so, I found another error in the "correct" files. Specifically, the vegopacity files in the CFxxxx have the wrong N_tile number in their header lines. I think we got away with this because MAPL_ReadForcing() does not actually use the N_tile information from the header lines within the vegopacity file.

Here's the call to MAPL_ReadForcing:

GEOSldas_GridComp/GEOSlandassim_GridComp/GEOS_LandAssimGridComp.F90

Line 2886 in 3222d8c

call MAPL_ReadForcing(MAPL,'VEGOPACITY',VEGOPACITYFile,CURRENT_TIME,VEGOPACITY,ON_TILES=.true.,RC=STATUS)

And here is MAPL_ReadForcing:
https://github.com/GEOS-ESM/MAPL/blob/666ea4cbfc9a4007973968b32cffe5ed2de7e3ac/generic/MAPL_Generic.F90#L9206

When you get a chance, please verify that my findings are in fact correct. That is, (i) we can indeed just replace the vegopacity file in Anthony's experiment (as opposed to re-doing any of the existing offline or coupled runs), and (ii) we can ignore the bad N_tile entries in the header lines of the cube-sphere vegopacity files. (Going forward, we should of course fix the bug.)
Thanks!

[gmao-qliu]

(i) we can indeed just replace the vegopacity file in Anthony's experiment (as opposed to re-doing any of the existing offline or coupled runs), and (ii) we can ignore the bad N_tile entries in the header lines of the cube-sphere vegopacity files. (Going forward, we should of course fix the bug.) Thanks!

Both statements above are correct. The CFxx data are interpolated from M36/M09 data, and I copied the header line of each record but failed to update the N_tile value. We can ignore this issue for now as the value isn't used in GEOSldas. I will modify the code to reflect the correct N_tile value in a future update. @gmao-rreichle