Subject: Re: Corrected gain fitting tables Dear Carol Anne, and all, Reading this e-mail again, I have the impression that you would like to have the gain history table implemented for OSA 5.1. This seems to us to be incompatible with the dead line that we target, i.e. end of September, for the release, especially since it shall be discussed at the SDAST meeting next week. Below is the list of changes that I think we should try to have implemented for this release. Some may be obsolete, others already implemented but not closed, but, in these cases, it would be good if all the respective maintainers could provide me with an assessment, so that we won't be bothered with these SPRs/SCREWs anymore (I know Carol Anne is working on the full list of outstanding SPRs/SCREWs, but I doubt the other ones should be considered for this release). Flagged as urgent ----------------- SCREW-01701 Option to store PIF values j_src_spectra SPR-03322 Memory leaked in j_ima_shadowgram.c j_ima_shadowgram SPR-03815 All JEM-X science analysis components j_bin_evts_spectra, must use the new STATUS flag values in j_bin_spec_spectra, jemx.h j_bin_evts_lc, j_bin_rate_lc SPR-03893 Lightcurve time bin value calculated j_src_lc wrongly Others that I think should be done ---------------------------------- SCREW-01761 Save parameters from the Scrip-GUI j_scripts SPR-03485 Lack of data can leave invalid entries j_src_spectra in SWG SPR-03835 Typo in keyword copy j_bin_bkg_spectra SPR-03966 j_ima_shadowgram needs to reassign j_ima_shadowgram energy bins correctly for REST events SPR-04252 FPE in j_src_lc j_src_lc SPR-04253 j_scripts does not preselect j_scripts JMX2-SIDX-DBG for j_bkg_spec_sel SPR-04028 JEM-X bkg lightcurves not correct j_src_lc There may also be important SPRs/SCREWs with a raised status. If you can find some, please tell me immediately, so that we accept them immediately. The fix absolutely necessary is the one following SCREW-01761, although it is very minor in terms of amount of work. We need to define properly the type of the parameters. "hl" types are forbidden, but there are none for Jem-X. Queried parameters should normally be learned ("ql"), but I found several non-learned queried parameters. Also, I have the impression that some queried parameters have no reason to be queried. Here is the list of queried parameters for jemx_science_analysis, with their current modes. Parameter Mode --------- ---- ogDOL q jemxNum ql startLevel q endLevel q nChanBins ql chanLow ql chanHigh ql GTI_gtiUser q GTI_TimeFormat q CAT_I_refCat q CAT_I_usrCat q BIN_I_backCorr ql SPE_timeStep q LCR_timeStep q I fail to see the logic. My logic is that as soon as one can find a default value which will be used more than 50% of the times, the parameter should be hidden. In my view, all of them could be hidden (except probably jemxNum, and possibly nChanBins, chanLow, chanHigh). I don't want to impose my logic, but I suggest that you opt for a more consistent scheme. Tell me what you think. Stephane >> Thinking about this problem, it seems that the easiest way to >> implement it is for the delivered tables from DNSC to be put in the >> same directory as the `raw' gain history tables, i.e. >> REP_BASE/scw/RRRR/rev.001/idx, but with a different file name. The >> format of the two sets of gain history tables would be identical, >> so no new template needed there. Then it would be up to the scripts >> to check which filenames are available, and IF there's a delivered >> gain history table use this. If there isn't a delivered gain >> history table, the scripts just use the regular `raw' tables used >> so far. Also if the delivered table is used, the scripts should set >> the gain smoothing model (gainModel) to 0 for linear interpolation. >> > > >> Please tell me what you think of this idea, and how soon we could >> get it implemented. > > > I agree with you that the easiest way to solve this problem is to > implement a new selection of the gain tables in the scripts. The > implementation of such a new selection in j_correction should not > take me too long. And if we are agree about this change, I can try to > implement this new selection in the coming days for the near future > OSA 5.1 release. > > On the other hand, with the current scripts the user can control the > gain history tables to be used and the gain model to be applied. > Then, may be as Soeren suggests is better if the user can control > this by his/her own and therefore we do not need to change our > current scripts selection. > > Best regards, > > Silvia.