Objects with odd ABSMAG_SDSS_R

[edarragh]

A handful of objects from the LOW-Z program with unexpectedly bright ABSMAG_SDSS_R

TARGETID

39633481701000832 39627862432552794 39633141308069648 39633343209279504 39633428097794736 39633507869262245 39627717636787810 39628023342826572 39628071015284948 39628159053726478 39628182306947825 39628135825672502 39628211436393100 39628199897861563 39628245884208887 39628188023785809 39628357876318744 39632941596281448 39628512897797887 39633072903160512

HEALPIX

11615 12320 15025 15279 16006 16106 19075 31655 31685 31725 31738 32298 32311 32311 32358 8521 8575 9397 9411 9868

PROGRAM	SURVEY
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main
bright	main

[moustakas]

Thanks for the report @edarragh.

What are the redshifts of the objects? One possibility is that the redshifts of these objects are incorrect, leading to the brighter-than-physical rest-frame photometry.

You can also generate QA to diagnose the issue. Do you mind doing so for your sample and reporting the results back here?

There's some documentation here, although admittedly probably not enough to be helpful! https://fastspecfit.readthedocs.io/en/latest/install.html https://fastspecfit.readthedocs.io/en/latest/running.html#one-fastphot-example

But from either perlmutter or cori, here's what I did to generate QA for the first two objects:

source /global/cfs/cdirs/desi/software/desi_environment.sh main
module load fastspecfit/main
fastspecfit-qa /global/cfs/cdirs/desi/public/dr1/vac/fastspecfit/guadalupe/v1.0/catalogs/fastphot-guadalupe-main-bright.fits \
  --targetids 39633481701000832,39627862432552794 --outdir /global/cfs/cdirs/desi/users/ioannis/tmp

To do the full sample, you'll just need to pass a longer comma-separated list of TARGETIDs and you can obviously change the output directory.

And here's the first object: The fit looks OK but the redshift is 3.79, so really bright in the rest-frame! https://data.desi.lbl.gov/desi/users/ioannis/tmp/fastphot-main-bright-11615-39633481701000832.png

[edarragh]

Yes it does look like the problem is the redrock redshifts for these objects are too high (1.5 < z. < 4). However, I think all of these objects have multiple observations because the redshifts I have for these objects are much lower:

Z

0.06153824 0.20843961 0.12874662 0.16083649 0.19068298 0.08696652 0.16535471 0.1724017 0.23208781 0.13507766 0.17187988 0.06583512 0.11884124 0.17460608 0.15292654 0.18862317 0.0871645 0.09431799 0.1686657 0.20266299

[moustakas]

@edarragh where are your redshifts coming from? My fits are based on the healpix coadds, so each SURVEY-PROGRAM-TARGETID is (should be!) unique.

[moustakas]

Oh, the exception is that we do use the updated QuasarNet redshifts, for very high-probability high-redshifts QSOs-- https://fastspecfit.readthedocs.io/en/latest/fujilupe.html#updated-qso-redshifts

Can you see if Z differs from Z_RR for the objects in your list? If so, then that means I've used the QuasarNET redshift when performing the spectral fitting.

[edarragh]

Yes it looks like the discrepancy is between Z and Z_RR for the objects mentioned

[edarragh]

It does appear that a number (though I don't think all) of the objects are blended

[moustakas]

This is very interesting, @edarragh. Do you mind posting your finding to the #fastspecfit channel and tagging @stephjuneau and @armengau? This is definitely an unexpected (for me) failure mode of the QuasarNet redshifts that will impact some low-redshift galaxy science which we'll want to think about.

In the meantime, if you generate the list of your targets where Z != Z_RR then I can run fastphot and fastspec at the original Redrock redshifts without too much hassle (or I can show you how you can do it!).

[edarragh]

Hi John, here is the full list of objects with significantly discrepant redshifts (Z - Z_RR > 0.3). fastspec_photo.fits.zip

[stephjuneau]

Hi @edarragh & @moustakas this issue will be fixed with the new QSO conditions that Becky & I sent to Edmond et al. today. Namely, all the cases with a discrepant QSO redshift had SPECTYPE='GALAXY'. The new recommendation for BGS targets (which some of those are also in addition to secondary targets) will be to only consider QSOs that also have SPECTYPE='QSO' in addition to passing a QuasarNet threshold. We are also now recommending not to apply the afterburner cuts on secondary targets until those are studied in more detail case-by-case. The new QSO criteria should be implemented shortly for both the QSO catalog and the fastspecfit package, so we can double-check afterwards that the problem is fixed.

[moustakas]

Fixed in #96.