Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_base
-
Labels:
-
Story Points:3
-
Epic Link:
-
Sprint:Science Pipelines DM-W15-4
-
Team:Data Release Production
Description
We need a way to get back the noise-replaced Exposure as it was when a particular source was measurement, after the measurement has been run, without having to run noise-replacement on all the previous objects again.
There is already code in afw::math::Random to output its state as a string; I think we should probably just save this string in the output catalog. This will require some API changes to allow the NoiseReplacer to modify the schema and set a field in the output records.
Attachments
Issue Links
- blocks
-
DM-1574 add support for "freeze-drying" measurement failures
- Won't Fix
Activity
I have redone the changes, according to this last comment. The changes are in u/pgee/DM-429 in meas_base and pipe_tasks.
You did not reply to my last email about the persistence to the metadata being unnecessary, but please read that and comment on it.
Perry Gee
added a comment - I have redone the changes, according to this last comment. The changes are in u/pgee/ DM-429 in meas_base and pipe_tasks.
You did not reply to my last email about the persistence to the metadata being unnecessary, but please read that and comment on it. You did not reply to my last email about the persistence to the metadata being unnecessary, but please read that and comment on it.
Sorry - I read and essetially agreed with it. The persistence to the metadata is incomplete and unnecessary, but harmless and possibly informative.
Looks great, just two comments:
- We need to make the same sort of changes for forced measurement.
- Please add a description for exposureId to the Doxygen comments for SingleFrameMeasurementTask.run().
No need to send back to me for review - I think we've converged on what's needed (sorry it took so long).
1. Yes.
2. Yes - but I haven't thought much at all whether multiplying by a constant is better or worse than adding a constant.
3. I think in this case, maybe we just use the config multiplicative/additive term by itself.
4. By default, though having a (non-default) option to go back to the current behavior would be good.
5. Yes.