
  		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

<njw> Hi Carol Anne
*** peter (~pkretsch@crab.unige.ch) has joined channel #jemxadr
<peter> Hello Carol Anne and Niels Jrgen!
* njw Hello peter, thanks for mail END
> Hi Peter! END
*** larsson (~larsson@tenma.dsri.dk) has joined channel #jemxadr
<larsson> Hi.
<njw> Hello Stefan
> Does anyone know if Sami will be joining us? END
<njw> N
<peter> N
<larsson> 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!
<smaisala> Hello everybody, Sorry I'm late. END
<njw> 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


<njw> This one was delayed thinking that I should 'just' deliver 
j_ima_shadowgram
<njw> but a nasty numerical difference between Linux and Solaris appeared.
<peter> If you get stuck on that one, you could ask Mark Gaber to explore the 
issue further.
<peter> END
<njw> The solution might interest Sami: In the map of indices there is a 
reference
<njw> to a spectral model that does not appear in the table. I'm now checking
<njw> for that setting it to a value I know is present and then continues.
<njw> I'm conviced that this solves the problem. ow I can continue delivering
<njw> j_ima_basic_recon (AI26.12), the templates are in place now.
<njw> (sorry for all the letters that disappear in the writing but our system
<njw> is a bit slow right now and it seems that some input is lost; can't blame
<njw> 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
<peter> N
<larsson> I dont remember if Peter gave a "deadline" for OSA3.1 delivery.
<larsson> What is it? END
<smaisala> 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
<peter> No absolute deadline has been defined, but people will need some days 
between your deliveries and the release.
<peter> So try for this Friday or next Monday the latest.
<peter> END
<njw> To Sami: I was using an uninitialised variable and the default 
initialisation
<njw> is different on Solaris and Linux. The missing number (0) in the  table
<njw> of spectra caused this END
<larsson> Then I will deliver Monday. src_spectra and _lc. END
<peter> 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.
<smaisala> To NJW: Ok I can see the problem. If you like, I can add that missing 
number (0)
> Any more comments?
<peter> Regarding NJW's experience: ALWAYS INITIALIZE ALL YOUR VARIABLES says 
the guru. END
<smaisala> to the models END
> Guru's are so boringly predictable! END
<larsson> yes, everything will be less predictable without the guru. END
<njw> To Sami: The question is what spectrum to use in that case ? END
<smaisala> 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
<njw> 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
<peter> N
<njw> N
<larsson> n
> Okay, about NL's AI27.10, I don't think thi s will be done this week, or
<njw> 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
<peter> 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
<larsson> Still ongoing. At least until delivery (Monday) END
> Delivery of what? END
<larsson> My _spectra/lc software used for the test. END
<peter> Any more? END
<njw> N
<larsson> 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
<njw> We have Peter's and my email from this morning. Would you like to add 
something,
<njw> 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
<larsson> 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
<larsson> models is now more similar to the way NJ does it.
<larsson> 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.
<peter> 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
<peter> There are several reasons to discuss new shared functions:
<peter> 1. For various issues like vignetting etc, the software has not settled.
<peter> 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.
<peter> 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. 
<peter> Common functions again allow a faster turnaround once a specific problem 
has been found.
<peter> 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
<peter> 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
<njw> I agree with CAO that the V1 software probably will not benefit from
<peter> Evidently, this is rather OSA4 work, but we better start sooner than 
later. END
<njw> new, shared function. But Peter is very convincing. The best way of
<njw> working is having this (new) llibrary ready or at least carefully 
plannedahead of new dvelopments
<njw> One concrete proposal is the JEMXgetGTIs. I have a function rather
<njw> similar to that one - developed together with Peter - that could be
<njw> brushed up and used. END
<peter> So how about NJW and I start to throw together one file xxxx.c (or 
several) with utility functions and good API descriptions
<peter> and circulate this for review?
> That's a good suggestion. AI on Peter and NJW to make and circulate
<larsson> Sounds fine to me too. END
> jem.shared1.c END
<njw> Agree, Peter, and we could urge everybody to think about their code - is
<njw> there a function that looks rather general or do I miss a general function
<njw> 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
<peter> OK
<njw> 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
<peter> OK
<peter> 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
<peter> Actually this would make a good topic for Munich. END
<larsson> It might need a bit of thinking but I will probably send some
<larsson> suggestions to NJW and Peter. END
<njw> 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
<peter> ok
<njw> Y
<smaisala> y
<larsson> y
> So suggestions? Shared functions and what else? END
<peter> JEM-X sensitivity
<peter> Spectral response
<njw> Foreseen ISSW improvements END
<njw> The Crab calibration will happen after the workshop END
<peter> OK, but maybe Stefan and I can summarize the problems (5 min 
presentation) END
<peter> 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
<peter> OK
<njw> Sound like a nice goal END
<larsson> ok too.
<smaisala> ok
> could we add SDAST communication as a topic since that seems to have
<peter> 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
<peter> 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
<njw> I hope to cover that in a talk, but we could do a follow-up discussion END
<peter> Two topics
<njw> Sensitivity and spectral response are two topics END
<peter> 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
<njw> Y
<smaisala> y
<peter> Y
<larsson> y
> Okay next agenda item: status for OSA 3.1 release. How's it going guys? 
> END
<peter> I've just started working on my j_bin_*** tools.
<peter> Actually I have a request:
<peter> 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
<peter> This would be useful for my non-imaging treatment and would serve as a 
sort of reference.
<peter> We could also include the fraction of open cells over all. END
<njw> 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
<njw> of anodes that are active. Perhaps it is better to put it into IMOD-GRP 
END
<peter> Or do you propse another scheme?
<peter> That would also be an option. END
> What about having one value for each anode and adding together the values
<peter> 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
<njw> 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
<njw> Well, in that case we could put the 'ideal' on axis area in jemx.h and
<njw> an actual one in IMOD-GRP (probably DETE-MOD). END
<peter> 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
<peter> And my software will be updated to do the following:
<peter> - try to read it from DETE-MOD
<peter> - if that fails, take default value from jemx.h
<peter> - write warning if chatter is set to a high value
<peter> 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
<njw> Why not ONAXAREA ? END
> That's good too. END
> Any more comments on this subject? END
<njw> N
<peter> N
<smaisala> 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
<njw> I believe that j_ima_shadowgram and j_ima_basic_recon will have cleared 
all
<njw> SPR's by the end of the week. For j_ima_src_find and j_ima_cor_intensity 
there
<njw> is still something to do END
<larsson> I will answer that on Monday Carol Anne.  At least the critical
<larsson> ones. END
> Sami how about you? END
<smaisala> 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
<peter> 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;
<peter> How about: flux extraction for low energy photons, with Stefan leading?
> lightcurve extraction; JEMIROS; 
<peter> 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
<peter> I'm here!
> I'm here
<njw> Sorry, phone call END
<larsson> Im not here. 
<smaisala> I'm not sure.. 
> So you won't be our topic person next week Stefan? END
<larsson> Sorry too many things happening around here. END
<larsson> 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
<njw> Perhaps we should postpone the special topic. I think that all of us have
<njw> our hands full with preparations. END
> How true! Let's restart the topics after the Munich workshop? Any
> comments? END
<njw> OK
<peter> OK
<smaisala> OK
<larsson> No, but thanks for all your imaginative topic proposals. END
<peter> 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.
<larsson> Looking forward to it mam. END
> any more AOB? END
<njw> N
<larsson> N
<peter> N
> Have a good week everyone, until we chat again. END
<njw> Bye
<smaisala> bye. 
*** njw has left channel #jemxadr : (njw)
<peter> Bye
*** Signoff: peter (ircII/tkirc)
> Bye
