Import Issues

Last updated:  03/02/2004 05:56 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.

Category Color Key:    

<APT/PP problem>  <Discuss>  <Importer problem or unknown>

Number

Priority

Status

From

Issue

1 2 RTT - descriptions should work for all targets

Tested (R) 1/20/04

T Target description seems to be just free text for solar system targets.  Handle that properly.  Also for ss targets, the Keyword: isn’t set.  Is this just the first word in the ss target description?
2 PR 50162 filed APT PR T APT allows both an RV and Z, but doesn’t write both to the prop file.  I don’t think it should.  It should probably red X the distance when both are set though.  I seem to be able to import either one.
3 PR 50163 filed APT PR T Generic target criteria not being set.  I can’t even see the criteria field on my generic target  If I duplicate the generic target that has it, the duplicate doesn’t have it!  Ok.  This is related to phase ½ duality.  When I switch back and forth from phase 2 to 1 to 2, I see the proper value for all the criterias.
4 2 Test behavior for illegal wavelengths - decide if the importer needs to generate its own diag.

Assigned (C)

Closed (T) 1/22/04

T Wavelength gets put in the free text area when it’s not legal at the time.  It doesn’t get moved back if it becomes legal.  This is probably OK, but it makes me nervous.

I thnk this issue can be closed.  There was a little more to this issue, but I'm not concerned about it.  Due to some subsequent APT changes in the wavelength GUI, it's less of an issue than before.

If you import an rps2 file that has a wavelength that is invalid due to the spectral element selection, the wavelength shows up in the picklist and is marked as illegal.  You can then either change the wavelength or the spectral element to make the combination legal and everything is cool.

When issue 4 was first filed, the illegal wavelength was imported into the text area for wavelength, not the picklist, and changing the spectral element to make the combination legal did not bring the wavelength selection into the picklist.

You can still get some of the old behavior if the rps2 file has no spectral element at all (thus no legal values are put in the picklist).  In this case, whatever wavelength was specified gets put in the text area, not the picklist.  Then selecting a spectral element that is legal with that wavelength does not bring the wavelength value into the selected picklist item.  The picklist shows None Selected, and the text area is not editable.

If you save that xml, and reload the wavelength value comes into the picklist, but in floating point form instead of integer, so it's marked as illegal.  I guess the wavelength text area is interpretted as floating point, so that's how it gets exported.

Although these situations seem potentially confusing to a user, I'm not too concerned.  The situations are fairly obscure, and not too hard to recover from when encountered.

5 OK Try it

Looks OK (T)

No Action

T Consider the hideous case where the visit number matches another token.  Make sure I cover all those.
6 Doc propinst should match what APT requires

Assigned (C)

Filed PP PR 50279

Doc that only legal format is dd-MMM-yyyy:[HH[:mm[:ss]]]

T What formats are allowed for Epoch and T in levels?  Propinst says 4 digits, test file has DateSpec().
7 2 Assigned (T)

Made changes to the importer only.

RTT 1/9/04

Failed (R) 1/20/04

RTT (T) 2/6/04

Passed (R) 2/12/04

T APT marks AFTER Visit as illegal.  It says that both by and to must be specified.  Both actually are, and the error goes away when the fields are refreshed.  This could probably be fixed either in APT or the importer.

The specific item to be fixed works, but the ability to just use AFTER 30, with no BY and TO should work but does not.  Also, AFTER 30 BY 30D should work (although APT will give a red X about the missing TO), but also fails.  Both are due to the same cause (reading the units token).

8   RTT 12/31

Tested (R)

C Visit PCS modes FINE and GYRO need to be input as Fine and Gyro.
9 2 Assigned (T)

Changed just the importer

RTT 1/9/04

Passed (C) 1/13/04

T, R Offset targets From Target is marked as illegal initially, but the diag goes away if you go to look at the offset position in the form editor.  This could probably be fixed either in APT or the importer.
10 2 APT shouldn't write this out.

We can then give a warning if it's specified (and ignore the value)

We should see what PP does with that value.

The PP silently ignores the offset target's equinox when creating the tdf.

We should just worry about how to ensure all targets use J2000. (see #40)

Closed.

T, R What should the importer do with equinoxes specified for offset targets?  When APT creates an RPS2 file with offset targets, it writes out the equinox.
11   RTT 12/31

Passed (C) 1/13/04

C Time_Per_Exposure with "." in the number gets parsing error.
Examples are 300.0 S and 30.5 S
12 Doc same as PP->xml

Doc?

Closed

C PI and Co-I names weren't in format with just PI_Name or CoI_Name
and had to be fixed in APT for Last/Honorific/First/(Middle)
13 OK same as PP->xml?

Illegal?

No action.

C Commanding certification proposal had Targets with
       Description: UNIDENTIFIED
which was translated to Category UNIDENTIFIED
and blank Description field which needed to be filled in.
14 Doc same as PP->xml

Doc

C Phase II ID field needs to be filled in.
15 Doc If multiple fluxes are on the Flux: line, they need commas between them.

Doc

C Flux of form V=10.7
             B-V=3.2
had to be rewritten as
             Flux: V = 10.7
     Other_Fluxes: B-V = 3.2
or got parsing error.
16 OK I'm surprised the PP still accepts this.

No Action

C Scan_Data had to be removed. got parsing error.
 (Yes, I know that's old, but was in my commanding props.)
17 2 same as PP->xml

Doc

Needs fix for B1950

It's serious so it needs to stop the import and be an ERROR.

Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/9/04

C, T Invalid Equinox
Equinox 2000 on target: MRK190 (Fixed Target) is invalid.

But there is a problem in that the importer does not warn if they use B1950!

18   Importer needs to upcase these.

RTT 12/31

Passed (C) 1/13/04

C Coordinate_Source: Guide_Star_Catalog
 getting saved back to .rps2 file as
Coordinate_Source: Other_Source: Guide_Star_Catalog
19   Importer needs to upcase these.

RTT 12/31

Passed (C) 1/13/04

 

C

 

target
      Description: STAR, FU Orionis Star
giving Rps2 Importer Uncaught exception during import
 however
      Description: STAR, FU ORIONIS STAR
imports cleanly, so appears to need capitalization
20 2 Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/9/04

C 954 visit 33 exposure 1 had been missing Comment: line
 caused parser error
 expected but it took me a while to figure this one out
 I kept thinking it was something to do with the next visit

/data/mimir2/apt/rps2/127/127.prop loads fine.
/data/mimir2/apt/rps2/128/128.prop doesn't.
Error Line 104: Error parsing: /data/mimir2/apt/rps2/128/128.prop

Only difference is that 127 has a
Comments:
line for the only exposure in Visit 33.

/data/mimir2/apt/rps2/127
mimir% !diff
diff *prop ../128/*prop
103d102
<             Comments:

21   RTT 1/7/04

Passed (C) 1/13/04

C patterns need exposure number
if exposure 1 has
Special_Requirements: PATTERN 1
you'll get a parsing error
need to use
Special_Requirements: PATTERN 1 1
22 Doc Doc C dual spectral elements need "," between them
          Sp_Element: F555W F435W
gives parsing error
          Sp_Element: F555W,F435W
is ok
23 PR 50156 APT differentiates case for targets.  In APT, you can define both FU-Ori and FU-ORI as separate targets.

APT PR filed.

C PP would change FU-Ori to FU-ORI in the tdf file.
import of .prop doesn't change target and therefore
APT gives Target is a required field for FU-Ori with
defined target of FU-ORI.
24 PR 50158 I think it's OK to defer to what APT thinks is required.

No action unless Christine says otherwise after investigating.

Filed APT PR

C I have a pattern without defined Coordinate Frame and
Pattern Orientation. PP had put default of POS-TARG
for Coordinate Frame and 0 for Pattern Orient in the tdf.
APT gives Coordinate Frame is a required field
and
Pattern Orientation is a required field.
25 PR 50538 needed for cal if at all.

These are illegal in APT because APT doesn't like the leading 0.

file PR

C 896 86.02 STIS MSMOFF warning on SETOFFSET=0500
    87.03 STIS MSMOFF warning on SETOFFSET=0700
    87.07 STIS MSMOFF warning on SETOFFSET=0900
    88.01 STIS MSMOFF warning on SETOFFSET=0200
 why are these illegal?
26 2 expecting a value, either fix or change propinst

Fixed it to allow no value.

RTT 1/9/04

Passed (C) 1/13/04

C 884
parsing errors for MIN DUR and MAX DUR
27 2 assigned (T)

need to make it work as well as PP

RTT 1/8/04

Passed (C) 1/13/04

C 887
parsing error on word "Visits" in Abstract:
 expected
Cmd prop 887 had lines like
Visits 07-08: Lines 500-590 test standard WFPC2 IMAGE operations. ---.........
28 3 doc

I decided to allow ";" or "," because it was easy.

RTT 1/8/04

Passed (C) 1/13/04

C parsing error on optional parameters separated by a ";"
 need to be ","
29 4 on wfc3 or cos

Closed.

C 887

Time_Per_Exposure: DEF
saved back to .prop as
Time_Per_Exposure:
30 2 assigned (t)

test was on solaris

RTT 1/8/04

Passed (C) 1/13/04

C parsing error if Questions line has a comment starting with
an exclamation mark (diagnostic will mention Observing_Description:)
example below

Questions  ! comment starting with exclamation mark
Observing_Description:
31 2 assigned (t)

RTT 1/8/04

Passed (C) 1/13/04

C 893

parsing error if no blank line between

Investigators
            PI_Name:
gives error
Investigators

            PI_Name:
doesn't
32 2 assigned (t)

RTT 1/9/04

Passed (C) 1/13/04

C parsing error if last Special_Requirement ends with ';'

punt if complicated;

the issue is that the diag is not informative enough, so either change the diag or accept the ';'

I decided to accept the last ';' with the side effect that multiple ;'s can be used in SR's wherever just one was allowed before.

33 2 assigned (t)

RTT 1/9/04

Passed (C) 1/13/04

C AFTER BY (exposure level sr) seems to be giving an
Uncaught exception during import.

And example prop is /data/mimir2/apt/rps2/665/665.prop

01.02 line 102 dying

The parser didn't like the AFTER BY without a 'TO' clause.

34   RTT 1/7/04

Passed (C) 1/13/04

T Invalid target descriptions cause concurrent mod exception in list.  This is related to issue #19.  This is an important bug.
35 PR 50309 Assigned (T)

Filed autofill PR.

R Random question: should the clear orbit numbers button also clear the actual duration field, since the duration makes no sense without the orbit numbers?

Yes.  "Clear All Orbit Numbers and Actual Durations"

36 Doc doc

The PP allows this, and it would be easy for us to allow it, but there's really no need to.

C Visit_Requirements:
                SEQ 1-10 WITHIN 24H

gives Rps2 Importer error invalid range
 as the visits are numbered 01, 02, 03 ... 10
37 PR 50161 assigned (t)

same as PP->xml->APT, but still wrong.

Filed APT PR.

C /data/mimir2/apt/rps2/886b/886.prop gets
This Plate ID may only be used with engineering proposals
 for Target 6 (NGC188-1). But it is an engineering prop.
  Proposal_Category: ENG/FGS
38 2 assigned (t)

The fix in the visit range handler should affect all SR's that use visit ranges.

RTT 1/11/04

Passed (C) 1/13/04

C /data/mimir2/apt/rps2/886b/886.prop
< original rps2  > exported rps2

 < SEQ 01-10 WITHIN 24H
 > SEQ 01,02,03,04,05,06,07,08,09 WITHIN 24 H

there are visits 01...10 but the new numbering only
goes through 09

similar for
 < SEQ 11-19 WITHIN 24H
 > SEQ 11,12,13,14,15,16,17,18 WITHIN 24 H
 < SEQ 20-26 WITHIN 24H
 > SEQ 20,21,22,23,24,25 WITHIN 24 H

 < SEQ 37-39 WITHIN 24H
 < SEQ 40-41 WITHIN 24H
were dropped in the exported rps2.
There are visits 37, 39 (no 38), 40, 41
39 2 assigned (t)

RTT 1/8/04

Passed (C) 1/13/04

C double filters truncated to one:
/data/mimir2/apt/rps2/887b/887.prop

visit 04 exp 02

< Sp_Element: F122M,F130LP
> Sp_Element: F130LP
40 PR 50333 see #17 for more info.

Filed PROPINST PR that equinox is required in RPS2 format and that it must be J2000

s/w changes handled in issue 17.

Closed

R I note that Equinox is optional, but since all
coordinates must have an equinox, I do not understand how this field
can be optional. On the other hand, we now require equinox 2000 for all
objects, so in a sense this keyword is unnecessary.  However, it is
still populated in the apt file, so it is necessary.  In APT, it is
cleared marked that coordinates are 2000, but for people doing ingest,
the should have the reminder that equinox is important.  So, I
propose we make equinox required. We also need to
have the software flag this as an error (at present, if you put B1950
in the RPS2-like file, the keyword is ignored).
41   Not a Bug

No Action

R I used the CR-SPLIT parameter for testing.  Everything worked as
expected, except that the software REQUIRED CR-SPLIT to be intact.
42 Doc Assigned (T)

This is due to the tokens not including NL's in between the words.  Those cannot be added to the tokens cleanly due to possible comments, so the correct fix would be to break up the tokens, and allow all WS() in the grammar.  1 day or so effort.

Doc

R The software requirements all multi-part requirements (e.g.  POS TARG)
to be on the same line.  The arguments, however, can be on different
lines (e.g. -1.0, and +2.0 on different lines).  The software
requirements all hyphenated requirements (e.g.  LOW-SKY) to be on the
same line.  These are all acceptable.
43   See #32

Passed (C) 1/13/04

R If you have a ";" on the last requirement, the importer dies
(since it is looking for a new requirement which is not there).  This
will be a common error, so a more benign failure mode is needed.
44   Prop file values for FORMAT, EXP PCS MODE and GS ACQ SCENARIO will all be forced to upper case by the importer.

RTT 1/11/04

Passed (C) 1/13/04

R A follow-on to my previous message regarding ingest of exposure level special requirements.  There are 3 requirements (FORMAT, EXP PSC MODE, and GS ACQ SCENARIO) that have defined text inputs (e.g. FORMAT has AN, FN, etc.), and these inputs are case sensitive. So, if your input file as "FORMAT an", the ingest works, but you get a red X saying the "an" is illegal.  This is OK since you can then use the picklist to select "AN".
45   Prop file values for FORMAT, EXP PCS MODE and GS ACQ SCENARIO will all be forced to upper case by the importer.

RTT 1/11/04

Tested (R) 1/20/04

R However, for GS ACQ SCENARIO, I think we have a problem.  This requirement has specific text inputs, but it also allows free text. So, if you wanted BASE1 as your selection, but put "base1" in your ingest file, you do NOT get a red X.  Although this is a PC mode and therefore the chance of a GO messing up are small, the PCs will be doing a lot of work from the ingest file, and this could be a
problem for them.

I talked with Denise about this, and the PC situation will not change from the present operational scenario when the APT ingest is functional.  So, we do NOT need to worry about this.

46 2 ***

RTT (T) 2/6/04

Passed (C) 2/11/04

T For parse errors (those that stop parsing), what should we do to make sure they know that the prop wasn't fully read in.  Options:
  • pop up with errors and pointer to file with errors in it.
  • leave the current diag, but get rid of the visits.
  • do something else safe with diagnostics.

We decided to do the following for all import errors, whether or not they cause parsing to stop:

  • Display a pop-up message indicating that they need to review there import diagnostics.
  • Remove the targets and visits from the proposal.
  • This removal can be overridden with the command line argument -ForceLoad.
47 2 assigned (t)

RTT (T) 2/6/04

Passed (C) 2/9/04

T add popup if any import diags are created
48   The list not working should be fixed by #38.

The white space issue is separate.

Assigned (T)

RTT 1/12/04

Tested (R) 1/20/04

R Issue: Visit lists do not seem to work properly.  If the list is 1,2,3, it works.  However, if the list is 1-3, only 1 is marked in APT.  If there are spaces between the visits (e.g. 1, 2, 3), it also does not work.
49   Assigned (T)

RTT 1/12/04

Tested (R) 1/20/04

R Issue: the Visit-level requirement VISIBILITY INTERVAL CORON does not work at all.  It seems to want a time only, so this is being confused with the other usage of VISIBILITY INTERVAL (which does require a time).
50 Doc I think this is a misunderstanding.  

Actually though, the importer does not require that the visit with the sr be included in the list.  Should it?  What does the PP require.

Doc that you *should* have the current visit.

Assigned (T) - make sure the only issue is the single digit visit id's. (issue #36)

R Issue: when using requirements list GROUP visitlist WITHIN, the current visit CANNOT be included in the visit list.  We must document this prominently.

Actually the import accepts the current visit in the visit list, but does not require it.   The PP may require that.  The biggest potential difference here is if the user intentionally puts the sr on a visit that they don't want in the list.

Say you have 3 visits.

case A:
visit 1 has GROUP 1-3 WITHIN 9D
(define-group-within
   :proposal-id 129
   :visit-ids '("01" "02" "03" )
   :time-interval 777600
)

case B:
visit 1 has GROUP 2-3 WITHIN 9D
(define-group-within
   :proposal-id 129
   :visit-ids '("02" "03" )
   :time-interval 777600
)

Neither case has any PP diagnostics.
So you need to specify the visit with the sr in the
list or the PP doesn't put it in the ldf group-within.

Case A and B both have RPS2 importer errors.
 ERROR - invalid range specification: 1-3
 ERROR - invalid range specification: 2-3

Case A has in the PP xml:
        <GroupWithin>
           <VisitList>
              <Visit Number="01" />
              <Visit Number="02" />
              <Visit Number="03" />
           </VisitList>
           <Within Days="9" />
        </GroupWithin>

Case B has in the PP xml:
        <GroupWithin>
           <VisitList>
              <Visit Number="02" />
              <Visit Number="03" />
           </VisitList>
           <Within Days="9" />
        </GroupWithin>

when opened with APT, saved as, and exported as prop both cases have
          GROUP 01,02,03 WITHIN 9.0D

51 PR 50201 Same issue when specified in the GUI.

APT PR filed.

R Issue: for SEQ vistlist WITHIN, I had a case where my visitlist was illegal.  APT did not populate the visit field, but kept the WITHIN requirements.  I did NOT get a red X (WTHIN specified but no visitlist), and I think I should have.
52 OK The PP doesn't accept the white space between JD and number either.

No issue with SCHED.

No action.

R Issue: for PERIOD AND ZEROPHASE, the software requires no spaces between the JD and date (i.e. JD2450000 works, JD 2450000 does not).  This is similar to things list SCHED 100%, so we need to document this restrictions carefully.
53 Doc Just make sure the new propinst contains rps2 syntax for things like this.

Closed

R Issue: ORIENT angle TO angle FROM visit is a different format than the Phase II instructions (ORIENT FROM visit BY angle TO angle). Also note that the orient range does NOT appear in the spreadsheet editor.
54   Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/9/04

T There seem to be (at least) two problems with
doing runAll.

1)  Batch mode with -import hangs if there's no -export.

2)  -runAll expects another argument, so the next argument after -runAll on
the command line is being ignored.
55   Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/11/04

T Deal with this PR:

47948 - Allow non-consecutive target numbers

56   Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/9/04

C while testing opr 50219.

I imported a prop with an unfinished REGION specification,
       Position:RA=01H 31M 01.7S, DEC=+30D 24' 15", REGION

Upon import it was quietly turned into a rectangular region
with sides 0.1 RA, 0.1 DEC.

Lost the PP warning of
"fixed position beginning with RA = 01H31M01.7S DEC = +30D24'15\" REGION
 appears to be incomplete"
57 Assigned (T)

Passed (R) 2/11/04

R 1) the error messages for incomplete requirements and parameters point to the line in the file AFTER the incomplete statement.  This is correct (since the next line could have had the missing information), but is confusing to the users (since they look at the line and see nothing wrong).  Could we change the software to point to the line the is missing the text?
58   Doesn't matter now that warning causes visits not to exist.

No Action

R 2) GROUP 10-40 WITHIN 10D (where there is no visit 40) - you get a warning about the illegal range, but the ingest does insert the GROUP requirement with only visit 10 (even though 20 and 30 are also legal).  If you try GROUP 10,20,30,40 WITHIN 10D, you get the same warning, but visits 10-30 are included in the group.
59  2 Assigned (T)

(Should change message)

RTT (T) 2/12/04

Tested (R) 2/17/04

R 3) PAR 1-2 WITH 4 (where there is no exposure 4) - you get a warning about the illegal range, but the software claims the range will be created as specified.  This does not happen (it cannot since the prime exposure does not exist).
60  1 Assigned (T)

(Make warning clearer)

RTT (T) 2/12/04

Tested (R) 2/17/04

R 4) PAR 2-3 WITH 1 (where these is no exposure 3) - very confusing.  The ingest error says "PAR 2-3 WITH 1 on line 165 overlaps with exposure group: Visit. The former will be ignored."  This is very unclear, but tells me that the PAR will be ignored.  However, an PAR container is created, but it just has the prime exposure.  The same situation arises if there I try PAR 2-4 WITH 1, where only 4 does not exist.
61   Assigned (T)

Problem seemed to go away with new OP interface.

No Action.

R 5) STIS/CCD ACQ ACQTYPE=CRAP (illegal; pulldown) - the error message says "null is no valid on the specified exposure. The parameter will be ignored."  This is fine (although it should say CRAP is NOT valid), except that the line number with the problem is reported as line 167, which is well past where the offending line is, and is even past another exposure in the visit.  It is pointing to the next Visit keyword in the file (or the end of the file). The entire file is ingested.
62   Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/9/04

C Simple MARS isn't working...
parsing on Level_1/Level_2 lines

   Target_Number: 2
    Target_Name: CERMARS
    Description: PLANET PLANET-MARS
       Level_1: STD=MARS
       Level_2:
       Level_3:
        Window: CML OF MARS FROM EARTH BETWEEN 0.0 30.0
 Ephem_Uncert:
   Acq_Uncert:
           Flux:
V = -2.6
SURF(2500)=2.84 +/-0.3E-13
SURF(4350)=2.52 +/-0.3E-11
SURF(6580)=6.87 +/-0.3E-11
     Comments:

This turned out to be a collision between the token "MAR" for March and the planet name "MARS".

Also there needs to be a comma after the V = -2.6.  That is one of the separators that is now required that the PP didn't require.

63   Assigned (T)

RTT (T) 2/6/04

Passed (C) 2/9/04

C /data/mimir2/apt/rps2/133/133.prop error parsing at line 41.
/data/mimir2/apt/rps2/134/134.prop error parsing at line 42.

133 exposed a parser problem that wouldn't allow decimal numbers that started with a '.'.  It also had a new-line in the middle of a number on line 51.

134 had the same problems discussed in issue 62.

64   Assigned (T)

This is an APT issue.  GS ACQ SCENARIO allows an "other" value that can accept any text.  Do we need a warning?

No.  No action.

C APT doesn't mark unknown GS ACQ SCENARIO value of
BASES (based on Karla's earlier tests) when imported
from an rps2 or opened from an xml file.

PP gives: "Warning: Unknown GS ACQ SCENARIO value (BASES)."
65   Assigned (T)

These illegal values were caught by the parser instead of being red X'd by APT.  There was no particular reason for that distinction.

No action.

C parsing error on rps2 import of illegal FORMAT ZN.
parsing error on rps2 import of illegal EXP PCS MODE SLOW.
66 PR 50309 filed APT PR

RTT (T) 2/6/04

Passed (C) 2/9/04

T Either get rid of the visit-id on subexposures, or flag an error when one's value doesn't match that of the visit it's in.

Decided to stop exporting the visit_number and ignore it on read.

67   RTT (T) 2/6/04

Now these diagnostics have gone away entirely with the new optional parameter interface.  (T) 2/17/04

Closed.

T Diagnostic for invalid optional parameter had parts missing and didn't look good.
68   RTT (T) 2/6/04

Passed (C) 2/9/04

T Automatically upcase o.p. values
69   RTT (T) 2/6/04

Passed (C) 2/9/04

T Allow both PAR and PARALLEL for visit level requirement, because APT currently exports "PARALLEL" and it's easier to change the importer to accept both.
70   RTT (T) 2/6/04

Passed (C) 2/19/04

T Importer diagnostics about optional parameters contained misleading line numbers.  (They were also a little sloppily written.)
71   RTT (T) 2/6/04

Passed (C) 2/9/04

T Stop restricting RPS2 importing to STScI mode.  Do not mark the action as unsupported.
72    The reponse matches the current behavior.

Closed (T) 2/12/04

T When importing an ACS-SBC-DITHER-BOX pattern with line spacing and sides angle unspecified, APT gives those values defaults.  When APT opens the same thing from an xml file, those values are left blank.

In the APT file case, the user either cleared those defaults from the APT editor and saved the proposal or is reading an old APT file.  In the former, we should definitely preserve the blank fields.  In the latter, I'm not sure what we should do.

The RPS2 importer has the same dilemma.  Those fields are optional with built-in defaults.  The prop file doesn't give us a good way to determine whether unspecified values for those fields meant "use the default" or "preserve the fact that I still haven't entered a value".

So what should we do in APT and the RPS2 importer for unspecified line spacing and sides angles when the pattern gives defaults but leaves the fields editable?

Response:

Since the PI was reading in an old APT file, that file had to ASSUME the default values, so we should do the same thing on read.

I think we should assume that the PI would have populated the fields if they wanted non-default values, so if they are blank, put in the defaults.

73   Assigned (T)

RTT (T) 2/10/04 

Passed (C) 2/19/04

Visit 03, exposure 2 in Import-Test is not part of a pattern or number of iterations.  It does have a CR-SPLIT.  In an APT load, those indeces for the subexposures are nil, but in an RPS2 load they are 1.

This will happen in all cases where the exposure's target name is not legal for that exposure.  The outermost clause in createSubexposures() prevents it from running and setting the proper indeces for the ExposureCopy's.

The fix requires retesting of subexposure ingest.

This needed to be fixed in conjunction with PR 50347

74  4 Let's not do anything about this.

Closed. 

 C/T  When the Fixed_Targets line is missing, the fixed targets can be ignored (gobbled up by the Additional_Comments: field of the proposal description).

I wrote the grammar to require the Fixed_Targets line.  I didn't realize the PP would recognize the fixed targets in this case.

75  2 RTT (T) 2/12/04 

Passed (C) 2/17/04

 C  When the Sub_Exposures: line is present, the parser requires it to be populated.  The PP allows a blank Sub_Exposures: line.
76   Ignore 

Closed

 C  Getting
Error Line 68: Incomplete Target Position

Region target requires either a radius specification or +/- values for both RA and Dec.


/data/mimir2/apt/phase2/5596/5596new/5596.prop
  Target_Number: 2
    Target_Name: M33
Alternate_Names:
    Description: GALAXY, SPIRAL
         Position: RA=01H01M1.1S +/- 2.0S,DEC=+01D01'1.1" +/- 3.0",REGION

This prop was exported from APT after having read in the
/data/mimir2/apt/phase2/5596/5596new/5596new.apt file
77  PR 50534  File PR.  In parser errors, the "Was expecting one of:" lists can be confusing.  This is especially true when the list is trying to describe something general, like an alphanumeric string.  Optional parameter values are such strings, so if they are missing, the "Was expecting one of:" list is long and not helpful.
78  2 Importer was getting NPE's on any STD level 2's.

 RTT (T) 2/17/04

Passed (C) 2/17/04

 C  Getting an rps2 importer error on line 46 for
/data/mimir2/apt/rps2/143/143.prop
NullPointerException

Solar_System_Targets

  Target_Number: 1
    Target_Name: GANYMEDE
    Description: SATELLITE Ganymede
        Level_1: STD=JUPITER
        Level_2: STD=GANYMEDE
        Level_3:
         Window: OLG OF GANYMEDE BETWEEN 15 50
   Ephem_Uncert:
     Acq_Uncert:
           Flux: V=5.32
       Comments:
 79  2  UTD 2/16/04

Closed

 C ;; after last visit sr crashes parser.
 80  PR 50535  file PR   C Blank target templates are not accepted.  Neither are blank pattern templates.  Are there any other blank parts of the template that should be accepted?
81 PR 50536 file PR C Scientific notation not accepted for any numbers.  Example was -4.0E-5 for RA_PM.  Should all floating point fields allow scientific notation?
82 PR 50537 file PR C There's a SEQ NON-INT 1-23
1,2,4,5,6... have SAME POS AS 3.

APT reading the xml from PP has SAME POS AS on
1,2,4,5,6...

When importing the prop the SAME POS AS is on
4,5,6... but not on exps 1,2.

the input is at
/data/mimir2/apt/rps2/149/149.prop
/data/mimir2/apt/rps2/149/ppdir/149.xml

83 I don't think this is a problem.  The reason the PP accepts this is that the ";" wasn't required. C ! in line with a ; at the end:

not a problem, just a comment perhaps for doc

rps2 ingest accepts
ORIENT 125.0D TO 125.0D; !122.0D TO 122.0 D
BETWEEN...

but crashes on
ORIENT 125.0D TO 125.0D !122.0D TO 122.0 D;
BETWEEN...

I was going along editing an old proposal and just putting the ";" at the end of the visit sr lines.

84