Open rmjarvis opened 11 months ago
After further discussion with Patricia it seems what we want are the cosmodc2 native quantities
morphology/diskHalfLightRadius
and morphology/spheroidHalfLightRadius
. These are currently not mapped to any other names by GCRCatalogs (though the plan is that they will be) and are not available from existing skyCatalogs. I propose that new skyCatalogs when created should fetch and store these quantities, using the native cosmoDC2 (later diffsky) names, though column names could be changed for the skyCatalogs files. Within skyCatalogs my preference is to not use the names size_bulge_true
, size_disk_true
since these names have had different meanings in the past.
Could this fix wait for diffsky?
Looking at this yet again, size_true
and size_minor_true
are handled entirely differently from the quantities skyCatalogs has been using (size_<cmp>_true
, size_minor_<cmp>_true
) and the latter are not derived from the former. For example size_disk_true
is just another name for morphology/diskMajorAxisArcsec
I don't think this changes what should be done in the future: use the native quantities Patricia suggested. But it probably means the existing calculation is not wrong in the way suggested above.
I just chatted with Patricia Larsen about the half-light radius convention that has been confusing for a while now. We ended up digging into the provenance of the hlr quantities all the way back up the chain. It turns out that the quantities called
size_*_true
are actually the values we want for half-light-radius, and not the major axis, as it says in the GCR schema. So the line in skycatalogs where we computehlr = sqrt(a*b)
is not correct.should become simply
It also means that DC2 sizes were correct, and not too large by a factor of sqrt((1+e)/(1-e)) as we thought.