Allow arbitrary units in Spectrum methods

[erwanp]

SpectrumFactory can read arbitrary astropy.units inputs after #55

We need to do the same thing for the Spectrum post-processing methods, for instance rescale_path_length, crop, etc. See all the methods there: https://radis.readthedocs.io/en/latest/spectrum/spectrum.html

Most of the work will be in the spectrum.py file.

• parse inputs with the convert_and_strip_units function as in Deploy astropy units throughout radis : Take I #55
• update examples in the docs

Edit: Here are all the Spectrum methods:

• apply_slit
• compare_with
• copy
• crop
• get
• get_conditions
• get_integral
• get_name
• get_populations
• get_power
• get_quantities
• get_radiance
• get_radiance_noslit
• get_rovib_levels
• get_slit
• get_vars
• get_vib_levels
• get_wavelength
• get_wavenumber
• get_waveunit
• is_at_equilibrium
• is_optically_thin
• line_survey
• offset
• plot
• plot_populations
• plot_slit
• print_conditions
• resample
• rescale_mole_fraction
• rescale_path_length
• save
• savetxt
• store
• update

---

Edit :

Could also be done in sPlanck to combine the use of wavelength or wavenumber, and also allow the use of Frequency (in Hz)

• once done, could answer with a RADIS example on this StackOverflow post that requires Planck blackbody calculation with frequency (in Hz)

[pkj-m]

@erwanp after working on SpectrumFactory and adding support for wmin/wmax and wunit, I think I gained a decent understanding of how to implement arbitrary units in the Spectrum methods, so I'd like to take this up next. Are there any specific methods that you think I should prioritize or is it okay if I start taking them up sequentially?

[erwanp]

Hello! I listed all the methods above. They are all quite similar in terms of complexity. As discussed in #96 you will only have a problem in choosing what to do when dimensioned inputs contradict the default unit value (for "wunit" for instance). That should be resolved in #96 first. We may want feedback from users too!

[pkj-m]

Hey @erwanp , I had a small question. From the docs, the get methods functions as follows:

w, I = s.get('transmittance_noslit', wunit='cm-1')

should return the wavenumber and the transmittance in cm-1 and the default unit respectively. At the same time, if I try to call the method like this:

w, I = s.get('transmittance_noslit', wunit='m-1'),

it throws an error. So if I got this right, the goal of this issue is to allow us to make the above function call work and give us the wavenumber and transmittance in m-1 and default respectively? Is that correct? And this flexibility should be offered to the Iunit parameter's unit as well?
Additionally, the values being returned need to stay as numpy arrays or are we supposed to change that and return astropy's Quantity array instead?

[erwanp]

1. Exactly for wunit. Currently it's only reading from harcoded set of values, either ~nm or ~cm.
   With that change we'll allow other wavelengths ("cm", "µm"), wavenumbers ("m-1") or even frequency units ("GHz").

• Btw, I noticed that "cm" was featured in the wavenumber-like units as a shortcut to "cm-1" in spectrum\utils.py\WAVENUM_UNITS. This becomes dangerous with new arbitrary units, as it would be confused with a wavelength. Can you remove it in the process?

2. Conversion with arbitrary Iunit is already possible (handled with conv2). I think nothing is needed there.

3. Returning astropy arrays is an interesting idea. By default we do not want that: get() is also used internally during calculations: calculations with dimensionned array will always be slower.

What we could do (tell me what you think):

• as long as Iunit (or wunit) are specified, we return the numpy arrays, because the users knows what they're doing (the unit appears explicitly in their script).

• when wunit / Iunit are not specified, there is a chance that some information is lost in the process, so we return a Quantity instead.

Edit: this, however, seems a bit convoluted. The other option could be:

• we add an argument in get() that says "values only". Defaut to False (> returns dimensioned array). And all of the computationally-intensive calculation parts, we set it to True.

you'll also find that get() has a "copy=True" argument, that plays a similar role: if set to False, we return the reference to the array. It's much faster (no need to copy), but dangerous as any modification to the array will modify the Spectrum directly. Certaintly, any place in the code where we specified copy=False would also require a values_only=True.

[pkj-m]

Got it. For the second part, I think your suggestion in the edit might be the way to go. It'll help us keep the code clean and also, more importantly, keep it easy for the users to make use of and get familiar with the newly added functionalities.

[erwanp]

Ok perfect!!