Chat Meeting #118: Wednesday 8th November 2006 Participants: Stephane Paltani, Niels Joergen Westergaard, Jerome Chenevez, Carol Anne Oxborrow Subjects discussed: 1) Stephane: Status for OSA 6.0 delivery - Still waiting for ISGRI responses. Deadline is November 15th, set by IUG. - Very minor redeliveries can be accepted up to November 13th - Still waiting for JEM-X BTIs - NJW/NL still working on j_ima_iros and j_ima_shadowgram: would like to deliver again if possible - j_cor_position 5.1 now used for OSA 6.0 - if new j_ima_iros breaks the pipeline (mosaicking), will go back to older version - Andrii still needs to be sent data for the UM 2) j_cor_position: revert to version 5.1 for OSA 6.0 and shift to version 6.0 only when j_src_properties is ready? Or have both randomised and non-randomised event positions? - ISDC would prefer just to have randomised positions in future when SL's programs are removed. 3) CAO: BTIs for both units. Should be finished by this afternoon. 4) NJW: status of j_src_properties: Nothing to report. 5) JC: Mosaicking news. - Flux units problem needs an SPR written and for j_ima_iros to be changed accordingly - Flux units should be flux per pixel for images - Units for variance and significance in pixellated maps is not so easy to determine - discuss offline. - Errors on Crab results from mosaic_spec huge, possibly because it's an extended source. 6) AI list news: AIs on search engines for webpages to be cancelled: too time- consuming at the present time. AI30_5 AI35_8 - CAO to put BTIs on her webpage instead of SB doing it.AI29_1 - CAO added average detector gain figures to gain archive page.AI35_6 - Evidently someone else will have to take over responsibility for SPAG maintenance AI35_10 7) AOB **** Logging Started : Wed Nov 08 11:01:59 MET 2006 *** stephane (~paltani@isdcsf2.unige.ch) has joined channel #jemxadr Good morning Carol Anne! > Hi Stephane! I'm busy working on those BTI's - I'm taking a good look at *** njw (~njw@130.226.216.2) has joined channel #jemxadr > engineering windows (horrible changes in HV, just for fun!) and switch ons Hello > after long dormant periods (horrible changes in gain, temperature, SPAG and > probably lots of other things too!). You'll get the list this afternoon. END Good morning Niels Jørgen! Carol Anne, thanks for your work! END > Actually, it does me good to go through the revolutions once in a while and > remind myself of their little personalities. END Glad you remain in such a positive mood! END > Hi guys! Shall we get started? No Peter and Silvia today. What's the status > with OSA 6.0 release Stephane? END On the non-Jem-X side, we are still waiting for ISGRI responses. They have *** jerome (~jerome@130.226.216.3) has joined channel #jemxadr a dead-line on Nov 15, after which ISDc has a two-week dead line, i.e. the release _must_ be at the end of November. Regarding jem-X, we have switched back to j_cor_position 5.1, and we are about to redo the full testing we did previously. I do expect the results will be good, but we never know... If everything is OK, I think we are ready for the release, save a few remaining small issues, like BTIs... END (the deadlines are imposed by the IUG) END Hi Stéphane. is this deadline of 15 nov. the date until it is still possible to deliver something to ISDC for OSA 6? END Stéphane, I think we are pretty close with j_ima_iros and j_ima_shadowgram versions that handle the few or no event case. Sould we try to deliver At this point, we would prefer not to have any new delivery (except for the fact that * njw before Nov 15 ? END deliveries and releases are separated things). The real question is whether you can deliver something now to be included in OSA 6. This must be discussed with me on a case-by-case basis. END Ok. I have only small cosmetic things in mind. maybe it can wait then. END (Sorry Niels Jørgen, I didn't see you typed something). For these two cases, we may accept the deliveries. It depens in part when exactly you can deliver these items END Jerome, you mean the SPR regarding the units? END Yes, for example. For j_ima_shadowgram within a day or two. For j_ima_iros I'm not quite sure, Niels is still working on the variance map that looks peculiar when there And also the variance default parameter and other small changes in the log. END are very few events but it is my impression that we should be able to deliver Monday (13. Nov) END I'd say, tentatively, that a delivery for relatively small problems can be accomodated if it is delivered before the 15th of November, but this week would be better! END We'll make an effort then. END OK. Regarding a new delivery of j_ima_iros, I am actually quite concerned about these last minute changes that may have some big effects on j_ima_mosaic... I hope not to have to made another important new delivery at the very last moment! END Yes, that's right! But there's only a single chance for a new delivery; if it breaks something, we go back to the previous version, and won't ask you (in the case of a new problem in j_ima_iros) to update j_ima_mosaic in a hurry END Ok. It sounds preferable indeed. END > Okay, is that everything on OSA 6.0? END Yes, except: Did you pass the information for the UM to Andrii? END No, not yet, but we will do that very soon END > I haven't passed anything to anyone. END Neither did I. END > Okay, just a quick question about j_cor_position. You've gone back to > version 5.1 with non-randomized event positions since randomized event > positions are not needed till j_src_properties arrives - which I though it > would soon when version 6.0 of j_cor_position was delivered. Now, in the > future, should the component output both randomized and non-randomized size- > by-side so that we have the freedom simply to switch from niels' to stefan's > programs (and back again if NL's program breaks the pipeline)? I can do > it either way. For backward compatibility, I think it may be better to have > both forms of the posisitons. END I think we should keep the S/W simple. In my view, it is clear that Stefan's S/W will disappear, if only there's no maintainer anymore. So the non-randomized positions will become useless at one point. To produce 2 additional columns seems a waste of disk space If there is a good reason, we may think of a parameter telling j_cor_psition to randomize or not, and set a keyword in the COR data structure. But you'll have to convince me about the usefulness of non-randomized positions. END > The thing is - we're all assuming that NL's program, when it comes, will be > better than Stefan's. If it's not, then we have to go back to the old programs > and simply find someone to maintain them - but I can see that's a problem > quite a long way off yet. Perhaps we should think about the randomisation > parameter. Okay, any other comments on event positions and j_cor_position? END It is FORBIDDEN to have j_src_properties be worse than j_src_spectra!!! END My POV is that we should wait and see j_src_properties before making any changes to what works today. END > Yes, it really is a problem for the next release, so we've got some time yet > to think about how to handle the hand over between Stefan and Niels. END > Next on the agenda: BTI's. I'm working on them. There's not so many. Mostly > engineering windows with periods where the boys play around with the HV > setting, and the first half day or so where a dormant instrument has just > been switched on and gain and SPAG and heaven-knows-what are changing very > rapidly. You'll have the full list this afternoon Stephane. Any questions? > END It is good for everybody that you make the effort to produce these BTIs. Thank you CAO. END Yes, thanks a lot! END > Like I said - it's good to take a look through the revolutions and be > reminded of their various foibles. Next our perenially favourite topic: > NJW: status of j_src_properties!!! END Same as last time; we have been working on other things like j_ima_iros END > Well, that was quick. Any comments - apart from the fact that it MUST be > better than Stefan's? END There's also CBJ's alternative. We're looking forward to his visit at ISDC next week! In the end, we _will_ something quite good, whether j_src_properties or j_cbj_properties! END ('have' is missing somewhere... END) > That's the spirit Stephane! END > If there's no more comments on source extraction, let's move on to mosaicking > news. Jerome? END I do not know: are you expecting something special? Because I have nothing new to say about mosaicking. Apart maybe the above mentioned SPR about flux units, but it is rather a problem in j_ima_iros. It supposes that 1) the SPR is accepted, and 2) that the fix is made in j_ima_iros. > And you'll try to redeliver this before 13th November? eND One point about the units, shouldn't the units be 'something/pixel' instead of 'something' ? END It is a flux: by surface area like cnts/dm2/s. END We sum the fluxes from the different pixels, so it is a flux per pixel END I do not know. Should not the sum be correct in cnts/dm2/s when you have summed all the pixels? END Yes, that's my point; if you take the flux in a single pixel, you do not have the full flux END Of course. One HAVE to make the sum, taht is clear! END So we agree the units are 'flux/pixel' END Mmmh. I would say it is cnts/dm2/s in each pixel. One gets the source flux by adding every source pixels. END Yes, 'flux/pixel' END!! Do you mean you want to have the unit: cnt/dm2/s/pixel? But that is implicit no? END yes to 1; no to 2 END As I sais, I am not sure. Any suggestion NJ? END Well, I tend to agree with Stéphane here for intensity images but > I think we should continue this discussion offline. I would also agree as Jérôme points out the case for variance and significance is not so clearcut > on the per pixel unit convention for fluxes END * njw because here addition does no work - not in a simple way at least END Is not it because fluxes already include the /area unit? And variance beign intensity² thne you would have /pixels²... END Sorry: beign -> being thne -> then END significance should have no unit; for variance, we need to think a bit But this is really a *very minor* point END Btw. do you have any comments Stéphane or NJW about my email yesterday? I am quite surprised that mosaic_spec is so sensible on the position in the low energy band, but only in JMX1-SKY.-IMA END Crab being slightly extended, it is not a surprise that fixing the position might distort the results; but of course we would need much more extensive testing END Yes, because the error is huge in the present case. END Generic recommendation for ISGRI (but it should work also for Jem-X): - Fix the position of faint sources - Let the position free for bright sources But it's clear that we do not have enough experience with Jem-X to check the effects of this parameter, and also of the widthmode parameter END Ok. Thanks. END > Is that all on mosaicking? end If you mean it was about mosaicking, yes! END > Okay, let's be moving quickly on to the AI list. I've started putting > average detector gain figures on each of the most recently processed > revolutions on the gain archive page, so that AI's closed. I looked inot > adding a search engine for the JEM-X forum, but haven't found any solutions > I've got time to implement other than having huge flashing banner ads on > the page, so I'd like to cancel the search engine AI. Is that allowed - > if it is I'll cancel the search engine AI on Soeren as well. END No problem for me at least! END > Also with respect to Soeren and his unfinished AI's, I suggest that the AI > that he puts a list of BTIs on his webpage be labelled OBE. When I've made > up the list today, I'll add this to my webpage and add notes in the appropriate > places on the gain history page. Is that okay? END (what means OBE?) END > Overtaken by Events (perhaps undertaken in this case!) END You should update the "accro'" with that one CAO :-) END > Also, I see now with regard to SB and his comments on Monday - it seems > like he has no intention to make an update of the SPAG, though he has > presumably all the software needed to do this. The AI on him to see if this > is needed is undoubtedly redundant and obsolete - it's pretty certain we > need a new SPAG by now, the question is who's going to do it. AS SB pointed > out on Monday, it's not difficult - I could easily do it - but it takes > TIME, and that's a commodity of mine that HUNN was hoping to use quite > soon. Perhaps we should talk to NL about this, and I'll just OBE SB's AI. > Any questions or comments? END N No comment is probably better... > Well I'll tidy up the AI list a diplomatically as possible. What aboauat the > rest of you? Any AIs cleared up? END N > Alright, Any Other Business before lunch? Sudden and wonderful clusters of > papers containing masses of high-quality JEM-X data perhaps? END A letter on a new X-ray transient in the KP has just been accepted; Jem-X data are included END Do you have a reference? END > Could you send me the reference _ I'll include it on the forum. END For the moment, "Walter et al., 2006, A&A in press"... END Well, CAO, is not it only if SDATS member are in the author list...? END So no astro-ph either? END It will appear on astro-ph probably tomorrow or Friday END > We'll see if we can make an auxilliary list for papers with JEM-X data. > Okay, any more, or off to lunch? END I would just say: BON APPETIT! END Lunch seems fine! > Bon appetit tout le monde! END