Hi,
I humbly accept the advices. One of the things which I can do for now is
that I make sure I learn something from my mistakes here.
Thank you,
Aki
PS. I saw a large turkey cross a road, today. Does this mean something?
Douglas Hasell wrote:
> 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