Repository navigation
Crop .plot() issues with CHASE Data #258
Description
Describe the bug
I am using sunraster with CHASE data, and it has worked almost perfectly out of the box, thanks! I have encountered a strange issue whereby .plot() works fine on the spectrogram cube, and on a wavelength plane of the cropped cube (e.g. crop[71].plot()), but crop.plot() has a very strange wavelength grid. The first few planes appear correct (it's hard to be certain), but then the data seems to be wrong.
CHASE data can be acquired from SSDC here but this requires registration and login, so I have also made one file available on my OneDrive here.
To Reproduce
from astropy.io import fits
from astropy.wcs import WCS
import astropy.units as u
import matplotlib.pyplot as plt
from sunraster import SpectrogramCube
import numpy as np
from sunpy.coordinates import frames
from astropy.coordinates import SkyCoord
data = fits.open("RSM20240321T000051_0005_HA.fits")
data[1].header["CTYPE1"] = "HPLT-TAN"
data[1].header["CTYPE2"] = "HPLN-TAN"
data[1].header["CTYPE3"] = "WAVE"
wcs = WCS(data[1].header)
array = data[1].data
cube = SpectrogramCube(array, wcs, unit=u.DN)
pt1 = [SkyCoord(0*u.arcsec, 0*u.arcsec, frame=frames.Helioprojective), None]
pt2 = [SkyCoord(250*u.arcsec, 250*u.arcsec, frame=frames.Helioprojective), None]
crop = cube.crop(pt1, pt2)Screenshots
Result of crop.plot
System Details
sunraster: 0.5.1
==============================
sunpy Installation Information
==============================
General
#######
OS: Ubuntu (22.04, Linux 5.15.146.1-microsoft-standard-WSL2)
Arch: 64bit, (x86_64)
sunpy: 5.1.4
Installation path: /home/cmo/miniconda3/envs/Dask312/lib/python3.12/site-packages/sunpy-5.1.4.dist-info
Required Dependencies
#####################
astropy: 6.1.0
numpy: 1.26.4
packaging: 24.0
parfive: 2.1.0
pyerfa: 2.0.1.4
Optional Dependencies
#####################
asdf: 3.2.0
asdf-astropy: 0.6.1
beautifulsoup4: 4.12.3
cdflib: Missing cdflib!=0.4.0,!=1.0.0,>=0.3.20; extra == "docs" or "tests" or "timeseries"
dask: 2024.5.1
drms: 0.6.4
glymur: Missing glymur!=0.9.5,>=0.9.1; extra == "docs" or "jpeg2000" or "tests"
h5netcdf: 1.3.0
h5py: 3.11.0
lxml: 5.2.2
matplotlib: 3.9.0
mpl-animators: 1.1.1
pandas: 2.2.2
python-dateutil: 2.9.0.post0
reproject: 0.13.1
scikit-image: Missing scikit-image>=0.18.0; extra == "docs" or "image" or "tests"
scipy: 1.13.1
sqlalchemy: Missing sqlalchemy>=1.3.4; extra == "database" or "docs" or "tests"
tqdm: 4.66.4
zeep: 4.2.1
Installation method
pip
Activity
Abinash-bit commentedon Nov 17, 2024
hello I was trying replicating the issue but i am getting this error while replicating !!!
Can anyone help me out please.
nabobalis commentedon Nov 17, 2024
This is not an error but a warning. It is emitted by astropy and can be ignored for this case.
Abinash-bit commentedon Nov 18, 2024
Screen.Recording.2024-11-18.092808.mp4
Getting this result.
nabobalis commentedon Nov 18, 2024
Which replicates the original issue, so we still have a problem here.
Abinash-bit commentedon Nov 18, 2024
At 6.5 * 10 ^ -7 m of wavelength the plot becomes purple....
I have some queries regarding this:
in spectrogram_sequence.py.
nabobalis commentedon Nov 18, 2024
I don't know, if there is data that, it should be plotted instead of purple.
One will have to figure out if there is data in that part of the array and why its not being plotted.
sunraster is a light wrapper around ndcube, this is why you can't find the source code.
It would be worth testing this without sunraster and directly into ndcube to see if there is a difference in behavior.
Abinash-bit commentedon Nov 20, 2024
I have plotted the FITS data
array = data[1].data
which gives me this plot
and it has non empty values
also for wavelengths the data array is non empty
the only thing we need to see ......is there any data in between the two points we have taken that is
pt1 = [SkyCoord(0u.arcsec, 0u.arcsec, frame=frames.Helioprojective), None]
pt2 = [SkyCoord(250u.arcsec, 250u.arcsec, frame=frames.Helioprojective), None]
nabobalis commentedon Nov 20, 2024
Well that's what the crop should do, we need to track down why. If its a bug in the crop code or how astropy has handled the WCS