Page 1 of 1
SeaDAS cannot reproduce OBPG l2 product
Posted: Mon May 15, 2023 6:34 pm America/New_York
by jing.tan
Hi, I downloaded the latest version of SeaDAS and installed the ocssw processor. I believe everything is up to date. However, when I processed one level 1a MODIS-A image to l2 and compared the chlor_a with the l2 product released online by OBPG, the values are actually not the same. Does this mean that SeaDAS does not include the latest processing parameters? How to generate exactly the same l2 product? Thanks!
Re: SeaDAS cannot reproduce OBPG l2 product
Posted: Tue May 16, 2023 9:59 am America/New_York
by OB SeaDAS - xuanyang02
Can you do SeaDAS-Toolbox -> Software & System Info, and post the results here?
Please share the filename of L1A and L2. Did you run l2gen with GUI or command line? Did you use the default settings of l2gen? Did you use the ancillary data?
Re: SeaDAS cannot reproduce OBPG l2 product
Posted: Tue May 16, 2023 12:08 pm America/New_York
by jing.tan
L1A: A2023131213500.L1A_LAC
L2: AQUA_MODIS.20230511T213500.L2.OC.NRT.nc
I ran l2gen using command line. I used the default setting of l2gen. The command that I used is: " l2gen ifile=xxx ofile=xxx l2prod="Rrs_vvv aot_869 chlor_a solz senz' geofile=xxx".
Unfortunately I cannot post the Software & System Info. In the begining I installed SeaDAS on my Mac and I encountered some problem in Catalina (when I ran l2gen from GUI, it always show segmentation fault). I searched in the forum and it seemed that I need to update my Mac system. So I updated it to macOS Ventura 13.3.1. But SeaDAS does not work well on this version. What I can tell now is that macOS is Ventura 13.3.1, SeaDAS is 8.3.0 and ocssw is V2022.3.
Re: SeaDAS cannot reproduce OBPG l2 product
Posted: Thu May 18, 2023 8:44 am America/New_York
by OB.DAAC - SeanBailey
Make sure you are using the same ancillary inputs that were used in the OBPG processing. With NRT files, the OBPG processes with the best available at the time of processing. If you process a file later, is it possible - actually quite likely - that the ancillary files obtained via getanc will not be the same as used in the OBPG processing. This is one of the reasons we reprocess data as 'refined' once the definitive ancillary products are available.
The ancillary files used are listed in the Level 2 file metadata as part of the processing_control group, e.g:
:input_sources = "AQUA_MODIS.20230511T213500.L1B.hdf,AQUA_MODIS.20230511T213500.GEO.
NRT.hdf,GMAO_FP.20230511T120000.MET.NRT.nc,GMAO_FP.20230511T120000.MET.NRT.nc,GMAO_FP.20230511T12000
0.MET.NRT.nc,GMAO_FP.20230511T120000.MET.NRT.nc,GMAO_FP.20230511T120000.MET.NRT.nc,GMAO_FP.20230511T
120000.MET.NRT.nc,anc_cor_file_28jan2014.nc,morel_fq.nc,polcor_modisa_2010b,aerosol_modisa,modisa_oc
r_vc_nn,gebco_ocssw_v2020.nc,gebco_ocssw_v2020.nc,gebco_ocssw_v2020.nc,mld_climatology_woa1994.hdf,2
0230510120000-CMC-L4_GHRSST-SSTfnd-CMC0.1deg-GLOB-v02.0-fv03.0.nc,20230510120000-CMC-L4_GHRSST-SSTfn
d-CMC0.1deg-GLOB-v02.0-fv03.0.nc,sss_climatology_woa2009.hdf,no2_climatology_v2013.hdf,alpha510_clim
atology.hdf,taua865_climatology.hdf,calcite_table-20170109.txt,owmc_lut.hdf,water_spectra.nc,xcal_mo
disa_axc_oc_v2.9d,bt_modisa.hdf" ;
The input_sources attribute lists the files, while the input_parameters group (under the processing_control group) provides the values actually passed to the code, e.g.:
:met1 = "GMAO_FP.20230511T120000.MET.NRT.nc" ;
:met2 = "GMAO_FP.20230511T120000.MET.NRT.nc" ;
:met3 = "GMAO_FP.20230511T120000.MET.NRT.nc" ;
:ozone1 = "GMAO_FP.20230511T120000.MET.NRT.nc" ;
:ozone2 = "GMAO_FP.20230511T120000.MET.NRT.nc" ;
:ozone3 = "GMAO_FP.20230511T120000.MET.NRT.nc" ;
Sean