atcollab / at

Accelerator Toolbox
Apache License 2.0
48 stars 31 forks source link

atSetRingProperties and cavpts side effect #636

Open lnadolski opened 1 year ago

lnadolski commented 1 year ago

Dear @lfarv,

I am in trouble with the behavior of atSetRingProperties.

If I call the function, per default il will add a RingParam element at the beginning of the lattice. :-)

atSetRingProperties(THERING, 'FamName', AD.ATModel);

but per default, it will add the field cavpts. ;-(

This is unwanted since if I add a new element before the cavity in the lattice cavpts should be updated by hand. Line 70 of atSetRingProperties: [parmelem,~]=atparamscan(ring,parmelem,'Particle','cell_harmnumber','cavpts');

For instance, atGetRingProperties(myringRadOn, 'HarmNumber', 'rf_frequency') will use the cavpts if present in ringparam.

Is there any reason to keep this behavior? I will either remove the 'cavpts' or make a sanity check that the cavpts need update.

Do you have any thoughts about it?

Best regards,

Laurent.

lfarv commented 1 year ago

I see the problem. I think that the idea was to improve performance when acting in the cavities. The two solutions you propose may be implemented. The easiest (and safest) is to remove cavpts from the cached values. That's my preferred option for now.

cavpts will remain as a user-defined property to describe the "main cavities" in the case of complex RF systems (if they are different from the lowest frequency cavities), and for optional performance improvement. But it will then be completely handled by the user and absent by default.

The cavity "how-to" guide needs to be updated.