acc issueshttps://gitlab.triumf.ca/hla/acc/-/issues2022-01-10T12:53:21-08:00https://gitlab.triumf.ca/hla/acc/-/issues/38Polartiy for ILE2:Q20 may be inconsistent between theory tune values and phys...2022-01-10T12:53:21-08:00Spencer KiyPolartiy for ILE2:Q20 may be inconsistent between theory tune values and physical wiringhttps://gitlab.triumf.ca/hla/acc/-/issues/37We should define our axes (+/- X and+/- Y)2021-11-17T11:42:02-08:00Spencer KiyWe should define our axes (+/- X and+/- Y)Or maybe we already have and I am out to lunch. @oshelb @tplanche We should discuss this at Friday's meeting if possible! David needs to know for training of the agent so I've double checked which way steerers operate and RPM axes and am...Or maybe we already have and I am out to lunch. @oshelb @tplanche We should discuss this at Friday's meeting if possible! David needs to know for training of the agent so I've double checked which way steerers operate and RPM axes and am starting to add the info into acc but want to make sure you are ok with how I'm going about it.https://gitlab.triumf.ca/hla/acc/-/issues/369 degree deflector plates at ISAC seem to be operated 5-10% below their theor...2021-09-25T13:35:31-07:00Spencer Kiy9 degree deflector plates at ISAC seem to be operated 5-10% below their theoretical settingsMost significantly seen in OLIS at IOS:XCB1A, but also routinely observed at other 9 degree deflectors. Most recently I ran the OLIS MWS with B1A (36 degree bender) at theory, but had to lower the XCB1A plates by around 13% to get beam t...Most significantly seen in OLIS at IOS:XCB1A, but also routinely observed at other 9 degree deflectors. Most recently I ran the OLIS MWS with B1A (36 degree bender) at theory, but had to lower the XCB1A plates by around 13% to get beam to IOS:FC3. Some brief check of IOS:Q1-3 after showed they were not steering much suggesting beam was on axis through those quads.
I was curious and also checked a tune from OLIS SIS and found that XCB1A was ran 18% low in a tune in 210418_1123-ios-hebt1-db0.snap. So the 9 degree bender is ran low from either direction/polarity.
This behaviour is also observed at:
* ILT:XCB7
* ILE2:XCB11
* ILE2:XCB21
@baartman would be great if someone from beam physics could investigate this when someone has time. Is there a beam physics note on how the voltage of these deflectors is calculated?https://gitlab.triumf.ca/hla/acc/-/issues/35We lack understanding of MCIS's effect on both SIS and MWS beams2021-08-25T15:53:42-07:00Olivier ShelbayaWe lack understanding of MCIS's effect on both SIS and MWS beamsIt is part of tribal knowledge that the MCIS fringe field affects OLIS beams from either SIS or MWS. With the supernanogan cart installed, there is a consistent need for hundreds of volts steering right at IOS:X/YCB1.
Per Keerthi: "With...It is part of tribal knowledge that the MCIS fringe field affects OLIS beams from either SIS or MWS. With the supernanogan cart installed, there is a consistent need for hundreds of volts steering right at IOS:X/YCB1.
Per Keerthi: "With the MCIS in, maximum vertical steering (1000V) is needed to steer the beam through the front end, which introduces additional noise and some emittance growth to the beam."
Removal of the MCIS cart is the usual solution to this issue. OLIS beams are therefore expected to differ from the source - with consequences downstream. This also naturally leads to a discussion about diagnostics.
This issue lies at the interface of engineering and optics; the solution likely does as well. @baartman @spencerkiyOlivier ShelbayaOlivier Shelbayahttps://gitlab.triumf.ca/hla/acc/-/issues/34Differing IMS quadrupoles between acc and original TRANSOPTR model2021-09-13T14:40:46-07:00Olivier ShelbayaDiffering IMS quadrupoles between acc and original TRANSOPTR modelIMS quadrupole lengths and aperture seem to differ between acc/ database (sequence ims_db6.xml) and beam physics TRANSOPTR model used for theory tune computation: http://lin12.triumf.ca/optr/ISAC/Sep-LEBT/matlab/sy.f
Specifically, see I...IMS quadrupole lengths and aperture seem to differ between acc/ database (sequence ims_db6.xml) and beam physics TRANSOPTR model used for theory tune computation: http://lin12.triumf.ca/optr/ISAC/Sep-LEBT/matlab/sy.f
Specifically, see IMS:Q11 and Q12 (each representing two quads), which differ between versions.
I'm tagging @baartman and @spencerkiy for awareness. I'll handle fixing this, but am tracking bugs/finds as I go along!
OlivierOlivier ShelbayaOlivier Shelbayahttps://gitlab.triumf.ca/hla/acc/-/issues/33Electrostatic benders in ISAC need to run ~5% high to keep beam centered on RPMs2021-08-12T14:45:35-07:00Spencer KiyElectrostatic benders in ISAC need to run ~5% high to keep beam centered on RPMsThis is a known issue, but hasn't been properly investigated yet.This is a known issue, but hasn't been properly investigated yet.https://gitlab.triumf.ca/hla/acc/-/issues/32Design optics settings for match into ISAC RFQ don't seem to work well - reas...2021-08-12T14:42:54-07:00Spencer KiyDesign optics settings for match into ISAC RFQ don't seem to work well - reason unknownWe now have some confidence that the observations of beamsize in the ILT beamline from OLIS to IRA mostly agree with the model. However, I still find that using the design optics for ILT:Q50 to IRA:Q4 to not give very good RFQ transmissi...We now have some confidence that the observations of beamsize in the ILT beamline from OLIS to IRA mostly agree with the model. However, I still find that using the design optics for ILT:Q50 to IRA:Q4 to not give very good RFQ transmission, suggesting maybe an issue with the optics in that section of beamline. Currently, we use emperically established optics settings found [here](https://gitlab.triumf.ca/hla/acc/-/blob/master/isac/tune/tunesequence/iltdb34-mebtdb0_ref.xml)https://gitlab.triumf.ca/hla/acc/-/issues/31Find a way to all converge on only using acc as basis for transoptr simulations.2021-04-29T16:30:50-07:00Spencer KiyFind a way to all converge on only using acc as basis for transoptr simulations.There are too many different copies of different sy.f on too many different computers and we are not at all taking advantage of the fact that we now have a central repo to collect all this information.
There are too many discrepancies ...There are too many different copies of different sy.f on too many different computers and we are not at all taking advantage of the fact that we now have a central repo to collect all this information.
There are too many discrepancies and we should try to find a way to **all** use acc.
Once solution is to at a minimum convince everyone to mark devices with their unique ID from acc in their sy.f ('IOS:Q6') and then write a script that will compare drift distances, effective lengths with the equivalent section in acc automatically and spit out errors if there are disagreements.
Maybe transoptr could be programmed to get angry at people when they don't appropriately label devices and not let them do simulations until they do...
Anyway up for discussion. @tplanche @oshelb @pjunghttps://gitlab.triumf.ca/hla/acc/-/issues/30Unnecessary extra optr attirbutes: "scale", "scaleVmap", 'scaleBz'2019-09-30T10:24:20-07:00Spencer KiyUnnecessary extra optr attirbutes: "scale", "scaleVmap", 'scaleBz'Seems like we should only need one of those, and I would propose it be 'scale' so that it is general. @tplanche @pjung what do you think, this would require a minor tweak to xml2optr as well.Seems like we should only need one of those, and I would propose it be 'scale' so that it is general. @tplanche @pjung what do you think, this would require a minor tweak to xml2optr as well.https://gitlab.triumf.ca/hla/acc/-/issues/26Updating the database optr tags for generating layout points2019-09-27T10:25:11-07:00Vishvam MazumdarUpdating the database optr tags for generating layout pointsRecently, I've been trying to generate the xyz values of elements from the s, the l, and the angles (thetas) of magnetic benders. Some of these thetas seem have the wrong sign. I have updated the ones that had the wrong sign in the datab...Recently, I've been trying to generate the xyz values of elements from the s, the l, and the angles (thetas) of magnetic benders. Some of these thetas seem have the wrong sign. I have updated the ones that had the wrong sign in the database (at least in the elinac for now) by changing the sign from positive to negative. These were the ones with the wrong signs in the elinac: ehat:mb4, ehdt:mb2, ehdt:mb4, ELBD:MB0. Carla and I thought this was the way to go but were wondering if there is a problem with changing the signs on the angles. I.e. Does it interfere with any other app? Also was wondering if there's already a way to tell about which axis the beam bends at a magnetic bender. If not, this will also have to be added to the database. @tplanchehttps://gitlab.triumf.ca/hla/acc/-/issues/24Config File Mapping Only2018-05-10T16:54:05-07:00Carla BarquestConfig File Mapping OnlyI think that the `config.ini` file should only specify mapping from element type in the acc database to different quantities such as transoptr element type, plotting color, or how different types scale, or when types are visible etc. The...I think that the `config.ini` file should only specify mapping from element type in the acc database to different quantities such as transoptr element type, plotting color, or how different types scale, or when types are visible etc. There seems to be quite a bit of information inside `config.ini` that doesn't really pertain to element type mapping, such as: https://gitlab.triumf.ca/hla/acc/blame/master/lib/config.ini#L45. We may need to expand our database structure in order to accommodate this type of information, or include it in files that are linked to within the database etc. Or perhaps these things really do belong here--Up for discussion! :ok_hand:Carla BarquestCarla Barquesthttps://gitlab.triumf.ca/hla/acc/-/issues/23Add ISAC FEBIAD paths, as well as CTIS/CSB source and its paths2021-04-29T15:58:22-07:00Spencer KiyAdd ISAC FEBIAD paths, as well as CTIS/CSB source and its paths2019-03-31https://gitlab.triumf.ca/hla/acc/-/issues/22I would like to be able to specify the precision I would like floats returned...2018-03-19T09:32:08-07:00Spencer KiyI would like to be able to specify the precision I would like floats returned to when I call unify.So the call to unify would be something like:
`unify("string in here", precision=4)`
Precision should be optional and can default to whatever (currently is to 6 which works for me).So the call to unify would be something like:
`unify("string in here", precision=4)`
Precision should be optional and can default to whatever (currently is to 6 which works for me).Thomas PlancheThomas Planchehttps://gitlab.triumf.ca/hla/acc/-/issues/17useBIcurve in scale.py takes ~0.4 seconds to run for the tune ios-mws-sebt3a-...2018-02-21T11:34:09-08:00Spencer KiyuseBIcurve in scale.py takes ~0.4 seconds to run for the tune ios-mws-sebt3a-tigress_refScaling magnetic quads linearly with p/q for the same path takes 30 ms, when useBIcurve is enabled the scale takes 430 ms. This should be investigated and improved upon if possible.
With no BI fit:
`(venv-py3) [spencerkiy@hlx lib]$ py...Scaling magnetic quads linearly with p/q for the same path takes 30 ms, when useBIcurve is enabled the scale takes 430 ms. This should be investigated and improved upon if possible.
With no BI fit:
`(venv-py3) [spencerkiy@hlx lib]$ python scale.py ios-mws-sebt3a-tigress_ref
0.10306835174560547s (time to generate full tuneroot from path and tune files)
0.03018975257873535s (time to scale)
0.00475001335144043s (time to re-parse and print to file)
0.13800811767578125s (total run time)
`
with BI fit:
`(venv-py3) [spencerkiy@hlx lib]$ python scale.py ios-mws-sebt3a-tigress_ref
0.10311174392700195s (time to generate full tuneroot from path and tune files)
0.4269981384277344s (time to scale)
0.0026226043701171875s (time to re-parse and print to file)
0.5327324867248535s (total run time)
`Thomas PlancheThomas Planche2018-05-31