Pass the cosmoDC2 SEDs directly to imSim

[cwwalter]

Item for discussion:

If we had a new instance catalog like I just described in #71, we could consider adding an option where we passed the the 30 or so top-hat fluxes from CosmoDC2 directly into imSim where we could then use an interpolation function and utilize that SED directly rather than doing a template match to the system SEDs as is being done now.

This future enhancement would be possible with new instance catalog infrastructure since, with a flexible binary format, we could select which system to use and more easily pass the data structures we needed.

This isn't something we necessarily want to do right away but might be a good option in the future.

CCing: @evevkovacs and @erykoff since they don't follow this repo.

[jmeyers314]

I guess the one thing I'd worry about with a simple SED interpolation is the that we may be smoothing over emission/absorption lines / breaks in a way that could impact photo-z estimates. How narrow are the 30-bands?

[cwwalter]

Well... the function could do whatever we need... but (for my info) do the CosmoDC2 SEDS know about that sort of structure?

[rmjarvis]

In particular, once we start caring about fringing, we'll want emission lines in galaxy spectra as well as the sky.

[danielsf]

Are we sure that there are cosmoDC2 SEDs? I had many conversations with @evevkovacs and @aphearin about how I would like an SED library to feed to PhoSim. The conclusion was that this was not possible (but I cannot remember why)

[evevkovacs]

The narrow band filters vary in width: Here's a list of the 30 filters, where sed_A_B means a filter spanning the wavelength range A to A+B: ['sed_1000_246', 'sed_11467_1710', 'sed_1246_306', 'sed_13177_1966', 'sed_15143_2259', 'sed_1552_381', 'sed_17402_2596', 'sed_1933_474', 'sed_2407_591', 'sed_2998_186', 'sed_3184_197', 'sed_3381_209', 'sed_3590_222', 'sed_3812_236', 'sed_4048_251', 'sed_4299_266', 'sed_4565_283', 'sed_4848_300', 'sed_5148_319', 'sed_5467_339', 'sed_5806_360', 'sed_6166_382', 'sed_6548_406', 'sed_6954_431', 'sed_7385_458', 'sed_7843_486', 'sed_8329_517', 'sed_8846_549', 'sed_9395_583', 'sed_9978_1489'] (Note that these are rest-frame quantities). More finely grained SEDs would be very expensive to simulate. I have just made a set of comparison plots between the rest-frame LSST magnitudes from the CatSim fits to the 30 cosmoDC2 sed filters and the cosmoDC2 LSST magnitudes calculated by cosmoDC2 galaxy model. In general these look reasonable. I'll post these soon.

Re emission lines: cosmoDC2 has separate quantities for emission lines. The values for the sed* filters are just for the continuum. Validation of the ELG model is in progress by the PZ group and others, but early indications are that it has some behavior that is not realistic.

[cwwalter]

Hi All,

I'm still confused by this question

Are we sure that there are cosmoDC2 SEDs? I had many conversations with @evevkovacs and @aphearin about how I would like an SED library to feed to PhoSim. The conclusion was that this was not possible (but I cannot remember why)

and then Eve's response. For the non-experts: are there suitable SEDs and ELGs etc in cosmo DC2 that we could use if we built the proper interfaces?

[evevkovacs]

It depends what you mean by "suitable". My understanding is that the "SEDs" (described above) are too coarsely binned for the image simulations (at least for PhoSim). Galacticus doesn't use templates. We have to define "SED filters" by setting up a bunch of narrow-band top-hat filters to approximate the SED. More finely grained "SED filters" than the 30 described above would be very expensive to run. Emission-line information also exists but has not been validated.

[cwwalter]

It depends what you mean by "suitable". My understanding is that the "SEDs" (described above) are too coarsely binned for the image simulations (at least for PhoSim). Galacticus doesn't use templates. We have to define "SED filters" by setting up a bunch of narrow-band top-hat filters to approximate the SED. More finely grained "SED filters" than the 30 described above would be very expensive to run. Emission-line information also exists but has not been validated.

Well what we mean is that we can take those 30 samples and interpolate them, add lines, or what ever we need.

The question for you and @aphearin etc, is if there is enough information from Galacticus alone to simulate the galactic spectra?

[cwwalter]

Also, for our information: what is going on internally where you represent the SED with a "SED filter"? I mean: Does galacticus have its own set of templates? Or are things calculated analytically, etc etc?

We could also think about the best way to represent what Galacticus wants to output.

[cwwalter]

For example: a 30 component PCA representation of the internal galacticus SED might be more effective than 30 top-hats, but I don't know if that is possible or even makes sense in this setup.

[evevkovacs]

There is no "internal galacticus SED" (in the sense of an available template, See below for a detailed explanation of how the filter fluxes are computed in Galacticus). The fluxes in the 30 filters are the only information available. Whether or not this is sufficient to reconstruct a sufficiently accurate SED for the image simulation is a complicated question that needs to be evaluated by experts.

[cwwalter]

Sorry, I really don't understand the details of this and need some help to evaluate the situation. Can you give us more specifics of what the code is doing? Above you said:

"Galacticus doesn't use templates. We have to define "SED filters" by setting up a bunch of narrow-band top-hat filters to approximate the SED. "

So what is it that you are approximating with the filters?

[abensonca]

What happens internally in Galacticus is the following:

1. For each galaxy, we compute a star formation history. That is, a function r(t,Z) which gives the rate of star formation (Msun/yr) in a galaxy at cosmic time t, and at metallicity Z. (Since galaxies can form through merging it possible for a single galaxy to have star formation occurring at multiple different metallicities at a single time.)

2. There is a library of SEDs for simple stellar populations (SSPs), that is, each of these SEDs represents unit mass of stars, distributed according to some IMF, of a single age, t, and metallicity, Z. Call this S(lambda;t,Z).

3. The SED of each galaxy, G(t), is then constructed by integrating:

G(lambda;t) = int_0^t dt' int_0^infinity dZ r(t',Z) S(lambda;t-t',Z)

In practice, since S() is tabulated at ~2000 wavelengths we don't actually want to compute the full integral at every wavelength to get the galaxy SED (due to memory and CPU limitations). Instead, we define some bandpass, R(lambda), and compute the luminosity in that bandpass using:

L(t) = int_0^infinity dlambda G(lambda;t) R(lambda)

or:

L(t) = int_0^t dt' int_0^infinity dZ r(t',Z) s(t-t',Z)

where now

s(t,Z) = int_0^infinity dlambda S(lambda;t,Z) R(lambda)

If we make R(lambda) a narrow, box bandpass, and compute luminosities for many such bandpasses we get a crude approximation to the SED. (We use the same approach to compute luminosities in actual bandpasses.) This keeps things computationally manageable, both in terms of reducing the memory requirements per galaxy, and also because the s(t,Z) functions can be precomputed in advance.

So, the bottom line is that there is a set of template SSP SEDs which go into the calculation, but each Galacticus SED is some weighted combination of a large number of those SSP SEDs.

[cwwalter]

For the time being we have decided to do a more unconstrained fit to use the built in SED library. In the future we might revisit this discussion but it will be done in the context of a more general look at the galaxy color models and interfaces.