diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..7df6197 --- /dev/null +++ b/404.html @@ -0,0 +1,1033 @@ + + + +
+ + + + + + + + + + + + + + +Polaris is designed to be deployed into a kubernetes cluster
+ + + + + + + + + + + + + ++++ +title = "Polaris REST API" +type = "swagger" +weight = 1 +description = "Reference for the Polaris API" ++++
+{{< swaggerui src="../../../openapi/openapi.yaml" >}}
+ + + + + + + + + + + + + +The proposal tool uses the Proposal Data Model as +its native storage format. The Proposal Data Model is developed in parallel as it is +intended also to be a stand-alone interchange format that can be used to share proposals between different systems.
+The proposal tool is designed as a microservices based architecture +that can run on kubernetes clusters.
+skinparam component {
+ backgroundColor RosyBrown
+}
+actor PI
+actor "TAC Chair" as tac
+[api service] as api
+[cli]
+[gui service] as gui
+[web browser] as web
+[aai system] as aai
+
+database "PostgreSQL" as db {
+ frame ProposalDM
+}
+note as keycloak
+currently using [[ https://www.keycloak.org keycloak]]
+end note
+
+aai .. keycloak
+
+cloud external {
+[identity provider] as idp
+
+[simbad]
+}
+
+tac --> web
+tac --> cli
+PI --> web
+api -down-> db
+gui --> api
+aai --> idp
+gui --> aai
+gui --> simbad
+api --> aai
+web --> gui
+cli --> api
+
+url of cli is [[https://github.com/orppst/pst-cli-app]]
+url of gui is [[https://github.com/orppst/pst-gui]]
+url of api is [[https://github.com/orppst/pst-api-service]]
+url of ProposalDM is [[https://ivoa.github.io/ProposalDM/]]
+
requirements
+Need to clone the following projects in sibling directories
+git clone git@github.com:orppst/build-logic.git
+git clone git@github.com:orppst/pst-lib.git
+git clone git@github.com:orppst/pst-api-service.git
+git clone https://github.com/orppst/pst-gui
+
The following are the actors and high level use cases for the proposal tool.
+left to right direction
+title High Level use cases for the Proposal Tool
+actor :System Administrator: as sysadmin
+actor :AAI User: as user
+actor :Observatory Admin: as obsadmin
+actor :TAC member: as tacmem
+actor :TAC Chair: as tacchair
+actor :Reviewer: as rev
+actor :CO I : as coi
+actor :Principal Investigator: as pi
+usecase "deploy the system" as UC0
+usecase "user registers to system" as UC1
+usecase "create observatory admin" as UC2
+usecase "configure observatory" as UC3
+usecase "create new proposal cycle" as UC4
+usecase "create observing proposal" as UC5
+usecase "edit observing proposal" as UC6
+usecase "submit a proposal" as UC7
+usecase "create TAC Chair" as UC8
+usecase "add TAC members" as UC9
+usecase "review proposals" as UC10
+usecase "score proposals" as UC11
+usecase "assign observing time" as UC12
+usecase "inform PIs about allocation" as UC13
+usecase "export whole proposal" as UC14
+usecase "import whole proposal" as UC15
+sysadmin --> UC0
+sysadmin --> UC2
+user --> UC1
+obsadmin --> UC3
+obsadmin --> UC4
+user ..>pi
+user ..>coi
+user ..>tacmem
+user ..>obsadmin
+tacmem ..>rev
+tacmem ..>tacchair
+pi-->UC5
+coi-->UC6
+pi-->UC6
+pi-->UC7
+pi-->UC14
+pi--> UC15
+obsadmin-->UC8
+tacchair-->UC9
+tacchair-->UC10
+tacchair-->UC12
+tacchair-->UC13
+rev-->UC10
+rev-->UC11
+
The following use cases occur in rough chronological order of configuring and using the Proposal tool.
+In deploying the system a special user that is the system administrator is created - this user's authentication is managed locally +rather than using the AAI and has full access to the system.
+All other users should go through the AAI mechanisms on initial creation
+the system administrator configures initial supported observatory object(s) and assigns an already registered user (or users) +to be the observatory administrators
+observatory administrators have the permission to be able to more fully configure observatories - e.g. add telescopes and instruments
+the observatory administrators can assign someone to be the time allocation committee chair for the observatory
+The TAC chair would then create Proposal Cycle
+A PI will create an observing proposal and invite CO-Is
+PIs and CO-Is can edit an observing proposal
+When the proposal is complete the PI can formally submit the proposal
+The TAC Chair can add existing users to the TAC
+The proposals can be distributed to the TAC - this might
+There might be a scoring system that allows people outside the TAC to score as well.
+The TAC assigns observing time to the highest scoring proposals
+the proposal could be exported in several forms
+Functions available to observatory administrators
+ + + + + + + + + + + + + +A fresh proposal will have no Targets added, and you will be presented with the following page:
+ +To add a Target click the Add + button, which will bring up the New Target form.
+ +In the screenshot you will see we have added the Aladin Lite Sky Atlas, +and we have found the Crab Nebula using the Lookup function. This fills in the corresponding +positional and coordinate system data for the named target, and displays the target in the Sky Atlas. +Notice that the backend uses Simbad to search for the named target, such that the name must +exist in their databases to be successful; an appropriate error notification is displayed if the +named target cannot be found.
+You may also simply click anywhere on the Sky Atlas and the corresponding positional details will be +updated in the RA and DEC fields (notice that these are currently displayed as degrees only, we have +development plans to add HH:MM:SS format and to allow you to select between the units with which you +are most comfortable).
+You can also manually fill in the fields, the Sky Atlas will automatically change the view to those +coordinates. Notice that in this alpha version of Polaris, you can have any coordinate system you like, +so long as it's J2000.
+You may also change the name of the target after you have looked it up and before you save it as a +Target. To save, click the Save button. This will return you to the Targets tab of your proposal +now displaying the Target you just saved, and any other targets you may have added.
+ +Please notice that the Reference System should read ICRS but due to some bug that has yet to be +squished it reads unknown; did I mention this was the alpha version?
+You may Delete this target if you so wish, just remember that you need at least one target in order +to build an Observation for your proposal.
+If you haven't already added a Technical Goal then please follow the guide here. +If you have now added at least one Target and one Technical Goal to your proposal then please +follow the link to Building Observations.
+ + + + + + + + + + + + + +A fresh proposal will have no Technical Goals and you will be presented with the following page:
+ +To add a Technical Goal click the Add + button, which will bring up the New Technical Goal form.
+ +In the screenshot you can see we have filled out the Performance Parameters with some values and their +corresponding units; the values in the screenshot are contrived for this guide. The units are selected via a +drop-down menu. These values are what you would like the observation to achieve, and are not necessarily strict +requirements. Further explanation of each field can be found here (to-do). The Performance Parameters +are the minimum amount of information required to Save (screenshot reads Submit because alpha version) a +Technical Goal. For now, we ignore the Spectral Window aspect of a Technical Goal, to be revisited later.
+After clicking Save you will be brought back to the technical goals summary page, which should now display your +newly added Technical Goal.
+ +Unlike Targets, you can also Edit and Copy Technical Goals as well as Delete them. This allows you +to change the attributes of an existing Technical Goal, or quickly add other Technical Goals that may have +similar Performance Parameters and/or Spectral Windows without having to re-input all the data.
+If you haven't already added a Target then please follow the guide here. +If you have now added at least one Target and one Technical Goal to your proposal then please follow the +link to Building Observations.
+ + + + + + + + + + + + + + + + +After adding at least one Target and at least one Technical Goal you will see the following summary page +for Observations, which will be empty.
+ +To build an Observation click the Add + button, which will bring up the new observation form.
+ +In this screenshot we have already selected our Target, the "crab", and our Technical Goal, and have +selected the Observation Type as Calibration and the Calibration intended use as Pointing. Notice that +the Observation Type is a choice between Target and Calibration, and if you select Target there is no +"intended use" field; the Target is the intention of the Observation. For a Calibration Observation +there are several "intended use" options to pick from; see the documentation (to-do) for details.
+Selecting the Target, Technical Goal, and Observation Type is the minimum amount of information to Save +an Observation to the database. However, for the Proposal to pass the server side validation before +submission, all Observations in the Proposal must have at least one Timing Window.
+A Timing Window is a timing constraint on the Observation, and consists of start and end times that +can be specified up to the minutes unit, an avoid toggle switch that changes the meaning of the window, to be +explained presently, and an optional note to provide additional information if required. Typically, a +Timing Window will specify the range of times when the Observation should be performed i.e., the avoid +toggle is unset. However, with the avoid toggle set the window then specifies the range of times when the +Observation should not be performed.
+You can add as many Timing Windows to an Observation as required by your needs. Please note that the +start time must be at an earlier time than the end time, but that different Timing Windows may overlap. +In this case, it is recommended to write optional notes to provide context for anyone reviewing your proposal. +Notice that we assume all times are entered as UTC.
+With all that information entered, click Save to save the Observation to your Proposal. This will +bring you back to the Observations summary page, that will now contain your newly built Observation.
+ +As with Technical Goals you may Edit and Copy Observations to avoid having to repeat data entry for +Observations that have similar attributes. For example, using the same Target but for different types, +Target or Calibration, of Observation with perhaps the same Technical Goal and/or timing constraints.
+With an Observation now built both the Target and the Technical Goal to which is refers have their +Delete button disabled. This prevents you from deleting either of these things while they are actively pointed +to by an Observation. In order to re-enable the Delete button on Targets and Technical Goals you +must first delete all Observations that refer to them.
+In this alpha version of Polaris, once you have an Observation with at least one Timing Window in your +Proposal it will pass server side validation checks, and you may submit it for review. In subsequent versions, +you will also have to provide both Scientific and Technical Justifications to pass validation checks, and +it is likely more things will be added to the validation check in the future.
+To see how to submit your proposal for review please follow the guide at +Submitting Proposals
+ + + + + + + + + + + + + +If you haven't registered with and logged-in to Polaris please do so now.
+This will bring up the new Proposal details form.
+The basic details of an Observing Proposal are the title, a brief summary, and the Kind of your proposal +either STANDARD, SURVEY, or T.O.O. (target-of-opportunity). These attributes can be changed after you create +the proposal.
+Now that you have a created a new proposal you can see its Overview by clicking the dropdown +menu for the relevant proposal in the navigation pane on the left, and clicking on the Overview +tab.
+ +In the screenshot example we have given our proposal the title An awesome proposal title, filled +in the summary with a very brief summary (literally), and assigned it a Kind of STANDARD. Notice +that, as the creator of the new proposal, you will have been automatically assigned the PI, or +Principal Investigator, role for the proposal (in the example we used for the screenshots, the +username is also PI; nobody said we had to be inventive).
+If you now try to go to the Observations tab you will be presented with the following page:
+ +In the Polaris app you must first add at least one observational Target and at least one Technical +Goal before you can generate an Observation for your proposal. Notice that the yellow text in the +screenshot is a link to take you to the corresponding page in the App.
+For the next steps in this guide, please follow either the Adding Targets link or the Adding Technical Goals +link, the order here does not matter. The Building Observations page assumes you have added at least one target +and at least one technical goal to your proposal.
+ + + + + + + + + + + + + +Please be aware that the submission functionality of Polaris is under active development such that this page +may very well be out-of-date. Please bear with us while we get around to updating this page.
+Last updated 2024-03-06 Polaris alpha version.
+Once you are happy with the details of your Proposal, and it has passed the server side validation checks +you may submit it for review.
+ +You will have to select the Proposal Cycle from the drop-down menu to which you wish to submit your Proposal. +Once selected the page will display the submission deadline for that cycle.
+Server side validation checks currently include:
+As we develop the server side validation checks this list will grow. For example, we'd expect that a Proposal +must have a Scientific Justification and a Technical Justification to be valid for review. Indeed, we +expect this list to expand significantly as we put Polaris in to beta-testing.
+If a Proposal doesn't pass the validation checks then you will be presented with the following page for the +Submit tab of your proposal, which lists the problems.
+ +Here we have created another proposal but haven't added any Targets, Technical Goals, or Observations.
+ + + + + + + + + + + + + +Observers will mostly interact with Polaris via the web based GUI
+There is also a Front end CLI under development which will offer a way of manipulating proposals via scripting.
+ + + + + + + + + + + + + +Functions available to the Time Allocation Committee (TAC)
+ + + + + + + + + + + + + +{"use strict";/*!
+ * escape-html
+ * Copyright(c) 2012-2013 TJ Holowaychuk
+ * Copyright(c) 2015 Andreas Lubbe
+ * Copyright(c) 2015 Tiancheng "Timothy" Gu
+ * MIT Licensed
+ */var Va=/["'&<>]/;qn.exports=za;function za(e){var t=""+e,r=Va.exec(t);if(!r)return t;var o,n="",i=0,s=0;for(i=r.index;i