
 Weekly Chat meeting#27: Tuesday 25th January 2000
 
Participants: Peter Kretschmar, Allan Hornstrup, Carol Anne Oxborrow, Stefan
	Larsson, Stephane Paltani, Sami Maisala.
	
Subjects Discussed: AI List from SDAST meeting in January 2000.
	DAL3 access functions for grey value and background data structures.
	
Action Items: no new items


**** Logging Started : Tue Jan 25 09:28:25 MET 2000
> Hello all! END
<Peter> Hi everybody, quite a crowd already - even Sami :-) !
> NJW is off sick to day, so we won't wait for him. I invited the hardware people, but
> it's very unlikely any of them will join us END
*** Stephane (~paltani@isdcul1.unige.ch) has joined channel #jemxadr
> Sami, will Juhani be joining us? END
<smaisala> I can ask, but I think he is quite busy END
<Stephane> Good morning everybody, I will follow points 2 and 3 of your discussion END
> If juhani's not joining in, I suggest we get started ASAP END
*** larsson (~larsson@tenma.dsri.dk) has joined channel #jemxadr
<allan> Yes, let's start ... END
> Hi Stephane ! Hi Stefan ! END
<larsson> Hi everyone
> First, has everyone got the AI list? If you can't give me a `CLOSED' on
*** Signoff: larsson ()
> these, then I do expect a due date at the very least END
*** larsson (~larsson@tenma.dsri.dk) has joined channel #jemxadr
<Peter> Yes, I have it before me. END
> 13.1 is closed, so what about a date for 13.2? END
<Peter> I'd like to close this immediately
<Peter> but since NJW is sick let's have it for Jan 31. END
> Okay, Jan 31 it is. For 13.3, I'd like to take responsiblity for getting
> that done with the Hardware people: warning here, it is politically
> very incorrect to call the hardware people `the instrument team'
> apparently we're all part of the instrument team: they do the instrument
<allan> -and we are the team ...
> hardware, WE do the instrument software END
<allan> I think I know who has advised you :-)
<allan> END
> Please remember to use this terminology: I don't expect you to call end users
<allan> CA takes the responsibility END
> he/she or any of that guff, but remember we're the instrument team too! END
> On 13.3, when would OSM like a list of our parameters Peter? END
<Peter> I need a minute to ask people END
> Okay, you find a date for that. What about 13.4? Can we say end of March? 
> I won't be coding JEventEvaluation before then, what with QLA to do as well. END
<Peter> Beginning of March would be fine, I think. END
> Hello? END
> Okay beginning of March for 13.3, end March for 13.4 END
<allan> Sorry to jump back: Why dont we keep the end february for the due date for 13.2, as
<allan> stated in the minutes? END
<Peter> Regarding 13.2 - should work also, but if we have some ideas earlier we might get  them integrated into the next DAL3JEMX release. END
<Peter> 13.4: Isn't end of March kind of late if you want to deliver the executable in March, Carol Anne? END
<Stephane> Hum, Peter, I don't know what 13.2 is, but your statement is certainly optimistic! END
> Let's be realistic PEter. END
<Peter> I am (almost) always optimistic. END
> While event correction executables will be delivered in March, I'm quite sure
> that Event Evaluation will have to wait till after some QLA's been done. END
> According to minutes 13.2 has `next week' as due date, which is already a
<allan> Sorry again, I meant 13.3 END
> week behind, so let's to stick to Jan31. END
<Peter> Regarding event evaluation: I don't mind this being delivered in full form later
<Peter> but we should have either a dummy version in place or at least
<Peter> be sure we can integrate it without changing any other code. END
> Is this how far the other ISSW teams will be at the end of March? END
<Peter> No. But if we wait for everybdoy crawling to the line it will be a loooong wait. END
<Peter> Look, all I'm saying is that we need something which ISDC can start to integrate. 
<Peter> So we don't necessarily need the code but we should be sure 
> Okay, you'll have something that ISDC can start to integrate, so let's get
<Peter> we have the data structures it writes understood so other code
> the AI done by the end of February. END
<Peter> (like mine) can be tested. END
> Okay, so that's the end of Feb for the AI. The next AI without a due date is
<Peter> Thanks! END
> 13.7, which is on you peter. When will you be ready with a description of
> the radiation monitor data? END
<Peter> I thought I closed this one already by a mail some time ago. END
<Peter> Hmm at the moment I can not find the mail, so let's say by
> Okay, officially closed. Next AI without a due date: 13.10 on NJW, AH and
> PK. What about it chaps? END
<allan> We havent really discussed it yet. END
<allan> I'll talk to NJ, when he is back in,
<Peter> Shall we say end of February, so we close it before our next meeting? END
<allan> and we will discuss with Peter via emails (or this channel, another time). 
<allan> Agree to have due end feb. END
> Okay end Feb for that one. END
> WHat about 13.11 on all SDAST to think about grey filter use?END
<Peter> Isn't that rather normal work, part of the design?
<Peter> I mean I have rather clear ideas on how to use it in my code,
<allan> The scope is different,
<Peter> Stefan and Niels Joergen probably too. I can't remember why
<allan> as you may recall, the on-board SW was too agressive in use
<Peter> we made this an action ...
<allan> of the grey filter, since
<allan> it wanted to have the telemetry fixed, by setting the output
<allan> from the buffer fixed.  In my opinion, the SW allowed too much
<allan> into the buffer before activating the grey filter, but
<allan> since we also want to see strong bursts as detailed as possible it is 
<allan>  a tricky cut-off.  Thus, you were invited to give it a thought.
<allan> END
<larsson> Is there a document on this? END
<Peter> OK. Let's also make that end of February END
<allan> OK END
<allan> We will chekc if there is documentation END
> Okay end of Feb for that one. END
<allan> OK, next AI? END
> 13.12 needs a deadline for feedback on test data. END
> I think this AI may be obsolete: complete test data will be freely available
> after the Alenia campaign with all formats, and the most upto date OBSW.
<Peter> I agree
> Time is the limitation here: SB will do what he can by way of testing IF
> there's extra time. So I'll close this one? And close 13.14 for same reasons? END
> 13.13 is closed by my emails today. END
> Any comments?END
<Peter> Agree to both END
<Peter> Very nice job, btw your mails. END
> I will make sure that the Alenia test data is indeed made available, and is
> unpacked as well as I can manage at the moment. END
> 13.15, 13.16 and 13.17 all need due dates END
> On behalf of NJW and myself, I suggest mid Feb for 13.15. END
<Peter> Just what I wanted to say :-) END
> For 13.16, what data are we talking about: if you mean EM/QM test data, then
> this item is already closed by my emails this morning. END
<Peter> Though you should probably view this as a first draft for those things we are sure we need for V1 and V2. END
> `those things'?? Test data? Instrument test data? Simulated data? Output from
> delivered executables? END
<allan> (13.16 is calibration data, as far as I understand the minutes I wrote) END
<Peter> My comment was on 13.15 and I meant the data END
> Then that has same due date as 13.15, since the details will be decided in
<allan> YEs END
> the same meeting as for the 13.15. So that's mid Feb for 13.16 - I'll make
> the AI a little clearer too. END
<Peter> Regarding 13.16 I think we could have some definition early (as CAO proposes) but then this will evolve in the future. END
<Peter> 13.17 probably runs in the same vein END
> I think 13.17 should be somewhat later: a document has to be made. How about
> end of March to be realistic. END
<Peter> Should be OK, I think. END
> For all AI's having to do with updating the ADD, the deadline (AND I MEAN IT
> THIS TIME!!) is end of February. END
<smaisala> Ok ENd
<Peter> OK END
> 13.26 has a natural deadline in April, which leaves 13.27 and 13.28. These
> both pertain to keeping the Southampton group informed of our activities
> and I think this should be done quite soon. If we're finally clear about
<Peter> Isn't 13.27 closed by all the discussions we had? END
> our BKG handling storing and accessing, who will take responsiblity to tell
> Southampton, along with sending the diagrams? END
<smaisala> I think it is our job to do that END
> Okay, Helsinki, can you send all the bumpf to them in Southampton by next
> week? END
> I'll put 31Jan as due date on the last two AIs. Now onto other business....
<smaisala> What is that all ? 
<allan> I have talked to Josef about JEMX drawings, and we have
<allan> everythiong available - I just need to know which format they
<allan> want tihe info in, and to whom it should be delieverd.
<allan> AI due is OK. HAve to leave for another meeting END
> Can Juhani find out that for use, Sami? END
*** allan has left channel #jemxadr : (bye bye)
<smaisala> I think (hope) so END
<Peter> It shouldn't be difficult. Otherwise I'd be able to help END
> So please tell Allan, and then he can send the diagrams ASAP: you should
> also get on to sending them details of our background storage scheme. Both
> AIs I've given Jan 31 as due date. END
<smaisala> Ok if that is all it is not a problem  :-) END
> Good: now onto DAL3 interfaces. What do we want by way of Mode/grey/background
> accessing functions? END
<Peter> Let's do this step by step - first mode & grey END
<Peter> At least Stefan seems to prefer to have the direct access, 
> I'll take a backseat here: as you all know my I/O is very straightforward
> and I don't feel any need for special accesssing APIs. END
<Peter> i.e. effectively just the readout of the time history. 
<Peter> Niels Joergen has not spoken up. So let's say we have the
<Peter> trivial function that just reads in the whole table at once. OK? END
<larsson> OK END
> OK END
<Peter> Background access:
<Peter> Here Stefan also votes for direct access to the spatial model, spectral model and scaling. 
<Peter> I have no problem with this, but it's slightly unfortunate that we do not hear Niels Joergen.
<Peter> Did he mention anything to you at DSRI? END
> No he didn't jEND
> Unfortunately he was ill yesterday and also today. END
> What about the other background people? END
<Peter> OK, so let's settle for the direct access if no one else has a strong opinion. END
> Well, that seems to be the concensus peter - no one can say you didn't try
> to get to the root of people's wishes! END
<smaisala> Yes we agree that. But I think we need a function which generates background model. Example we have that interactive tool which needs that kind of function. END
<Peter> Do you mean you need a function to build the model you give to the analysis software? END
<smaisala> I mean function which calculates 'real' model with spatial, spectral and scaling parameters. END
<Peter> If you mean the function to get the overall background from the data
<Peter> structures we have defined, that would just be the ...calcBackgroundShadowgram
<Peter> function I proposed - wouldn't it? END
<smaisala> Yes exactly END
<Stephane> Do you consider having this in DAL3? It could be possible, but the development must be made by Jem-X END
<Peter> Note: Stephane and me have another meeting at 11:00 END
> I don't think this is part of DAL3: it belongs in ISSW. END
<Peter> So what's the final verdict - should we try to have this function, 
<Stephane> DAL3 is suposed to be partly ISSW...END
<Peter> or rather have access functions to the background data structures 
<Peter> and leave the calculation of the background shadowgram, spectrum
<Peter> or lightcurve to the ISSW (which would mean having local 
> Yes, but DAL is about Data Access: ie. I/O, not about manipulating or
<Peter> functions, no SDAST wide for this). END
> treating the data which is what happens when one calculates the full
> background from the various models and scaling parameters END
<Stephane> I don't mind; put the function where you want! END
> I think we should be careful to keep the distinction between I/O and
> processing. END
<larsson> I agree with CA on this. END
> I KNOW the `hardware team' will agree with me on this! END
<Peter> OK, so Sami and everybody else do this locally. END
<smaisala> I was thinking this function to DAL3JEMX because we need to use this function in ROOT END
> If there's common I/O that needs to be repeated throughout SDAST then of
> course there should be a comon DAL3 function to do the same things over
<Peter> Seems you are outvoted - and in any case you would have probably been assigned the task of writing it. END
> and over. If there's repeated processing to be done, then there should
<Peter> (The comment was to Sami) END
> be an SDAST executable for it. Perhaps our BKG people should write an
> `get shadowgram' executable - isn't this already forseen? END
<Peter> Be careful or we will be back at the start of all oru background discussion! 
<Peter> That was just what we abolished ... actually a good point why we should not have a DAL3buildBackgroundShadowgram instead ... END
> The real question is: is there common repeated I/O that has to be done to
> access background stored quantities that could be a DAL function? END
<Stephane> (not: DAL3; not DAL! END)
<Peter> IMHO absolutely, and there's no harm in this being a little bit smart too. END
<Stephane> hem:(notE:DAL3; not DAL! END)
> Sorry, Stephane, I meant DAL3 END
<Peter> OK, how about I send out a mail with an updated proposal before the end of the week. 
<Peter> And I will also discuss implementation with Stephane. END
> Sounds good Peter. I know you're not the only ones pressed to get to another
> meeting. END
> I think we should all stop here: we've done as much as we can today. But
> there definitely will be another meeting next week, so make sure you all
<Stephane> WHAT ABOUT THE COORDINATES??? END
> reserve time for it. END
> I'll gather some info by email first, and we'll discuss it next week. END
<Stephane> OK END
> I think we all have other places to go now, unfortunately.Sorry if it was a
> waste of time for you Stephane: you'll be hearing from me soon! END
<smaisala> Bye everyone END
<Stephane> Don't worry; it was no waste of time! END
*** smaisala has left channel #jemxadr : (smaisala)
<Peter> See you next week. END
*** Signoff: Peter (Leaving)
<Stephane> Bye! END
>  Have a happy and productive week everyone: END
*** Signoff: Stephane (I Quit)
<larsson> Bye folks. END
*** Signoff: larsson ()
