I agree with Bill. Shift takers should take special care to
communicate all changes from normal operation to the next shift. They
should also inform the weekly run co-ordinator of problems and/or
actions taken.
Cheers,
Douglas
26-415 M.I.T.
Tel: +1 (617) 258-7199
77 Massachusetts Avenue Fax: +1 (617)
258-5440
Cambridge, MA 02139, USA E-mail:
hasell@mit.edu
On Apr 17, 2005, at 9:27 PM, Wilbur Franklin wrote:
> Thanks for the explanation, Aki. It sounds like the data are
> recoverable. This situation raises an important point though. Our
> present schedule of 1 person per shift with a run coordinator relies
> heavily on steady state operation. When changes of this nature are
> made which require specific action on the part of upcoming shift
> takers, it is essential that these changes be communicated clearly to
> the next shift, and especially to the run coordinator (in this case
> me). I'll accept responsibility for not going through the e-log
> thoroughly enough yesterday to recognize what had happened and for
> failing to check in at the end of your shift.
>
> Please do not be shy about calling the run coordinator and bothering
> them with these types of details.
>
> Bill
>
> On Apr 17, 2005, at 9:17 AM, Akihisa Shinozaki wrote:
>
>> Hello there,
>>
>> There is bad news. The test.sh had been running all night until I
>> came here. So the spin bits from run # 15315 to 15334 should not make
>> sense unless one can artificially interprets the states in the data.
>> I think test.sh is overriding the spin bits which ABS had written.
>> Run # 15334 stopped prematurely because of this. test.sh is no longer
>> running from run # 15335. I should have explicitly said to the shift
>> taker but I did not and I am so sorry.... :-(
>>
>> Regards,
>> aki
>>
>> Akihisa Shinozaki wrote:
>>
>>> Hello,
>>>
>>> I will run the Tylan's script from run 15313. I am currently power
>>> cycling the HV crate and the script is running ok.
>>>
>>> Thank you,
>>> aki
>>>
>>>
>>> Taylan Akdogan wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> This is fine until we have the ABS software. As Michael noted;
>>>> for the false asymmetry extraction, we prefer to have -exactly-
>>>> the same operating conditions.
>>>>
>>>> I have two remarks about the script:
>>>>
>>>> 1) Although, you set the target state to 0 while changing the
>>>> bits, this will have no effect in practice. CA (epics
>>>> channel access) library is a highly optimized - good design -,
>>>> and it will most likely deliver the commands in the right order
>>>> but at the same time (same epics update interval) to the
>>>> ABS.STATUS channel. Thus, the change in status will be done
>>>> instantly on all bits for all practical purposes, without
>>>> any status-0 target.
>>>>
>>>> To mimic the ABS operation (I assume this should be the aim),
>>>> put a delay after setting the status bit to 0. Is is something
>>>> like 5 sec? (attached the changed script)
>>>>
>>>> 2) Isn't the ABS transition sequence quasi-random? If so,
>>>> same algorithm is desirable for this script, rather than
>>>> linear change sequence.
>>>>
>>>> Taylan
>>>>
>>>>
>>>>
>>>> On Apr 16, 2005, at 3:57 PM, Akihisa Shinozaki wrote:
>>>>
>>>>> Hello there,
>>>>>
>>>>> I made a simple shell script to flip the spin bits. I have not run
>>>>> the script on one of the dblast machines because I do not want to
>>>>> screw things up. It flips the bits every 10 minutes. Every 10
>>>>> minutes, the script flips from state 1,6> to 2,5> or 2,5> to 3,4>
>>>>> or 4,5> to 1,6>. During the flip, the target status bit (6) is set
>>>>> to 0. I think I need someones approval before I run this thing.
>>>>> What do you think?
>>>>>
>>>>> Thank you so much,
>>>>> aki
>>>>>
>>>>> Taylan Akdogan wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Sat, 16 Apr 2005, Michael Kohl wrote:
>>>>>>
>>>>>>
>>>>>>>> - Had to change the ABS states manually, because ABS software
>>>>>>>> was not running.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Just as a comment,
>>>>>>>
>>>>>>> if we want any confidence on false asymmetries measured with the
>>>>>>> unpolarized system, we need to run the experiment in the same
>>>>>>> way like with the ABS, i.e. with the ABS software (even if the
>>>>>>> ABS software only uses the commands to set the spin bits that
>>>>>>> Taylan invoked manually).
>>>>>>>
>>>>>>> Otherwise, the unpolarized running is only good for the
>>>>>>> luminosity check.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree. I should have been more informative about this in the
>>>>>> shift summary: Because of the SFT problem, Genya didn't want to
>>>>>> turn on ABS RF, so didn't want to run the ABS software. (elog
>>>>>> 34974)
>>>>>>
>>>>>> I'm sure, we can/will use the ABS software for future unpol runs
>>>>>> as was used in the past, once it's fixed.
>>>>>>
>>>>>> Taylan
>>>>>>
>>>>>> --
>>>>>> ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
>>>>>> Taylan Akdogan Massachusetts Institute of Technology
>>>>>> akdogan@mit.edu Department of Physics
>>>>>> Tel: +1 (617) 258-0801 Laboratory for Nuclear Science
>>>>>> Fax: +1 (617) 258-5440 Room 26-559
>>>>>> ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
>>>>>>
>>>>>>
>>>>>>
>>>>>> <test.sh>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST