8000 Set interrupt_loads to shorten timelines only as short as zero length by jeanconn · Pull Request #61 · sot/chandra_cmd_states · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Sep 19, 2024. It is now read-only.

Set interrupt_loads to shorten timelines only as short as zero length #61

Merged
merged 1 commit into from
Sep 28, 2020
Merged

Set interrupt_loads to shorten timelines only as short as zero length #61

merged 1 commit into from
Sep 28, 2020

Conversation

jeanconn
Copy link
Contributor

Description

Set interrupt_loads to shorten timelines only as short as zero length. This sets the timelines to not have negative duration.
This should prevent recurrence of sot/timelines#24 without any side-effects.

Testing

  • Passes unit tests on linux (though those aren't really comprehensive tests)
  • Functional testing

I tested just with sqlite and confirmed expected datestop values by eye, with an interrupt time set to '2020:266:14:48:29.000' in full interrupt and observing_only modes.

Current real database

sqlite> select * from timelines where datestart > '2020:260';
426104399|426104272|/2020/SEP1220/oflsa/|2020:261:23:14:59.959|2020:264:06:44:08.275|0|0|0
426104400|426104273|/2020/SEP1220/oflsa/|2020:261:23:14:59.959|2020:264:06:44:08.275|0|0|0
426104401|426104274|/2020/SEP2120/oflsa/|2020:264:06:42:00.000|2020:267:05:04:01.816|0|0|0
426104402|426104275|/2020/SEP2120/oflsa/|2020:264:06:42:00.000|2020:267:05:04:01.816|0|0|0
426104403|426104276|/2020/SEP2120/oflsa/|2020:267:05:46:01.272|2020:270:03:15:02.313|0|0|0
426104404|426104277|/2020/SEP2120/oflsa/|2020:267:05:46:01.272|2020:270:03:15:02.313|0|0|0
426104405|426104278|/2020/SEP2120/oflsa/|2020:270:08:32:29.334|2020:272:05:01:47.549|0|0|0
426104406|426104279|/2020/SEP2120/oflsa/|2020:270:08:32:29.334|2020:272:05:01:47.549|0|0|0


Doing a full interrupt

sqlite> select * from timelines where datestart > '2020:260';
426104399|426104272|/2020/SEP1220/oflsa/|2020:261:23:14:59.959|2020:264:06:44:08.275|0|0|0
426104400|426104273|/2020/SEP1220/oflsa/|2020:261:23:14:59.959|2020:264:06:44:08.275|0|0|0
426104401|426104274|/2020/SEP2120/oflsa/|2020:264:06:42:00.000|2020:266:14:48:29.000|0|0|0
426104402|426104275|/2020/SEP2120/oflsa/|2020:264:06:42:00.000|2020:266:14:48:29.000|0|0|0
426104403|426104276|/2020/SEP2120/oflsa/|2020:267:05:46:01.272|2020:267:05:46:01.272|0|0|0
426104404|426104277|/2020/SEP2120/oflsa/|2020:267:05:46:01.272|2020:267:05:46:01.272|0|0|0
426104405|426104278|/2020/SEP2120/oflsa/|2020:270:08:32:29.334|2020:270:08:32:29.334|0|0|0
426104406|426104279|/2020/SEP2120/oflsa/|2020:270:08:32:29.334|2020:270:08:32:29.334|0|0|0

Observing-only

sqlite> select * from timelines where datestart > '2020:260';
426104399|426104272|/2020/SEP1220/oflsa/|2020:261:23:14:59.959|2020:264:06:44:08.275|0|0|0
426104400|426104273|/2020/SEP1220/oflsa/|2020:261:23:14:59.959|2020:264:06:44:08.275|0|0|0
426104401|426104274|/2020/SEP2120/oflsa/|2020:264:06:42:00.000|2020:267:05:04:01.816|0|0|0
426104402|426104275|/2020/SEP2120/oflsa/|2020:264:06:42:00.000|2020:266:14:48:29.000|0|0|0
426104403|426104276|/2020/SEP2120/oflsa/|2020:267:05:46:01.272|2020:270:03:15:02.313|0|0|0
426104404|426104277|/2020/SEP2120/oflsa/|2020:267:05:46:01.272|2020:267:05:46:01.272|0|0|0
426104405|426104278|/2020/SEP2120/oflsa/|2020:270:08:32:29.334|2020:272:05:01:47.549|0|0|0
426104406|426104279|/2020/SEP2120/oflsa/|2020:270:08:32:29.334|2020:270:08:32:29.334|0|0|0

Fixes sot/timelines#24

@jeanconn
Copy link
Contributor Author

Are we thinking about backports to ska2? I suppose I also need to test and update the scs107 directions to use ska3 (whinch may be shiny... not sure about our promotion plan).

@jeanconn jeanconn requested a review from taldcroft September 22, 2020 15:13
taldcroft
taldcroft approved these changes Sep 28, 2020
View reviewed changes
Copy link
Member
@taldcroft taldcroft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I generally prefer the Python ternary syntax for a case like this but either way is OK.

@jeanconn
Copy link
Contributor Author

Good point about the ternary. I think here I don't mind seeing more lines of code because it does deserve a bit of attention.

@jeanconn jeanconn merged commit 37a2926 into master Sep 28, 2020
@jeanconn jeanconn deleted the to_zero_length branch September 28, 2020 14:52
@jeanconn jeanconn mentioned this pull request Sep 28, 2020
Merged
2 tasks
@javierggt javierggt mentioned this pull request Nov 17, 2020
Merged
@javierggt javierggt mentioned this pull request Dec 7, 2020
Merged
@taldcroft
Copy link
Member
taldcroft commented Oct 23, 2021 •
edited
Loading

This should prevent recurrence of sot/timelines#24 without any side-effects.

Not completely without any side effects. 😄

Kadi.commands uses the following to select commands within timeline segments:

        # Only store commands for this timeline (match SCS and date)
        bs_cmds = [x for x in bs_cmds
                   if tl['datestart'] <= x['date'] <= tl['datestop']
                   and x['scs'] == tl['scs']]

So if there is a command that is exactly at tl['datestart'] and tl['datestop'] then it gets accepted. This happens for some AOACRSTD in real life (e.g. the 2021:296 NSM interrupt).

Question: is the datestop supposed to be inclusive? Should I write if tl['datestart'] <= x['date'] < tl['datestop'] or should we clip datestop (for an interrupt) to 1 ms earlier?

ANSWER: Yes, it is inclusive (from examining some loads and the corresponding timelines). So we may need to clip to 1 ms earlier.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@taldcroft taldcroft taldcroft approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

truncated timeline via SCS107 can result in extra/wrong timeline inserted in DB
2 participants
@jeanconn @taldcroft
0