From choc@ta3.sk Fri Jul 6 08:28:22 2007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on auriga.ta3.sk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.2.1 Received: from auriga.ta3.sk (localhost.localdomain [127.0.0.1]) by auriga.ta3.sk (8.13.6/8.13.6) with ESMTP id l668SJ4W026424 for ; Fri, 6 Jul 2007 08:28:19 GMT Received: (from choc@localhost) by auriga.ta3.sk (8.13.6/8.13.6/Submit) id l668SJ6p026423 for choc; Fri, 6 Jul 2007 08:28:19 GMT Received: from mssltz.mssl.ucl.ac.uk (mssltz.mssl.ucl.ac.uk [128.40.71.165]) by auriga.ta3.sk (8.13.6/8.13.6) with ESMTP id l64Hl5UR024540 for ; Wed, 4 Jul 2007 17:47:56 GMT Received: from [128.40.71.151] (msslf8.mssl.ucl.ac.uk [128.40.71.151]) by mssltz.mssl.ucl.ac.uk (8.13.6/8.13.6) with ESMTP id l64Hkse1022442; Wed, 4 Jul 2007 18:46:54 +0100 Message-ID: <468BDD27.1070700@mssl.ucl.ac.uk> Date: Wed, 04 Jul 2007 18:47:19 +0100 From: Khalid Al-Janabi User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "'Jan Rybak'" CC: Len Culhane Subject: Re: EIS propsal - Rybak et al. References: <000301c7b38f$5782e5c0$1203470a@MSSLGX> In-Reply-To: <000301c7b38f$5782e5c0$1203470a@MSSLGX> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MSSL-MailScanner-Information: Please contact the ISP for more information X-MSSL-MailScanner: No virus found X-MSSL-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 5, BAYES_00 -4.90) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) X-Virus-Status: Clean Sender: choc@ta3.sk X-Status: X-Keywords: X-UID: 6 Status: RO Dear Jan, Following are my thoughts about your study which are related to: 1) Operations 2) Structure As far as point 1, I have consulted our chief observers (CO) in Japan, and I got the following reply in response to my question about running 8h 29m study in connection with Hinode SYNOPTIC studies (sun disk pointing), and I quote: David Brooks comment: "Another point is that it lasts 8 hours. Currently there is *no* possibility of running this study without it being interrupted by XRT synoptic repointing to disk centre." From what I can gather from one of your emails to Len (copied to me) is that you are willing to reduce the study run-time, which is a *must* now. Point 2 (study structure) is a little bit more complex: Your proposal/study structure: ------------------------------ 1. Context_calib_jr ( 3 times) - 3x8m31s (25.m in total) 2. Obs_sit_stare_jr (12 times) - 12x28m3s (5.61h in total) slit placed to the X-center of the previous raster 3. Context_calib_jr ( 3 times) - 3x8m31s (25.m in total) My suggestion: -------------- Break down the study into two studies (two .def files): 1) Context_calib study. *One* raster study (RA:000031) 2) Obs_sit_stare study. *One* raster study (RA:000032) These studies can be used by planners as follows: 1) Put Context_calib_jr on the time line 2) put Obs_sit_stare study on the time line and point to X 3) put Obs_sit_stare study on the time line and point to X center of previous raster. .. Perform 3 as many times as time allows 4) Put Context_calib_jr on the time line (end of study context) This gives the flexibility of shortening and lengthening the study run time as time permiting (controlled by the number of Obs_sit_stare study instances). Question: Dose it matter how many Obs_sit_stare study runs per day (say 8 today, 10 tomorrow, 9 the day after .. etc) or you would like to run the same number every day through out the campaign? Before you do any thing yet, I would like you to think about my suggestion and come back to me. Changes (or not) should be performed once they are agreed. Please do not hesitate in asking questions. Regards, Khalid Len Culhane wrote: > Dear Jan, > > I note that a complete study with EIS requires a total of 8h 29m to run. I > may have missed this but can you say specifically how often you wish to run > this study and under what conditions in the period 18-31/08/07 when you > request Hinode support. > > Since there are many campaign requests for operations with Hinode in August, > the July SSC meeting on 17/18 July and the following monthly meeting about > one week later will need to schedule these quite carefully and may not be > able to accommodate all of the requests. So I was asked at the SSC meeting > teleconference yesterday to clarify the nature and detailed timing of your > campaign. > > Also I understand that Khalid has contacted you about the details of your > study. It would be good if you could respond to him soon since we will have > periods in July and August when the simulator will be fully occupied with > the testing of new code for upload to the instrument during August. Khalid > will be in Japan for the upload which will mean that he will also be unable > to do study validation work during a part of August. He will shortly > circulate the schedule for this work. > > It would be good therefore if we could simplify your study and seek a > validated version in time for your campaign. > > Regards > > Len