a couple of bugs are fixed so that the notebook produces correct output for medium and low gains.

Dear Misha,

The FastCCD dark notebook had a few bugs. I had forgotten to remove the gain bit from the data in two of the cells and therefore, when dark runs with low and medium gains were processed, the output were wrong. I have fixed this issue and also have fixed the last table of the notebook so that the conversion factor from ADU to electrons is correct for low and medium gains.

Thank you for your time. I appreciate it. Best Wishes, Kiana

@setoodeh

Notebook introduces two parameters: fix_temperature and temperature_k, which make it not back compatible with previous version. Once it already happen and corresponding fix is currently in master. I would suggest to use this way.

I would suggest to print information about number of trains/images processed to evaluate offset. This may help in case of empty of corrupted dataset.

Also I would suggest to round temperature to some reasonable number. E.g. max two digits after point.

It would be good to add an information about raw data location, using the same format as in current master: metadata.calibration_constant_version.raw_data_location = file_loc

Notebook stores without output is easy to review. Therefore I would suggest to cleanup output before storing notebook. A report file attached to the discussion can be used instead of output. FASTCCDDARKCalibration.pdf

added 1 commit

• fec1b9d2 - Fixed the issues Misha has kindly suggested.

Compare with previous version

added 1 commit

• b1dd9f32 - Update Characterize_Darks_NewDAQ_FastCCD_NBC_New_Common_Mode.ipynb

Compare with previous version

Dear Misha,

I have fixed all the issues that you had kindly suggested. My xfel_calibrate does not work anymore so I cannot send you the pdf of the output but it should all be fine as I have tested it. Could you please go through it one more time and merge it if you don't have any objections? Thanks a lot.

Best Wishes, Kiana

Hi Kiana,

Looks fine. One small question: why in xcal.CommonModeCorrection value parallel=False is hardcoded?

Hi Misha,

That's probably because that was how Steffen told me I could use the new common mode method. There's no good reason for it to be hard coded.

Best and thank you for your time. Cheers, Kiana

added 1 commit

• 90b24286 - Use parallel for common mode correction

Compare with previous version

merged

mentioned in commit 48c0d9c2