-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layout Database for CHIME Outriggers #11
Comments
Running Order;
Deliverables
Inputs
Purchasing:
|
CHIME LNA Rev C Allenby |
Update: New python backend for adding, modifying, and connecting components in the layout db is done. In progress: Working on developing a local database (in python) that will be used to capture components at the site, which will later be uploaded to the layout db (with "connexions") using the new python backend that I've developed. #TODO: Barcode scanning not yet implemented. We'll implement that capability as a user-input protocol within the local database. |
My current (on-going) implementation plan for the local db (in progress):
Comments & suggestions appreciated! |
Question: Will the Allenby team provide a list of part numbers, component types, and revisions for their outrigger site? This information will be needed for the local database. |
There is a list of components (e.g. LNA, FLA, cables, etc) that are barcoded and there are some that are not (e.g. vestibule cables). We can provide a list. There are also things that are "virtual". for example a focal-line cassette position. Some components are already entered in the database. |
are you planning to replicate the database? I thought the decision (at some point in time?!?!) was to keep one global database. |
As a requirement: there should be a way to replace components : sever connections, replace connection and able to provide a comment/date/user for the action. There is currently a web php interface in addition to the python interface. The web interface has been extremely useful during field work. |
@mondana I have no plans to replicate the database. I intend to keep one global database. Everything will be propagated to the layout db that is currently in use, but we will have different telescopes (or graphs) for each outrigger site. In case it's not clear, the purpose of the local database is to allow us to add components to the layout db when we assemble on site. We'll store these locally, and then run a pipeline that I'm building that will populate new entries into the global database. The functionality to sever and/or replace connections and add user comments already exists (both in the web interface, and now in my python backend). You'll have this option also with the local database (e.g., in case we find a faulty cable, and want to replace it with a different part). Any other issues/thoughts? |
ah, I see. Not sure why we won't be adding them directly to the global database, what would the pipeline do? perhaps you can provide a use case or an example. |
The local database will give us more flexibility in several ways. For example, (i) it is easier to make changes since the data structure is essentially a simple python dictionary or look-up table, (ii) we won't need an internet connection nor will we have to worry about complicated library dependencies to make updates (as is currently needed for the layout db), and (iii) if we need to replace a part in the database, we won't have to worry about additional overhead (e.g., making sure we sever connections in order to replace a part in the middle of the chain). I'm extremely keen to proceed in this fashion. I believe this will minimize our work. The pipeline will be run at the end. It will just add each entry (if it doesn't already exist in the global database), along with all of its properties, connexions, etc..., and populate the elements in the local db into the layout db. It will just loop over components and add them one at a time. The local db will serve as a temporary record of the connections we made on site. Yes, we'll have 3 more geographic sites / graphs as you mentioned for each of the outriggers. The 26m also has a graph, so we'll ultimately have a total of 6. |
At least two scanner/table setup, because at Allenby, we will be doing things in parallel and quite possibly need one at the bottom. |
Niko informs me that we have the 3 scanners at chime site and can use at Allenby. Please note that at CHIME, we had to buy other scanners that worked in sunlight and dim lighting, had the multi-directional laser, and could tolerate certain skew. So I suggest we use those from CHIME, and buy one for Aaron's testing at McGill only. |
@nikola1003 also expresses preference for using android phones instead, so you can use with LTE and upload on the spot. Remember the difference at Allenby site is that, we have LTE. At CHIME, we did not. |
Or for that matter, LTE-enabled tablets (there is a bunch on the market so it should not be hard to source). |
Keep in mind that we're building this for use at the other outrigger sites as well. At GBO, we won't have (and can't use) LTE, so uploading components to the permanent database in real-time is not part of our plan at the moment. We can discuss if you think this will be an issue. Do you know the model of the tablets that were used in the past? Are they still available for use, or do we need to identify new ones? |
Not sure if you are still planning to refer to the google sheet of conventions, I made some edits and can do more if that is the place to capture those kind of information. Note that components are manufactured and barcoded in their manufacturing series. So the range of serial numbers should be free form. The first 3 letters are just chosen as a convention, but in most cases the serial number NNNN can be anything depending on when the unit was manufactured. LNA999C or ADC557 for example. unless I am missing a point about that googlesheet. |
Note that although we should make it flexible enough to be applicable to other outrigger site, but I really think we should focus on getting Allenby to work. We may find later that signal chain and scanning strategies are different at those sites and they may not even care about tracking and scanning every component depending on the assembly procedure. For example. There is one cylinder at Allenby while there are more in other sites (I think!) |
Things should be pretty similar at the other outrigger sites, from my understanding. There will be one cylinder at all sites, and I expect scanning and logging components will be handled more-or-less identically. There's also other issues with adding components to the permanent database in real-time, which we've discussed previously. For example, what happens if someone makes a mistake, or we need to replace something in the middle of the chain? All of this is much easier to handle if we just log all of the scans and connections, and then upload them to the permanent database at the end. We don't need internet or LTE for this, just some way to store the entries until we're done (i.e. the local database). It turns out that this is also how Kiyo and others did it in the past. A separate protocol just for Allenby is a lot of work, which I'm not keen to do. Let's not over-engineer this, but instead design something that will be reusable and work at all of the outriggers! |
TO DO:
|
Just wondering what these photos are for? |
Layout Database Overview https://arxiv.org/pdf/1410.8418
Layout_Database_ARXIV_1410.8418.pdf
Layout Database Interface: https://bao.chimenet.ca/layout/component.php
Layout Database file: https://github.com/chime-experiment/ch_util/blob/master/ch_util/layout.py
Layout Database Naming Convention: https://docs.google.com/spreadsheets/d/1Sn8_ny-i6sJFZybJgQROhPzNQ5hW-YBSkyjylhv3q8A/edit#gid=1807920613
Allenby Layout DB Issue: https://github.com/chime-experiment/allenby_infrastructure/issues/35
GBO Layout DB Issue: https://github.com/chime-experiment/GBO_infrastructure/issues/24
Useful existing code bases:
Scanner that was used by Kiyo:
HONEYWELL, VOYAGER 1400G, USB SCANNER KIT, OMNI-DIRECTIONAL, 1D, BLACK, USB TYPE A 11.5M STRAIGHT CA (pandemic/legacy model) Kiyo paid $160 CAD, but $250 CAD is reasonable.
In doc_assembly:
Code in field/: https://github.com/chime-experiment/doc_assembly/tree/master/field - Contains scripts that get run on the tablets in the field. There's different scripts for each field “task” (assembling a cassette, raising a cassette, etc). These produce "ltf" files.
Code in script/: https://github.com/chime-experiment/doc_assembly/tree/master/scripts - Entries in the "ltf" files get added to the permanent layout database using these scripts.
Code in single_use/: https://github.com/chime-experiment/doc_assembly/tree/master/single_use - Scripts for creating labels, which Kiyo printed on vinyl at kinkos. To generate the bar codes, the convention is the first 3 characters spec the type of component, after that sequentially. The conventions are quite loose.
Code in testing_env/: https://github.com/chime-experiment/doc_assembly/tree/master/testing_env - Contains a script to duplicate the whole layout database to a local sqlite. Then you can fiddle with that database without worrying about breaking the main one. (VERY IMPORTANT!)
Suggestion from Kiyo: In the field, you break a USB to mini USB adapter about once an hour… so buy lots of them.
The text was updated successfully, but these errors were encountered: