tickets/DM-19272 Add script and task to create skymap in gen3 #288
Conversation
| except ValueError: | ||
| self.log.info(f"Inserting SkyMap {self.config.skyMapName} with hash={skyMapHash}") | ||
| with self.butler.registry.transaction(): | ||
| skyMap.register(self.config.skyMapName, self.butler.registry) |
There was a problem hiding this comment.
It seems I'm not able to create one deepCoadd_skyMap skymap with config1 and then create another deepCoadd_skyMap skymap with config2, even with a different butler collection name. I would get lsst.daf.butler.core.registry.ConflictingDefinitionError: Existing definition for skymap entry with {skymap: deepCoadd_skyMap}.
Is this intentional? Is the idea to change the skyMapName when a different config is used?
There was a problem hiding this comment.
Hmm... it seems changing skyMapName doesn't change the hash; the hash is determined by other config parameters.
Is it not allowed to make two skymaps to two collections using the same configs, for example,
makeGen3Skymap.py REPO collection1 and then makeGen3Skymap.py REPO collection2 ?
There was a problem hiding this comment.
In today's standup @TallJimbo clarified that a duplicate skymap of the same set of configs (determining the hash; skyMapName not included) cannot be ingested no matter the collections. That explains the ConflictingDefinitionError I saw. It seems okay to me for now, when we each have our own sqlite3 registry. I'm not sure how it will be when we share things on one Oracle database, but probably fine for now.
|
Attempted to run this with oracle gave me |
|
The above |
| "but does not save it to the data repository", | ||
| dtype=bool, | ||
| default=True, | ||
| ) |
There was a problem hiding this comment.
I don't think we need this option - if someone just wanted to create a SkyMap from a config, they wouldn't really need to use this task.
| butler : `str` | ||
| Path to a gen3 butler | ||
| collection : `str` | ||
| The name of the collection which the created skymap will be inserted |
There was a problem hiding this comment.
I think it's probably better to accept a Butler instance in run, and actually construct it from a path and collection string in the bin script - I envision the shared logic for constructing a butler from command-line arguments to eventually move to common place, and when it does, that will reduce the need for changes to this task.
| def logSkyMapInfo(self, skyMap): | ||
| """!Log information about a sky map | ||
| @param[in] skyMap sky map (an lsst.skyMap.SkyMap) | ||
| """ |
There was a problem hiding this comment.
Should be a numpydoc docstring, and note that the actual class is lsst.skymap.BaseSkyMap.
Also, given the duplication with the Gen2 makeSkyMapTask, maybe we should move this code into BaseSkyMap, as a method that takes a Log instance?
natelust
force-pushed
the
tickets/DM-19272
branch
from
9ecfd2e
to
56334b1
Compare
natelust
force-pushed
the
tickets/DM-19272
branch
from
56334b1
to
d75386a
Compare
natelust
force-pushed
the
tickets/DM-19272
branch
from
3d2d67b
to
e2ca2c6
Compare
No description provided.