Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TRILEGAL support #118

Open
JoanneBogart opened this issue Aug 20, 2024 · 3 comments
Open

TRILEGAL support #118

JoanneBogart opened this issue Aug 20, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@JoanneBogart
Copy link
Collaborator

JoanneBogart commented Aug 20, 2024

TRILEGAL star properties may be obtained from Astro Data Lab. See available quantities at https://datalab.noirlab.edu/query.php?name=lsst_sim.simdr2. As compared to the information available to skyCatalogs when producing catalogs of stars from other simulations, the following inputs are missing:

  • unique object id
  • SEDs, though these can be computed from quantities which are available.

Since there is concern that many parallel processes accessing the db during simulation could cause too much contention, we are currently planning to first create skyCatalogs main catalogs for TRILEGAL stars (parquet files, partitioned by healpixel; adding a column for a unique id in the process) by querying the database, then from that create SEDs (probably hdf5, also one per healpixel), and finally create (parquet) flux files.

Uncompressed hdf5 SED files could amount to about 50 Tbytes total (LSST footprint) but should compress down to about 3 Tbytes. Parquet files per healpixel would be similar to the ones produced now for DC2 stars.

@cahebert
Copy link

The lsst_sim stellar catalog (generated with TRILEGAL) is described in detail in this paper.

@JoanneBogart JoanneBogart added the enhancement New feature or request label Aug 20, 2024
@sidneymau
Copy link

I know Claire has also done some work on producing spectra for the lsst_sim stars, but I thought these figures may be relevant to this conversation. A few notes:

  • The data are 100 stars from lsst_sim with label=1 (i.e., main sequence stars) and ring256=743100 (similar part of sky)
  • I am passing the lsst_sim parameters to several different libraries for generating individual stellar spectra. I then compute the magnitudes and colors for each spectrum (using the throughputs distributed through GalSim, which I think are equivalent to the lsst baseline v1.4). The 1-1 lines for color and magnitude are shown as dashed grey lines
  • The FSPS spectra here were produced using the BaSeL spectra library, which I believe are based on the Kurucz models
  • BT-Settl and Phoenix spectra are both produced via pystellibs, the latter of these using Claire's preliminary code for doing so. I haven't looked into why the Phoenix spectra have several stars that are anomalously much fainter than expected
  • The applied dust model is G23 from dust_extinction (source)

image
image
image

@cahebert
Copy link

Thanks for these plots, Sid. I think the plan is to use BT-Settl.

I'd done a similar comparison on a sample of 5000 stars (label=1 but sampled randomly across the sky), using pystellibs to produce the spectra. The lsst_sim catalog was generated with the O'Donnell 1994 dust model (O94 in dust_extinction), so I used that here, but I checked with the G23 model you used above and the difference was minimal.

Something funky is going on with Phoenix: >50% of rmag values are >1.5mag fainter than lsst_sim! Haven't looked much into where this is coming from, since the BT-Settl results looks good and it probably makes sense to use the same library that was used to generate the stellar catalog in the first place.
lsstsim-colormag-compare-mainseq

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants