"How to use a2p2 as communication bridge between Aspro2 and CHARA facility"
- 7 Nov 1H - 11AM EST / 5PM CET / 8AM PST
- Theo, Jeremy, Gilles, Laurent, Guillaume
why a2p2 - quick reminder of its motivations
- Leave only generic management of preparation steps in Aspro2 (implemented in JAVA)
- delegate to a collaborative tools the link onto remote tools
- first goal was to send OB to ESO with a tool were all ESO specific is controlled (and coded) by ESO colleagues
- second was to open the way to CHARA
- futur features could manage the observations follow up : track what has been observed and plan remaining slots (a2p2 could help Aspro2 to harvest various records on various archives, logs )
- give instrument scientist responsible a way to edit rules in the a2p2 tool
software architecture overview
- Aspro2 sends OB to a2p2 through SAMP VO protocol
- this is available on local connection ( tunneling may me possible but not straightforward )
- A2P2 is a python program
- distributed on pip
- code hosted on JMMC's github account https://github.com/JMMC-OpenDev
- tkinter graphical widgets (good platforms portability)
- Jeremy get troubles on window but can use linux :
- maybe gtk related
- dependencies:
- help tab for facilities/instruments
- log test
- with facility submodules
which inputs from Aspro2
OB are subset of internal informations of Aspro2 plus computed extra informations
- Current detailed information doc online at :
- Received as an XML document but manipulated as a simple hierachical object ( https://github.com/JMMC-OpenDev/a2p2/blob/master/a2p2/ob.py#L38 )
- Some info are currently missing and then require discussion for new asproOB model revision:
- Pops - when pops are entered manually, they get passed.
- TODO: best pops are not sent yet
- LST observable ranges (generic) should be sufficient -> providing this information to a2p2 would help a lot night PI to arrange multiple OB
- TODO: how are computed such observability ranges ? all constraints or not ?
- TODO: ASPRO2 should send also UTC ranges specific to the specific date (including precise moon / night ... constraints)
- diameter/other model parameters
- diameter is provided only for calibrators
- time above min. elevation ? see UTC range (before)
- what else ? (Beams, Reference cart, Beam combiner, PI, Project ID)
- PI & Project ID will be necessary in the long term if the goal is to have these OBs read by the observing software
- Beam Combiner is provided
- Probably should be done on a2p2 side, rather than aspro side
- The remaining items would be nice to have in the OB, but I'm not sure how necessary it is. It could be worth asking the community
- If we use it to help control observing, we will need these things.
- Only selected target gets passed and only the first calibrator and other associated helper stars (GS)
-
- TODO: send all calibrators and associated objects (not only first)
Discussions:
- There are two ways to see aspro2 and a2p2 being used:
- As a planning tool, Aspro2 will find the best POPs and help determine the configuration for an observing run.
- As an observing tool it should fix the POPs to those currently in use and help the observer decide what can and can not be observed at any given time during the night.
- This means that POP information needs to travel in both directions.
- Look at previous attempt between PIVOT/VEGA and Aspro2 communication (LB has the knowledge):
- ASPRO2 already accepts incoming load.votable SAMP messages (VOTable format) to take control of the ASPRO2 observation:
- TODO JMMC: Implement in A2P2 this message support to expose a new python class/API to
- define observation setup
- add / remove targets, in the future, also calibrator associations and target groups
- TODO CHARA: Port the CHARA message system in python to FIRST get the current CHARA setup (instrument, date, baselines with PoPs/Beams)
- That's all folks: plugin both in A2P2 will allow to have ASPRO2 aware of the current CHARA setup to determine target observability ... !
review on code specific to CHARA
- Facility class
- Receives OB object automatically from Aspro2
- Current implementation only forwards to the GUI for basic display
- Should handle more details:
- specific checks according facility requirements
- forward content to a dedicated instrument class or generic one as fallback
- GUI class
- Jeremy feedback
- can't display DIAMETER
- [] JMMC will look into
- would like to provide a good planning in a2p2
- would like a2p2 can injest this onto CHARA system
- Next steps should implement CHARA's specific constraints and communication with dedicated protocol
- We will need some code to translate between CHARA messages and a2p2 messages.
- In the CHARA GITLAB
- chara-documentation/howto/cliserv
- Also see
- chara-array-software-libraries/include
- Does A2p2 and/or Aspro2 need to be able to send information to the CHARA observing log during the night?
- I think a Python version of the CHARA message system exists.... I will ask around.
how to distribute future collaborative releases using git
- first - feel free to create issues on GitHub!!
- basic proposal :
- CHARA fork the JMMC a2p2's repository
- CHARA add some changes and commit in specific account
- CHARA send pull requests
- JMMC review and merge if ok for a new revision
- JMMC upload a new package available on PIP