Iris/SED tool fitting not transparent [BR-113]

[jbudynk]

I'm attempting to fit an SED of a star + protoplanetary disk. The attached image shows my current best effort, which is somewhat nonsensical.

1. The wavelength axis has to be in Angstroms, because that's the only unit that Iris recognizes for fitting, even though microns is a more natural unit for this particular data set.
2. The fitted amplitudes are well below 0.1 Jy, yet the SED itself clearly shows both the star and disk components peaking well above 0.1 Jy.
3. Not shown in this screen shot, but, if I constrain the ranges, run a fit, then look at the ranges again, they've reset to the extreme range rather than being constrained to the values that I specified initially. (E.g., I know that the disk temperature is probably close to 100 K, so I should be able to constrain it so some reasonable range, not 1E-38 and 3E38 which is what the default range is.)

DUPLICATE OF #3 [VAOPD-600]

[jbudynk]

I am not sure there is anything that needs to be done for this report for Iris 1.1. I have studied the three issues raised, and have these comments to make:

1) It is true that the internal units of the wavelength axis has to stay in Angstroms, to be recognized for the fit--even though the units may be displayed in other units. (For example, here you display the data in microns.)

I think addressing this is outside the scope of Iris 1.1, though the issue should be prominently noted in the caveats issued with the release. I've spoken with Janet, and we do think the issue should be open for discussion for Iris 2.0. For example, you proposed that we enable some units conversions for parameters that are now stuck in Angstroms--it's sensible to look at that for any parameters stuck to particular units.

So issue 1 should be closed for Iris 1.1, but opened up for Iris 2.0.

2) I think that for this issue, you are caught on a point that is perhaps not well documented in the help files for models like the blackbody. The amplitude parameter is not the amplitude at the peak of the blackbody, but is the amplitude at the wavelength equal to the value of the "refer" parameter. This location obviously need not coincide with the peak of the blackbody curve.

I confirmed that this is so by calling the blackbody model with its default parameters (refer=5000, ampl=1.0, temperature=3000) – feeding the function a wavelength of 5000 (so wavelength=refer) returns a value of 1.0. And if you study your plot, this should also be true. Where the wavelength is 10037, then the red curve should be about 0.04 (the value of the ampl parameter for that model), as an example.

The parameter of interest in these fits is the temperature. The refer and ampl parameters are degenerate – ampl will change in proportion to the value you set the refer parameter to. (The reason for this is that you can fit for much lower or higher temperatures by changing the "refer" parameter – without exceeding what the exponential function can calculate. The exponential function is called by the blackbody model – and of course, is constrained by the size of floating point numbers.)

I think this point needs to be documented in the help for blackbody in Iris 1.1. Perhaps for Iris 2.0 we do need to revisit the implementation. If the user would like to read off the ampl parameter, as well as the temperature, then this method of using the refer parameter is perhaps not so good. If the user only is interested in temperature, then this is still OK.

3) You should be able to constrain parameter ranges. And I found that this is an issue with the text boxes in the Specview GUI. I think this has actually been found before and there should already be a bug report for it.

Suppose that you edit the temperature parameter for the blackbody (just as an example). If you type "50" in the Min field, "200" in the Max field, and then click OK, the editor GUI closes – and the next time you open it, you see the edits did not take, just as you say here.

The reason is that you have to hit the Return button after each edit. If you open the editor again, and this time type "50", then Return, in the Min field; then type "200", then Return, in the Max field – then the edits will take. If you click OK, then open the editor GUI again – this time, you should see the edits you had made.

I believe this is a long-standing issue with how you need to enter edits in text fields of the Specview GUIs.

In my opinion, this is something we should aim to amend in the Iris 2.0 release. The edits should take if you click the OK button, whether or not you hit the Return button when making edits in those text fields. But this is a GUI issue, and Ivo can say how much work is involved in changing this behavior. I'd have to dig up the bug report, but I think it was given a somewhat lower priority when previously reported.

To sum up, I think we've identified issues that mean more clear documentation and caveats for Iris 1.1, and coding work that would be candidates for Iris 2.0 improvements. There should be no additional coding or bug fixes for Iris 1.1 due to this report.

Does this seem like a reasonable summary? Or am I underestimating the importance of any of the above points?

[jbudynk]

I don't remember the release schedule for Iris 1.1, other than "soon," so I'm happy to accept the suggestions that you have for version 1.1. However, they should be fixed for Iris 2.0. It seems completely nonsensical to ask the user to convert from his/her units of choice to Angstroms simply because that's what the software uses internally, and it's quite counter-intuitive that clicking 'OK' doesn't implement an entered change to parameters.

[jbudynk]

Just to close this out:

It seems completely nonsensical to ask the user to convert from his/her units of choice to Angstroms simply because that's what the software uses internally

I can certainly see that, and we will have a serious discussion about how to address that for Iris 2.0.

It's quite counter-intuitive that clicking 'OK' doesn't implement an entered change to parameters.

I asked Ivo, and he said that actually the fix to this was small enough to accomplish for today's Beta 9 build. As Omar has just put Beta 9 out for testing (see his note today to the SED mailing list) – then you should see this fix, at least, in Beta 9. (You should see the button is now named "Apply", and there should be no need to hit Return after typing a number in the text box.)