
	V2 interfaces review: Thursday 25th January 2001
	
Participants: Peter Kretschmar, Carol Anne Oxborrow, Sami Maisala, Stefan
	Larsson, Niels Joergen Westergaard
	
Agenda: To review V2 executable interfaces, parameters and input as part of
	V2 consolidation process.
1) Current standard practices:
   - Standard for all executables: inSWG outSWG and DOLS to EVERY data structure
        used by the exe in these two groups. Any questions?
   - Standard instrument model group is `instMod' - script ensures you get the
        right one. AQ?
   - Standard file-cleaning parameter is `clobber'
   - Everyone involved with background handling or usage to update parameter
        names to the convention agreed to before Christmas.
2) Grey areas in current standards:
   - Override DOLs for Auxillary data structures?
   - Override DOLs for housekeeping data structures?
   - What are the possible values for evtType and what do they mean? Do the
        possibilities need to be extended for various combinations?
3) Possible new innovations -
   - Instrument model group as input to every executable? (Problem with then
        providing override DOLs for every data structure)
   - Would a timeStop be appropriate as well as timeZero for binning purposes?
4) ADD and *.txt descriptions:
   - Full parameter descriptions including name, purpose and data type
5) AOB


Action Items: 

V2_rev1.1	NJW	30/3/01	Remove cleanIDX parameter from *.par files
OPEN			and use clobber instead

V2_rev1.2	ALL	30/3/01 Use outSWG, override DOLs and inDol, outDOL
OPEN			correctly in CommonPreparePARS

V2_rev1.3	ALL	30/3/01	Use instMod as parameter to find JMXi-IMOD-GRP
OPEN			DOL

V2_rev1.4  SM/SL/PK	30/3/01 Update background executables with consistent
OPEN			parameter names for background data structures. 

V2_rev1.5	CAO	30/3/01 Update list of allowed values of evtType in the
OPEN			common parameter name list

V2_rev1.6	SL	15/2/01	Circulate email of suggestions for new input
OPEN			parameters for binning executables. Everyone else to
			read and comment on emails

V2_rev1.7	SM/PK	30/1/01 Circulate examples of their *.txt and *.tex
OPEN			files with parameter descriptions. Everyone else to
			use the same layouts in their *.txt and *.tex files.

**** Logging Started : Thu Jan 25 14:55:06 MET 2001
> Hi Sami - did you send this `gone for coffee' message? END
<smaisala> Unfortunately not. END
*** peter (~pkretsch@isdcul10.unige.ch) has joined channel #jemxadr
<peter> Hi Carol Anne and Sami! It seems starting at 15:00 works better for 
Sami :-) END
> Hi Peter, how are you? I just got and anonymous `gone for coffee' message END
*** larsson (~larsson@tenma.dsri.dk) has joined channel #jemxadr
<peter> I'm fine. What's that business with the `gone for coffee' message? END
*** njw (~njw@heao1.dsri.dk) has joined channel #jemxadr
<njw> Good afternoon, everyone END
<peter> Seems we have all the developers, shall we wait for anyone else? END
<njw> No, I think not END
<peter> Carol Anne - will you start running through the agenda? END
<peter> It's strangely quiet from Copenhagen ... knocked out by too strong hot chocolate??? :-) END
* njw The sound of silence. Why don't we start. Does everyone have the agenda ? END
<peter> Y
<larsson> I am with you
<njw> Comments to point 1) ?
<peter> Yes, two general ones:
<peter> (1) Whatever you do otherwise you _must_ have the "outSWG" parameter and one override parameter for each direct child of the SWG you are writing to.
> Sorry, I just had to go and cuddle a colleague's little baby END
<peter> This is the only easy way for me to generate those output data structures.
<peter> [Sidenote to CAO: one of the nicest excuses I've ever heard]
<peter> Naturally it assumes you correctly use CommonPreparePARs.
<peter> (2) It is ggod practice to have override parameters for all children of the SWG.
<peter> Currently, no mechanism exists to override settings for children of another group, like, e.g., the IMOD group. END
> Any more comments to point 1? Anyone not clear about how to use
> `inDols' and `outDols' in CommonPreparePARS for the override parameters? END
<njw> I think there is a conceptual difference between clobber and cleanIDX.
<njw> The former will allow a datastructure to be overwritten whereas the latter
> Yes , NJW I think there could be - could you explain cleanIDX ? END
<njw> will erase all members of an index table. This could be a reason for
<njw> keeping 'cleanIDX'. END
<njw> Setting cleanIDX=y means that all members of the IDX in question will be deleted END
> Yes, perhaps this could be useful for others as well. END
<njw> This can be used when rerunning an executable with (presumably) better inputs
<njw> or code updates END
> Peter, what do you think - should we include cleanIDX as a common
> parameter - alongside `clobber' of course - everyone should have 
> a clobber parameter. END
> Stefan and Sami - you're both very quiet, what do you think - is
<peter> Basically I have nothing against it. But I wonder what sense the clobber parameter would still have in this case.
> cleanIDX something that could be used in your ISSW? END
<njw> There could be other products than members of IDX e.g. ENMD
<peter> Wouldn't you either want to keep your previous outputs and thus have cleanIDX=no, clobber=no, or want to start from scratch and thus be willing to clobber your Index as well? END
<njw> Could there be a situation where you want to keep certain data structures
* njw and clobber others ? END
> So cleanIDX is redundant in you opinion, Peter? END
> I think the cleanest functionality will involve either keep all older
<peter> I can't claim to have it thought through completely, but currently yes. END
> data structures or clobbering all of them. END
> Surely it's best if all output can be traced back to a particular
> run of the pipeline software. END
> So what's the decision on this one? Keep cleanIDX and clobber, or move
> over totally to clobber? END
<peter> My vote is to just have clobber. END
> If cleanIDX=no, does clobber kill of the index table anyway? END
<njw> If clobber takes completely over then clobber=y means: get rid of all previous
<njw> members, doesn't it ? END
> That's how I understand it - which means if we keep cleanIDX it will
> be meaningless without changing the whole functioning of clobber. END
<larsson> I like to hear how strongly NJ feels about this.
<larsson> What will be the difference for you in your programs. END
<njw> I'll have to think more about it if I can find a good example END
<peter> Remember: clobber has no "magic" life of it's own, usually, you have to use it actively.
<peter> So at the moment it would just repalce cleanIDX.
<njw> Put an action on me to come with a good example. Otherwise clobber alone will do END
> If NJW can come up with a really good example where he keeps everything
<peter> To limit this discussion: can we agree on using clobber, _except_ if NJ comes up with a good counterexample before next Monday? END
<peter> OK - we all had the same idea ... END
> and just flushes out the old index table, I'll be glad to accomodate
> cleanIDX, but at the moment I don't see what it's really useful for. END
> Good suggestion Peter. END
<larsson> What about a cleanSDAST which cleans up our programs.....END
> Any questions about using instMod - was it NJW who had a parameter for
> each instrument - I don't think that should be necessary at all - Peter
> shouldn't have to set DIFFERENT parameters for the two instruments -
<njw> The reason for having both instMod DOLs has disappeared with the scripts
> they should both function with identical data templates, software and
<njw> suppoying the DOL END
> parameters. If you use instMod, the script should find the right
> version of JMXi-IMOD-GRP. END
<njw> suppoying = supplying END
> Okay, so everyone to use instMod. Any comments? END
<larsson> N
<njw> N
<smaisala> N
<peter> N
> What about updating background parameters to the new consistent names? END
<larsson> Done but not delivered. END
> Good news. END
> Any rebellious guys out there who refuse to update? END
<njw> N
> Okay, on to point 2) Grey areas. Is it possible, necessary etc. to
> provide override DOLs for auxilliary and housekeeping data structures,
> surely they come from/to inSWG/outSWG, but do realistic overrides
> exist? END
> We don't currently have any parameter names for auxilliary and other
> outside-of-jemx data structures: do we need them? END
<peter> One _could_ imagine a different attitude solution, but it is not an obvious thing to do. END
> I find it hard to imagine a situation where more than one auxilliary
> data structure would even be available for a given time/SciWin. END
> Comments from people other than Peter and myself? END
<smaisala> My opinion is that we do not try to override auxliary/housekeeping DOLs. END 
> Thanks Sami - I'm tending more to that opinion the more I think about it. END
<peter> OK, so no overrides for AUX or HK (until we learn better ;-) ). END
<njw> Y
> Is there the slightest possibility that ISDC will want these
> voerrides in the future? END
> Okay then, no AUX, HK, etc. overrides until further notice. END
<peter> That's a question I cannot answer. There is always a possibility > 0 for such a thing. But currently I know of no such ideas. END
> Next: NJW could you please give us a complete rundown of the possible
> values of evtType and what they mean? END
<njw> evtType 0 - FULL, 1 - REST, 2 - SPTI, 3 - TIME, 4 - SPEC, well I have to
<njw> look it up, this is the idea. The reason for bringing it up was a case
<njw> where I had used evtType=2 representing both FULL and REST and then a crash
<njw> came up since it was interpreted as SPTI (or ? ). That's why I use -1 (as
<njw> suggested by Peter) all sensible types in stead of 2; Stefan has used this
<njw> value as well and I just recommended to change that. END
<larsson> Right NJ, my mistake. I'll change it. END
> That sounds fine. I'll and -1 (FULL+REST) to the list - what about
> other combinations, what about RATE? Do we need other event types? END
<njw> To CAO: -1 is not necesssarily FULL+REST, but all sensible. END
* njw I think that RATE also has a number END
> All sensible what? END
<peter> The full list is: FULL = 0, REST = 1, SPTI = 2, TIME = 3, SPEC = 4, RATE = 5
<peter> END
<njw> Whatever evtTypes you can use in your application. END
> So it really doesn't mean anything to put -1 in because it just means
<njw> E.g. in imaging only FULL+REST are sensible END
> `whatever' and an application can presumably assume `whatever' as a
> default without being told. END
<njw> Yes END
<peter> Yes, but since it's driven by parameters, there must be a default value. END
> Okay folks, shall we keep `-1' as our standard `default' input? END
<njw> Y
<peter> Yes, 0 is already taken. END
<larsson> Y. END
> In that case I'll add -1 as the default value, to the parameter list. END
> Okay, speeding on to new suggestions:
> Is it feasible to ask every executable to input JMXi-IMOD-GRP, just 
> in case instrument-driven improvements/changes are made in the future -
> this group is very good value for money, in that you initially take in
> one DOL and in exchange have access to all the instrument model/configuration
> data structures which could be used in more sophisticated functionality
> for the executables in the future. It's just an idea. END
<njw> I have no objection since I use it in most (if not all) of my stuff END
<peter> In my opinion we should only have inputs if we use them. It's not 
like we can never change interfaces later, it's just that it won't be all left 
to our whims. END
<larsson> I agree with Peter (although in this case i do use this one). END
> `whims'???? We don't have `whims' - we have creative suggestions! END
<peter> Sami?
> Okay then, only use JEMXi-IMOD-GRP if you actually use it. END
> Finally, what about stopTime to go along with zeroTime in binning
> executables? END
<njw> Is it correctly interpreted that zeroTime is the start time of the 
lightcurve ? END
<peter> Or any other time binning. END
<larsson> To NJ: Yes. END
> Yes, if timeZeroSet is set, I believe so NJW. END
<njw> The reason for proposing stopTime is the case with small step size. You 
can
<larsson> Actually I have already half-introduced a timeStop in my  code.
<njw> end up with a tremendous table END
<peter> To Stefan: how? END
<larsson> I think it is logical. As I have told (at least Peter) I also have
> It sounds like we need this one. END
<larsson> defined parameters for cyclic folding or time resolved spectra
> These parameters should be on the common list, Stefan. END
<larsson> . But I have changed the definitions a few times so I
<larsson> have been waiting with it a little while to make sure it is a
<larsson> good definition. END
> Stefan could you send me a list of your `new' parameters and their
<larsson> Maybe I should send around an email with a suggestion. END
> usage and I'll put them on the list. END
> The email sounds like a good idea too. END
<larsson> I will first circulate for comments then you will get it CA. END
> Agreed, SL END
<peter> OK END
> Last on the agenda: presentation of parameters in *.txt and *.tex.
> It seems like Sami has a very nice layout in *.txt to me, and Sami
> thinks that Peter's ADD description is pretty good, so how about we
> all take a look at these examples and try to do likewise. END
<peter> OK, so Sami and me circulate examples - right? END
<njw> I'll be happy to adapt to those examples. Yes, Peter, I haven't seen them END
> Thank you, Chaps, that would save me some work. END
> Okay AOB anyone? END
<peter> Not from me. END
> I think we should have baby cuddling at the beginning of very chat
> meeting - but how to implement it? END
<larsson> There is one upstairs here so I'll do fine. END
<peter> Nothing in reach at ISDC :-( END
<larsson> Peter: Maybe an AI for you. END
> So Any Other (non-baby) Business, or are we through? END
<larsson> No, no nothing more.. END
<peter> Seems we are through ... END
> Great stuff - thanks for helping get a lot of things cleared up.
> Chat with you all next Thursday. END
<njw> Alright, good bye and have a good time. PS: I'll probably be in Ferrara
<njw> next thursday, so don't wait for me. END
> I'm sure they've got IRC there too! END
<njw> I'll see. END
<larsson> I will be away next week so you will be chatting without me. END
<larsson> (I will be chatting with students) END
> Poor you! END
*** njw has left channel #jemxadr : (njw)
> Have a good weekend everyone! END
<peter> Thanks, same to you. END
*** Signoff: peter (ircII/tkirc)
