-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #19 from orppst/pah-polaris-poster-and-paper
Pah polaris poster and paper
- Loading branch information
Showing
52 changed files
with
12,612 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
Binary file added
BIN
+360 KB
ADASS2024/PolarisPoster/Paper/InstructionsforPresenters,Posters,ProceedingsandTutorials.pdf
Binary file not shown.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,239 @@ | ||
% This is the ADASS_template.tex LaTeX file, 19th Sep 2019. | ||
% It is based on the ASP general author template file, but modified to reflect the specific | ||
% requirements of the ADASS proceedings. | ||
% Copyright 2014, Astronomical Society of the Pacific Conference Series | ||
% Revision: 14 August 2014 | ||
|
||
% To compile, at the command line positioned at this folder, type: | ||
% latex ADASS_template | ||
% latex ADASS_template | ||
% dvipdfm ADASS_template | ||
% This will create a file called ADASS_template.pdf | ||
|
||
\documentclass[11pt,twoside]{article} | ||
|
||
% Do NOT use ANY packages other than asp2014. | ||
\usepackage{asp2014} | ||
|
||
\aspSuppressVolSlug | ||
\resetcounters | ||
|
||
% References must all use BibTeX entries in a .bibfile. | ||
% References must be cited in the text using \citet{} or \citep{}. | ||
% Do not use \cite{}. | ||
% See ManuscriptInstructions.pdf for more details | ||
\bibliographystyle{asp2014} | ||
|
||
% The ``markboth'' line sets up the running heads for the paper. | ||
% 1 author: "Surname" | ||
% 2 authors: "Surname1 and Surname2" | ||
% 3 authors: "Surname1, Surname2, and Surname3" | ||
% >3 authors: "Surname1 et al." | ||
% Replace ``Short Title'' with the actual paper title, shortened if necessary. | ||
% Use mixed case type for the shortened title | ||
% Ensure shortened title does not cause an overfull hbox LaTeX error | ||
% See ASPmanual2010.pdf 2.1.4 and ManuscriptInstructions.pdf for more details | ||
\markboth{Walker et al}{Polaris: a new open source observation proposal preparation tool} | ||
|
||
\begin{document} | ||
|
||
\title{Polaris: A New Open Source Observation Proposal Preparation Tool} | ||
|
||
% Note the position of the comma between the author name and the | ||
% affiliation number. | ||
% Authors surnames should come after first names or initials, eg John Smith, or J. Smith. | ||
% Author names should be separated by commas. | ||
% The final author should be preceded by "and". | ||
% Affiliations should not be repeated across multiple \affil commands. If several | ||
% authors share an affiliation this should be in a single \affil which can then | ||
% be referenced for several author names. If only one affiliation, no footnotes are needed. | ||
% See ManuscriptInstructions.pdf and ASP's manual2010.pdf 3.1.4 for more details | ||
\author{Darren~Walker, Allan~England, Ben~Green, and Paul~Harrison} | ||
\affil{JCBA, The University of Manchester, Manchester, UK; \email{[email protected]}} | ||
|
||
% This section is for ADS Processing. There must be one line per author. paperauthor has 9 arguments. | ||
% Arguments are: {NAME}{EMAIL}{ORCID_ID_OR_BLANK}{INSTITUTION}{DEPARTMENT}{CITY}{PROVINCE}{POSTAL CODE}{COUNTRY} | ||
\paperauthor{Darren~Walker}{[email protected]}{}{The University of Manchester}{Dept. of Physics and Astronomy}{Jodrell Bank Observatory}{Cheshire}{SK11 9DL}{UK} | ||
\paperauthor{Allan~England}{[email protected]}{}{The University of Manchester}{Dept. of Physics and Astronomy}{Jodrell Bank Observatory}{Cheshire}{SK11 9DL}{UK} | ||
\paperauthor{Ben~Green}{[email protected]}{}{The University of Manchester}{Dept. of Physics and Astronomy}{Jodrell Bank Observatory}{Cheshire}{SK11 9DL}{UK} | ||
\paperauthor{Paul~Harrison}{[email protected]}{}{The University of Manchester}{Dept. of Physics and Astronomy}{Jodrell Bank Observatory}{Cheshire}{SK11 9DL}{UK} | ||
|
||
% There should be one \aindex line (commented out) for each author. These are used to | ||
% build up the author index for the Proceedings. The surname must come first, followed by | ||
% initials. Note the use of ~ before each initial to control spacing. | ||
% The \author entries (see above) have surname last. These \aindex entries have | ||
% surname first. | ||
% The Aindex.py command willl create them for you after you have constructed the \author | ||
% The first entry should be the first author, for bold-facing the author index page-reference | ||
|
||
%\aindex{Walker,~D.~J.} | ||
%\aindex{England,~A.} | ||
%\aindex{Green,~B.} | ||
%\aindex{Harrison,~P.~A.} | ||
|
||
|
||
\begin{abstract} | ||
We are developing a new, open source proposal tool called \emph{Polaris} as a deliverable of the Horizon | ||
2020 OPTICON RadioNet Pilot project. | ||
This tool has been built on top of the Proposal Data Model, defined in the IVOA standard VO-DML\@. | ||
Although this is an important part of the tool, this paper will focus on the technologies | ||
used build and develop \emph{Polaris} itself. | ||
|
||
The API, GUI and CLI are maintained in open-source repositories on GitHub. | ||
This allows others to contribute to the development of Polaris or fork the projects to change the tool | ||
to suit their needs. | ||
\end{abstract} | ||
|
||
% These lines show examples of subject index entries. At this stage these have to commented | ||
% out, and need to be on separate lines. Eventually, they will be automatically uncommented | ||
% and used to generate entries in the Subject Index at the end of the Proceedings volume. | ||
% Don't leave these in! - replace them with ones relevant to your paper. | ||
%\ssindex{FOOBAR!conference!ADASS 2024} | ||
%\ssindex{FOOBAR!organisations!ASP} | ||
|
||
% These lines show examples of ASCL index entries. At this stage these have to commented | ||
% out, and need to be on separate lines. Eventually, they will be automatically uncommented | ||
% and used to generate entries in the ASCL Index at the end of the Proceedings volume. | ||
% The ascl.py command will scan your paper on possible code names. | ||
% Don't leave these in! - replace them with ones relevant to your paper. | ||
%\ooindex{FOOBAR, ascl:1101.010} | ||
|
||
|
||
%figures are included using the following commands: | ||
%\articlefigure{image.eps}{ref-label}{figure caption} | ||
%\articlefiguretwo{image1.eps}{image2.eps}{ref-label}{figure caption for both} | ||
%\articelfigurefour{1.eps}{2.eps}{3.eps}{4.ps}{ref-label}{figure caption for all} | ||
% probably what a '\clearpage' following figure commands | ||
|
||
|
||
\section{Motivation}\label{sec:motivation} | ||
\emph{NorthStar} is dead (technically ``end-of-life'', but that just doesn't have the same ring | ||
to it). | ||
\emph{NorthStar} is the name of a current observation proposal tool used both by the radio and optical | ||
astronomy communities. | ||
It is no longer actively developed or maintained, it is outdated, and in need of replacement. | ||
|
||
The Opticon RadioNet Pilot (ORP) aims to support and develop seamless access to radio and optical, | ||
ground-based astronomy facilities across Europe and the rest of the world. | ||
The ORP attempts to deliver on this aim by developing common standards for observation requests and | ||
specifications, as well as a common framework for data access and processing. | ||
As part of work-package JA2.1 of this pilot we are developing a new open source proposal tool that provides | ||
a single access point for the community to create, edit, and submit observation requests to various astronomy | ||
facilities. | ||
The tool also strives to provide a uniform and useful interface for reviewing and allocating proposals by the | ||
time-allocation-committees (TAC) at the relevant astronomy facilities. | ||
|
||
To avoid the mistakes of the past we set out to develop a proposal tool with a modern, open source philosophy. | ||
To that end, our code base is currently version controlled in a private repository on | ||
GitHub~\footnote{\url{https://github.com/orppst}} that we hope remains active for the foreseeable future. | ||
Our intention is to allow the user community to contribute to the projects, either directly by writing and | ||
editing source code, via feedback in terms of bug-fixes and feature requests, or to fork the projects to | ||
better tailor them to their own needs. | ||
|
||
As a nod to the outgoing proposal tool, and perhaps signifying progress, we are calling this new proposal tool | ||
\emph{Polaris} (\emph{North Star++} felt a bit too ``on-the-nose''). | ||
|
||
We are aware of other such efforts to create observation proposal preparation tools. | ||
Notably, the European Southern Observatory (ESO),and the Square Kilometer Array Observatory (SKAO), | ||
both have their own proposal preparation tools under development.~\footnote{\url{https://www.eso.org/sci/observing/phase1/p1intro.html}}~\footnote{\url{https://developer.skao.int/projects/ska-oso-pht-ui/en/latest/UserIntroduction.html}} | ||
|
||
Our tool is built on top of the International Virtual Observatory Alliance (IVOA) Virtual | ||
Observatory Data Modelling Language (VO-DML). | ||
As such, we are confident that \emph{Polaris} can export and import proposals to and from other tools using | ||
VO-DML as their underpinning data modelling language with minimal manual intervention. | ||
|
||
\section{Architecture}\label{sec:architecture} | ||
|
||
Figure~\ref{architectureFigure} shows a diagram representing the architecture of \emph{Polaris}. | ||
The functionality of the tool is exposed as a RESTful Application Programming Interface (API) in a | ||
microservices architecture deployed on Kubernetes. | ||
The API connects with a Postgres database using the Hibernate query language, and database schemas, generated | ||
from the Proposal Data Model, provide the Java class definitions we can work with when writing the implementation | ||
of the API calls. | ||
|
||
\articlefigure[scale=0.4]{P1-nn_architecture.eps}{architectureFigure}{Polaris microservices that can be run on Kubernetes clusters} | ||
|
||
\clearpage | ||
|
||
We have created a web-based Graphical User Interface (GUI) frontend to access our API that has been | ||
written in Typescript using the React framework. | ||
The TypeScript is transpiled to JavaScript, which calls the REST endpoints defined in the API, and produces the | ||
HTML for the application. | ||
|
||
The GUI accesses the SIMBAD Table Access Protocol (TAP) service as an aid to observational target lookup. | ||
We are also actively developing a command line interface CLI, written in Java, to provide a companion access to | ||
the API. The intention of this CLI is to provide convenient access for administrators to the configurable parts of | ||
Polaris, like the operational details of astronomy facilities. | ||
|
||
Authorisation to the API is done using KeyCloak and an OpenID Connect (OIDC) server. | ||
You can sign-on to \emph{Polaris} using your orcid ID\@. | ||
|
||
|
||
\section{Technologies Used}\label{sec:technologies-used} | ||
|
||
In modern development of ``full stack'' applications, there is an extensive choice in how you set up your | ||
development environment, and how the application is packaged for deployment. | ||
|
||
Let's face it, software developers are lazy beasts. | ||
The less code they have to type the happier, in general, they are. | ||
If code can be automatically generated, with little to no human intervention then we are all for it (looking at you | ||
ChatGPT). | ||
|
||
In this section we discuss the technologies we choose to develop Polaris, bearing in mind this ``lazy'' attitude. | ||
|
||
\subsection{Quarkus: a Kubernetes-native Java framework}\label{subsec:quarkus} | ||
|
||
Quarkus\footnote{\url{https://quarkus.io/}}, a ``Supersonic Subatomic Java'', is designed around a | ||
container-first philosophy to develop applications with low memory usage and fast startup times. | ||
It is an open source project with a large community of developers and contributors, and a vast ecosystem | ||
of extensions and plugins. | ||
|
||
Using Quarkus allows us to concentrate our development effort on the business logic, user experience, and GUI | ||
without having to spend time on much of the underlying boilerplate work. | ||
Combining Quarkus with Kubernetes is relatively seamless and means Polaris can be deployed on any standard | ||
Kubernetes cluster for high resilience and scalability. | ||
|
||
Quarkus comes with a built-in development mode that allows developers to update source, resource, and | ||
configuration files that are then automatically reflected in the running application. | ||
|
||
\subsection{OpenAPI: code generation}\label{subsec:openapi-code-generation} | ||
|
||
OpenApi-codegen\footnote{\url{https://github.com/fabien0102/openapi-codegen}} can automatically generate | ||
the functional components and type schemas from our Java API code to be used in the Typescript GUI\@. | ||
In other words, it creates from our API the ``fetch'' calls to the REST endpoints. | ||
OpenApi-codegen is relatively easy to use and required only a moderate amount of developer effort | ||
required to intervene when it did not do quite the right thing. | ||
|
||
\subsection{Mantine: a React components library}\label{subsec:mantine:-a-react-components-library} | ||
|
||
Mantine\footnote{\url{https://mantine.dev/} - named after a Pok\'emon.} is a React components library that | ||
provides many customisable components and hooks, based in TypeScript, to quickly and easily build accessible | ||
frontend web applications. | ||
It is an open source project that, at time of writing, is actively developed and maintained on GitHub. | ||
We have found Mantine to be an intuitive, comprehensive, well documented, and performant library. | ||
|
||
\section{Future Developments}\label{sec:future-developments} | ||
|
||
Some grand-plan, blue-sky (vomit), ideas go here. | ||
A centralised repository/database of observatories and their instruments/detectors. | ||
A standardised list of global astronomy facilities. | ||
Single-sign on feature or service for astronomy. | ||
|
||
\section{Summary}\label{sec:summary} | ||
In summary, we have created a full-stack, web-based, open source observation proposal tool, \emph{Polaris}, | ||
for intended use within both the radio and optical astronomy communities. | ||
It is our hope that those communities contribute to the development of \emph{Polaris} such that it remains an | ||
active project on GitHub, and continues to mature into the foreseeable future at least. | ||
|
||
\emph{Polaris} will replace \emph{NorthStar} as the de facto observation proposal preparation tool for | ||
the \emph{eMerlin} facility in the near future. | ||
|
||
\acknowledgements This work has received funding from the European Union's Horizon 2020 research and innovation programme, grant agreement No 101004719. | ||
We would also like to acknowledge the individual contributions of Allan Stokes and Michael Ahearn to the development of our frontend GUI\@. | ||
|
||
\bibliography{example} % For BibTex | ||
|
||
% if we have space left, we might add a conference photograph here. Leave commented for now. | ||
% \bookpartphoto[width=1.0\textwidth]{foobar.eps}{FooBar Photo (Photo: Any Photographer)} | ||
|
||
\end{document} |
Oops, something went wrong.