Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 07 08:40
    sraaphorst commented #1618
  • Jan 07 00:50
    andrewwstephens opened #1618
  • Jan 06 02:28
    andrewwstephens closed #1617
  • Dec 30 2018 21:36
    andrewwstephens synchronize #1617
  • Dec 30 2018 21:34
    andrewwstephens opened #1617
  • Dec 20 2018 14:24

    sraaphorst on 2019A.1.1.2

    (compare)

  • Dec 17 2018 20:00

    sraaphorst on develop

    REL-3569: Fixed issue with base… Merge pull request #1616 from s… (compare)

  • Dec 17 2018 20:00
    sraaphorst closed #1616
  • Dec 17 2018 19:21
    sraaphorst opened #1616
  • Dec 10 2018 20:26

    sraaphorst on 2019A.1.1.1

    (compare)

  • Dec 10 2018 20:25

    sraaphorst on ocs-2019A

    (compare)

  • Dec 10 2018 14:22

    swalker2m on develop

    REL-3550: use CWFS3 to evaluate… (compare)

  • Dec 10 2018 14:22
    swalker2m closed #1615
  • Dec 10 2018 13:35
    swalker2m opened #1615
  • Dec 04 2018 13:46

    sraaphorst on develop

    REL-3563: Update Altair default… Merge pull request #1614 from s… (compare)

  • Dec 04 2018 13:46
    sraaphorst closed #1614
  • Dec 04 2018 12:52
    sraaphorst edited #1614
  • Dec 04 2018 12:51
    sraaphorst opened #1614
  • Nov 30 2018 14:25

    sraaphorst on develop

    REL-3552: Trying to get PIT to … Merge pull request #1613 from s… (compare)

  • Nov 30 2018 14:25
    sraaphorst closed #1613
Rob Norris
@tpolecat
but of course if there are other changes that really do need to be reflected in the XML then it's a problem
Shane Walker
@swalker2m
well now the proper motion stuff is, or will be, meaningful. won’t that need to appear in the XML?
Carlos Quiroz
@cquiroz
What do you mean by meaningful?
It isn’t now?
Shane Walker
@swalker2m
at least in the OCS code, we don’t currently use it to correct coordinates
Carlos Quiroz
@cquiroz
ok
Rob Norris
@tpolecat
yeah we're not doing anything new with proper motion
we will but not right away
Shane Walker
@swalker2m
the PIT model has ProperMotion but it is missing the epoch (as you noted) and parallax and radial velocity. i suppose those could be defaulted on import/export
Rob Norris
@tpolecat
yeah that's something that would affect the xml for sure
if we couldn't default them
@andrewwstephens said any movement since 2000 would likely be on the order of 1.5" which would only have an effect on guidestars near the edge of the field
if i understood him correctly. it did not seem to be an urgent thing to have PM corrections in OCS
although we do send them to the TCS
andrewwstephens
@andrewwstephens
Fun Fact: Barnard's star (HIP 87937) has the highest proper motion: 10357 mas/yr. Thus this star has moved 155 arcseconds (2.5 arcmin) since 2000.
Arturo Nunez
@arturog8m
I think making changes to ITAC this time around needs to be done conservatively; as Carlos will be gone for a while starting in August. So I think it makes sense to NOT mess around with it now, and use the available time to move forward on the Catalog work. Once that is done, regroup and attack the ITAC issue
so one consequence of it is that PIT might not be able to be fully integrated with the new target model in September - we need to be prepared for that.
Shane Walker
@swalker2m
As long as we can still read a P1 target and produce a reasonable core target I think we’ll be okay. That conversion will have to happen in the skeleton creation code. The template targets will be missing the extra PM information which is a bit unfortunate though.
Carlos Quiroz
@cquiroz
I propose that in the short term I complete the port of Magnitudes (Basically integrating that part to ITAC + testing)
And we leave Coordinates/Targets for later
Arturo Nunez
@arturog8m
I agree. Later might be outside of the OCSADV project, but I don’t see a problem with that
@andrewwstephens maybe we can talk about this on Monday
Rob Norris
@tpolecat
@andrewwstephens can we do a parallax computation to convert a GN RA/Dec to GS, and vice-versa? Or do we really need to re-fetch the ephemeris from horizons?
It amazes me that this isn't already accounted for, somehow.
Shane Walker
@swalker2m
Seems like it will depend on the object’s distance from the earth.
Rob Norris
@tpolecat
mm, right
andrewwstephens
@andrewwstephens
Unfortunately I think we would need to re-query Horizons if we move an observation from one site to another.
Rob Norris
@tpolecat
ok
Shane Walker
@swalker2m
@/all I put together some notes produced from thinking about the sequence model updates and a couple of conversations with Rob. It’s quite rough but I’d be quite interested in how far off the mark this is. https://github.com/gemini-hlsw/ocs/wiki/Sequence-Model-Goals
Rob Norris
@tpolecat
the single-sequence case seems straightforward, although (as we discussed) i'm concerned about the mechanics of client/server synchronization
if we're sending the whole thing back and forth then the total transfer size is going to be pretty big
and the business with the live editor and swapping partial edits (as we do with the obslog now) is kind of tricky
Rob Norris
@tpolecat
what if the user-editable obslog were a distinct structure?
Map[Dsid, QaInfo] or something, to avoid having the local one overwritten
Shane Walker
@swalker2m
i think by separating the server-updating bits from the user-editable bits in distinct nodes it might be okay. also we can certainly store a compact version of the sequence, storing only the bits that differ across the steps
Rob Norris
@tpolecat
oh so it's compressed internally but the external representation just looks like a List[Step]
yeah, ok
Shane Walker
@swalker2m
right
andrewwstephens
@andrewwstephens
? The idea is that each observation would include: one Target node, one Observing Conditions node, one Obslog node (as seen by the user), one or more Acquisition Sequences, one or more Science Sequences, and one or more daytime calibration Sequences (arcs, flats, darks, biases, etc) ? Where is the static instrument configuration defined ?
The most common "OR" relation is between standard stars, e.g. observe standard A or standard B, so I think we will still need logical relations between observations.
Shane Walker
@swalker2m
The idea is to combine the instrument, obslog, and sequence in one node as seen by the user. Then eventually to allow multiple instances of this node for different types of sequences as you say (e.g., acq, science, cal).
All the instrument properties could be defined when you click on a step in the sequence planning table. The truly static properties like the position angle should probably be presented differently so it is clear which ones apply to all steps. At one point I had these separated out but it seemed unnecessarily awkward to go to two different places to edit the instrument config. On the other hand, if they are always the same across all sequences then maybe they should be separated out.
Shane Walker
@swalker2m
I added an alternative idea for the sequence node UI that combines the log, execution and planning sections into a single table-like view.
Javier Lührs
@jluhrs
I found this page that some of you may find useful to learn more about ScalaZ: http://eed3si9n.com/learning-scalaz/index.html
Javier Lührs
@jluhrs
I plan to merge gemini-hlsw/ocs#499 today if there are no more comments.
Rob Norris
@tpolecat
oh i didn't see that you had made a change, sorry
i will look at it some more today
Rob Norris
@tpolecat
@jluhrs i'm going to make a PR to your branch to fix a few things. there are some side-effects we can squash to make ExecutorImpl pure
Later today. Sorry i didn't see your update. In the future it's helpful to make a comment like "ok i updated that thing" so watchers will get notified.
Javier Lührs
@jluhrs
@tpolecat Ok.