SDAST Chat meeting 119: Wednesday 14th February 2007 Participants: Peter Kretschmar, Niel Joergen Westergaard, Jerome Chenevez, Silvia Martinez-Nunez, Stephane Paltani, Carol Anne Oxborrow Subjects discussed: Updating the ADD: Everyone to get current files from Jerome. New due date to send tex files to Jerome: 1st March 2007 New ADD to be presented and discussed at SDAST meeting Observers Manual: PK finished with editing this. Current version will be circulated again. OMs generally begin reviewed in Madrid, may require more changes SVR: will be discussed at the SDAST meeting OSA 6.1: no schedule as yet. JEM-X can help define the deadlines etc. Should be discussed at the SDAST meeting. Chances of j_src_properties being included hard to determine. j_ima_cross still not sufficiently tested etc. for inclusion. Deadtime calculation: needs to be improved to reflect new understanding of double triggers with grey filter. Division of labour between j_dead_time_calc and later components many also need to be changed This must also be discussed at the SDAST meeting Every programmer should describe how deadtime is handled in their programmes and how they'd like it to be handled. PK to take a look at SL's programmes SDAST meeting: Date is fixed for March 13th and 14th. Meeting will start on morning of 13th and end 15.30 on 14th Already on agenda: ADD, SVR, OSA 6.1, deadtime calculation Other agenda items: Science results ISDC representatives j_src_properties j_ima_cross Change of PI Status of non-FULL data modes (archived and future data) AOB: Silvia will be leaving JEM-X work after her maternity leave and move to Alicante (July 2007) Simona Soldi will join ISDC as a post-doc and work on JEM-X data Next chat meeting: March 7th 2007, 11.00 Danish Central Time **** Logging Started : Wed Feb 14 10:58:38 MET 2007 > Hi NJW! I'm hoping for a full house today. END *** peter (~pkretsch@crab.unige.ch) has joined channel #jemxadr *** jerome (~jerome@130.226.216.3) has joined channel #jemxadr Good morning everyone! Salut Peter! Good morning > Hi Peter! Seems like ages since we all had a get together. That's what comes *** stephane (~paltani@isdcsf2.unige.ch) has joined channel #jemxadr > of deleting SDAST chats from one's PDA task list! END Hello Everybody! END > Hi Stephane! Everyone's here except Silvia. No doubt she'll be here soon. END *** silvia (~silvia@130.226.216.2) has joined channel #jemxadr Buenos dias ! Good morgen !!! END Bonjour Silvia! > Hi Silvia! Thanks for being so prompt everyone. Let's get down to business: > First point: the update of the ADD. How are we doing Jerome? If you send me > my files today I'll update them this afternoon. END To date, I have only got Silvia's contribution... So, yes, I will send you your files CAO. But, there is actually no reason to hurry, for I am presently busy with > Now I'm really under pressure to keep the female side ahead! It'll be done > this afternoon. What about the rest of you? END the writing of a paper which (of course...) takes longer time than expected... END > Okay, so there's no rush......but it still needs doing everyone! END > Any comments on the ADD update anyone? END Maybe a more reasonable deadline would suit you? How about March 1st? END Jerome, how can we check that the .tex files that we've lying around > When should this be done for Stephane? END are younger than your copies? END The sooner the better! END > The best way is to have Jerome send you the files you need to update. END Well, I sent an email to every contributor after I was finish with the previous ADD. > Is March 1st a good deadline Stephane? END I can sent it again if you want NJ. END Yes, thanks, please do that END March 1st will be OK END > So new deadline is March 1st and everyone should make sure they have the > latest files from Jerome before beginning the editing. END > Any more comments? END N 1st March will be Mt deadline to get the tex files Then i will have to edit the document and so on... That means that it will not be ready March 1st but some days later. OK? END > Okay END > Next on the agenda: The Observers Manual. I'm not really involved with this, > so can you give us a summmary of the status NJW? What's needed from > Stephane, Silvia and Peter? END It is really Peter that should report on the status END If you are talking about the Observer's Manual issued by ISOC, then the interaction with the JEM-X team is suuposedly over. We are currently reviewing all docs internally again, which might lead to some requests from my side, but otherwise it is considered finished. I could still mail you the latest PDF again, but by now there should be no major changes anymore. END I do not think we have got the current version from you, have we? END Since the last one I sent around I only made a tiny change (for the Fe line, remember?). But if you wish, no problem for me to circulate it once more. END OK Is OK, "OK, please circulate", or "OK, we are done"? END Both! So who wants to see this again? END > Not me END I do, though I think we are done. END I'd like to have a copy END > Any more comments on the Observers Manual? END N N N N N > next on the agenda: The SVR for OSA 6.0. Where are we on this NJW? END Now we have OSA6 to use for some re-analysis. At the latest SDAST meeting we made some recommandations for updates. I'll follow those up. Unfortunately I haven't done much in this direction but up to our coming Sdast Meeting I'll make efforts to make and ask for contributions from as many as possible. END > Other comments on the SVR? Can this wait till the SDAST meeting? END N. I think the next SDAST meeting is the right place to discuss about it. END I think the same. Stéphane, please correct me if I'm wrong, but I was under the impression that ISDC was not too much in a hurry on SVRs given the relatively small changes for OSA6. END > So that's one agenda item for the meeting. END Yes, indeed (to CAO) END Y, we'd rather have the fforts put on the s/w; but at one point we'd likr to see an update SVR ;-) Not only you, ESA as well ... END > Any more comments on the SVR? END N N A propos, is there any schedule for OSA 6,1? (Sorry to ask)END Not really a schedule, but: we are heading towards an OSA 6.1 release. This is because we may have a better energy calibration for ISGRI (it was realized just before the release that the OSA 6 calibration was defective, and we reverted to that in OSA 5.1). This means that we should think about what we can do for Jem-X on a time scale of a couple of months. END (I type fast, no??) Yeah! Right END I agree - any chance of j_src_properties materializing? END Niels L. has worked a lot on improving j_ima_iros and understands a lot better the workings. This means that we have a better chance of supplying a PIF that is accurate enough for j_src_properites. It is hard to say something about the timescale, though. So yes, there is a chance. On the other hand we are also developing what you might call Carl's method for source property extraction with Stéphane and for that the timescale is probably much shorter. END This seems a bit difficult, because it will have to be thoroughly tested before and we must prove that it is better than j_ima_iros. In addition, it will require big changes to the script, and important effort Do you mean difficult for OSA6.1 ? END if we want the user to be able to choose between j_ima_iros and j_ima_cross_whatever Yes, difficult for 6.1 END Do you indeed think about Carl's method as an alternative to j_ima_iros, or rather to j_src_properties? END A bit difficult to explain in a chat, but let's say an alternative to j_ima_iros AND j_src_* END I see. END > This clearly needs a thorough discussion at the meeting. END Yes, please take a note for the agenda END I agree - let's hope we can compare results. END If there is a need for beta testing, I'm sure ISOC/ESA could provide some hours of humanpower. END > Any more comments on OSA6.1? Do you have a software freeze date for that > release Stephane? END I don't think there's some fully functional code yet, whether j_src_properties or j_ima_cross... No, no freeze yet; I'll let you know as soon as we have better plans. Jem-X will also have its say about the freeze date. So we must make (battle) plans as soon as possible END > Okay, any more comments on OSA 6.1, or the SVR? END N N N > So, next on the agenda: Interesting deadtime problems. A quick summary > is that Soeren has discovered that our deadtime correction isn't quite right > because the instrument does something a little bit odd when the grey filter > is on. It produces extra double triggers and so the deadtime correction is > not right. Also we can't calculate the deadtime correction with grey filtering > as though this was a random process, because it isn't, which events get > thrown away is very carefully controlled by the values in an array, and this > also affects the deadtime. Basically we're waiting for Soeren to find a nice > equation to describe the actiual deadtime caused by the grey filter. When > this is done j_dead_time_calc and the imaging and source extraction components > will have to be updated to incorporate this new equation. Any comments? END N Why "imaging and source extraction components will have to be updated" ? Would not j_dead give the right result automatically for the rest of the pipeline? END > Currently it is split up so that j_dead_time-calc calculates the input, > buffer loss and crude grey filter deadtime using HK data with 8 second > resolution. Originally NJW and Stefan preferred to do their own grey filter > calculation using the grey filter values in the grey filter table which have > time resolution closer to that of individual events. The crude grey filter > calculation was for emergencies only where the grey filter table couldn't > be read - an eventuality that never occurred as far as I know. If we keep > this split then components after j_dead_time_calc have to be updated. If > however, NL/CBJ don't want to do their own grey filter calculation, this could > be incorporated into j_dead_time_calc and calculated once and for all in > that single component. END Thanks Carol Anne! Hey, I'm using j_dead to figure out dead time in j_ima_cross... I'd like to have it calculated correctly, please!!! END Should I put a SCREW on j_dead? END Has someone estimated how much the "wrong" deadtime calculation is affecting to the JEM-X scientific results ? END The worst case happens when the grey filter is high i.e. rejecting many events. In that case the error can be 10% but this does not happen so often. The case > There's already an SPR on this problem, but it doesn't cover a major that triggered the analysis was the Crab observations in revolution 422 where > rearrangement of responsiblity like having j_dead_time_calc use the grey we had limited TM allocation. END > filter table as well as the housekeeping, and do all the deadtime calculation. > Perhaps this should also be discussed at the meeting. END Then, we should recommend to the user to take a look to the grey filter in his/her data and in the case of heavy grey filtering take into account this error. Do you agree ? END > I didn't realise that you're using j-dead_time_calc for your new component. > The grey filter part's really only for emergencies. END If I have to calculate it myself (once more), then I'll be ready for OSA 10.8 END Carol Anne, would you agree to implement the full grey filter correction in j_dead? END > Yes, just as soon as SB can tell us what it should be like. There is currently > a known bug in the grey filter calculation part that could be corrected > very quickly just to get us as far along as possible until SB's magic > formula is worked out. END Yes, of course. END > Any more comments on dead time calculations? END Just a caveat: we had some reasons for the split in the past If I remember correctly, it may be because some deadtime information is available only at the HK time scale while we have grey filter data more freuqently, via the dummy events. So currently j_src_* (and j_bin_*) probably treat other deadtime & grey filter as two separate things. Therefore: (1) One must make sure one has a workinh consistent scheme - i.e. do a solid architectural design. (2) One must check all tools downstream of j_dead_time_calc what they are doing now and how they need to be changed. END > Yes that's absolutely right. Originally j-dead_time did all the calcualtions CAO: here is another item for the SDAST agenda END > that were possible with only HK data, while the other components added the > grey filter part that had a more event-like resolution. NJW and SL wanted > to do their own grey filter calculations each in their own way. Now it > very much depends how the new components want to do things. Perhaps NL > still wants to use a method only appropriate for PIF-based algorithms and > CBJ and Stephane just want a multiplicative correction factor with 8 second > resolution. How this gets split up depends very much on the new components > and when they'll be taking over from the old ones. END > Yes this should be on the SDAST agenda. END > Any more questions? END I don't think the imaging method has an influence on how the dead time needs to be calculated END > That's a matter for discussion with Niels END Just a comment: Each developer that uses the dead time information should make a short presentation of how the correction is implemented in his/hers component at the SDAST meeting EDN > And how they'd LIKE it to be implemented END > Okay, that brings us on to the SDAST meeting itself. Have we definitely > got a date fixed for it NJW? END So who describes j_src_spectra/lc then? I would not dare trusting that they will no longer be required ... END Oh yes, indeed: March 13 and 14, starting in the morning and ending around 15:30 so that the plane around 17:00 can be caught. END Peter, you have been involved in that software before. Would it be too much to ask for your assistance here? END OK, can do. END > So things on the agenda so far: The SVR; OSA 6.1 goals and time schedule; > Deadtime, improved grey filter calculation and adjustment of responsibility; > What else? END Perhaps the ADD will need an extra iteration (?) END I aim to present the new version at the meeting... END In particular with respect to the the description of how to handle the dead time correction END I guess this will first be included when implemented in another new version? END > Yes.....maybe. If we've got a couple of months, I can have a new j_dead_time > read y for OSA 6.1. Will we make a separate ADD for 6.1? END Let 's see then. END Depends of course what's in there... END > So ADD also to be on the meeting agenda. What else? END Science results END Yes indeed - I hoep to see some new :-) END ISD representatives... END Sorry: ISD = ISDC of course END > Yes that's important. Of course NL and CBJ's software will need to be > presented and their battle-readiness discussed. END Stéphane's report on j_ima_cross... END > That too. What about longer term plans, OSA 7.0? END For the rest, all of you, please send us your suggestions for the agenda when you come to think of them END OK > So that's an action on everyone to send NJW their suggestions for agenda > items END > Any more comments on the SDAST meeting before we take a look at the AI list? END n N Anything about the PI change...? END > Yes.....but what? END I think that there should be some discussions at the SDAST meeting - I'm not sure if Søren will take over all Niels' responsibilities - I mean I haven't heard any detailed statement. END Is this a topic for an SDAST meeting, or an internal one at DNSC? END Well, the details are the kind of things I have in mind... END It is first internal for us and then reported to SDAST. END > Yes, I'd like to know who does what in the future. We're also lacking a > function leader as from March31st, so I'm not even sure who my boss is > after that. This needs firming up formally. Perhaps NL should make a > presentation at the meeting. END That 2nd part is definítely an internal issue. END any more to say on this? > Okay any other ideas need airing before we take a look at the AI list? END N Not at that time. END > Would everyone please turn to this page: > http://spacecenter.dk/~oxborrow/sdast/AIList.html > Take a look at your AIs and let me know if they're done, ongoing, OBE or > need a new due date. END AI35_2 needs a new due date: 12/3/2007 AI_200906_3 is no longer needed for this OSA END > What about AI35_3 Stephane - that must have been done long ago. END Not sure what I can do without j_src_properties... END > I'll give it a new due date: May 2007 okay? END OK Is AI 27.7 still actual since it is now agreed to almot only use FULL format? Or does the "almost" justify the AI...? END We have non-FULL data in the archive... END > Perhaps we shouldn't be wasting time on those obsolete formats.....END That's for the PI to decide. END Well, in the long run we should be able to do something with these data. But it's not urgent (neither is the due date). END Actually the rebinning tool for such array that I made in connection with Actually, if it is decided to do nothing about these data, this should come in some formal statement as then the archive(s) must flag the matter very clearly for all future. END the mosaic_spec spectra just the right thing for that job. END (Sorry for the broken English) END > A discussion of the fate and priority of non-FULL formats should probablyy > also be discussed at the SDAST meeeting. END > Okay, we'll just leave that AI as it is for the time being. Now, Any Other Yes, we should. END > Business? END I have one item: Do you all know that Simona Soldi will soon start a post-doc at ISDC, and that she will spend quite a bit of time working on Jem-X? I wanted to have Simona joining us today, so that she can start climbing the learning curve, but I couldn't find her today. Anyway, please make sure you CC her each time you contact me. In the future, you'll have to CC me each time you contact her ;-) END How about lunch now?? END Motion for lunch supported! And I'm very glad that Simona will take up this work, it can only help. > Good news: Simona and lunch! END OK, rapid typer (not burster) Simona is on my mailing lists for this kind of work END One last thing I'll like to share with you My baby is a boy, not doubt at all ! END > When's he due? How long will your maternity leave be? Will you come back to > us? END Good - as you surely know, we boys are easier to handle ;-) ;-) ;-) END He should arrive around 6th of July ! The maternity leave in Sapin is only 16 weeks ! But after the maternity leave Well - well, after 40-odd years END I'll join the Alicante team and then I'll not have more time for JEM-X work. END > Yes they calm down alot after the age of 40, that's for sure.END Good luch to everyone ! And see you soon in DK ! The next SDAST meeting will be definitely my last one ! END luch=lunch ! I'm already eating the letters ! :-) Bye ! END So have a good lunch everyone, especially you Silvia and little Junior :-) * jerome END > Have a good lunch everyone! Congratulations to Silvia! We chat again in Bye bye everybody > 3 weeks! Bye! END Bye *** Signoff: stephane (Connection reset by peer) *** njw has left channel #jemxadr : (njw) Bye! *** Signoff: peter (ircII/tkirc) *** silvia has left channel #jemxadr : (silvia) *** jerome has left channel #jemxadr : (Bye)