acc issueshttps://gitlab.triumf.ca/hla/acc/-/issues2018-03-01T08:52:32-08:00https://gitlab.triumf.ca/hla/acc/-/issues/18the test case "python scale.py ios-mws-sebt3a-tigress_ref" suddenly running m...2018-03-01T08:52:32-08:00Thomas Planchethe test case "python scale.py ios-mws-sebt3a-tigress_ref" suddenly running much slower!It was running in ~0.46s on my computer yesterday after I implemented some speedup (it was ~0.6s before the speedup). It now runs in almost 2 s! 4 times slower. What happened?It was running in ~0.46s on my computer yesterday after I implemented some speedup (it was ~0.6s before the speedup). It now runs in almost 2 s! 4 times slower. What happened?Spencer KiySpencer Kiyhttps://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-31https://gitlab.triumf.ca/hla/acc/-/issues/16xml2optr data.dat discussion2019-06-20T10:11:47-07:00Carla Barquestxml2optr data.dat discussionWe need to discuss :)We need to discuss :)Thomas PlancheThomas Planchehttps://gitlab.triumf.ca/hla/acc/-/issues/15After fixing tune syntax for all sequences, I am still not able to use xml2op...2019-06-20T10:08:58-07:00Stephanie RadelAfter fixing tune syntax for all sequences, I am still not able to use xml2optr.py. The fault see below.Traceback (most recent call last):
File "../../lib/xml2optr.py", line 4, in <module>
from xml2datadat import xml2datadat
File "/home/sradel/acc/lib/xml2datadat.py", line 11, in <module>
from acc.lib.scale import load_beam_pro...Traceback (most recent call last):
File "../../lib/xml2optr.py", line 4, in <module>
from xml2datadat import xml2datadat
File "/home/sradel/acc/lib/xml2datadat.py", line 11, in <module>
from acc.lib.scale import load_beam_properties
File "/home/sradel/acc/lib/scale.py", line 11, in <module>
from acc.lib.calc_isac_linac import calc
File "/home/sradel/acc/lib/calc_isac_linac.py", line 6, in <module>
from beam.home.lib import get_epicsDict_from_list
File "/home/sradel/beam/home/lib.py", line 279, in <module>
beamlines = initialize_beamlines(accDir,apps)
File "/home/sradel/beam/home/lib.py", line 216, in initialize_beamlines
blpathIsURL = validators.url(accDir)
File "<decorator-gen-13>", line 2, in url
File "/home/sradel/beam/home/venv-py3/lib64/python3.4/site-packages/validators/utils.py", line 78, in wrapper
value = func(*args, **kwargs)
File "/home/sradel/beam/home/venv-py3/lib64/python3.4/site-packages/validators/url.py", line 105, in url
result = pattern.match(value)
TypeError: expected string or bufferhttps://gitlab.triumf.ca/hla/acc/-/issues/14import epics in lib/calc_isac_linac.py2018-02-19T12:27:26-08:00Thomas Plancheimport epics in lib/calc_isac_linac.pyI do not want to install epics (not even pyepics packages) onto my computer. And when I try to run scale.py or xml2optr.py I get an "ImportError: No module named 'epics'" because of the from epics import ca in calc_isac_linac.py.I do not want to install epics (not even pyepics packages) onto my computer. And when I try to run scale.py or xml2optr.py I get an "ImportError: No module named 'epics'" because of the from epics import ca in calc_isac_linac.py.Spencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/13acxml clean up2021-04-29T15:58:10-07:00Thomas Plancheacxml clean upI see a lot or repeated code in acxml.pyI see a lot or repeated code in acxml.pyCarla BarquestCarla Barquesthttps://gitlab.triumf.ca/hla/acc/-/issues/12scale isn't handling cases with different cavities on/off in DTL or SC linac2018-01-26T13:31:05-08:00Spencer Kiyscale isn't handling cases with different cavities on/off in DTL or SC linacTo reproduce current functionality of how setpoints have been calculated the status of cavities should be read from epics, then used to calculate setpoints in scale.pyTo reproduce current functionality of how setpoints have been calculated the status of cavities should be read from epics, then used to calculate setpoints in scale.pySpencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/11Update acc database up to EHDT2019-06-20T10:15:01-07:00Carla BarquestUpdate acc database up to EHDTStephanie RadelStephanie Radelhttps://gitlab.triumf.ca/hla/acc/-/issues/10Individual CCBs should be included in tune files, ecbs should scale differenc...2018-01-29T13:52:22-08:00Spencer KiyIndividual CCBs should be included in tune files, ecbs should scale difference with its designated ccbElectrostatic steerers (ECB) in scale.py should scale with the ccb for that steerer identified in the path/sequence xml. If no ccb is found for that ecb, it should be scaled assuming it is a bipolar supply.Electrostatic steerers (ECB) in scale.py should scale with the ccb for that steerer identified in the path/sequence xml. If no ccb is found for that ecb, it should be scaled assuming it is a bipolar supply.Spencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/9unify does not handle subtraction, must add a negative number instead.2018-02-28T22:49:11-08:00Spencer Kiyunify does not handle subtraction, must add a negative number instead.see attached command line snippet
![unify_error](/uploads/4c7a050cf0bc3eaf460e58c1c7a4aefd/unify_error.png)see attached command line snippet
![unify_error](/uploads/4c7a050cf0bc3eaf460e58c1c7a4aefd/unify_error.png)Thomas PlancheThomas Planchehttps://gitlab.triumf.ca/hla/acc/-/issues/8scale.py does not deal with ecb2018-01-15T14:03:34-08:00Thomas Planchescale.py does not deal with ecbSpencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/7Ugly output from scaling.py2018-01-24T10:03:09-08:00Thomas PlancheUgly output from scaling.pyThe XML output from scaling.py, even after running it through 'prettify' looks ugly. Things like:
<set pv="IOS:EE:VOL" value="4501.1*V">
</set>
that should be:
<set pv="IOS:EE:VOL" value="4501.1*V"/>
or:
</tune><tune chargestate="1.0"...The XML output from scaling.py, even after running it through 'prettify' looks ugly. Things like:
<set pv="IOS:EE:VOL" value="4501.1*V">
</set>
that should be:
<set pv="IOS:EE:VOL" value="4501.1*V"/>
or:
</tune><tune chargestate="1.0" energypernucleon="0.306*MeV/u" id="MEBT:RFQ" mass="22.9877*u">
that should look like:
</tune>
<tune chargestate="1.0" energypernucleon="0.306*MeV/u" id="MEBT:RFQ" mass="22.9877*u">
I am not sure how to fix that...Spencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/6Tune Units in xml2optr2019-06-20T10:08:02-07:00Carla BarquestTune Units in xml2optrI noticed that I originally had the wrong units in the emma.xml tune file when running `xml2optr`, but it didn't seem to change the output optr.eps file. I'm assuming `unify` is called when generating data.dat file--but I haven't had tim...I noticed that I originally had the wrong units in the emma.xml tune file when running `xml2optr`, but it didn't seem to change the output optr.eps file. I'm assuming `unify` is called when generating data.dat file--but I haven't had time to look into it yet. Something we can discuss @tplanche ?
See comment on this line: [Tune for emma.xml](https://gitlab.triumf.ca/hla/acc/blob/2823deaea582cca2d43001a3b0c2fb703f62eb2a/isac/tune/emma.xml#L4)Carla BarquestCarla Barquesthttps://gitlab.triumf.ca/hla/acc/-/issues/5Bender position calculation in xml2optr/optr2xml2017-09-25T11:37:48-07:00Carla BarquestBender position calculation in xml2optr/optr2xmlFound an offset before and after bends in emma.xml when running the following command on hlx:
```
/home/cbarquest/acc/lib/xml2optr.py '/home/cbarquest/acc/isac/path/emma.xml' -E 79.3591 -q 7 -m 33533.80 -Q 0 -t '/home/cbarquest/acc/isac...Found an offset before and after bends in emma.xml when running the following command on hlx:
```
/home/cbarquest/acc/lib/xml2optr.py '/home/cbarquest/acc/isac/path/emma.xml' -E 79.3591 -q 7 -m 33533.80 -Q 0 -t '/home/cbarquest/acc/isac/tune/emma.xml' -o '/home/cbarquest/acc/lib/emmatest/'
```
The output I put for the first version in beam/envelope highlights the drift that I had to manually change for the generated xml2optr sy.f file to match the reference sy.f output:
https://gitlab.triumf.ca/hla/beam/envelope/blob/c3c71a2e9bc9afb68587dfec0f7f05f7c0dc74b6/optr/isac/emma/sy.f#L37
Drifts before and after the bends were off by +/-26.18cm. Note the sequence emma.xml file was originally generated by optr2xml(I think?) so not sure if the position calculation is off in optr2xml or xml2optr.
Here are the relevant emma.xml path/sequence/tune files:
* [Path emma.xml](https://gitlab.triumf.ca/hla/acc/blob/7398886db772256ccd284a540305f2dec6564e9a/isac/path/emma.xml)
* [Sequence emma.xml](https://gitlab.triumf.ca/hla/acc/blob/7398886db772256ccd284a540305f2dec6564e9a/isac/sequence/emma.xml)
* [Tune emma.xml](https://gitlab.triumf.ca/hla/acc/blob/7398886db772256ccd284a540305f2dec6564e9a/isac/tune/emma.xml)
And here are the reference sy.f and data.dat files:
* [Reference emma sy.f](https://gitlab.triumf.ca/beamphys/transoptr/blob/55f7ee22a74be564ad1dfc4cd810aadba9b2746c/example/ISAC/EMMA/sy.f)
* [Reference emma data.dat](https://gitlab.triumf.ca/beamphys/transoptr/blob/55f7ee22a74be564ad1dfc4cd810aadba9b2746c/example/ISAC/EMMA/data.dat)Thomas PlancheThomas Planchehttps://gitlab.triumf.ca/hla/acc/-/issues/4Stange attributes of ao in sequence XML files2017-09-12T15:17:08-07:00Thomas PlancheStange attributes of ao in sequence XML filesThis is only a suggestion:
I see things like:
<ao ccb='IMS:CCB6:VOL' EGU='V' DRVL='0.0' DRVH='1000.0'>IMS:YCB8:VOL</ao>
The common power supply should be a separated ao. I mean it should look instead like:
<ao EGU='V' DRVL='0.0' DRVH='1...This is only a suggestion:
I see things like:
<ao ccb='IMS:CCB6:VOL' EGU='V' DRVL='0.0' DRVH='1000.0'>IMS:YCB8:VOL</ao>
The common power supply should be a separated ao. I mean it should look instead like:
<ao EGU='V' DRVL='0.0' DRVH='1000.0'>IMS:YCB8:VOL</ao>
<ao EGU='V' DRVL='0.0' DRVH='1000.0'>MS:CCB6:VOL</ao>
What do you think?
I also see things like:
<ao rw='RO' type='scan'>IMS:RPM24:SUBRPM</ao>
what is rw??Spencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/3change 'at' to 'center'2017-08-15T14:49:41-07:00Thomas Planchechange 'at' to 'center'The tag 'at' is creating confusion as to whether it corresponds to the location of the element entrance or center (with respect to the beginning of the sequence). It does corresponds the the location of the element center. It was propose...The tag 'at' is creating confusion as to whether it corresponds to the location of the element entrance or center (with respect to the beginning of the sequence). It does corresponds the the location of the element center. It was proposed during the last HLA meeting to rename it to 'center' to avoid further confusion.Thomas PlancheThomas Planchehttps://gitlab.triumf.ca/hla/acc/-/issues/2Add accurate DRVL and DRVH to every ao2017-07-27T12:10:11-07:00Thomas PlancheAdd accurate DRVL and DRVH to every aoOne could probably write a script to do that: get from EPICS the value of DRVL and DRHV for every valid PV, and append them to the sequence XMLs.
I need the DRVL and DRVH for transoptr. For now I sneaked them in the tune file. but they d...One could probably write a script to do that: get from EPICS the value of DRVL and DRHV for every valid PV, and append them to the sequence XMLs.
I need the DRVL and DRVH for transoptr. For now I sneaked them in the tune file. but they do not belong there.Spencer KiySpencer Kiyhttps://gitlab.triumf.ca/hla/acc/-/issues/1Fortran Type Elements in XML2019-06-20T10:15:52-07:00Carla BarquestFortran Type Elements in XMLSpencer copied this element from ims-yslit0.xml in BeamPaths, should be discussed if it belongs as an element.Spencer copied this element from ims-yslit0.xml in BeamPaths, should be discussed if it belongs as an element.Thomas PlancheThomas Planche