SDAST Chat #86: Wednesday 21st January 2004 Participating: Peter Kretschmar, Niels Joergen Westergaard, Carol Anne Oxborrow Stefan Larsson, Sami Maisala Highlights: No AI's closed, a couple still ongoing NJW had nasty bug in j_ima_shadowgram that only showed up under linux Moral of this story: ALWAYS INITIALIZE ALL YOUR VARIABLES Chat topic: see PK's and NJW's emails on Shared Software Shared functions will most likely benefit late V2/V3 software, not V1 Suggested shared functions so far: JEMXgetGTIs; JEMXgoodFraction PKK and NJW to start on draft shared library of functions (see AIs) Everyone else to come with suggested functions (see AIs) Topics for Munich mini-meeting (5 min. presentation + 15 min discussion each): Possible shared software functions (PK,All) Detector sensitivity, weak sources (PK,NJW) Spectral Response (PK,SL) Foreseen ISSW improvements (NJW) SDAST communication (CAO) Status for OSA 3.1: All major SCREWs and SPRs will be closed New defined constant in jemx.h and keyword in -DETE-MOD needed to describe illuminated on axis area of detectors (see AIs) JEM-X configuration tables can be accessed through SDAST forum There will be no more chat topics until after the Munich Workshop Next week's agenda: AI list; topics for the mini-meeting agenda: 1) AI list 2) Featured topic: shared software and its developement (NJW) 3) Subjects to discuss at SDAST mini-meeting at Munich Workshop 4) Progress for OSA 3.1 freeze 5) AOB Action Items: AI040121_1 PK,NJW 27 Feb 2004 Make first draft of jemx.shared1.c library OPEN with headers of suggested shared functions and circulate to the rest of SDAST AI040121_2 ALL 4 Feb 2004 Provide PK and NL with suggestions for OPEN shared functions that could benefit our own software, and presumably, everyone elses AI040121_3 CAO 23 Jan 2004 Write a screw on DETE-MOD to include a keyword OPEN ONAXAREA to describe the actually illuminated area for on axis sources, as modified by dead anodes etc. AI040121_4 CAO 23 Jan 2004 Add an new constant to jemx.h to describe OPEN the ideal on axis illumination of the detector **** Logging Started : Wed Jan 21 12:29:08 MET 2004 Hi Carol Anne *** peter (~pkretsch@crab.unige.ch) has joined channel #jemxadr Hello Carol Anne and Niels Jørgen! * njw Hello peter, thanks for mail END > Hi Peter! END *** larsson (~larsson@tenma.dsri.dk) has joined channel #jemxadr Hi. Hello Stefan > Does anyone know if Sami will be joining us? END N N n > Silvia sends her apologies - apparently politicians are visiting the *** smaisala (~smaisala@gemini.astro.helsinki.fi) has joined channel #jemxadr > lab in connection with the general election. END > Hi Sami! Hello everybody, Sorry I'm late. END Hello Sami! > Okay, you all know the drill: AIs for everyone. First NJW, how's this > onecoming along.? Are the templates accepted? > AI26.12 NJW 13 Jan 2004 IMA level to output significance maps CLOSED 7/01/04 by NJW, but waiting for data templates to be accepted This one was delayed thinking that I should 'just' deliver j_ima_shadowgram but a nasty numerical difference between Linux and Solaris appeared. If you get stuck on that one, you could ask Mark Gaber to explore the issue further. END The solution might interest Sami: In the map of indices there is a reference to a spectral model that does not appear in the table. I'm now checking for that setting it to a value I know is present and then continues. I'm conviced that this solves the problem. ow I can continue delivering j_ima_basic_recon (AI26.12), the templates are in place now. (sorry for all the letters that disappear in the writing but our system is a bit slow right now and it seems that some input is lost; can't blame it all on the computer, though) END > I'll change this one to ONGOING then, and you can let me know when the > s/w's delivered. Amny comments anyone? END N I dont remember if Peter gave a "deadline" for OSA3.1 delivery. What is it? END When this weird numerical difference between linux and solaris is solved I'd like to know the detailed description of the situation when this kind of problem might occur. END > I understood `end of January', but no firm date. END No absolute deadline has been defined, but people will need some days between your deliveries and the release. So try for this Friday or next Monday the latest. END To Sami: I was using an uninitialised variable and the default initialisation is different on Solaris and Linux. The missing number (0) in the table of spectra caused this END Then I will deliver Monday. src_spectra and _lc. END The time between delivery and release is much shorter than for a full release as we do not include documentation and tests are less refined. To NJW: Ok I can see the problem. If you like, I can add that missing number (0) > Any more comments? Regarding NJW's experience: ALWAYS INITIALIZE ALL YOUR VARIABLES says the guru. END to the models END > Guru's are so boringly predictable! END yes, everything will be less predictable without the guru. END To Sami: The question is what spectrum to use in that case ? END To NJW: That is a good question. :) O=is out of detector -> empty. But, I think that bug must be solved first. END > Shall we move on with the AIs? END Well, in that case I'd better set the expected number of counts to zero, * njw right ? END > Any more comments on this one? END N N n > Okay, about NL's AI27.10, I don't think thi s will be done this week, or He is away for the rest of the week END > maybe even next week: he's very busy. So how about 6/2/04. That's > realistic. He say's it'll be a short job, but he is as I say, very busy. END OK > Last AI that need concern us this week is for Stefan: > AI27.18 SL 15 Jan 2004 Run rev. 53 data on GRS1915 (PIDs 65, 66) ONGOING and compare results with NL's results A > So is th still `ongoing' or is it now `ongone'? END Still ongoing. At least until delivery (Monday) END > Delivery of what? END My _spectra/lc software used for the test. END Any more? END N not from here. END > No more on AIs from me, so looks like it's NJW's turn to get the ball > rolling. END > Ladies and gentlemen: SHARED SOFTWARE DEVELOPMENT AND ALGORTITHMS !!!!! > END We have Peter's and my email from this morning. Would you like to add something, Peter ? END > I'd like to say something as a general comment: I'm against creating > shared functions that don't add to the current functionality of the I can add that the way I will use the background > software as it already stands: if it ain't broke, don't go adding new models is now more similar to the way NJ does it. Sorry for interupting CAO. END > bugs. Replacing our own functions with super new shared ones with > 52 arguments in the calling list is just making extra work. Response to CAO: > What I would be intersted in hearing about are joint functions that > actually improve what we do, not just do it differently. END There are several reasons to discuss new shared functions: 1. For various issues like vignetting etc, the software has not settled. By using common functions, which are shared and discussed, one can probably weed out mistakes faster and improve our ability to compare results from different tools. 2. For 'old topics' like data access, the current code often is quite messy and still routinely leads to new SPRs as we discover small oversights that only hurt us under special circumstances. Common functions again allow a faster turnaround once a specific problem has been found. 3. Code like Stefan's (sorry for picking on you) is by now close to un-maintainable in its convoluted structure. From experience with my own code and that in the OMC, a clean-up is the only valid longterm solution. > That was a good summary of the benefits, Peter. What about concrete Instead of having everybody spend a lot of time doing different clean-ups I would rather provide people with common functions for common tasks which then shortens their personal code and makes its structure clearer. > suggestions, NJW? END I agree with CAO that the V1 software probably will not benefit from Evidently, this is rather OSA4 work, but we better start sooner than later. END new, shared function. But Peter is very convincing. The best way of working is having this (new) llibrary ready or at least carefully plannedahead of new dvelopments One concrete proposal is the JEMXgetGTIs. I have a function rather similar to that one - developed together with Peter - that could be brushed up and used. END So how about NJW and I start to throw together one file xxxx.c (or several) with utility functions and good API descriptions and circulate this for review? > That's a good suggestion. AI on Peter and NJW to make and circulate Sounds fine to me too. END > jem.shared1.c END Agree, Peter, and we could urge everybody to think about their code - is there a function that looks rather general or do I miss a general function here? That would be useful input END > What about a due date for the first draft? END > AI on everyone else to provide suggestions for shared functions with > due date in, say, 2 weeks? END OK OK, but I have my hands full before 5th IW; we can have a start at lease END > I'll put PK and NJW's dead line at end of Feb, okay? END OK I'll start discussing matters in a bit more detail earlier with NJW. END > Can anyone think of any shared functions they'd like to have access to > right now? END Actually this would make a good topic for Munich. END It might need a bit of thinking but I will probably send some suggestions to NJW and Peter. END Very good END > So that's one Munich topic. Shall we end this discussion and move > onto the subject of the Munich mini-meeting? END ok Y y y > So suggestions? Shared functions and what else? END JEM-X sensitivity Spectral response Foreseen ISSW improvements END The Crab calibration will happen after the workshop END OK, but maybe Stefan and I can summarize the problems (5 min presentation) END Note that all our presentations _must_ be short if we wan to manage in time. END > I suggestion 5 minutes for presentations and 10-15 mins each for discussion > for each subject. END OK Sound like a nice goal END ok too. ok > could we add SDAST communication as a topic since that seems to have If discussions become extended, they should be continued at the sidelines of the workshop, the mini-meeting just serves as trigger then. END > been of general concern recently? END OK > I agree, Peter. END > Are JEM-X sensitivity and spectral response two topics or one Peter? END > What about weak sources and survey results (in the sense of looking > for weak sources) as a topic? END I hope to cover that in a talk, but we could do a follow-up discussion END Two topics Sensitivity and spectral response are two topics END Sensitivity goes along with the question of weak sources END > That's what made me think of it, actually. So, no other topics? We'll > discuss this again next week. Shall we move on? END Y y Y y > Okay next agenda item: status for OSA 3.1 release. How's it going guys? > END I've just started working on my j_bin_*** tools. Actually I have a request: Could NJW give the best current estimate of what the illuminated area of an on-axis source is in cm2 and this is then included as constant in jemx.h? > Fine with me. If you This would be useful for my non-imaging treatment and would serve as a sort of reference. We could also include the fraction of open cells over all. END I could, but it must be kept in mind that the value changes with the number > 'll both agree on a constant name e.g. J_ONAXIS_ILLUM, and NJW will > send me the value I'll include it in jemx.h 7.19. END of anodes that are active. Perhaps it is better to put it into IMOD-GRP END Or do you propse another scheme? That would also be an option. END > What about having one value for each anode and adding together the values Hm, I just notice that I do not access IMOD-GRP yet, but that will have to be changed anyway. END > for the anodes that are active. e.g. J_ONAXIS_ILLUM_1, J_ONAXIS_ILLUM _2 > etc.? END > Or are you talking about individual anode strips not anode sections? > I was referring to the latter. END I was talking about the total area lost by dead anodes END > If you're talking about individual strips, surely the area for on axis > illumination can be found by summing up the total length of non-dead > anodes in DETE-MOD and scaling this by some value. END Well, in that case we could put the 'ideal' on axis area in jemx.h and an actual one in IMOD-GRP (probably DETE-MOD). END OK, let's do this. END > That sounds sensible: then the illuminated area would be updated each time > the map of dead anodes it. END And my software will be updated to do the following: - try to read it from DETE-MOD - if that fails, take default value from jemx.h - write warning if chatter is set to a high value Whill you write the SCREW on JMXi-DETE-MOD? END > The constant for the ideal illumination can be called J_IDEAL_ILLUM > and the keyword for the actual illumination could be ILLUMREA. I'll write > the screw on DETE-MOD, Peter. END Why not ONAXAREA ? END > That's good too. END > Any more comments on this subject? END N N N > More on OSA status. How are you all coming along? Will all your SPRs and > SCREWs be closed by the end of next week? END I believe that j_ima_shadowgram and j_ima_basic_recon will have cleared all SPR's by the end of the week. For j_ima_src_find and j_ima_cor_intensity there is still something to do END I will answer that on Monday Carol Anne. At least the critical ones. END > Sami how about you? END I'm just working my j_bkg_scal_calc. j_bkg_spat_sel should be ok and I'll deliver that by end of the week. END > That all sounds like we're pretty much on top of things. If there're > no more comments, lets move on to AOB. Has everyone seen the new > JEM-X configuration tables - they've taken me the better part of two > days to assemble, so please make use of them! Apart from one patch > during the Scorpius observation, which doesn't appear in the ESA > configuration document, they're completely up to date. However, there'll > be a deal of activity patch-wise before the next Crab calibration, so > we can expect updates in a couple of weeks. Any more AOB anyone? END N > I suppose our last item of the meeting should be to choose another topic > and another topic person for next week's chat. Any volunteers? Suggested > topics are: mosaicing; weak source detection; spectral extraction; How about: flux extraction for low energy photons, with Stefan leading? > lightcurve extraction; JEMIROS; So it would not always be NJW? END > Good idea Peter!!! END > What say you, Dr Larsson? END > could everyone please give a sign that they're still connected please? END I'm here! > I'm here Sorry, phone call END Im not here. I'm not sure.. > So you won't be our topic person next week Stefan? END Sorry too many things happening around here. END Not even that CA. END > Okay, who wants to kick-start a topic? Here are a few I could manage: > amplifier stability in a space envirionment > glitches for pleasure and profit > hotspots we have(n't) loved > deadtime for live people Perhaps we should postpone the special topic. I think that all of us have our hands full with preparations. END > How true! Let's restart the topics after the Munich workshop? Any > comments? END OK OK OK No, but thanks for all your imaginative topic proposals. END If something specific comes for one of us, (s)he should just trigger matters via the email. END > I was only getting started, Stefan. So next week's chat will be very > short, just to look over the AIs and fix the mini-meeting topics. Looking forward to it mam. END > any more AOB? END N N N > Have a good week everyone, until we chat again. END Bye bye. *** njw has left channel #jemxadr : (njw) Bye *** Signoff: peter (ircII/tkirc) > Bye