**** Logging Started : Wed May 17 10:45:21 MEST 2006 > Dette er en prøve > Flere linjer *** stephane (~paltani@isdcsf3.unige.ch) has joined channel #jemxadr *** jerome (~jerome@130.226.216.3) has joined channel #jemxadr Salut Stéphane. Hej niels Jørgen! END > Hello Stéphane and Jérôme END Hello everybody! END *** peter (~pkretsch@isdcsf5.unige.ch) has joined channel #jemxadr Hi Peter! > Hello Peter, do you know if Silvia is around ? END Bonjour a tous! Niels Joergen, j'espere que tu peut continuer en francais :-) > d'accord, ca va marcher FIN Bonne idée! She should be, I might give her a call if you wish. END > yes, please END Not responding to her office phone ... END Shall we start then? > In the meanwhile let us start the items: As I mentioned in the email > I have really done nothing on the science validation report being fully ... But to her mobile, she was just taking coffee, forgetting about the chat :-) END > occupied by j_src_properties. Have you other people done something in that > direction ? END Stéphane, I remember we discussed the SVR issue during my visit at ISDC and we agreed that it would be reasonable to wait for OSA 6 before spending time on a new SVR. END Yes, in my view you should prepare the SVR for OSA 6, which is obviously premature. I've done nothing special, currently I need clear requests before doing anything in this regard. I don't think it is a good idea to spend time on SVR 5.1 while OSA 6 is just around the corner. Waiting for OSA6 seems a good idea. END > Right, then, but we must be careful not to put it too much aside END I also mentioned this last time in Copenhagen END I think Peter has a point here. A list over what to do for SVR would be a help. END This was heavily discussed in Copenhagen last time END *** silvia (~silvia@130.226.216.2) has joined channel #jemxadr > Jérôme, I belive that such a list will by my job and I will do my best to > get it out in due time END Hi everyone ! I'm so sorry, I completely forget about the Chat. END OK. I may re read the minutes too. Hello Silvia! END > Hello Silvia, we have just discarded the SVR for the time being until OSA6 > do you have any news for that ? END N > Then OSA6 preparations, where are we ? > Jérôme, did you deliver j_ima_mosaic ? END Yes. I have told about that at our last monday meeting. END > Alright, I'd better check the minutes that haven't been distributed yet. > BTW we will have the Monday Meeting a little later today. > Carol Anne is working on the gain correction executables and I understand > that the work is going well but there is still at least a couple of weeks > of work before she can deliver. Can you confirm that, Jérôme ? END I guess so, but I don't know better than you about CAO's plans... END BTW, there's one SCREW about REST spectra that is not completely clear. We did not accept it for the moment \. It would have been good to chat with her. END > I guess CAO will be back soon so you might catch her on the phone END Also, are you all clear regarding the outstanding SPRs? Did you put all the SCREWs you need for your future deliveries? END I'm thinking in particular about j_ima_iros END ... for the SPRs. And j_src_properties for the SCREWs END We did that at ISDC for the delivery of j_ima_mosaic. END In general, do not assume you can put a SCREW and get it accepted 5 min later > Thanks for this reminder, I will try to summarize the wishes etc. in a few The CCB is there to make sure a SCREW does not introduce inconsistencies in the system END > SCREWs for j_src_properties and j_ima_iros shortly END This may take a lot of time END > and for jwfindsrc, by the way END Just keep on mind that some of the SPR and SCREW have to include the scripts as affected items. END Btw. what will be the status of jwfindsrc? I mean: a off-line tool? END > I think we agreed that jwfindsrc should be part of the IMA2 level of the Is this the tool to find sources in the mosaics? > jemx_science_analysis script END > Yes, Peter, it is END In that case, I filly support putting it into IMA2. Yes, it sounds reasonable. END Ans what is the 'w' in the name? END Decision was pending. You may have to rerun it many times, tuning the parameters so an off-line tool might actually be better END > Worktool END or Weestergard :-) Seriously, I've been testing this new tool in several mosaicking images. And it works quite fine and it is stable. But of course, before including it at IMA 2 level further testing is needed. END Have you tried many different images? END BTW, when do you think we can have the prototypes at ISDC to start testing? software freeze is in ~6 weeks > Then we must try to hand it out to a larger group of people for testing and and we need to start testins asap END > parameter tuning. END A suggestion vs. inclusion in IMA2. For many students their main interface is the scripts, not indivdual executables. So if we could call it from IMA2 with a switch to avoid redoing mosacis, that might also help. To be discussed further. END I may be wrong, but I have the feeling that there is quite many parameters, but only one or two Individual executables pop up at one point: spe_pick, xspec, ... END are really sensitive. END > Let me try to deliver a version to ISDC and let the outcome of the test > be part of the decision (I must write the SCREW immediately) END OK. Just send me the tar file by e-mail. A real delivery is premature END The difference to spe_pick is that finding sources in images is a step people assume to take place from experience. > Alright, that is easier END While spe_pick then selects spectra for individual sources. But I agree that we should have it for testing etc before we take a final decision. Better offline than not there at all. NJW, have you included already a call to q_identify_srcs in your tool ? If not, we have to keep on mind I just want to avoid that everyone runs ejmx-science_analysis and then immediately jwfindsrc. > No, q_identify_srcs must be called afterwards END that to identify the sources according to the ISDC catalog the users need also to call the q_identify_srcs tool. END If that happens we could as well have it in the scripts. Yes, it will not be to hard to include a call in the scripts to do so. END The tool could be in IMA2, but we need to allow off-line execution as well END That should not be a problem, IMHO. END Make sure it does not crash on an OG when it has already been run once... END > I'll take notes of these remarks - would there be more ? END One more, to decide which parameters will be queried for the users, if any . END Make sure it does not crash if the images are missing but errors of with an esay to understand message :-) > There is a connection between parameters for j_ima_mosaic and jwfindsrc > that I'm not sure how to deal with: The pixel size in the mosaic images A silly question, do we want to use this tool also in the IMA level instead of the j_ima_iros subroutine or not yet ? END > determines the width of the PSF, which must be indicated for jwfindsrc. END It should also be permit, I guess. END > To Silvia: We don't know yet, we have thought of comparing the sources Isn't this something you should read from the data instead having the user enter a parameter which may be wrong also in off-line usage? END > found both ways, but not yet come to it END Regarding findSrc in IMA, that would bypass the IROS; a bit confusing... END For a start, it might actually be interesting to compare the individual results with those found by jwfindsrc (which I would like with a j_*** name, but that's just me). END > In principle I agree, Peter, but I don't know how to do that in a general > way - specially if there is not a strong source present. END The point is that the pixel size varies over the mosaic, right NJ? END > Also that, but for a general tool one does not know the typical shape of > the PSF - some input is required. But that input could be the assumption > that the basic image input is from j_ima_iros (and the a certain parameter But if it depends on the pixel size, as you say, you should be able to read the pixel size from the image data and base your guess on that - with an option for the user to chose something different. END > could override that assumption). END > I think we are saying the same thing, Peter END From the FITS file you only know the pixel size at the center of the image. END > Yes, but for the moment I think that I will only be able to handle images > where the PSF in pixels only changes insignificantly END That is also reasonable, but as to be documented i think. END > "for the moment" = next 4 or 5 months END > Sure END What about j_src_properties? Did you progress? When shall we have a prototype? END > I explained a little about the situation in the chat reminder email. > We are progressing now, I'm knitting together the input and output > functions and Niels will carry over his more or less private extraction > functions. It will take three weeks before a prototype can be expected. END OK. As soon as it runs, send me the tar file, and we'll start testing END * njw I will. END Once you have a test ISDC_ENV let me know and I might try a few things myself. END > Any other inputs for OSA6 ? END Oh, I also want full pulse-pahse-resolved spectroscopy ;-) END > Noted! END Please, send also to me the tar file of the beta version to start with the work on the scripts. END > Agreed! END Now you can breath NJ! END Actually one more question: are there plans to include a smarter GTI handling in OSA6 or what's the status of handling Sco X-1 (and similar, if we ever have it). END If I have understood correctly, it is ISDC's job to skip the GTI level following Peter's suggestion by previoulsy to detach the GTI from the SWG with og_clean. END No,this is not correct. This may be a work-around, but it's not a long term solution END Imean for the SCo-X1 case END > I think that our decision would be not to provide a new algorithm Sco X-1 case will pop-up each time we reprocess the archive END > because it would not be safe. The solution is to increase the countrate limits END > I'll check this at our JEMX meeting in half an hour END You mean a special increase for the Sco-X1 case? END > No, I think we talked about an increase for all observations, but > we will put it on the table in a short while END But this as already be don by Peter less than one month ago, right? END as-> has > ldir > (sorry, wrote in the wrong window) END > Peter ? END This was not for Sco X-1, but for the increased background, if I'm not mistaken END Yes. END No, I only made a new table for the Alert Limits, as far as I remember (brain getting weaker) because the GTI discussion wasn't fully finished. END I am sorry, i do not understand. Some raise for the background took place. Stéphane coudl quickly check what we have, I'm sure :-) END Yes, the Alert Limits, but this was in reactions to many alerts due to the increased background END So it was not for Sco X-1, but for the increasded bkg. No? END Ok, we are saying the same things... END Allo? Are we done? END My last update for JMX1-GOOD-LIM was 2005/10/19 Yes, I am :-) END There are nice WWW pages at ISDC to check these things :-) END So, I still not understand. When I was at ISDC I have be toild that they > I propose to skip the action item list for now and go directly to AOB just got an unpte from you Peter. END > but we should chat again no later than in 14 days END Once again, the update was for JMX?-ALRT-LIM; nothing to do wigth GTIs!!! END OK! END > AOB ??? Yes I have: From my list of open Ground Segment issues: (1) What is the status of handling all On-Request HK where some seemed to be not handled? (2) What is the status of handling Test Mode data? And actually I have not understood today what we will now do about GTIs ... END For (1), it seems the DB is not correct. It must be corrected so that we can turn on the preprocessing of these packets END For the latter: increase the countrate limit as suggested by NJ. END For (2), I need to check the present status > Peter's last remark: I suggest that we re-discuss this now and then let So is omebody working on the DB correction for (1)? For the GTIs, Jem-X is responsible to provide us with good IC files... END > Niels and Søren take up the matter with Stéphane END > Stéphane, do you recall the name of that particular IC file ? END for the GTIs ?? JMXi-GOOD-LIM END A moment: something urgent here - I'll be back END That becomes consistent at last. END > Regarding Stéphane's reply: who will be responsible for correcting the DB ? END Sorry to ask, but what means DB??? END The Instrument Teams... DB=database which contains the packet description END Well, i am not aware about this part.. END This is probably for Soeren (?) END > Any other AOB ??? I think we should have Søren for these chat meetings. END None on my side END > We could have a dedicated chat meeting for these technical issues END Good idea! END Just to mention that in 14 days I'll not be able to attend to the Chat. From 29th of May to 2nd of June I'll be in Madrid in a Workshop of XMM. No INTEGRAL that week at all. END > We will have to supply the informations for the scripts pretty soon then END YYes please. END > Thanks for now - we have a busy period ahead of us. Take care! END How is it going with j_ima_mosaic from your side Silvia? END Weell the new mosaic works fine with the current scripts version. May be we will need to tune some parameters, or no ? END > Have to leave now, bye bye END hej, hej ! END