Transmittance Coefficient Generation

Agenda Item 1:

A brief status update before talk

Discussion:

Introduction by Ben:

Meeting with ECMWF and HITRAN team

(1)   Complicated spectral regions (H2O continue absorption microwave submillimeter)

(2)   Species (line mixing)

Result:

We could keep pushing the remote sensing RT technique on different channels

Tasks:

Responsible People:

Deadline:

Agenda Item 2:

Science talk

Discussion:

Talk by Patrick: 

A first look at the CRTM coefficient generation package

1. Acknowledgements to contributors
2. Introduction
   1. Development issues (poor doc, missing files, no access to working version, lblrtm, and clear cases in favor of the JEDI approach)
   2. High level process overview is simple, but details are complicated. (lblrtm, ODAS, ODPS)
   3. Limitations of the code from the CRTM SVN trunk (HPC, not user friendly, config & hard coded Fortran set up)
3. GitHub Repository overview (User Guide in progress)
4. IR process
   1. LBLRTM set up and run

• Predictor training profiles, e.g., ECMEF83 (why not use reanalysis data instead?)
• SRF convolution steps
• Example: AVHRR3 transmittance

1. ODAS/ODPS
   1.                            i.     Pros and cons
   2.                           ii.     Running ODPS code
   3.                          iii.     Example: ODPS coefficient output, AVHRR3 NOAA19 CRTM legacy/new coefficients
   4.                          iv.     Alternatives? (user friendly, JEDI, more flexibility)
   5.                           v.     Remaining Issues (non-LTE, Zeeman splitting, polarization)

Questions:

Bryan: how complicated is it to get the package compiled?

Patrick: similar to code sprint. Package is on GitHub repo, need to set up specific library paths.

Bryan: any challenges for the apodization for interferometers?

Ben: reaching out to the instrument team, if there are enough requests by the community we might push forward.

Bryan: Everybody is still using the boxcar apodization function for simulations

Ben: We’d like more community feedback on instrument that you need coefficient for, especially if it is going to launch in the future. (spectral response function)

Ben: thanks to Patrick for doing this hard work!

Result:

Tasks:

Responsible People:

Deadline:

Agenda Item 3:

Aerosol update

Discussion:

Updates by Cheng:

Waiting for CRTM-CMAQ merge to look into the binary interface modification

GOCART GEOS5: need to find out how delta fit was applied to generate phase elements in CRTM LUT

Question:

Sarah: will CRTM support GOCART GEOS4?

Ben: yes, we will support binary GOCART GEOS4 to make CRTM backward compatible.

Sarah: Mark perhaps has more information on GEOS4 data version.

Result:

Contact Mark Liu on delta-fit

Tasks:

Responsible People:

Cheng Dang

Deadline:

Agenda Item 3:

CRTM 2.4 release

Discussion:

Update by Ben:

CRTM 2.4: Open MP, coefficient (Major work in the next month)

Continue developments on CRTM 3.0:

• Ming: surface elements
• Polarized elements
• Aerosol test is challenging
• Microwave (effective radius expansion for precipitation, Fuqing’s previous work)

Result:

CRTM2.4 deadline

Tasks:

Open MP, coefficients

Responsible People:

Team

Deadline:

October 2020

Agenda Item 4:

General questions and comments

Discussion:

Bryan: Snow emissivity bug in ATMS?

Ben: snow emissivity requires certain channels to presents for brightness temperature calculations. If there is missing data, the code crashes. We have a preliminary fix now.

Ming: the temporary fix is okay.

Ben: the error only shows up in JEDI. GSI has a better QC on data.

Ming: in the future, we need some input check in for CRTM. Especially for my surface work. It is the users’ responsibility to check inputs.

Ben: I agree. We want to also provide some flexibility and let the model fail gracefully if necessary.

Ming: When will the NetCDF interface be released?

Ben: CRTM v3.

Ming: For surface part, everything is in NetCDF format soon.

Hui-Ya: we changed from the binary format to netCDF, which is a big effort. netCDF is slow, and we spend a lot time on parallel coding.

Cory: The coefficient files should be much smaller compared to model output (10GB per hour model output)

Hui-Ya: we already have slow performance UPP?

Ben: netCDF definitely has more overhead, and we will do a speed test. Hopefully the file size reduction will compensate the time.

Hui-Ya: Will netCDF interface be parallel?

Ben: yes, we will provide necessary tools.

Ming: we might need to provide some configuration file for users, such as CRTM utility set up and configuration?

Ben: Yes, for example, CRTM does not have unit converting utilities. we will need to discuss it more.

Ming: STAR has AI conference now.

Ben: yes, we are interested in the AI based solution for CRTM.

Ming: we plan to do some AI based CRTM research looking forward, the challenge is the model accuracy.

Result:

Tasks:

Responsible People:

Deadline: