Closed pmelchior closed 7 months ago
To summarize my understanding of the motivation for this. Assume we have a galaxy/source (maybe a GC) with multiple stellar populations. These multiple populations may occupy different regions, and would expectedly have different SEDs. So the 2-model approach is motivated physically by saying one model would be maybe a point source where it would be more focussed on the SED correctness, the other is an extended source which can now have a better colour fit to the outskirts, as it is no longer tied to having a good colour match for the different population residing within.
Adding a second component will make the likelihood better of course, I am thinking for some kind of constraining on this is it unreasonable to make the morphology of the point source fixed, and only use a small single pixel point source to fit for an SED. That way we can use the same simpler uniform gaussian initialisation, and not worry about the degeneracy of having two identically constrained morphologies.
The reason for doing this is that galaxy often show some variation from the core to their outskirt colors, even if you cannot spatially identify individual stellar pops. In particular, the bulge is thought of as hosting older stars than the disk that has undergone more recent star formation.
But we're not talking about a point source here. Although the inner component might be very compact, it usually is wider than the PSF. So, there's morphological information beyond the point source model. We used to deal with this by two co-centric ArrayMorphology
components. It's highly degenerate, but with constraints we got it to work. I wonder if the same single-component prior would allow us to do the same.
Working on this now, there are two options, both can be implemented straightforward enough.
Option 1: user specifies how many components when initializing the sources
Option 2: if the auto-computed box size is larger than box_size.shape[0] > X
then create a second source. (currently implemented)
I like the second method, and currently this is what is implemented.
EDIT: I will look into altering some things for optimization of multi-component sources. Going with the "we handle everything" route, ideally I will make a new morphology class which can work with arbitrary amounts of components. Meaning both initialization and optimization the user need not decide if two components should be used, this is all handled in the backend unless explicitly not wanted, where you can revert to enforcing only one component per source.
closed with #44
In scarlet1, we enabled two-component models to mimic bulge-disk decompositions and allow for the primary inner-outer color variation to be modeled. In light of newer findings about the flaws of proximal optimization, I have the strong suspicion that we unknowingly provided more slack for the optimizer to find paths that are monotonic by bouncing around flux between the two components (a behavior we clearly observed). In any case, we got better models and could control the high level of degeneracy between the two components with the monotonicity constraint.
How can we bring this option to scarlet2? First, there's no problem in adding multiple sources to the scene that are initialized to have the same center. However, our current cheap initialization options (#33) would make them identical Gaussians. And those two sources would not necessarily remain centered at the same location during fitting. So, we have to solve two problems:
Initialization
At the very least, we'd need a size measurement for such a source, so that we can make one morphology image wider than the other. This could be achieved with something like Matt's Gaussian fitting code from 690d4e7. We could then use the layer-cake approach from scarlet one of splitting the same morphology vertically to create an inner and an outer component, for which we then measure the average color over their respective footprints to initialize the spectrum.
Fitting
Even if we create a suitable initialization, the fitting is not constrained to use the same center because
ArrayMorphology
doesn't actually have a center parameter: it's just an image. In scarlet1, the center was maintained because the mono constraint defined a center (in the middle of the source box), and so the components were forced to maintain the same center because they were both constrained that way.With the prior approach, we get some of these benefits by training on centered morphology images, that means the center is implicit. The obvious approach would be to train the prior network on images of the inner and outer morphology separately (or as separate channels in the same score network). But I'm concerned about the training data. For Matt's paper we used a flux-weighted combination of the two morphology images to create a single-component morphology. The reason is that I don't believe the individual components in scarlet 1 were that meaningful. Again, I think they helped the optimizer more than they modeled physically distinct stellar populations in the galaxies. So, yes, we could train on these components separately, but we would reinforce the splitting that we happened to get in scarlet1, however arbitrary that may be.
I would like to make this more physical, e.g. by looking simulations where we can distinguish different stellar pops. This is a research project in its own right: important and useful, but not quick.
In the meantime, I wonder if we can do something cheeky. We could use the single-component prior for both components. Yes, I know, it'll be misspecified for both components. And it will push the two components to be more similar even if we initialize them differently. But this would allow us to find cases, in which the likelihood really wants two different co-centered components, while preferring to give us two degenerate ones if not: Occam's razor. We can decide the combine two degenerate components afterwards with some correlation criterion.