Skip to content

support for new object type skysim5000 and "rough flux"#158

Merged
JoanneBogart merged 7 commits into
mainfrom
u/jrbogart/skysim_support
Jun 30, 2026
Merged

support for new object type skysim5000 and "rough flux"#158
JoanneBogart merged 7 commits into
mainfrom
u/jrbogart/skysim_support

Conversation

@JoanneBogart

Copy link
Copy Markdown
Collaborator

New object type skysim5000 is structurally nearly identical to galaxy except there are no knots. It is generated from a skysim5000 truth catalog rather than cosmodc2 galaxies

Also allow for "rough" fluxes. These may be included in the main sky catalog for any object type where the input truth includes magnitudes, such as skysim5000. The call interface to get_LSST_flux has a new keyword argument rough. If True the routine will

  • return pre-computed "regular" flux if it exists, otherwise
  • return pre-computed "rough" flux is it exists, otherwise
  • compute and return regular flux

@jchiang87 jchiang87 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly ok, but it does seem like you need to provide separate SED factories if the cosmologies for galaxy and skysim5000 can be different.

'''
return _load_lsst_bandpasses()[0]

def load_lsst_bandpasses_version():

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lsst_bandpasses_version seems like a better name.

Comment thread skycatalogs/objects/base_object.py Outdated
if att in self.native_columns:
return self.get_native_attribute(att)

if rough: # rough flux is acceptable

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these "rough" fluxes always available? Or are they only available in the precomputed flux files for special cases? Some comments here (or in the docstring) explaining when they are available would be helpful.

@JoanneBogart JoanneBogart Jun 29, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are only available if precomputed during catalog creation, in which case they're in the main file. (The catalog creation script for main catalogs in the development branch of skyCatalogs_creator has a new --rough-flux option to request them.) They can't be computed by the API on the fly because they depend on access to the magnitudes from the truth catalog. Currently those magnitudes are not saved in skyCatalogs.

--rough-flux is described in the help for the script create_main.py in repo skyCatalogs_creator. When/if there is a catalog including the rough flux columns, I'll make a new doc page similar to this one which will describe the column.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll put something in the docstring

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be useful to explain when they are available in the docstring.

Comment thread skycatalogs/skyCatalogs.py Outdated
th_parameters = self._config.get_tophat_parameters(object_type=g)
cosmology[g] = self._config.get_cosmology(g)
if th_parameters:
# In the unlikely case that object types galaxy and

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can one set different cosmologies in the yaml config for different galaxy types? If so, then I think you need to have separate sed factories.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cosmologies in the configs actually come from the underlying truth catalog. They could conceivably be different, though to date I don't believe they every have been. The new code will keep them separate, just in case.

'''
return _load_lsst_bandpasses()[0]

def load_lsst_bandpasses_version():

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be cleaner to define a BandPasses class like this:

class BandPasses(dict):
    def __init__(self, **kwargs):
         super().__init__(**kwargs)
         self._version = None
    @property
    def version(self):
         return self._version

and use that in load_lsst_bandpasses instead of a plain dict, setting the version in that function and so have it carried around with the band passes dict and not have to do the _load_lsst_bandpasses / load_lsst_bandpasses workaround.

If you don't want to something like this in this PR, that's fine, but this is a much better way of handling the versioning info, IMO.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that using a class to keep the two pieces of information together is neater than the current arrangement, but I'm going to leave it as is for now.

Revamp to keep all factories in a dict, keyed by object type
@JoanneBogart JoanneBogart requested a review from jchiang87 June 29, 2026 22:01
Comment thread skycatalogs/objects/base_object.py Outdated
if att in self.native_columns:
return self.get_native_attribute(att)

if rough: # rough flux is acceptable

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be useful to explain when they are available in the docstring.

@JoanneBogart JoanneBogart merged commit 607e975 into main Jun 30, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants