Re: magnet field unit conversion

[Shen, G. <sh...@bn...>]

Hi Greg,
In my mind, the first step is to make the unit conversion work.
Whether it should be inside V3 IOC is a design strategy. There are lots of issues to do
it inside an IOC, such as connectivity to RDB to get latest parameters and fitting algorithm.
Also as you already mentioned, there are lots of work to do at current stage in the V4 when
embedding the conversion inside an IOC.

It sounds reasonable to me that we make it a standalone V4 server, and add other functions
like magnet coordination step by step.

Thanks a lot, and I believe I get lots of information from your use case.

Guobao

On 3/28/12 9:28 AM, White, Greg wrote:
> [Adding epics-pvdata-devel and possibly interested PSI people]
>
> Hi Guobao,
>
> Let me first put aside the question of whether there is a standalone "service" for unit conversion.
> In my thinking, as I've said before, is I don't think one would do that. Rather one would
> either
> 	1. put unit conversion right in the (V3) IOC that handles magnet control -
>             but with an important addition I'll get to, or
>          2. implement a "magnet service" whose job would be both coordinated gets
>             and sets of magnets *plus* unit conversion.
>
> In both cases, I would not implement the unit conversion as a service in the RPC sense (is
> this what you meant?). That is, for me the API would NOT be:
>
>     field = eget("QUAD46_I.VAL","convert=i_to_f");       Convert current (amps) to field
>
> But rather, all 3 of ways of looking at a quad say, would just be direct PVs of the magnet.
> For example my desired API would be simply that a quad, say called QUAD46, would have
> all of the following PVs (in B field rather rather than Tesla because that's what I'm used to, and
> forgive me if there are mistakes here, this is off the top of my head):
>
>     QUAD46_BDES   = setpoint B field value that a user [KG.m for dipole, KG for quad]
>     QUAD46_BACT   = B from polynomial conversion of IACT [KG.m for dipole, KG for quad]
>     QUAD46_IDES   = Desired Current (I) by polynomial conversion from BDES [Amp]
>     QUAD46_IACT   = readback current [Amp]
>     QUAD46_KDES   = BDES / ( Cb * E * L_eff)  [bend angle in radians per unit length, 1/m]
>     QUAD46_KACT   = BACT / ( Cb * E * L_eff)
>
>     QUAD46_KMOD   = K from model   (you'd also give users K directly from the model)
>
> Where:
>     Cb = "magnetic rigidity" constant, 33.356etc KG-m/GeV
>     L_eff = Effective length from the model [m].
>     E = Energy [GeV]
>
> Accepting an API like this, then the important question is where should "E" come from, since
> E is dependent on active, working klystrons and is therefore variable:
>
> A simple but maybe insufficient answer would be, it will be computed by an application
> when operators choose to do so, either for the ring as a whole in your NSLS case, or
> for each magnet in a linac.
> A much better answer is it be continuously estimated at every magnet
> by an "Energy service", whose job is to continuously monitor klystrons
> and continuously estimate E at each magnet. This would be the most sophisticated answer,
> but is real work. It would though go most of the way to a LEM service.
>
> Whether an app or a continuously running service, another function might be to set all
> BDeses directly from the model, by conversion of K from the model, to Bdes.
>
>
> Putting this in the V3 Control IOC
> ----------------------------------
> Personally I'd put the work of supplying the 6 control/readback PVs above (all except
> KMOD) right in the controlling IOC, which is likely to be V3. So you ask, how would it
> get E for calculating K, and how would it get the polynomial - especially if that polynomial
> changes for hysteresis. Answer - from EPICS V4 records. So, another main question:
>
> How do I get simple (float val and array) V4 PV Data into a V3 record processing chain? Is
> this possible?
>
> The answer to this question drives the architecture for me.
>
> Cheers
> Greg
>
> On 27 Mar 2012, at 14:50, Shen, Guobao wrote:
>
>> Hi Greg,
>> Here our physicists are pushing a unit conversion server to convert between magnet current (ampere), field (Tesla),
>> and model (K), which will eventually become our next V4 server based on RPC.
>> Since it is under design phase, I think it is a chance to gather your input before I start any coding.
>> What kind of API are you using at AIDA for unit conversion?
>> What is the API definition including input and output?
>> How do you track the hysteresis?
>> Which kind of fitting algorithm do you use for the conversion? If poly, which order?
>> Where do you get the fitting parameters, probably RDB, right? If yes, do you have the schema,
>> and can you send me a copy?
>> Do you have any reference document?
>>
>> Guobao
>>
>> -- 
>> Guobao Shen
>> Bldg. 902-B, 17 Cornell Avenue
>> National Synchrotron Light Source II
>> Brookhaven National Laboratory
>> Upton, New York 11973
>> Tel.	: +1 (631) 344 7540
>> Fax.	: +1 (631) 344 8085
>> http://www.bnl.gov/nsls2
>>
> .
>

-- 
Guobao Shen
Bldg. 902-B, 17 Cornell Avenue
National Synchrotron Light Source II
Brookhaven National Laboratory
Upton, New York 11973
Tel.	: +1 (631) 344 7540
Fax.	: +1 (631) 344 8085
http://www.bnl.gov/nsls2