<SYSTEM_TASK:>
Given the following text description, write Python code to implement the functionality described below step by step
<END_TASK>
<USER_TASK:>
Description:
 Warning!
The %timeit (for 1-liners) and %%timeit (for several lines of code) ipython magics (that's what they call %-functions) don't actually store the results for memory protection reasons (imagine each of your tests create a lot of data), so you have to run it without the timing test to actually get to the result.
Also, even so the wavenumber min delta required would have been around 40, anything larger than 0.1 wavenumbers and the code barks that that would lead to declining accuracy.
Using OmegaGrid
Interestingly, using OmegaGrid, it does not bark, even so the deltas are between 40 and 70 wavenumbers.
Step1:  wavelengths vs wavenumbers issue
I understand it now. When one calculates the wavenumbers from wavelengths and does NOT invert them in sequence and provides it to the coeff calculator, the confusing part is that it returns things in increasing wavenumber order.
This means, if I plot the result over un-inverted wavelengths, it's wrong! One has to invert the wavelengths, now that the results are sorted by increasing wavenumber. This is no Python-ism but a decision of the HAPI API, probably based on old calculation formulas that were used to start at the lowest wavenumber. See below how to get it correct and consistent.
Step2:  This strongly looks like 0.005 micron is not enough resolution, the plots looks a lot different then before. I go to 0.001 micron resolution for the following plots
<ASSISTANT_TASK:>
Python Code:
nu, coeff_co2 = hapi.absorptionCoefficient_Voigt(SourceTables='CO2',
                                                 Environment={'p': 90,
                                                              'T': 700},
                                                 OmegaGrid=wavenos,
#                                                  OmegaRange=[wavenos.min(),
#                                                              wavenos.max()],
#                                                  OmegaStep=0.1,
                                                 GammaL='gamma_self')
print(wavenos[::-1])
waves_nu = 1e4/nu
Explanation: Warning!
The %timeit (for 1-liners) and %%timeit (for several lines of code) ipython magics (that's what they call %-functions) don't actually store the results for memory protection reasons (imagine each of your tests create a lot of data), so you have to run it without the timing test to actually get to the result.
Also, even so the wavenumber min delta required would have been around 40, anything larger than 0.1 wavenumbers and the code barks that that would lead to declining accuracy.
Using OmegaGrid
Interestingly, using OmegaGrid, it does not bark, even so the deltas are between 40 and 70 wavenumbers.
End of explanation
plt.semilogy(waves[::-1], coeff_co2)
plt.semilogy(nu, coeff_co2)
Explanation: wavelengths vs wavenumbers issue
I understand it now. When one calculates the wavenumbers from wavelengths and does NOT invert them in sequence and provides it to the coeff calculator, the confusing part is that it returns things in increasing wavenumber order.
This means, if I plot the result over un-inverted wavelengths, it's wrong! One has to invert the wavelengths, now that the results are sorted by increasing wavenumber. This is no Python-ism but a decision of the HAPI API, probably based on old calculation formulas that were used to start at the lowest wavenumber. See below how to get it correct and consistent.
End of explanation
waves = np.arange(0.8, 1.1, 0.001)
wavenos = 1e4/waves
nu, coeff_co2 = hapi.absorptionCoefficient_Voigt(SourceTables='CO2',
                                                 Environment={'p': 90,
                                                              'T': 700},
                                                 OmegaGrid=wavenos,
                                                 GammaL='gamma_self')
plt.semilogy(waves[::-1], coeff_co2)
plt.semilogy(nu, coeff_co2)
Explanation: This strongly looks like 0.005 micron is not enough resolution, the plots looks a lot different then before. I go to 0.001 micron resolution for the following plots:
End of explanation
<END_TASK>