ValueError: transmittance not defined in Spectrum spectrum2742832803272. Use one of : ['radiance']
So I guess not possible (yet)?
This just tells you that there is no transmittance in this Spectrum. Did you geenrate it with
experimental_spectrum?
instead of experimental_spectrum?
where the user has to specify what he/she is loading with a keyword
or perhaps experimental_spectrum would not be needed at all (other than legacy perhaps)
Alright it seems when I do this it compares with transmittance_noslit
any way to compare it to the synthetic transmittance with slit applied
?
oops nevermind I'm having other problems
this is technically true since it is off by a fraction of 1e-8 due to truncation errors
it seems for this reason it doesn't let me plot a spectrum with slit
by the way is this chat the right place to post this or is it better to start an issue on Github for such cases?
You can resample the Spectrum, that may help fix the padding.
or perhaps experimental_spectrum would not be needed at all (other than legacy perhaps)
That could be an Issue too, btw!
Did you also see this: https://radis.readthedocs.io/en/latest/spectrum/spectrum.html#initialize-from-text-file-or-arrays ?
Hi all, I was working on implementing astropy units inplace of pint throughout RADIS and came across this particular test which calls the
apply_slit(..norm_by="max") method. When it does so, the code tries to process a string "I/I0" as a unit. I have been looking all over the pint documentation but I still haven't been able to identify how this worked. Any leads on how this worked would be appreciated!
Oh wow, turns out the example Erwan shared just before my message is doing the very same thing!
or perhaps experimental_spectrum would not be needed at all (other than legacy perhaps)
That could be an Issue too, btw!
Did you also see this: https://radis.readthedocs.io/en/latest/spectrum/spectrum.html#initialize-from-text-file-or-arrays ?
Not yet, looks useful!
Hi @erwanp , do you think there might be any other ways of handling the issue of using strings like
I/IO, -ln(I/IO) and eps in conjunction with Astropy? I have been at it for quite some time and it appears simply changing all occurrences of these strings to 1 won't resolve the issue. I have been forced to add a lot of if-else blocks in a lot of places to handle issues arising from the way astropy parses strings. For instance, while we could simply multiply two units represented as strings in pint by concatenating them with a * in between, in Astropy we need to first check whether both the strings are pure units or is one of them 1 (like in our case, following which we need to ensure that this string appears before the other string, nm in this case).
Inspite of making these changes, there are still other tests which break due to these changes, especially coming from matplotlib.
I have shared the console output on the PR ( #106 ) obtained from executing
test_slit() locally on my laptop. The traceback seems to be hinting at something going wrong with matplotlib but I still not clear about it.
@pkj-m I answered some of your problems: check the PR. the problem does not originate from fix_style but by how the LaTeX of the label is written.
Also, regarding the many print() comments in your code: I usually debug with the "%debug" feature of ipython, going through the different functions with "u" [up] and "d" [down], and evaluating the variables there. Of course it's up to you!
Also, regarding the many print() comments in your code: I usually debug with the "%debug" feature of ipython, going through the different functions with "u" [up] and "d" [down], and evaluating the variables there. Of course it's up to you!
Is there a diagram like this https://radis.readthedocs.io/en/latest/_images/RADIS_flow_chart.svg that includes the functions and modules that calculate each of the blocks
Hello @pkj-m @dcmvdbekerom : there are the Slack access : https://join.slack.com/t/radis-radiation/shared_invite/zt-ebxf872e-OQ5qGuf_HRMXTK9IXU6i3Q