Autofill Issues

Last Updated:  01/21/2004 02:18 PM

Priority Key:

  1. Needs to be fixed before user testing.
  2. Needs to be fixed before final phase 2 testing.
  3. Nice to have fixed before final phase 2 testing.
  4. Not important enough to worry about.

 

Number

Priority

Status

Issue
1 1 RTT (T)

Tested

 Comments in PR 46888 regarding selectability of WAVECALs
2 3.5 Assigned (T)

May not be reproducible

 When trying to auto-adjust a STIS TIME-TAG exposure that had been automatically shrunk by TRANS, I got an error saying that the visit could not be adjusted.  I was then locked from selecting the exposure for auto-adjusting.  It also appears that there was something in the actual duration field (although not visible in APT), as when I edited the field, then cleared it out, I was able to select the exposure again.
3 1

Tested (R&C)

 When you have an orbit with 1 exposure that is not auto-adjustable and 1 (or more) that is adjustable, and you adjust the adjustable exposure, the actual duration field gets populated for the unadjustible exposure, and you get a red X.  This should not happen.  An example is a STIS orbit with a target acquisition (not adjustable) and a science exposure (adjustable).
4 2 RTT (B)

Tested

 Visits with SHADOW and LOW SKY on the visits actually shorten exposure length when an exposure is selected for auto-adjustment.

Visits with SHADOW, LOW SKY or AFTER BY will not be adjusted.
5 4 APT Threading Issue - On Hold until it happens too often. When I try to Clear Auto Adjustments I get this long purple vertical bar on the exposure in the left menu side. And nothing happens... well trans-apt runs but the exposure doesn't get cleared.
6 4 RTT (B)

NICACCUMS withdrawn

 I've got a NIC visit with 5 exposures. No shadow, sky, etc. I started with 1308s of unused visibility, I autoadjusted exp 4 and then had 54s, I autoadjusted exp 3 and then had 32s, I then autoadjusted exp 4 and was up to 114s of unused visibility.  Thought it was interesting that the number went up, but perhaps that's within the expected amount. I'd have thought it would just not go down further.
7 2 Assigned (T/B)

closed due to #4

 I have two exposures with AFTER BY 600 S on the 2nd one.  If you try to autoadjust the first exposure, either nothing happens or the first exposure shortens.  If you try to autoadjust both the exposures, either nothing happens or the first exposure shortens.  If you try to autoadjust the second exposure, it adjusts to fill the orbit.

The either|or depends on what happened previously. I've gotten both behaviors when I've been fairly sure I've started from a 'cleared all adjustments' state.
8 2 RTT (T)

Tested

 Exposures in a CVZ visit that could potentially be adjusted do have the <-> on them. Autoadjust didn't seem to change anything.
9 4 Assigned (T)

On Hold until reproduced

 I noticed that the little green box only appears on the PC.  It is not there in the Solaris, eventhough the Auto-adjust button is there and works fine.
10 2 On Hold until reproducible I had a situation where there was a visibility overrun by a certain amount of time.  Then I did auto-adjustment, the overrun went away.  Then I cleared adjustment.  The visibility overrun came back with a different amount of time.

Is this OK ?

I am trying to reproduce that case and not able to.
11 2, for remainder of work Assigned (B)

Will prioritize parallel issues after Ron tests them.

RTT for single layer only - more complete fix to come

Close in lieu of other

 I have a new debug-auto image with better support for parallel adjustment.  In general, this will do the logical thing.  That is, it will expand out parallels to fill the available parallel time when they are selected. 

It will also shrink parallels when they extend the primary's alignment time.  One thing it *won't* do is extend a primary when the parallel is too long (even if only the primary is selected).  These two desires are sort of conflicting.  We might want to make a decision about what to do in this case consistently.

Another problem is that when shrinking a parallel set, it will usually shrink too much.  I know why this is occurring, I'll look into fixing it.

It needs some work to be faster for multiple orbit visits.
12 1 Assigned (T/B)

 

Priority 1 to investigate only.  then we can reprioritze.

Analyzed by Brian - no actual bugs

 Start with my proposal 8464 (attached)

Visit 01
Ran Orbit Planner - all's well - none of the exposures can be auto-adjusted.  Exposure 10 is HRC with 3 iterations. 

Then I changed Exposure 10 to be WFC with only 1 iteration.  Went to Orbit Planner.  The display now has the 3 copies as adjustable.  This is misleading since I have not Updated Display. 

Then I clicked on Auto-adjust to see what would happen.  The exposures were NOT adjusted but the display was updated to the two CR-SPLIT copies of the WFC exposure which is now really auto-adjustable.

Clicked on Auto-adjust.  Nothing happened. 

I made a new visit and copied this exposure on to the new visit.  I am able to Auto-adjust.

Went back to visit 01.  Changed Exp 20 to be WFC.  Updated display.  There was a visibility overrun by 917 seconds.  Selected Visit 01.  Clicked on Auto-adjust.  I didn't see any lengthening of the exposures 10 or 20.  But now the visibility overrun was 944 seconds.

Strange.  At this point Auto-adjust and Clear Adjustments are NOT working at all.
13 1 RTT(B)

Tested(R)

 Trans error popups in Rons WFPC2 test proposal:

Visit 1
- if I select any subexposure, I get a TRANS error popup on autofill

Visit 2
- EARTH-CALIB is not autofillable (OK)
- if I try and autofill, I get a TRANS error popup

Visit 4
- all internals not autofillable (OK)
- one science exposure is autofillable (OK)
- if I select any subexposure, or if I select no subexposures, I get a
  TRANS error popup
14 1 RTT(T)

Tested

 From Ron's ACS test proposal, tooltip and actual duration field different (Visit 1).
15 3 Assigned (T) On COS TIME-TAGs with FP-POS=AUTO, have the icon for adjustment on the first split but not on the remaining 3. What is expected here?
16 3 Assigned (T/B)

Would be nice if this i/f worked, but more important for trans ops testing to pass.

 When fitMode=PC in OrbitPlanner.prop, no adjustments occur.
17 2 Assigned (T) Should we require "-mode STScI" anymore?

No.
18 4 RTT(T)

Tested

 From Ron's NIC test proposal, tooltip and actual duration differ (Visit 1).
19 4 Assigned (T/B)

Withdraw

 From Ron's NIC test proposal, actual duration changes between 1st and 2nd autofills (Visit 1).
20 2 Assigned (B)

RTT - not in frozen version; also see PR 50002

Tested (C)

 I've got a WFPC2 exposure with CR-SPLIT followed by a NIC exposure.

Originally they're in one orbit with 965s of unused visibility.  I autoadjust both splits of the WFPC2 exposure and they bump the NIC exposure into the next orbit.

If you adjust just the second split of the WFPC2 exposure the NIC gets bumped into the next orbit. But if you adjust only the first split of the WFPC2 exopsure they all pack nicely in the one orbit.

(/data/mimir2/autofill/223.xml visit 1)
21 1 Assigned (B)

RTT

Tested

 From Ron's STIS test proposal, ACQ/PEAK are adjusted by autofill (Visit 1)
22 1 Assigned (B)

RTT

Tested

 From Ron's STIS test proposal, when ACQ/PEAK adjusted, autofill does not work correctly (Visit 1)
23 1 Assigned (B)

RTT

Tested

 From Ron's STIS test proposal, when ACQ/PEAK adjusted, BIAS in orbit 3 is moved to orbit 2 (Visit 1)
24 2 Assigned (B)

Closed with popup diag

 From Ron's STIS test proposal, when an orbit has an overfill, if you do not autofill with that orbit, nothing happens (Visit 2)

open requirements issues for this and next one
25 2 Assigned (B)

Closed (R)

 From Ron's STIS test proposal, when autofill an orbit with TIMETAG that has been shrunk by TRANS, an extra autowavecal is added (Visit 3)

Brian investigated and presented 2 options:

So the real issue is our policy about adding wavecals.  Which of the
following two options do we think is more useful/less confusing?

1. Never allow new wavecals to be created, and thus leave the
possibility that an orbit will not be expanded fully.

2. Allow new wavecals to be created that don't cause overfills, and
expand fully.

2 is what we currently do, and I think that is more useful and less
confusing.
26 2 Assigned (B)

RTT - not in frozen version; also see PR 50002

 Additional example of exps switching orbits during autofill:

I have a WFPC2 science exposure, followed by 6 internals.  I specify orbit 1 for all exposures.  I then autofill, and the science exposure completely fills the orbit.  There are 4 internals in occulation for orbit 1, then 2 internals in orbit 2.  This is a bizarre case, so in and of itself, I am not worried.  But this may be another clue to the moving exposure syndrome seen in STIS and NICMOS.
27 1 Assigned (T/B)

PR 50079 to be merged with autofill branch

 I have the latest (Dec 08) APT.

I started with an ACS/WFC exposure with exposure time 1000.0.  This is auto-adjustable.  Then I set PAREXP=MULTIPLE - little green boxes went away but the auto-parallels are not there.

The reverse is fine.  If I first set PAREXP=MULTIPLE, the auto-parallels are there (no green boxes - good).  Then I change the PAREXP to none selected or DEF or NONE.  The green boxes come back.

There are other misbehaviors which seem to go away if I delete the visit and start fresh.  But this problem persists.

I went and set CR-SPLIT = NO.  Updated display. The auto-parallel was correctly there.  Then I went and changed CR-SPLIT to none selected.  The autoparallels are fine now.

I did update display each time.  I guess I didn't explicitly mention this in my email.

I have noticed that when you change optional parameters and then go to Orbit Planner, before clicking on Update Display you will see strange things !!

I checked HRC and it is fine.  I am working on my PC with Dec 08th image.  I am going to try all this out on my Solaris with the Dec 10th image.
28 1 RTT (T)

Tested

 Change button to Clear All AA's
29 2 RTT (T/B)

Tested

 Remove NIC ACCUM's from adjustable list in PI mode.  Brian will investigate PC mode.
30 2 RTT (T)

Tested

 Pop-up a warning message when auto-adjusts are attempted on visits with CVZ, LOW SKY, SHADOW, AFTER BY, impossible-to-shrink overfilled orbits, non-consecutive orbit numbers, and all visits in SNAP proposals.
31 2 RTT (T)

Tested

 For exposures that don't have the adjustable icon, add to the tooltip an explanation of why it's not adjustable.
32 2 for remainder of work. Assigned (B)

RTT (B) for single layer only - more complete fix to come

Issue 1 is RTT 1/20/04.  Issue 2 will not be addressed.

Tested (R)

Assigned (L)

 From Lalitha's parallel testing prop 9999:

Visit 01:  Auto adjust of entire visit does nothing.  I am
able to adjust the STIS exposure (primary without the
wavecal) by itself.  I am not able to adjust either of the
HRC parallel split copies.  I tried with CR-SPLIT=NO.  Not
able to adjust.  These are claimed to be adjustable with the
green boxes.  I changed the config to be WFC.  Now I can
adjust the entire visit.  But not the parallel exposures
(ofcourse I have first adjusted the primary).

Visit 02: 

I am able to auto adjust the entire visit. 
Not able to adjust Parallel by itself (of I have first
adjusted the primary)

Visit 03:

I am able to auto adjust the entire visit.

I am able to auto adjust the primary first and then the
parallel.

Visit 04:

I am able to auto adjust the entire visit.

I am able to auto adjust the primary alone by selecting on
the item from the left hand side frame.  But if I select the
auto-adjustable exposure by itself without the wavecal in the
Orbit Planner display, I am getting the pop-up message:

Orbit Planner server failed to adjust visit.  Please check
legality of proposal and try again.

In all cases I am not able to adjust the parallel alone first
(this is probably how it should be since we don't want the
parallel to be longer than the primary).

Brian identified two issues:

1.  The overhead after wfpc2 exposures is accounted for incorrectly in
the "PARALLELS SIGNIFICANTLY EXTEND ALIGNMENT TIME" diagnostic.  The
overhead normally occurs at the end of the orbit and could be placed in
occultation.  However, the diagnostic will be triggered if this overhead
is in occultation, because it think it's making the alignment too long.
It is, but it's not taking up visibility, so this shouldn't matter.
Auto adjust won't allow any new diagnostic to occur, so wfpc2 parallels
will always have this overhead in visibility.  Plus, this will prevent
other parallel exposures from fitting optimally, because the auto adjust
diagnostic checker doesn't know which layer is causing the diagnostic,
so it shrinks all the parallel layers until the diagnostic goes away.

Currently there's no way to get auto adjust to put the parallel wfpc2
overhead in occultation.  However, if you find that other parallel
layers are underfilled due to this problem, you can select those
exposures and run auto adjust again (which won't take nearly as long as
it did the first time).

2. Various complications with serial/parallel buffer dumps and gaps in
parallel exposure time. 

I think #1 is relatively easy to fix, but I think we'll need to go
through the regular Trans OPR process in changing the definition of the
diagnostic. 

Issue #2 is harder.  I would need to significantly increase the
intelligence of auto adjust, and I'm not sure if the problem occurs
often enough to be worth the effort.
33   On hold for more user comments. From usability testing:

The only thing which I found counterintuitive is that when "Clear All Auto-Adjustments" is pressed, the display is not updated automatically. Given that when one presses "Auto-Adjust" this is done automatically, that both buttons are on the same level, and that one reverses the action of the other, one expects the same type of behavior.
34     Use PR system for all real issues from now on.