Open Questions

[pernak18]

• right now, i extract the broadening parameter for a US 1976 standard atmosphere from LBLATM. this is done with the assumption that all of the dry molecules have defined been defined in LBLATM. but when we're running LBLRTM and calculating OD/ABSCO for just a single molecule, we zero out all of the other molecules. and in this case, should we not be increasing the broadener correspondingly?

• water vapor needs to be run twice because of the effects of the self continuum, which is a function of water vapor amount. our current plan is to scale the profile with PWV values of 1 and 2.5 cm. for other values of PWV, the user would have to interpolate or extrapolate using the two profiles we provide for 1 and 2.5 cm. but could we not just allow the user to input different PWV amounts?

• does this method for water vapor have implications for record 1.2a (continuum scaling factors), or should self and foreign continua always be on for H2O if H2O is a molecule requested by the user?

• should we always be using 10.3E format, or should we give the user the ability to use 15.8E? right now, we are only allowing 10.3E.

• there are some molecules with both line parameters and XS coefficients (item 1 in https://github.com/pernak18/ABSCO/issues/3). CF₄, HNO₃, NO₂, and SO₂ are part of this sample (and in the list of molecules we'll allow -- are a couple others with both sets of parameters but we will not do any processing with them). the latter 3 are labeled "0" in https://aer-rc.slack.com/files/U3M7CKC3U/FB6H4V8V7/fscdxs, which means only XS files exist for certain bands, and the three do have line files in /nas/project/rc_static/models/aer_line_parameters/AER_line_files/aer_v_3.6/line_files_By_Molecule/, but what do we do if the input band overlaps both the "line parameter territory" and the the "XS territory"? break up the band into smaller bands? use one set of parameter in both zones?

• what should be done with HDO, O2-O2, and BRO? None of these are in the XS or AER line parameter databases.

• HITRAN provides us with two bands for BrO, but we specify only the 25927-34919 cm^-1 as active. is that what we want?

• should we consider writing a parallelization script that utilizes ABSCO_tables.py (which can be used in multithreading)?

• i define the height of the standard atmosphere surface pressure (1013 mbar) as 0.5 km. is this OK for our purposes?

• is degradation of OD, rather than of ABSCO, OK? seems like we're just switching up our division (first by kernel, then by layer amount)

• i've only designed the code with wavenumbers in mind. how do we plan on extending to other spectral representations?

• if the user provides a non-wavenumber spectral unit (um and nm are currently allowed), do we wanna convert LBL output spectral grids to those units, or keep them in wavenumbers? right now, we are sticking with wavenumbers.

• LBLRTM ignores speed dependence (it's a monoRTM thing), but i believe in our requirements we say we'll take it into account. how?

[pernak18]

for the broadener, see https://github.com/pernak18/ABSCO/issues/5

[pernak18]

on the second bullet point, my interpretation on what we wanted to do with PWV was incorrect. there is no scaling with PWV. rather, for the molecules whose continuum is affected by WV, we provide the H2O VMR with the molecule's VMR (while simultaneously keeping the H2O continua "off"). this has been implemented.

[pernak18]

while the code should be easy to use in parallel, i would not yet recommend it (and thus have not written a parallelization script) because of the expected RAM requirements, which are calculated in the calcRAM() method of the configure class (ABSCO_preprocess.py). as an example, O₂ for 100 wavenumbers at 4e-4 (degraded) resolution and all Ts and Ps (and since it's O₂, both H₂O VMR values) is expected to need 23.520 GB of memory. Non-WV affected molecules with the same parameterization would be half of that (11.760 GB).

[pernak18]

• we are not prioritizing HDO right now.
• O₂-O₂ is already taken into account in the O₂ continuum, so the dimer is already handled.
• BrO has been added as a cross section

[mcduffie]

I think parallelization is a good idea given the under utilization of available CPU resources by the CPU. If not on the same machine it would be great if the software could be parallelized to multiple machines with the results stitched back together. For the RAM issue this could be offset with writing blocks to disk instead of keeping it all in memory.