ROS SPICE Data Set Release 0004 Review notes
BVS/NAIF, April 10, 2019
===========================================================================

on RO-RL-E-M-A-C-SPICE-6-V1.0_rel0004_20190405.tar provided on April 5, 2019

md5sum:

a7f21f6ea10fd9cefd86f8ad83761317


===========================================================================
Notes on kernel data and comments:
===========================================================================

\begin{solved}
DATA/DSK/DEIMOS_K002_THO_V01.BDS

-- typo in comments: 

      ROS_DSK_SURFACES_V00.TPC -> ROS_DSK_SURFACES_V00.TF

-- we should change this DSK's file name because the _K002_ is incorrect.
   This model has 5184 plates so the token should be _K005_. Sorry for 
   missing this when we did original review of this DSK.

   If we decide to not rename the file (which will make this token
   ambiguous across DSKs in the data set) we should clearly describe this 
   in DSKINFO.TXT
\end{solved}
   
\BG{
  The minor typo in the comment  would possibly not require a new version
  (and thus a new file name), but correcting the token in the file name
  implies a new file name and in the SKD, this has also to be adapted for
  of the OBJ and PNG files. The old version (with the wrong token in the
  file name) will go to the former_versions diretory in the SKD.
  As there is no file name ambiguity, we keep version number V01 for the
  new files.

  The file name change has to be propagated to the DSK SURFACES FK and
  the meta kernel (and to the dsk/aareadme.txt for the SKD release) and their
  versions have to be incremented. In the fk/aareadme.txt, the description
  of the SURFACES FK is version generic, so that's fine.
  
  So, these are the steps:

  -  Read the comment from DEIMOS_K002_THO_V01.BDS and put them into
     ../src/deimos_comment.txt (and add this to the CVS).

  -  Rename in the rel0004_staging area DEIMOS_K002_THO_V01.BDS to
     DEIMOS_K005_THO_V01.BDS.
  
  -  Rename in the rel0004_staging area ROS_DSK_SURFACES_V01.TF to
     ROS_DSK_SURFACES_V02.TF and correct therein the DSK surface name.
  
  -  Correct the file name in the comment and add note that the previous
     version had different file name.

  -  Regenerate with the new files the dskbrief output and insert it in the
     comment.

  -  Add my contact information in the comment.

  -  Change ROS_DSK_SURFACES_V00.TPC to ROS_DSK_SURFACES_V02.TF in the comment.
  
  -  Have the new comment replace the old one in DEIMOS_K002_THO_V01.BDS.
     This is done by the Makefile.

  -  Create in ARCGEN_OUTPUT/EXTRAS/MK a new meta kernel ROS_V08.TM and
     update the SURFACES FK.

  -  Update the file name in the dsk/aareadme.txt in the rel0004_staging area
     to DEIMOS_K005_THO_V01.BDS. This is irrelevant for the archive, as the
     fuzzy matching I have implemented in arcgen still picks the correct
     description, but it is needed for the new SKD release.
     
  -  Clean in ARCGEN_OUTPUT the DSK and FK directories and rerun arcgen.
}

\begin{solved}
DATA/DSK/PHOBOS_K137_DLR_V02.BDS

-- typo in comments: 

      ROS_DSK_SURFACES_V00.TPC -> ROS_DSK_SURFACES_V01.TF

-- we should change this DSK's file name because the _K137_ is incorrect.
   This model has 274874 plates to the token should be _K275_. Sorry for 
   missing this when we did original review of this DSK.

   If we decide to not rename the file (which will make this token
   ambiguous across DSKs in the data set) we should clearly describe this 
   in DSKINFO.TXT
\end{solved}

\BG{
  We repeat the steps for the previous correction:

  -  Read the comment from PHOBOS_K137_DLR_V02.BDS and put them into
     ../src/phobos_dlr_comment.txt (and add this to the CVS).

  -  Rename in the rel0004_staging area PHOBOS_K137_DLR_V02.BDS to
     PHOBOS_K275_DLR_V02.BDS.
  
  -  Correct respectively the surface name in ROS_DSK_SURFACES_V02.TF.
     Note that the former version V01 appears therein also with the
     wrong token, but we don't touch that.
     
  -  Correct the file name in the comment and add note that the previous
     version had different file name.

  -  Regenerate with the new files the dskbrief output and insert it in the
     comment.

  -  Add my contact information in the comment.

  -  Change ROS_DSK_SURFACES_V00.TPC to ROS_DSK_SURFACES_V02.TF in the comment.
  
  -  Have the new comment replace the old one in DEIMOS_K002_THO_V01.BDS.
     This is done by the Makefile.

  -  The SURFACES FK has already been updated in the new meta kernel
     ROS_V08.TM.

  -  Update the file name in the dsk/aareadme.txt in the rel0004_staging area
     to PHOBOS_K275_DLR_V02.BDS.
     
  -  Clean in ARCGEN_OUTPUT the DSK and FK directories and rerun arcgen.
}

\begin{solved}
DATA/DSK/PHOBOS_M157_GAS_V01.BDS

-- typo in comments: 

      ROS_DSK_SURFACES_V00.TPC -> ROS_DSK_SURFACES_V00.TF

-- DSKBRIEF summary included in comments does not show surface name:

  Surface:                          14011 (Name not available)

-- we should change this DSK's file name because the _M157_ is incorrect.
   This model has 3145728 plates to the token should be _M003_. Sorry for 
   missing this when we did original review of this DSK.

   If we decide to not rename the file (which will make this token
   ambiguous across DSKs in the data set) we should clearly describe this 
   in DSKINFO.TXT
\end{solved}

\BG{
  Same procedure, once more:

  -  Read the comment from PHOBOS_M157_GAS_V01.BDS and put them into
     ../src/phobos_gas_comment.txt (and add this to the CVS).

  -  Rename in the rel0004_staging area PHOBOS_M157_GAS_V01.BDS to
     PHOBOS_M003_GAS_V01.BDS.
  
  -  Correct respectively the surface name in ROS_DSK_SURFACES_V02.TF.
     
  -  Correct the file name in the comment and add note that the previous
     version had different file name.

  -  Regenerate with the new files the dskbrief output and insert it in the
     comment.

  -  Add my contact information in the comment.

  -  Change ROS_DSK_SURFACES_V00.TPC to ROS_DSK_SURFACES_V02.TF in the comment.
  
  -  Have the new comment replace the old one in DEIMOS_K002_THO_V01.BDS.
     This is done by the Makefile.

  -  The SURFACES FK has already been updated in the new meta kernel
     ROS_V08.TM.

  -  Update the file name in the dsk/aareadme.txt in the rel0004_staging area
     to PHOBOS_K275_DLR_V02.BDS.
     
  -  Clean in ARCGEN_OUTPUT the DSK and FK directories and rerun arcgen.
}

\begin{solved}
DATA/DSK/TEMPEL1_9P_K032_THO_V01.BDS

-- typo in comments: 

      ROS_DSK_SURFACES_V00.TPC -> ROS_DSK_SURFACES_V00.TF

-- _K032_ in the name of this DSK is correct.
\end{solved}

\BG{
  This minor typo in the comment does not deserve a new version of the file.
  So I just correct this silently:

  -  Read the comment from TEMPEL1_9P_K032_THO_V01.BDS and put them into
     ../src/tempel1_comment.txt (and add this to the CVS).

  -  Add my contact information in the comment.

  -  Change ROS_DSK_SURFACES_V00.TPC to ROS_DSK_SURFACES_V02.TF in the comment.
  
  -  Have the new comment replace the old one in TEMPEL1_9P_K032_THO_V01.BDS.
     This is done by the Makefile.

  -  Clean in ARCGEN_OUTPUT the DSK directory and rerun arcgen.
}

\begin{solved}
DATA/FK/ROS_V33.TF

-- typos in SREM section:

      Nominally, the SREM D12 and GIADA D3 frames -> 

      Nominally, the SREM D12 and SREM D3 frames


      are rotated form the s/c frame ->

      are rotated from the s/c frame

-- ROSINA IDs table in comments at the end of the file (lines 5377..5385) 
   does not show new name/ID pairs for COPS_G0 and COPS_G1.
\end{solved}

\BG{
  These few typos in only the comment section would possibly not necessarily
  require a new version of the FK (currently V33), however, OSIRIS would
  like to know which version the FK with their final FOV update will be in
  order to put it already in their new image headers. So we can tell them
  V35 and make another release V34 anyway when the increment is ready.
  So we could incorporate any critical issues that may come up before.

  Thus I rename ROS_V33.TF to ROS_V34.TF in the rel0004_staging area and
  make the corrections therein. The meta kernel read by arcgen and the one
  in ARCGEN_OUTPUT/EXTRAS need both to be updated with the new FK. Then clean
  in ARCGEN_OUTPUT the FK directory and rerun arcgen.
}

\begin{solved}
DATA/IK/ROS_COSIMA_V14.TI

-- cross angle in FOV definition was not updated. It should be:

          INS-226140_FOV_CROSS_ANGLE           = ( 12.000 )

-- it is not clear what these parameters mean for COSIMA:

         INS-226140_PIXEL_SAMPLES      = ( 32000 )
         INS-226140_PIXEL_LINES        = ( 10000 )
         INS-226140_CCD_CENTER         = ( 16000, 5000 )

   Nothings in the comments explains them. They should be explained.
\end{solved}
   
\BG{
  -  Renamed the IK in the rel0004_staging area to ROS_COSIMA_V15.TI.

  -  Updated meta kernel read by arcgen and the one in ARCGEN_OUTPUT/EXTRAS
     respectively.

  -  Changed the value for INS-226140_FOV_CROSS_ANGLE from 17.000 to 16.000.
     This should be the correct value. The 12.000 given above is probably a
     typo.

  -  Wrote an email to Martin Hilchenbach to ask for the meaning of the
     spurious keywords. Added an explanation according to their response
     and also corrected an outdated remark on the use of IFOV.
}
  
\begin{solved}
DATA/IK/ROS_STR_V11.TI

-- these sets of keywords added in V11 use NAVCAM IDs (-226170
   and -226180) instead of STR IDs (-226080 and -226090):

         INS-226170_FOCAL_LENGTH       = ( 46                   )
         INS-226170_F/RATIO            = ( 1.5                  )
         INS-226170_FOV_ANGULAR_SIZE   = (   0.287456, 0.287456 )
         INS-226170_IFOV               = (   0.0002807          )

         INS-226180_FOCAL_LENGTH       = ( 46                   )
         INS-226180_F/RATIO            = ( 1.5                  )
         INS-226180_FOV_ANGULAR_SIZE   = (   0.287456, 0.287456 )
         INS-226180_IFOV               = (   0.0002807          )


         INS-226170_PIXEL_SIZE         = ( 13, 13 )
         INS-226170_PIXEL_SAMPLES      = ( 1024 )
         INS-226170_PIXEL_LINES        = ( 1024 )
         INS-226170_CCD_CENTER         = ( 511, 511 )

         INS-226180_PIXEL_SIZE         = ( 13, 13 )
         INS-226180_PIXEL_SAMPLES      = ( 1024 )
         INS-226180_PIXEL_LINES        = ( 1024 )
         INS-226180_CCD_CENTER         = ( 511, 511 )

         This needs to be fixed.
\end{solved}

\BG{
Corrected this in place in the rel0004 staging area, rerun arcgen, and checked
that the change is propagated to the ARCGEN_OUTPUT directory.
}

\begin{solved}
DATA/SPK/ROS_COG_V2.BSP

-- this SPK needs to be re-made with a different polynomial degree 
   (suggest 3) or different type and degree (Type 9, Degree 1).
   Step-like changes in CG position, combined with velocities set to 0,
   and interpolation degree set to 11, cause extreme polynomial
   ringing -- see attached plots that show Z coordinate of the offset
   stored in the SPK (red points) and offset obtained by sampling from 
   the SPK (green line) computed using this SPKDIFF command:

      spkdiff -k /kernels/gen/lsk/naif0012.tls DATA/FK/ROS_V33.TF -s 1 -t dump -f YYYY-MM-DDTHR:MN:SC ::RND -b 2016-08-27 -e 2016-08-28 ROS_COG_V2.BSP > ROS_COG_V2.BSP.sample

-- looking at the data stored in the SPK (see attached plot showing the
   Z coordinate for example), the millimeter level changes in the CG
   location seem rather noisy and don't necessarily look realistic.

   Have these variation were explained by those who provided the data?

   Have they also provided any accuracy estimates for this position? 

   Is this actual variable position estimate is better than the single fixed
   average value used in V1 for the applications that need it?
\end{solved}
   
\BG{
  Remade the kernel as Type 9, Degree 1. Plotted time series with one second
  time step, looks fine. Updated the comment field.
}

\begin{solved}
===========================================================================
Missing CRs in meta-files:
===========================================================================


DATA/IK/ROS_ALICE_V17.LBL

-- line 70 (DESCRIPTION                = "...) does not have CR




DATA/IK/ROS_CONSERT_V11.LBL

-- line 64 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_COSIMA_V14.LBL

-- line 64 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_DIM_V11.LBL

-- line 69 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_GIADA_V12.LBL

-- line 73 (DESCRIPTION                = "...) does not have CR




DATA/IK/ROS_MIDAS_V11.LBL

-- line 64 (DESCRIPTION                = "...) does not have CR




DATA/IK/ROS_MIRO_V11.LBL

-- line 68 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_NAVCAM_V03.LBL

-- line 68 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_OSIRIS_V15.LBL

-- line 70 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_ROSINA_V12.LBL

-- line 71 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_RPC_V19.LBL

-- line 83 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_SREM_V01.LBL

-- line 68 (DESCRIPTION                = "...) does not have CR



DATA/IK/ROS_STR_V11.LBL

-- line 70 (DESCRIPTION                = "...) does not have CR




DATA/IK/ROS_VIRTIS_V14.LBL

-- line 73 (DESCRIPTION                = "...) does not have CR
\end{solved}

\BG{
  Correcting these requires corrections to arcgen. As Marc has in the meantime
  done some modifications, I have to pull and rerun and then should check that
  the checksum of my results does not change.

  git pull does not work (any more) as there is a binary file (an SPK) in
  my working directory that should have been treated by LFS, but it wasn't.
  It looks like this situation can actually lock git. Fortunately, I don't
  have any uncommitted changes, so I can just re-clone the repository.

  A couple of new keywords are now required in the configuration file.
  These should only affect the PDS4 version, so I modify the class Mission
  to only read them in that case. However, to avoid errors further
  downstream, two of them have to be read and set to empty strings in the
  configuration file.

  After these modifications, arcgen runs again and the CHECKSUM.TAB is
  unchanged.

  When investigating the cause of the missing carriage return, found that
  in the case of an IK, arcgen overwrites the description extracted from
  the aareadme.txt with a default description, and this default is missing
  the CR. Took that overwriting out to get the correct description (with
  the CR).
}

\begin{solved}
===========================================================================
Long lines in meta-files:
===========================================================================

DOCUMENT/SPKINFO.TXT

-- contains these lines longer than 80 characters:

   Line 65 is too long (81 chars).
   Line 68 is too long (81 chars).
   Line 72 is too long (81 chars).
   Line 79 is too long (81 chars).
   Line 80 is too long (81 chars).
   Line 81 is too long (81 chars).
   Line 82 is too long (81 chars).
   Line 129 is too long (81 chars).
   Line 132 is too long (81 chars).
   Line 133 is too long (81 chars).
   Line 219 is too long (81 chars).
   Line 226 is too long (81 chars).
   Line 227 is too long (81 chars).
   Line 228 is too long (81 chars).
   Line 229 is too long (81 chars).
\end{solved}

\BG{
  Indeed, there are lines wich have 79 characters, which, together with the
  two line ending characters makes up 81. These occur in the kernel
  descriptions, where we have file names on the left side of the page and
  descriptions on the right side. This could have been tedious to fix,
  requiring complete manual reformatting of the descriptions. However,
  fortunately, there are at minimum two blanks between file names and
  descriptions, and the descriptions start always at the same column.
  Therefore, we only have to check for two blanks just before the start
  column of the descriptions, and, if we find them, just remove one. This
  could in principle affect two consecutive blanks in a regular line of text,
  but we can easily check this with a diff.

  So, we write a script for this, check that it shortens description lines as
  expected and does not affect regular lines.
}

\begin{solved}
===========================================================================
Incorrect MISSION_PHASE_NAME in labels:
===========================================================================


DATA/CK/ROS_HGA_2016_V0042.LBL

-- based on file coverage MISSION_PHASE_NAME should be 

MISSION_PHASE_NAME           = {
                                 "ROSETTA EXTENSION 1",
                                 "ROSETTA EXTENSION 2",
                                 "ROSETTA EXTENSION 3"
                               }



DATA/CK/ROS_ORBITER_EXTENSION_V2.LBL

-- based on file coverage MISSION_PHASE_NAME should be 

MISSION_PHASE_NAME           = {
                                 "ROSETTA EXTENSION 3"
                               }


DATA/CK/ROS_SA_2016_V0041.LBL

-- based on file coverage MISSION_PHASE_NAME should be 

MISSION_PHASE_NAME           = {
                                 "ROSETTA EXTENSION 1",
                                 "ROSETTA EXTENSION 2",
                                 "ROSETTA EXTENSION 3"
                               }



DATA/CK/ROS_SC_MES_110101_110608_V03.LBL

-- based on file coverage MISSION_PHASE_NAME should be 

MISSION_PHASE_NAME           = {
                                 "RENDEZVOUS MANOEUVRE 1",
                                 "CRUISE 6"
                               }



DATA/CK/ROS_SC_MES_140120_150101_V03.LBL

-- MISSION_PHASE_NAME has no values:

MISSION_PHASE_NAME           = {

                               }

   It should be:

MISSION_PHASE_NAME           = {
                                 "CRUISE 6",
                                 "PRELANDING",
                                 "COMET ESCORT 1"
                               }



DATA/CK/ROS_SC_MES_160101_160930_V03.LBL

-- based on file coverage MISSION_PHASE_NAME should be 

MISSION_PHASE_NAME           = {
                                 "ROSETTA EXTENSION 1",
                                 "ROSETTA EXTENSION 2",
                                 "ROSETTA EXTENSION 3"
                               }



DATA/SPK/ROS_ORBITER_EXTENSION_V2.LBL

-- based on file coverage MISSION_PHASE_NAME should be 

MISSION_PHASE_NAME           = {
                                 "ROSETTA EXTENSION 3"
                               }
\end{solved}

\BG{
  For ROS_HGA_2016_V0042.LBL, the cause was a wrong year in the end date of
  "COMET ESCORT 4" in arcgen's mission phase map.

  For CK/ROS_ORBITER_EXTENSION_V2.LBL, the START_TIME is
  2016-10-01T00:00:00.000,
  which is actually after end of mission. We put there the last phase,
  which can easily be achieved by moving the
  end of "ROSETTA EXTENSION 3" forward in time in the mission phase table.

  For ROS_SA_2016_V0041.LBL, the cause was the same as for the first kernel
  above, so it is OK now.

  For, ROS_SC_MES_110101_110608_V03.BC the STOP_TIME is 2011-06-08T04:49:38.702,
  thus it is before the start date of "CRUISE 6" which is
  given as 2011-07-14 in argen's mission phase map. However, the MISSION.CAT
  in the SPICE archive and also the latest MISSION.CAT that Diego knows of
  gives as start data of "CRUISE 6" 2011-06-08. So, I update that in arcgen's
  mission phase table.

  For ROS_SC_MES_140120_150101_V03.BC, the problem is a sloppy implementation
  in arcgen. The mission phase map provides dates without clock time, with
  each phase starting one day after the end of the previous phase. The applied
  algorithm fails if the START_TIME of a kernel falls into this one day
  gap. Therefore, when getting the mission phase start and stop times from
  the table, we add 86400 seconds (one day) to the end time. When testing
  this, we noticed that there is no gap between the first two phases in the
  table, so we move the start of the second phase ("LAUNCH") forwasrd by one
  day (which also brings it in line with the MISSION.CAT). Then it works
  fine. Besides for this kernel, the mission phases for seven other
  kernels are also affected. They are now correct.

  ROS_SC_MES_160101_160930_V03.LBL is also correct now.

  In SPK/ROS_ORBITER_EXTENSION_V2.LBL there is now also the last phase,
  like for the extension CK. 
}

\begin{solved}
===========================================================================
Incorrect TARGET_NAME in labels:
===========================================================================


DATA/DSK/DEIMOS_K002_THO_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "67P/CHURYUMOV-GERASIMENKO 1 (1969 R1)"

   It should be 

TARGET_NAME                  = "M2 DEIMOS"



DATA/DSK/PHOBOS_K137_DLR_V02.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "67P/CHURYUMOV-GERASIMENKO 1 (1969 R1)"

   It should be 

TARGET_NAME                  = "M1 PHOBOS"



DATA/DSK/PHOBOS_M157_GAS_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "67P/CHURYUMOV-GERASIMENKO 1 (1969 R1)"

   It should be 

TARGET_NAME                  = "M1 PHOBOS"




DATA/DSK/TEMPEL1_9P_K032_THO_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "67P/CHURYUMOV-GERASIMENKO 1 (1969 R1)"

   It should be 

TARGET_NAME                  = "9P/TEMPEL 1 (1867 G1)"




DATA/FK/ROS_V33.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "67P/CHURYUMOV-GERASIMENKO 1 (1969 R1)"

   It should be like in other FK versions

TARGET_NAME                  = "N/A"




DATA/SPK/C2002_T7_LINEAR_HOR_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "N/A"

   It should be 

TARGET_NAME                  = "C/LINEAR (2002 T7)"


DATA/SPK/C2004_Q2_MACHHOLZ_HOR_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "N/A"

   It should be 

TARGET_NAME                  = "C/MACHHOLZ (2004 Q2)"




DATA/SPK/C2010_A2_LINEAR_HOR_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "N/A"

   It should be 

TARGET_NAME                  = "354P/LINEAR 58 (2010 A2)"



DATA/SPK/VESTA_HOR_V01.LBL

-- TARGET_NAME is set to

TARGET_NAME                  = "N/A"

   It should be 

TARGET_NAME                  = "4 VESTA"
\end{solved}

\BG{
  Revised and extended the assignment of target names in dependence on the
  kernel file name so that the target names are correct now in all these
  labels. Note that the DSKs have been renamed to get the shape model
  size tag in the file names correct.
}

\begin{solved}
===========================================================================
Incorrect DESCRIPTION in labels:
===========================================================================

DATA/DSK/ROS_CG_K050_OSPGDLR_N_V1.LBL

-- DESCRIPTION is set to 

  DESCRIPTION                = "Contain 67P/C-G shape data based on
                               OSIRIS images produced by DLR using
                               the SPG method with plate numbers
                               from 50K to 4M, for use with
                               Toolkits N0065 or earlier."

   Since this is a named surface DSK (_N_) it should be 

  DESCRIPTION                = "Contains 67P/C-G shape data based on 
                               OSIRIS images produced by DLR using
                               the SPG method with plate numbers
                               from 50K to 4M, for use with
                               Toolkits N0066 or later."
\end{solved}

\BG{
  This file name is missing in the description section of the aareadme.txt
  from which the description is taken, therefore my fuzzy matching algorithm
  picks the most similar one, which is ROS_CG_K050_OSPGDLR_U_V1.BDS. I add in
  the aareadme in the rel0004_staging area ROS_CG_K050_OSPGDLR_N_V1.BDS at
  the appropriate description. Now the correct description is picked, but
  this is the one missing a few words in the beginning, see following issue.
}                                 

\begin{solved}
DATA/DSK/ROS_CG_K100_OSPGDLR_N_V1.LBL
DATA/DSK/ROS_CG_K200_OSPGDLR_N_V1.LBL
DATA/DSK/ROS_CG_M001_OSPGDLR_N_V1.LBL
DATA/DSK/ROS_CG_M004_OSPGDLR_N_V1.LBL

-- DESCRIPTION is set to 

  DESCRIPTION                = "OSIRIS images produced by DLR using
                               the SPG method with plate numbers
                               from 50K to 4M, for use with
                               Toolkits N0066 or later."

   It is missing a few words at the start and should be 

  DESCRIPTION                = "Contains 67P/C-G shape data based on 
                               OSIRIS images produced by DLR using
                               the SPG method with plate numbers
                               from 50K to 4M, for use with
                               Toolkits N0066 or later."
\end{solved}
                               
\BG{
  Indeed, this description (it's the same that is picked for all these
  kernels) misses a few words. These have been added at the beginning.
}

\begin{solved}
DATA/DSK/ROS_CG_K200_OSPGDLR_U_V1.LBL

-- DESCRIPTION is set to 

  DESCRIPTION                = "OSIRIS images produced by DLR using
                               the SPG method with plate numbers
                               from 50K to 4M, for use with
                               Toolkits N0066 or later."

   It is missing a few words at the start and has incorrect
   last part because this is an unnamed (_U_) DSK. It should be

  DESCRIPTION                = "Contains 67P/C-G shape data based on 
                               OSIRIS images produced by DLR using
                               the SPG method with plate numbers
                               from 50K to 4M, for use with 
                               Toolkits N0065 or earlier."
\end{solved}
                               
\BG{
  The missing words are now already corrected, see previous issue. The wrong
  (_N_) description is picked because the exact file name is missing in the
  aareadme.txt. I add it and then it is correct.
}

\begin{solved}
DATA/DSK/ROS_CG_K006_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K012_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K024_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K050_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K050_OSPGDLR_N_V1.LBL
DATA/DSK/ROS_CG_K050_OSPGDLR_U_V1.LBL
DATA/DSK/ROS_CG_K097_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K100_OSPGDLR_U_V1.LBL
DATA/DSK/ROS_CG_K104_NSPCESA_N_V1.LBL
DATA/DSK/ROS_CG_K199_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K250_NSPCESA_N_V1.LBL
DATA/DSK/ROS_CG_K384_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K788_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_M001_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_M001_OSPGDLR_U_V1.LBL
DATA/DSK/ROS_CG_M002_NSPCESA_N_V1.LBL
DATA/DSK/ROS_CG_M003_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_M004_OSPGDLR_U_V1.LBL

-- DESCRIPTION starts with "Contain ". It would be more correct to 
   start it with "Contains ".
\end{solved}

\BG{
  "Contain " changed to "Contains " in all descriptions.
}

\begin{solved}
DATA/DSK/ROS_CG_K006_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K006_OSPCLPS_U_V2.LBL
DATA/DSK/ROS_CG_K012_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K012_OSPCLPS_U_V2.LBL
DATA/DSK/ROS_CG_K024_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K024_OSPCLPS_U_V2.LBL
DATA/DSK/ROS_CG_K050_OSPCLPS_N_V2.LBL
DATA/DSK/ROS_CG_K050_OSPCLPS_U_V2.LBL
DATA/DSK/ROS_CG_K097_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K097_OSPCLPS_U_V1.LBL
DATA/DSK/ROS_CG_K199_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K199_OSPCLPS_U_V1.LBL
DATA/DSK/ROS_CG_K384_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K384_OSPCLPS_U_V1.LBL
DATA/DSK/ROS_CG_K788_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_K788_OSPCLPS_U_V1.LBL
DATA/DSK/ROS_CG_M001_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_M001_OSPCLPS_U_V1.LBL
DATA/DSK/ROS_CG_M003_OSPCLPS_N_V1.LBL
DATA/DSK/ROS_CG_M003_OSPCLPS_U_V1.LBL

-- DESCRIPTION says "6K to 786K". The plate number range for this 
   producer's models is "6K to 3M".
\end{solved}
   
\BG{
  Changed accordingly.   
}

\begin{solved}
===========================================================================
Other corrections for kernel labels:
===========================================================================


DATA/SCLK/LANDER_170904_STEP.LBL

-- START_TIME should be set to the initial epoch of the clock

START_TIME                   = 2004-03-02T00:57:00

   (or at least the time used for other SCLKs: 2004-03-02T07:17:51)



DATA/SCLK/ROS_160929_STEP.LBL

-- START_TIME should be set to the initial epoch of the clock

START_TIME                   = 2004-03-02T00:57:00

   (or at least the time used for other SCLKs: 2004-03-02T07:17:51)
\end{solved}

\BG{
  In principle, the START_TIME is automatically extracted from the SCLK,
  however, the function that does it looks for the start of the first
  partition. For the kernels in question, the first partition does not
  start at zero, and thus the retrieved time does not correspond the the
  initial epoch of the kernel. For simplicity, we just set the START_TIME
  to the proposed value, 2004-03-02T07:17:51.
}

\begin{solved}
DATA/FK/ROS_DSK_SURFACES_V01.LBL

-- INSTRUMENT_HOST_NAME should be set like for other FKs (and DSKs):

INSTRUMENT_HOST_NAME         = { "ROSETTA-ORBITER", "ROSETTA-LANDER" }
\end{solved}

\BG{
  Changed accordingly.
}

\begin{solved}
===========================================================================
INDEX/ files
===========================================================================


INDEX/INDEX.TAB

-- is OK but ...

-- even though the current (rel0003) INDEX.TAB has this too, since 
   INDEX.TAB is regenerated, it would make sense to ROS_V25.TF's 
   creation time from 2015-11-23 to 2015-12-03 to be consistent with its
   label.
\end{solved}
   
\BG{
  This is a little bit tricky, as arcgen leaves lines present in the INDEX
  of the previous increment untouched. So I have to delete the line of
  ROS_V25.TF in the INDEX.TAB of my local copy of rel0003. Then the value
  from the rel0003 label is taken, which is just the desired 2015-12-03.
}

\begin{solved}
===========================================================================
DOCUMENT/*INFO.TXT files
===========================================================================


DOCUMENT/DSKINFO.TXT

-- should but does not describe 

DATA/DSK/DEIMOS_K002_THO_V01.BDS
DATA/DSK/PHOBOS_K137_DLR_V02.BDS
DATA/DSK/PHOBOS_M157_GAS_V01.BDS
DATA/DSK/ROS_CG_K096_OSPCLPS_U_V1.BDS
DATA/DSK/TEMPEL1_9P_K032_THO_V01.BDS
\end{solved}

\BG{
  Added ROS_CG_K096_OSPCLPS_U_V1.BDS to the list of an already present
  description. Added descriptions for the other kernels with corrected
  names (cf. above) taken from the dsk/aareadme.txt in the rel0004_staging
  area.
}

\begin{solved}
DOCUMENT/FKINFO.TXT

-- mentions ROS_V32.TF that is not in the archive

-- should but does not describe 

DATA/FK/ROS_DSK_SURFACES_V01.TF
DATA/FK/ROS_V33.TF
\end{solved}

\BG{
  Changed ROS_V32.TF to ROS_V34.TF (not V33, as we now have a new FK). Added
  description of the SURFACES FK taken from the fk/aareadme.txt in the
  rel0004_staging area.
}

\begin{solved}
DOCUMENT/IKINFO.TXT

-- should but does not describe 

DATA/IK/ROS_ALICE_V17.TI
DATA/IK/ROS_COSIMA_V14.TI
DATA/IK/ROS_SREM_V01.TI

-- after new corrected IKs are available (e.g. ROS_COSIMA_V14.TI, 
   ROS_STR_V12.TI), should be updated to mention them
\end{solved}

\BG{
  Added ROS_ALICE_V17.TI, ROS_COSIMA_V15.TI (not V14, as we have a new
  version), and ROS_STR_V12.TI to the file lists of existing descriptions.
  For ROS_SREM_V01.TI, there is no description in the aareadme.txt neither
  (which caused a wrong description picked for the label, by the way).
  So we had to add a desription in the aareadme.txt _and_ in IKINFO.TXT
  (this illutrated once more that all these files should consistently be
  created from a single source). We clean the IK directory and rerun arcgen
  to get the description in the label correct.
}

\begin{solved}
DOCUMENT/SPKINFO.TXT

-- should but does not describe 

DATA/SPK/C2002_T7_LINEAR_HOR_V01.BSP
DATA/SPK/C2004_Q2_MACHHOLZ_HOR_V01.BSP
DATA/SPK/C2010_A2_LINEAR_HOR_V01.BSP
DATA/SPK/LORB_C_G_FIXED_RBD_7_V2_0.BSP
DATA/SPK/MAR097_030101_170101_V0001.BSP
DATA/SPK/ROS_COG_V2.BSP
DATA/SPK/ROS_STRUCT_V6.BSP
DATA/SPK/VESTA_HOR_V01.BSP

-- after new corrected SPK(s) is(are) available (e.g.ROS_COG_V3.BSP), 
   should be updated to mention them
\end{solved}

\BG{
  We have already shortened long lines of SPKINFO.TXT with a script. In order
  to avoid interference of manual editing and automated processing, we work on
  the original version (with long lines) and have the script writing the
  processed version in the ARCGEN_OUTPUT directory. We add descriptions for
  C2002_T7_LINEAR_HOR_V01.BSP, C2004_Q2_MACHHOLZ_HOR_V01.BSP,
  C2010_A2_LINEAR_HOR_V01.BSP, LORB_C_G_FIXED_RBD_7_V2_0.BSP,
  MAR097_030101_170101_V0001.BSP, ROS_COG_V3.BSP (not V2, as we have a new
  version), ROS_STRUCT_V6.BSP, and VESTA_HOR_V01.BSP taken from the
  aareadme.txt. However, they have to be reformatted manually.
}

\begin{solved}
===========================================================================
EXTRAS/MK
===========================================================================


EXTRAS/MK/ROS_V06.TM

-- ROS_V06.TM has never been released and is superseded by ROS_V07.TM. It is
   not loadable because it refers to ROS_V32.TF not included in the archive.
   It should be removed from the archive.
\end{solved}

\BG{
  Removed ROS_V06.TM.
}

\begin{solved}
EXTRAS/MK/ROS_V07.TM

-- ROS_V07.TM should be renamed to ROS_V06.TM. The creation data included 
   in the comments (currently November 7, 2017) should be changed to something 
   closer to the time when it was actually made.

-- ROS_V07.TM is not loadable because of this entry in the kernel list
   (lowercase "ik"):

                          '$KERNELS/ik/ROS_SREM_V01.TI'

-- after new corrected kernels are available (e.g. ROS_COSIMA_V14.TI, 
   ROS_STR_V12.TI, ROS_COG_V3.BSP), this MK should be updated
   to use them.

-- after some discussion we propose to to still not include any DSK in this MK
   but consider making a new MK (e.f. ROS_WITH_DSK_V06.TM) that will include 
   a single DSK of your choice for each of the targets -- C-G, Steins, Lutetia, 
   Phobos, Deimos, and Tempel. 

-- Load-ability of the MK should be checked after all updates are made.
\end{solved}

\BG{
  In the meantime, I had even created ROS_V08.TM in order to accomodate
  the updated ROS_V34.TF, ROS_COSIMA_V15.TI, and ROS_DSK_SURFACES_V02.TF.
  So I remove also ROS_V07.TM and rename ROS_V08.TM to ROS_V06.TM. Corrected
  the lower case "ik". The new kernels are already employed by this MK.
  ROS_V06.TM is now loadable without errors. Created a new MK
  ROS_WITH_DSK_V06.TM where additionally one DSK is loaded for each of the
  six targets. This is also loadable without errors. While crosschecking
  the MK with MKINFO.TXT (cf. below), noticed that while MKINFO is correctly
  stating that multiple SPK files are needed to provide complete coverage of
  the orbiter in escort phase, only one of the three needed was actually
  loaded in the MK. So, corrected this in both V06 MKs.
}

\begin{solved}
EXTRAS/MK/MKINFO.TXT

-- needs to be updated to mention additional kinds of kernels that now
   appear in the MK (e.g. surface names FK; SPKs for comets, asteroid,
   and Mars system; SPK for COG)
\end{solved}

\BG{
  Now mentioning 67P/C-G radii PCK, DSK surfaces FK, comet, asteroid, and
  Mars system SPKs, Rosetta Center of Gravity SPK, and the target DSKs.
}

\begin{solved}
===========================================================================

To make the location SPKs more usable it would be good if the coverage of the
COG SPK matched the coverage of the ROS trajectory SPKs, in which case the
location of the s/c origin and locations of all instruments provided in
ROS_STRUCT_V6.BSP could be computed with respect to any object at any time
during the mission.

I think the easiest way to do this is to simply duplicate the first point in
your input set with the earliest ROS trajectory time (2004-MAR-02 09:25:17.397
UTC), duplicate the last point in your input set with the latest ROS trajectory
time (2017-JAN-01 00:07:42.816 UTC), and package this input with two additional
points into an SPK exactly as you did with ROS_COG_V3.BSP. If you choose to do
this, it would be good to add a note to the comments explaining what was done.
\end{solved}

\BG{
  Replicated first and last point of the input data as suggested and remade
  the SPK. Docuented this in the comments. Then it comes to my mind that
  we have to make this a new version ROS_COG_V4.BSP, as V3 was already
  released in the SKD. So renamed the file in the rel0004_staging area,
  cleaned the SPK directory, and rerun arcgen. Added the file name
  ROS_COG_V4.BSP to the SPKINFO.TXT. In the spk/aareadme.txt (from which
  the descriptions for the labels are taken) it is already version
  generic. Changed also V3 to V4 in the meta kernel.
}

===========================================================================
Other 
===========================================================================


-- checksum check is OK


-- all kernels, labels, catalogs, text files not mentioned in the notes
   above are OK.


===========================================================================
End.
===========================================================================
