DEM from EIS observations - discrepancy in the modeled intensities

[AlexandrosKoukras]

Hello,

I am trying to compute the DEM from a set of EIS observations that I have but the modeled intensities that I derive after the DEM (i.e. dn_reg) do not agree with the observed intensities. They seem to be systematically lower, especially for some ('colder') lines.
I have used all the three different methods for the regularization (default, gloci, user defined) and I played a bit with the free parameters of the framework (e.g. dn2dm keywords, density, temperature bins, noise levels, etc.) but the issue persists.

I created a jupyter notebook where I reproduce the issue, you can find it here. I might be doing something wrong or I am missing something, if you can have a look it would be awesome.

The notebook was put together from the scripts that I am using, so if you have any questions or something is not clear please let me know.

Thank you.

[alasdairwilson]

Hi, Sorry for taking some time to reply, I took a reasonably long look at this last week to be sure there wasn't a bug and while I agree with you that the estimated dn are low in a systematic pattern but I can not seeing any problem.

I think most reassuringly the DEMs recovered look really good. Not from all methods for sure but from some of them, especially if you plot with the loci curves they look like good:

Also the method which I would have expected to recover the best DEM: using the loci curves as the norm does get reasonably close to the DN counts:

I think there are probably a few tweaks that can be made but also some limitations in the problem as presented. Your temperature range doesn't cover the full range of sensitivities of the line, there is obviously material off both ends of the scale which are contributing to the instrument DN counts but not the counts of the recovered DN. However, there are potentially science limitations: at the low end you might be hitting in to problems with the opacity. I am not a spectral person so don't want to speculate too hard here.

Something that might really help is just more lines, in my experience you kind of have to cover the whole range where there is significant DEM, if you have significant contributions at the edge of the range then the dn counts are bad and if you extend the range without sufficient filter coverage then the algorithm might introduce spurious high and low T DEM material.

The other very minor problems I noticed were the self weight peaks at the first data point so will probably never work, the max_iter you set was very very high. This probably isn't a problem for single pixel stuff but if it isn't hitting a non-zero DEM solution with target chisq of ~1000 at 500 iterations then it probably isn't ever. (You can adjust rgt_fact as well so it reaches a positive solution in fewer iterations)

[alasdairwilson]

I also loaded some other EIS data, with 11 iron lines, and managed to get what I would call a "good dem"

[AlexandrosKoukras]

Hi Alasdair,

Thank you for looking into it.

I noticed that even in the case of the 11 lines the modeled intensities were systematically lower. Could this be an indication that the temperature range I used was not the issue?

The DEM indeed 'looks good' in some of the cases but my concern is that I cannot trust it if the modeled intensities do not match the input intensities I provide. Of course I don't expect them to match perfectly but to have a spread around 1 (for the ratio), which is something I haven't be able to get so far.

[AlexandrosKoukras]

Looking into this further I wanted to compare the results from demregpy with what I would get from the IDL version. For this reason I reproduced this issue in IDL. I tested two methods: the dn2dem_pos_nb which is based on H&K 2013 and the data2dem_reg which is based on H&K 2012.

The first one produced similar results with what I get from demregpy. I think this is somewhat expected since demregpy was based on that method.
But surprisingly the older method produced better results, in the context of modeled vs observed intensities.

[alasdairwilson]

I don't have a good answer for that: I do know that for AIA, as long as the algorithm succeeds, the recovered DNs are always VERY close to 1, these channels obviously have a slightly wider response which might help the algorithm. I feel there is a trap there though in that assuming a dn_reg that matches dn_in means a trustworthy result, with bad choices for running this code (and others) it is possible to get very good matches on these while producing completely unbelievable DEMs.

There might be something in the mathematics that penalises excess DEM more heavily than missing DEM. I.e. if you imagine a scenario where adding some more DEM at logT = 6.4 would help one channels counts by increasing them (say a dn ratio from 0.5 to 0.6) but hurt another channels results by bringing them further away from 1.0 (say 1.1 to 1.2) then it might end up weighting the problem such that it would rather channels read low than high. You certainly never see DEMs encroaching on the LOCI curves in my experience.

As for your second comment, regarding the idl versions, yeah I mean I don't really know offhand the totality of the differences between the non positivity constrained and the positivity constrained IDL versions but they certainly extend beyond just the positivity constraint.

Another thing of note here is that there are error bars on these DEM values and, as such, there are error bars on the dn_reg. Almost by definition the error bras on the extrema of the temp range are going to be orders of magnitudes higher than the central points, which are far more heavily constrained by overlapping filters. This almost certainly means that centrally oriented filters are going to have a dn_reg/dn_in closer to 1 and that extreme located filters are going to have a ratio <1.0.

[alasdairwilson]

If it helps with another puzzle piece, with a synthetic DEM generating dn's for those same 11 iron lines you get this as the ratio of dn_reg/dn_in:

I.e. a near perfect recovery of the input dn (all filters within 0.1% or so of their targets)

And with 10% noise on both DEM and DN:

And the DEMs: