Update tables for wig180 corrs

[xresende]

• Updated pwrsupply tables according to @gabrielbrunheira suggestions on adding wiggler180 correctors.
• We still need to update the excitation curve for these correctors! (@Gabrielrezende-asc ) (DONE!)

[xresende]

@fernandohds564 , I think it is useful to put the URL for Cabos_e_Fibras_Sirius.xlsx in the header of the file. This way we can access the original table when in CNPEM network.

[fernandohds564]

@fernandohds564 , I think it is useful to put the URL for Cabos_e_Fibras_Sirius.xlsx in the header of the file. This way we can access the original table when in CNPEM network.

@xresende, this is a google docs file. If I put its URL in the header this file everybody with access to github would be able to view and edit it, right?

[anacso17]

@fernandohds564 , I think it is useful to put the URL for Cabos_e_Fibras_Sirius.xlsx in the header of the file. This way we can access the original table when in CNPEM network.

@xresende, this is a google docs file. If I put its URL in the header this file everybody with access to github would be able to view and edit it, right?

Is there a way to share the file with read-only option?

[fernandohds564]

right @anacso17. I pushed one commit with this change, @xresende.

[xresende]

@fernandohds564 , did you manage to add it with read-only attribute URL ?

Since this file belongs to the Sirius control system / subsystems, is it not a good idea to ask the maintainer to move its primary location to one of our standard systems ? github, gitlab or sharepoint? are there other relevant Sirius files already stored at google services?

[fernandohds564]

@fernandohds564 , did you manage to add it with read-only attribute URL ?

yes

Since this file belongs to the Sirius control system / subsystems, is it not a good idea to ask the maintainer to move its primary location to one of our standard systems ? github, gitlab or sharepoint? are there other relevant Sirius files already stored at google services?

I already asked this in the past, but we could try again. What do you guys think @danielot, @mmdonatti ?

@xresende, is there any api to communicate with excel files in sharepoint the way I do in siriuspy with google docs?

[Gabrielrezende-asc]

Here are the excitation curves for both gaps:

[xresende]

Hi guys, I think it is missing to add SI-14SB:MA-CH-1 and SI-14SB:MA-CH-2 to magnets-model-data.txt file

done, @anacso17 !

[xresende]

@fernandohds564 , did you manage to add it with read-only attribute URL ?

yes

Since this file belongs to the Sirius control system / subsystems, is it not a good idea to ask the maintainer to move its primary location to one of our standard systems ? github, gitlab or sharepoint? are there other relevant Sirius files already stored at google services?

I already asked this in the past, but we could try again. What do you guys think @danielot, @mmdonatti ?

@xresende, is there any api to communicate with excel files in sharepoint the way I do in siriuspy with google docs?

there is a python api to interact with sharepoint objects, like retrieving a list of files names and files @ronecastro has implemented a subset of features using sharepy package. see documentation/procedures/build-link-page.py in PR https://github.com/lnls-sirius/control-system-constants/pull/256

as for getting into spreadsheet elements, I think the file can be retrieved using api sharepy and spreadsheet can be read/modifies with panda: https://pythonbasics.org/read-excel/

[fernandohds564]

@xresende, I talked to @danielot this morning about this.

He said the reason this table was in google docs is because it used to depend on references for spreadsheets in different files, which was not supported by Sharepoint back then. However, it seems these dependencies doesn't exist anymore, and we could move them.

He went even further, saying that we could translate this spreadsheet to other formats, such as text files, so it would be in accordance with our standards. He also suggested changing all the text files in this repository to json or some other multi-plataform format. The advantage would be that we wouldn't need to implement parsing scripts for every file.

Is this a good summary of our talk @danielot ?

I see the advantage of using json, but I wonder if this change would exchange human readability by computer readability and what would be better: to use a format easy to read or easy to maintain...

[danielot]

@xresende, I talked to @danielot this morning about this.

He said the reason this table was in google docs is because it used to depend on references for spreadsheets in different files, which was not supported by Sharepoint back then. However, it seems these dependencies doesn't exist anymore, and we could move them.

He went even further, saying that we could translate this spreadsheet to other formats, such as text files, so it would be in accordance with our standards. He also suggested changing all the text files in this repository to json or some other multi-plataform format. The advantage would be that we wouldn't need to implement parsing scripts for every file.

Is this a good summary of our talk @danielot ?

I see the advantage of using json, but I wonder if this change would exchange human readability by computer readability and what would be better: to use a format easy to read or easy to maintain...

@xresende and @fernandohds564, I think this is a good summary. I just have one complement in the topic about JSON and human readability. YAML format may be the one to give you what you're looking for. Besides human readability it is more flexible to things like commenting lines and so on.

My main point is that by using text files we are recreating a database. There should be benefits of using standard databases to store such data. I think it should be possible to keep it simple if we adopt a nosql database approach...

Does @edupcoelho have an opinion about this?

[xresende]

@xresende, I talked to @danielot this morning about this. He said the reason this table was in google docs is because it used to depend on references for spreadsheets in different files, which was not supported by Sharepoint back then. However, it seems these dependencies doesn't exist anymore, and we could move them. He went even further, saying that we could translate this spreadsheet to other formats, such as text files, so it would be in accordance with our standards. He also suggested changing all the text files in this repository to json or some other multi-plataform format. The advantage would be that we wouldn't need to implement parsing scripts for every file. Is this a good summary of our talk @danielot ? I see the advantage of using json, but I wonder if this change would exchange human readability by computer readability and what would be better: to use a format easy to read or easy to maintain...

@xresende and @fernandohds564, I think this is a good summary. I just have one complement in the topic about JSON and human readability. YAML format may be the one to give you what you're looking for. Besides human readability it is more flexible to things like commenting lines and so on.

My main point is that by using text files we are recreating a database. There should be benefits of using standard databases to store such data. I think it should be possible to keep it simple if we adopt a nosql database approach...

Does @edupcoelho have an opinion about this?

thanks, @fernandohds564 and @danielot for the discussion. I think we could use YAML. maybe new tables may be nserted already in this format and older ones gradually migrated. for a quick reference on yaml/pyhton for those of us who never used it: https://zetcode.com/python/yaml/