	
	Chat about DATA STRUCTURES: Monday 26th April 1999
	

Participating: Peter Kretschmar, Stephane Paltani, Niels Joergen Westergaard,
	Allan Hornstrup, Soeren Brandt, Carol Anne Oxborrow, Stefan Larsson,
	Sami Maisala, Juhani Huovelin.

Action Items:

AI990426_1	CAO 	ASAP		To get the instrument people to provide
an officially updated telemetry packet description to give to ISDC PreProcessing.
This matter to be raised at the next JEMX Tuesday afternoon meeting with
the IT. At the very least we must know which formats are considered stable now.
OPEN

AI990426_2	ALL	5/5/99		Everyone to circulate emails containing
questions/concerns about instrument description data structures in preparation
for chat meeting Friday 7/5/99.
OPEN.


*** IRC session log started at Mon Apr 26 09:30:22 1999.
#jemxadr> hello everyone
*** sb <~sb@apollo.dsri.dk> joined channel #jemxadr
#jemxadr> Are we all ready to discuss data structures? END
*** Stephane <~paltani@isdcul11.unige.ch> joined channel #jemxadr
<njw:#jemxadr> OK END
#jemxadr> 
*** Error: apollo.dsri.dk: Empty messages cannot be sent
<Peter:#jemxadr> Should we wait briefly for Sami, Juhani and Stefan? END
#jemxadr> Yes, I think everyone should be here, if possible. END
<Stephane:#jemxadr> By the way, good morning everybody! END
#jemxadr> Hello, all you chaps, any chapesses out there? END
<Peter:#jemxadr> Only youuuu ... :-) END
<njw:#jemxadr> Good morning END
*** huovelin <~huovelin@taurus.astro.helsinki.fi> joined channel #JEMXADR
<huovelin:#JEMXADR> Hi there all !
*** larsson <~larsson@tenma.dsri.dk> joined channel #jemxadr
#jemxadr> Thanks for your emails, Peter and Stephane - its good to have some fee
+dback going already END
<Peter:#jemxadr> Your welcome. Seems we're complete. Hi Juhani, is Sami with you
+? END
#jemxadr> If we're all here, how about Stephane getting the ball rolling since h
+e's the master architect of the data structures? END
<Peter:#jemxadr> I guess, he wanted mostly to listen ... END
<Stephane:#jemxadr> Well, what should I do ? END
#jemxadr> I have one very basic question: on the web all the datastructures seem
#jemxadr> to be randomly spread between the different levels: I don't understand
+ this ordering any more. END
<Stephane:#jemxadr> What do you mean by randomly? Do you have any example?
<Stephane:#jemxadr> I find that it's quite natural! END
<huovelin:#JEMXADR> Sami is here ,OK END
#jemxadr> Why aren't all the -RAW files together in the same level END
<Stephane:#jemxadr> All the RAW files ARE on the same level, as far as I can see
+.
<Stephane:#jemxadr> Otherwise, it would be a bug! But I cannot see that END
#jemxadr> Sorry Stephane, that's simply not the way things appear here:
<Peter:#jemxadr> To CAO: If I look up the page, I see them all under Level 1
<njw:#jemxadr> Could we have the definitions of the levels ? END
<Peter:#jemxadr> scientific data structures in the same table even END
#jemxadr> Under Level 1 scientific we have REST-RAW and REST-PRW, but TIME-RAW a
+nd
#jemxadr> SPTI-PRP are listed under Level 1 calibration data structures
<Stephane:#jemxadr> Sorry, but that's not what I have on my poages !! END
<Stephane:#jemxadr> When did you look at my pages last? We had some problems
#jemxadr> SPEC -RAW nand FULL-PRW turn up under Level2 Parameter data structures
+....
<Stephane:#jemxadr> last week; perhaps you got tramsient feature! END
<Stephane:#jemxadr> Again, it's not what I have...END
#jemxadr> etc etc. SPTI-RAW turns up under Instrument characteristics data struc
+tures END
<Stephane:#jemxadr> Do you really talk about http://isdc.unige.ch/doc/tec/add/ad
+d-w/data/list2html.cgi?add-w+JMXi
<Stephane:#jemxadr> ?
<Stephane:#jemxadr> END
<Stephane:#jemxadr> Peter can certainly testify that the pages are correct . END
#jemxadr> I'll look at the page again - if it's only a temporary problem, that's
+ okay. END
<Stephane:#jemxadr> Anyway, I would never put SPTI-RAW  in Instrument characteri
+stics
<Stephane:#jemxadr> So if it remains, we will have to understand why it's the ca
+se. But we certainly
<Stephane:#jemxadr> agree on that point END
#jemxadr> We'll look at the pages again. In the mean time, Soeren has some very 
+basic concerns about the way things are being done END
<sb:#jemxadr> ok
<sb:#jemxadr> why split the raw data as there are? END
<Stephane:#jemxadr> It is imposed by the ISDC architecture, sorry, I did not dec
+ide that ! END
<allan:#jemxadr> (good old comment !! :-) END
<Peter:#jemxadr> But honestly, it's too late to change that now. END
<sb:#jemxadr> We take the raw telemetry packet, unpack, and reassemble the packe
+t to get to the next step END
<Stephane:#jemxadr> That's ok for this, but we cannot add new columns to an exis
+ting table, because
<Stephane:#jemxadr> it is already archived END
<sb:#jemxadr> It seems the restricted imaging
<sb:#jemxadr> format is reasonable, keeping at least some info together
<sb:#jemxadr> why is that speciel? END
<Stephane:#jemxadr> I don't think it's special. All format have been defined wit
+h the same (maybe lack of) philosophy END
<sb:#jemxadr> It is special because the RAWY and RAWZ have already been decoded 
+END
<sb:#jemxadr> The same sould be possible with time in the full format END
<Stephane:#jemxadr> It is decoded because PP CAN decode RAY and RAWZ.
<Stephane:#jemxadr> But it cannot decode OBT, nor PI END
<sb:#jemxadr> It fail to see the logical diffrence between DELTA_POS and DELTA_T
+IME
<sb:#jemxadr> in the raw packets END
<Stephane:#jemxadr> The OBT in the Jem-X packet is not complete. MSB must be fou
+nd elsewhere
<Stephane:#jemxadr> using different packets. This PP cannot do END
<sb:#jemxadr> But at least the local JEMX time can be docoded END
<Stephane:#jemxadr> Yes, it could, but it is useless. So we don't store this tim
+e END
<sb:#jemxadr> ok, but not quite as useless as DELTA_TIME END
<Stephane:#jemxadr> Aother ISDC principle: ALL TELEMETRY FIELDS MUST BE KEPT AS 
+RECEIVED. I do not
<Stephane:#jemxadr> discuss the use of this principle... END
#jemxadr> but we do have tnhe fits-wrapped telemetry saved already end
<Stephane:#jemxadr> Basis idea is that in 50 yr, people will have lost the descr
+iption of the
<Stephane:#jemxadr> telemetry. But they will still be able to read old FITS tabl
+es ( are another format). So.. Again, its a decision taken long time ago on whi
+ch I don't
<Stephane:#jemxadr> have anything to do. END
<Peter:#jemxadr> If I may chime in:
<sb:#jemxadr> Exactly, you cannot use DELTA_TIME without the desription, but an 
+incrementing time makes sense END
#jemxadr> So we're not meant to use most of these data structures because they'r
+e useless until they've been processed by the next level? end
<Stephane:#jemxadr> We cannot build such a time apart from the OBT END
<Peter:#jemxadr> The point is that for Restricted Imaging we _add_ to the TM con
+tent to make things simpler for the S/W further down the stream.
<Peter:#jemxadr> And we can not make a useful add-on for time stamps as part of 
+PreProcessing. END
*** smaisala <~smaisala@taurus.astro.helsinki.fi> joined channel #jemxadr
<Stephane:#jemxadr> If you add the Central OBT in the Jem-X packet, we would be 
+very pleased
<Stephane:#jemxadr> to compute the OBT in PP END
<sb:#jemxadr> we have local JEMX time, although it is packed. END
<Peter:#jemxadr> Lets not get all hung up on this question alone. 
<sb:#jemxadr> ok, I rest my case, your honor! END
<Peter:#jemxadr> Yes, one could calculate local JEM-X time, but our PP people ha
+te to write code for something that may never be used. END
#jemxadr> Okay, so it that the end of that discussion for now? END
<Peter:#jemxadr> Hopefully :-) Is there anything that's absolutely _missing_ fro
+m our data formats is an even more important question. END
<Stephane:#jemxadr> At least counters and grey filter in REST and SPEC modes.
#jemxadr> Yes, I found some grey filter information that was missing for one of 
+the formats. END
<Peter:#jemxadr> For Rest. Imaging - but there I once heard that this would chan
+ge.
<Stephane:#jemxadr> Is the grey filter in REST finally transmitted as stated in 
+the documents?
<Stephane:#jemxadr> If yes I will include it soon END
<Peter:#jemxadr> From Gregorz' email it seems it's in ther after all - is that f
+inal? 
<Peter:#jemxadr> Stephane said all there was to say ... END
<sb:#jemxadr> restricted imaging is
<sb:#jemxadr> not quite final yet.
<sb:#jemxadr> There are a few details about keeping of time phase, and fillers a
+t
<sb:#jemxadr> the end of packets END
<sb:#jemxadr> ...but grey filter info should be ok END
<Peter:#jemxadr> OK, but the central question is: 
<Peter:#jemxadr> oops,. OK. END
#jemxadr> While there is not complete description of restricted imaging grey fil
+ter values, we do need to keep whatever the telemetry gives us - however useles
+s! So these beginning and ending values need to be saved, just for completeness
+. END
<Peter:#jemxadr> Asbolutely, that was never in question. 
<Stephane:#jemxadr> of course, every field present in the telemetry will be kept
+. I just
<Stephane:#jemxadr> need to know what will be present ! END
<Peter:#jemxadr> Stephane just removed that because I told him, this would be tr
+ansmitted differently. END
#jemxadr> About the eamil----- I should stress that IB was not too happy to have
+ it passed around - it is not official, but it is the most
<Peter:#jemxadr> I'm thankful for it. END
#jemxadr> up to date description of the telemetry so far. END
<Stephane:#jemxadr> Am I allowed to use it to modify the templates? END
#jemxadr> Let's say that I think the email provides a clearer picture of how the
+ telemetry will be than the EID-B, which was the last official
#jemxadr> description, but you should be prepared to change things later on.....
#jemxadr> nothing apparently is final till it's burned into an E-PROM - and even
+ then they can always burn more....... END
<Stephane:#jemxadr> Wait, PP is about to be finished! I need to tell them what t
+hey have to write END
<Peter:#jemxadr> Yes, there is a real problem there. 
<allan:#jemxadr> Unfortunally, the instrument teams are not known to have
<allan:#jemxadr> a too clear design well in advance, and we have 
<allan:#jemxadr> to face that reality.  I am sure, it is not
<Peter:#jemxadr> While we can accomodate minor changes, if they redo formats com
+pletely they are responsible for hanging up ISDC's schedule! END
<allan:#jemxadr> only our experiment which has these 
<allan:#jemxadr> problems.
<sb:#jemxadr> when is the magic deadline for putting everything in concrete??? E
+ND
<allan:#jemxadr> END
#jemxadr> I'll make and AI on my self to bug the on-board software people for th
+eir absolute, final, perfect telemetry packages.....but don't hold your breath!
+ END
<allan:#jemxadr> I think you can go ahead coding your PP, but as any other SW
<Stephane:#jemxadr> To my knowledge, only Jem-X still modifies the science telet
+ry END
<Peter:#jemxadr> I know that's reality, but keep telling them that we're now in 
+the "seriously unhappy" stage .... END
<allan:#jemxadr> part of ISDC, you have to realise, that we may have minor chang
+es
<allan:#jemxadr> later END.
#jemxadr> My feeling is that any future changes will be relatively minor. Stepha
+ne, did NL send you his latest countrate packet description? He told me 
#jemxadr> on Friday he was working on it. END
<Stephane:#jemxadr> I did not receive anything directly. ENd
<sb:#jemxadr> No, it went to Pland before being officially released END
<allan:#jemxadr> We have an internal JEMX meeting every TUesday, I'll bring the 
+issue
<allan:#jemxadr> up tomorrow.  
<allan:#jemxadr> END
<allan:#jemxadr> (Especially complaining, that we get the information too late) 
+END
<Stephane:#jemxadr> Ok, thank you! END
<Peter:#jemxadr> It would be also helpful, if we got a clear indication which fo
+rmats they consider as stable. Then our PP people could work on them. END
<Peter:#jemxadr> Clear indication means a 'formal' email by NL, I think. END
#jemxadr> I'll bring up all these points at the meeting tomorrow. END
<Peter:#jemxadr> Another question for tomorrow:
#jemxadr> I think it's not unreasonable to ask for some formal clarification, si
+nce we seem to have been drifting for so long with out a new formal description
+ . END
<Peter:#jemxadr> I see no indications of 'fake' (or grey-filter) events in Spect
+ral/Timing and Timing modes.
<Peter:#jemxadr> (In Ib's email). Is this on purpose, i.e. will there be none, o
+r just an omisson? END
<sb:#jemxadr> spectral time: see word 4 END
<Peter:#jemxadr> Is that the only information? END
<sb:#jemxadr> and also in timing mode, see word 4 END
#jemxadr> To the best of my knowledge both SPTI and TIME modes should have `dumm
+y' events to signal autonomous grey filter changes, but Gregorz seems to have l
+eft these out of his email.....he probably assumes Ib already knows about these
+. END
<Peter:#jemxadr> If yes there's a mjor difference between these modes and FULL. 
+END
<Peter:#jemxadr> OK. Please clarify this. END
#jemxadr> The only real clarification we can provide, is to get a complete, form
+al and official description of the telemetry from the instrument team. I'm on t
+o it. END
<Peter:#jemxadr> But as a partial solution, it would already help us to get a cl
+arfication which modes are considered a stable and an informal description of t
+hose. END
#jemxadr> I'll find that out too.....If they know themselves! END
<Peter:#jemxadr> Use charm, wit and a big club, but squeeze something out of the
+m :-) END
#jemxadr> Next: grey filter history tables.
<Peter:#jemxadr> Do we have some Action Items? END
#jemxadr> Clearly, the -SRW files are useless as grey filter histories, for the 
+reasons listed in my email. I have nothing against using the GNRL-...-STA struc
+tures, cumbersome as it is, so long as DAL3 deals with extracting the values we
+ actually ne
#jemxadr> ed. Any other comments? END
<Stephane:#jemxadr> I agree with all your points! -SRW is used to prepare a usef
+ul table END
#jemxadr> On the other hand, why can't we have our own grey filter history talbe
+,and our own instrument mode history table, as agreed before Christmas? END
<Peter:#jemxadr> And the only reason why we propose GNRL-MODE-STA is that this i
+nformation will be compiled anyway - just saves us time and effort END
<Stephane:#jemxadr> I see no objection. The only point is that apparently DAL3HK
+ can
<Stephane:#jemxadr> already give what you need if grey is stored in GNRL-MODE-ST
+A END
#jemxadr> That's okay then. END
<allan:#jemxadr> Let me add a point:
<allan:#jemxadr> Is there a performance question here ?
<allan:#jemxadr> Would it be easier to access our 'own' file (smaller) than the 
<allan:#jemxadr> general structure - since that is being used by all, it will
#jemxadr> Why are all useful times stored in files called -PRP? Surely, the leve
+l of the data structure alone is enought to indicate that it comes out of Data 
+Prep. END
<allan:#jemxadr> be 'looked' at a lot during SW run. END
<Stephane:#jemxadr> Actually I think that GNRL-MODE-STA will be made at 99% by J
+em-X grey filter changes!
<Stephane:#jemxadr> But you may perhaps want to extract this information, if onl
+y to separate between JemX 1 and 2 END
<allan:#jemxadr> Yes, but 90% of the data will look in the file for changesEND
<allan:#jemxadr> (I meant from IBIS , SPI and OM) END
<Stephane:#jemxadr> Once again, I would perfectly agree to have a JMXi-GREY-STA 
+table. Just decide! END
#jemxadr> It seems like the quickest way to sort through all those instrument an
+d mode changes is to start my splitting them up into separate data structures, 
+so that each instrument only looks where it's sure to find the information it's
+ interested 
#jemxadr> in. If I was having to write the mode/filter location software, I'd ce
+rtianly want this sort of basic filtering done first END
#jemxadr> Also, it seems as though there will be a huge amount of repetition of 
+information if each instrument has it's own column in one jumbo table, because 
+then the unchanged column values for each parameter has to be copied each time 
+just one of 
<Stephane:#jemxadr> I propose that there is JMXi-GREY-STA and JMXi-MODE-STA tabl
+es, and that I steal
#jemxadr> the parameters changes. Is this not the case? END
<Stephane:#jemxadr> Reiner's routine and put it in DAL3JEMX. OK ?
<Stephane:#jemxadr> END
<allan:#jemxadr> OK END
#jemxadr> Thank you that sounds like it will be a lot easier to use. END
<Peter:#jemxadr> Fine with me. EN
<Stephane:#jemxadr> (just one problem: who buiilds these tables? END
<Peter:#jemxadr> Good question. END
#jemxadr> Should these values be extracted by PreProcessing? END
<Stephane:#jemxadr> No. One must have the OBT of the changes and there are other
+ difficulties END
<Stephane:#jemxadr> There must be a small executable in DP that collects the inf
+ormation
<Stephane:#jemxadr> and write the output tables with the OBTS END
#jemxadr> So who's responsible for that? END
<allan:#jemxadr> I have to understand:  This is just an extraction of 
<allan:#jemxadr> the GNRL-MODE-STA, right?`END
<Peter:#jemxadr> Well, in principle - I could do it, but it won't be finished th
+is month. END
<allan:#jemxadr> (i.e. writhing same info in another file?) END
#jemxadr> If the  GNRL file already exists, and ISDC already provides a routine 
+in DAL3 to do the extraction, perhaps we'd just be wasting energy to do it over
+ ourselves: the point is I don't think the huge file covering all the instrumen
+ts is the be
#jemxadr> best way to go in the first place. Is this really how ISDC wants to do
+ things? If the answer is `yes', then we can problably live with using the DAL3
+ routine, and the overall system designers will have to worry about the questio
+n of 
#jemxadr> performance. END
<allan:#jemxadr> The point is taken, and the only logical way to write the new t
+ables 
<allan:#jemxadr> is to do it at the same time as they write the GNRL tables.
<allan:#jemxadr> END
#jemxadr> Yes, I agree, Allan END
<Stephane:#jemxadr> We need the GNRL-MODE-STA anyway. If one just need to extrac
+t something, it can
<Stephane:#jemxadr> easily be done by the program that creates GNRL-MODE-STA. Bu
+t we have
<Stephane:#jemxadr> to make sure that it will do exactly that. Peter, do you kno
+w better ? END
<Peter:#jemxadr> No. AFAIK, Reiner is writing the main program and hopes to get 
+afunction from me extracting the infor from -SRW files. END
<Stephane:#jemxadr> So, the work is still on the shoulders you have offered! END
<Peter:#jemxadr> Well, half-voluntarily ... nobody else with suitable knowledge 
+came to mind ... END
<Peter:#jemxadr> So waht's the final verdict - do write special JMXi- tables or 
+not?
<Peter:#jemxadr> END
#jemxadr> Since Peter seems to frequently get burdened with little extra data-pr
+ep tasks, should we perhaps leave this until we know if there is an efficiency 
+problem using the big table and the DAL3 routine? END
<Stephane:#jemxadr> Anyway it seems that Peter must provide a routine to Reiner,
+ so I don't
<Stephane:#jemxadr> think it makes a big difference END
<Peter:#jemxadr> To CAO: Btw, what about your ISSW? Will formal delivery be on t
+ime? END
#jemxadr> NO!!!!! END
#jemxadr> I had a very short working week last week......holiday, sickness, husb
+and away.....everything that can go wrong in one week! END
<Peter:#jemxadr> Any idea, how long it will still take? END
#jemxadr> Concerning the grey filter, and mode history tables: I think performan
+ce wise separate instrument specific tables are to be preferred, with their own
+ DAL3 routine. But if this means taking person powere away from other more basi
+c concerns
#jemxadr> we can live with the ISDC-proposed solution (jumbo table + DAL3) END
#jemxadr> Delivery date JGainCalculation version 1.0: about 2 weeks from now. EN
+D
<Peter:#jemxadr> Thanks. Back to DS discussion. So for the moment we'll stay wit
+h the big table, but will extract a specific one, if required. Everybody agree?
+ END
#jemxadr> Next subject: in -REST-PRP you are proposing to save some kind of aver
+aged event time for each restricted imaging event. This will mean repeating alm
+ost useless, identical numbers upto 2400 times every 8 seconds while the instru
+ment is in 
#jemxadr> restricted mode. Is this a good idea? Especially considering that the 
+number saved, is at best a compromise/average/guess. END
<Stephane:#jemxadr> You decide! There may be an utility to this time, but maybe 
+not. Maybe somebody
<Stephane:#jemxadr> will want to do timing analysis on sources with variability 
+time scales
<Stephane:#jemxadr> longer than 8s ?? END
<Stephane:#jemxadr> On the other hand, we would indeed appreciate the gain in di
+sk space if no OBT
#jemxadr> Yes, but why not leave the beginning and ending times just as a single
+ mention in the headers instead of pretending it's a real event time? END
<Stephane:#jemxadr> is calculated
<Stephane:#jemxadr> END
<sb:#jemxadr> anyway, a file with timestamps must always contain a statement of 
+accuracy END
<Stephane:#jemxadr> But then the access to the data will be different that with 
+the other modes.
<Stephane:#jemxadr> This column means (probably) less work for me ! END
<Peter:#jemxadr> If I remember correctly, we put this in, so S/W downstream coul
+d treat RI events (almost) like Full Events. END
#jemxadr> I don't think that's necessarily a bad idea, Stephane, if the data are
+ so different from each other, and mean different things. END
<Peter:#jemxadr> Remember that we have this old requirement to treat them equall
+y in analysis (which has been the source of most of our DS problems, to tell th
+e truth). END
#jemxadr> Sorry, my fault, I was forgetting that constraint. ! END
#jemxadr> So we stick with the REST-PRP file as it is. END
<Stephane:#jemxadr> OK. The question that remains is how do we calculate the tim
+e? the same as the
<Stephane:#jemxadr> first event? the average between first and last? END
<sb:#jemxadr> the minot details i spoke of in RI
<sb:#jemxadr> is to ensure a strict phase lock.
<sb:#jemxadr> So a time bin will always start on modulo 1/8 sec END
<sb:#jemxadr> Taht we a light curve can be reconstructed with equal bins
<sb:#jemxadr> also across mode changes END
<sb:#jemxadr> So time should be either start or middle of the bin. We have
<sb:#jemxadr> to check what is the most common FITS standard on this.
<sb:#jemxadr> I forgot right now .... END
#jemxadr> Can I put an AI on someone to find out what the FITS standard is for t
+his sort of problem? END
<Peter:#jemxadr> The OGIP document allows both. END
<Peter:#jemxadr> OGIP/93-003, Stefan pointed this document out to me. END
<larsson:#jemxadr> I guess I can do that. END
<sb:#jemxadr> Ok, it is then a matter of taste. I prefer middle... END
<allan:#jemxadr> So do I :-) END
<Stephane:#jemxadr> So do I END
<Peter:#jemxadr> Sorry, precision: center of bin is preferred. Misread something
+. END
#jemxadr> I prefer middle too. If that counts for anything......I'm only a physi
+cist after all END
<Peter:#jemxadr> Since everybody seems to like this ... lets agree on that! END
<sb:#jemxadr> While we are at it: the spectral format will also be phase locked 
+in time END
#jemxadr> So it's official: Resttricted image events will be saved by the time o
+f the middle of their time bin. Is that correct? END
<sb:#jemxadr> But this does not really matter for the current disc. on formats E
+ND
<Stephane:#jemxadr> Does it mean that the OBT will also be "centerized" ? END
#jemxadr> No, but it's nice to get a decision out of the way! END
#jemxadr> Sorry, Stephane, that should be a `yes' to your question if I've under
+stood the argument fully END
<Stephane:#jemxadr> Well, I meant the OBT for SPEC; I was not very clear! END
#jemxadr> For consistency it would appear that spectra should also be saved by t
+he mid-time of the integration period. Am I right guys? END
<sb:#jemxadr> yes END
<Peter:#jemxadr> OK, seems we all agree on this one as well. END
#jemxadr> So we'll make that official: spectra from spectral mode measurements a
+re saved by the midpoint of their integration period time. END
<sb:#jemxadr> TIMEDEL keyword will the indicate the time bin size END
#jemxadr> Presumably this may have some implication fo r DataPreparation, since 
+those prepared spectra should then also be saved by the midpoint time of the me
+asurements from which they are binned. Is this correct Peter? END
<Peter:#jemxadr> Yes, seems so - but that is no major headache. I'll take a note
+. END
#jemxadr> I just logged into the data structures work page, and got a list that 
+is
#jemxadr> completely different from the one I got last week - so it appears that
+ everything is working properly now, and the structures are all under the level
+s one would expect. END
#jemxadr> Also, Peter, when will your first delivery be? END
<Peter:#jemxadr> Ahem. If I throw OMC to the winds, _maybe_ this week. END
#jemxadr> One last point from this end: Soeren and I will be looking into the op
+timal binning for the Pulse Invariant data to see if a
#jemxadr> finer binning than 64 channels could benefit the data. Don't get alarm
+ed.....we'll warn you if it looks like the PI data will be in more than 64 chan
+nels. END
#jemxadr> Any other questions? What about the rest of SDAST - you guys have been
#jemxadr> suspiciously quiet - not plotting a revolution I hope. END
<larsson:#jemxadr> I have been looking in the OGPI doc on timing data.
#jemxadr> Allan, NJW, any comments? END
<larsson:#jemxadr> I note that OBT is given as Start time and end time plus inte
+gration time.
<allan:#jemxadr> No further comments, I am confident that those looking at the O
+GIP
<sb:#jemxadr> Any comments from ISDC on how you would react if we want 128 bins 
+in PI?
<allan:#jemxadr> makes the best decision END
<larsson:#jemxadr> I think I would like to check this a little more before we fi
+nalize these things. END
<Stephane:#jemxadr> No problem at all for 128 bins. You can go to 2^31! END
<allan:#jemxadr> About binning the PI - I guess 128 is better than 64, but I hav
+e no
<allan:#jemxadr> strong feelings until we see the data.  it seems not a problem,
+ so... END
#jemxadr> If there are no more comments..........END
<njw:#jemxadr> Not really - seems that more investigations must be done END
<larsson:#jemxadr> I sent a mail just when we started. Mainly pointing out a few
+ things needed (by myself). END
#jemxadr> Then it just remains to wish you all a good week. There will not be an
+y chat this coming Friday since it is Great Praying Day here, and we'll all be 
+on the beach, praying for sunshine. END
<Stephane:#jemxadr> Don't get a cold! END
<Peter:#jemxadr> CAO: Do you have a summary of what we finally decided? END
#jemxadr> Only this transcript, but I'll send a short summary round by email onc
+e I've put everything on the net as usual END
<allan:#jemxadr> Fine END
<Peter:#jemxadr> Great. END
<njw:#jemxadr> To Stefan: yes, I've seen your email and you're right we need som
+e
<njw:#jemxadr> structures for the instrumentdesciption. I don't know when we can
<njw:#jemxadr> determine the structures END
<Peter:#jemxadr> Should be soon, if I look at the ObsSim Schedule ... END
#jemxadr> We'll put a discussion of these instrument structures on the agenda fo
+r the next chat: Friday 7th May. END
<njw:#jemxadr> It'll be soon then. I have most of the information but still need
+ to
<njw:#jemxadr> streamline it. END
#jemxadr> Or shall we continue with the instrument description files here and no
+w? END
<Peter:#jemxadr> No, let's do that next time. Would need to long to type in deta
+ils. END
#jemxadr> Okay, so see you all again, Friday 7th May for a chat to include Instr
+ument description files END
<larsson:#jemxadr> It is better to start with emails. END
<Stephane:#jemxadr> Yes indeed! END
<smaisala:#jemxadr> Sounds good to me END
<njw:#jemxadr> I'll send round a description of what I have now (or before May 7
+) END
#jemxadr> That's an AI on all of us to circulate emails related to instrument de
+scription files. Deadline Wednesday 5th May. END
<larsson:#jemxadr> Bye, bye. (I guess?) END
#jemxadr> I declare this chat meeting closed: have a good week everyone - the su
+n's shining here! END
*** Signoff: larsson ()
<Stephane:#jemxadr> Good bye (you lucky!)
#jemxadr> Hope it's shining where you all are. END
<Stephane:#jemxadr> nOT US!!!
<smaisala:#jemxadr> Here too!! Bye Bye :) END
<Peter:#jemxadr> Good bye, no - around here it's grey. END
<Stephane:#jemxadr> bye bye ! END
<njw:#jemxadr> bye
*** Signoff: njw ()
*** Signoff: smaisala ()
*** Signoff: allan ()
#jemxadr> Good bye all! END
*** Signoff: Stephane (I Quit)
*** Error: Closing Link: oxborrow[~oxborrow@tenma.dsri.dk] () 
*** IRC session log ended at Mon Apr 26 11:54:19 1999.
