Bugfix transforms add support for arrays of obtstime#128
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #128 +/- ##
==========================================
+ Coverage 72.30% 73.60% +1.30%
==========================================
Files 31 32 +1
Lines 1892 1940 +48
==========================================
+ Hits 1368 1428 +60
+ Misses 524 512 -12 ☔ View full report in Codecov by Sentry. |
|
The windows test fail is unrelated so can be ignored. |
paolomassa
left a comment
There was a problem hiding this comment.
Looks good to me. Are the results consistent with IDL? If needed I can test it
|
At least in terms of the pointing information they agreement really well. python IDL IDL in in bold
|
a76c712 to
334aeca
Compare
FredSchuller
left a comment
There was a problem hiding this comment.
At least it makes sense, and I guess you tested that it does what it is supposed to do :-)
The sunpy/astropy coordinate stack expects SkyCoords to be able to take arrays of values but also arrays of times. This PR modifies the code to work with an array of times or values for example the flare flag positions. To support both a mean pointing between two times and and instantaneous (always interpolated between two nearest aux-epheris data point) this PR adds a new property
obstime_endto theSTIXImagingframe if set the average pointing, position betweenobststimeandobstime_endis used for coordinate transforms ifobstime_end = Nonethen an interpolated pointing and position is used.This all works nicely enough but it can introduce some inconsistencies you use a mean to transform one way but an interpolated value else where as shown in the example below.
The concept would be for imaging would always use
STIXImaging(obstime=<start_time>, obstime_end=<end_time>)and for other things e.g. CFL use inSTIXImaging(obstime=<start_time>