Testing an ORViewer-generated load

February, 2021 Update: Test NLET files
    - How To Create a Dated NonLoadTrackedEvents.txt File
    - How To Use the Test NLET file in your lr run
June, 2017 Update: testing of ORViewer-generated load products.
Testing Mirror Loads
Testing Super Schedule Loads

February, 2021 Update: Test NLET files

For production runs of lr, the default NLET file that is used is:

/data/acis/LoadReviews/NonLoadTrackedEvents.txt

This file has the latest and greatest non-load events stored within it.

However, the fact that non-load events can occur in any load type means that lr must search for events WITHIN the start/stop time of the review load and include them in the thermal history.

But when you are reviewing a new weekly load, no such events within the load yet exist. After that load was approved and uploaded, non-load event may have occurred during the load execution aboard the spacecraft. These events are added to the production NonLoadTrackedEvents.txt file, and the time stamp of the event(s) will be within the start and stop time of the executing load.

So if, later on, you are testing a load that was reviewed and executed in the past, you must be certain that you use a copy of NonLoadTrackedEvents.txt as it existed at the time of initial review.

A collection of dated NonLoadTrackedEvents.txt files has been assembled in the directory:

/data/acis/LoadReviews/TEST_NLET_FILES/

By "dated" we mean that the naming convention used in this directory is:

[Load_week|load letter].NonLoadTrackedEvents.txt

For example: DEC2418B_NonLoadTrackedEvents.txt

The load letter is required in order to differentiate between A, B and C (etc.) loads.

How To Create a Dated NonLoadTrackedEvents.txt File

Of course if you only need the A load and not the B or C load for your particular tests you can just create the A test NLET file. But the next person who comes along to do testing may growl.

Using a test NLET file in your lr run

GetOptions('break' => \$break, #run lr_break options,
	   's=s' => \$server, #to be passed to acisparams.pl
	   'n=s' => \$hostname, #to be passed to run_PSMC.pl
	   'nolucky' => \$skiplucky, # acquire backstop manually
	   'clean' => \$easy_clean,
	   't=s' => \$test_dir,      # Test dirctory
           'nlet_file=s' => \$nlet_file); #NLET file name

Back To Top

Update for June, 2017 testing of ORViewer-generated load products.

A new round of testing started in May 2017. This round includes two kinds of test loads:

1. Mirror of the official Weekly Loads


2. Super Schedules

So in reality we have 3 different kinds of LR runs these days. Two of the runs use the production OCAT server. The three test types and the servers they use (in parenthesis) are:

1. Official Production Weekly Loads (ocatsqlsrv)


2. Mirror of the official Weekly Loads (ocatsqlsrv)


3. Super Schedules (SYBASE)

Weekly Mirror loads: These loads are built using the new ORviewer DOT generator and mirrors the observations for the week's official load. Use the production OCAT for processing this load. This load will appear before the official OFLS-generated load. Process this load first, using the MIRROR_LR version of lr (see below). When the Official OFLS load appears, process it using the Production version of lr.

Super Schedule loads: These Super Schedule loads are fictitious loads which are tested using the Test OCAT. There is no attempt to adhere to thermal planning limits, or populate a full week's worth of observations. Process these loads using the SS_LR version of lr (see below).

Important General Notes

It is CRITICAL that you use the -t switch for the Mirror and Super Schedule TEST loads:

• You do not want the backup directory to be created on Colossus-v,
• You do not want the load placed in the Load Review Web page,
• If this is an LR BREAK you REALLY do not want the production history files mucked with.

NOTE: ACIS-Continuity.txt files

Ever since the introduction of the NLET system, in early 2017, ACIS-Continuity.txt files have appeared in every ofls directory you make. The file is created by lr and is based upon the lr command line, and answers you supply lr if you used the --break switch. However this started with the JAN3017 load. Any load prior to that Does Not Have those continuity files. The thermal models will fail unless they exist.

When you are asked to run lr on a test load, the load itself may be fictitious but you have to supply the name of the continuity load - the load that was running prior to the start of the load you are reviewing. And for that you have to use an existing load. And if the load you are testing occurs before the JAN3017 load then you must determine the load types (Normal, TOO, SCS-107, STOP) of the continuity loads and edit in an ACIS-Continuity.txt file in the Continuity load directories.

lr will create the ACIS-Continuity.txt file for the Test load in the Test Load directory.

NOTE: The Test load type may be totally different from the original load it was taken from. For example the JUN2716T load was a full stop load whereas the actual JUN2716 load was Normal.

So the drill is to:

1. cd into the ofls of the continuity load
2. Determine whether that load was Normal, TOO, SCS-107, STOP
3. Create the appropriate ACIS-Continnuity.txt file in the ofls directory.

You can determine the type of load the Continuity load was by looking at the load review announcement.

The ACIS-Continuity.txt file consists of 2 lines:

1. the full path to the Continuity file for the load being reviewed
2. Type of the load being reviewed (either Normal, TOO, SCS-107, STOP) and the interrupt time (if appropriate)

So for example, suppose you are reviwing the MAR2519 load. This was a normal load which follows the MAR1819 load. So the contents of the MAR2519 ACIS-Continuity.txt file are:

/data/acis/LoadReviews/2019/MAR1819/ofls
Normal

The first line tells NLET and lr where to go next to backchain the history of the MAR2519 load. Note that it is a full path.
The second line tells you that the MAR2519 load is a Normal load.

Another example is the OCT2118 load. This was the Return to Science load after the Full Stop of the 2018:283 event. It interrupted the OCT0818 load at 2018:283:13:54:39.00.

So the OCT2118 ACIS-Continuity.txt file contents are:

/data/acis/LoadReviews/2018/OCT0818/ofls
STOP 2018:283:13:54:39.00

If the OCT2118 load was a TOO interrupt load you'd put TOO instead of STOP at the start of the second line. You'd have the Time of First Command as the time stamp on the second line.

For SCS-107 events - where the science load has stopped but the maneuver load continues - the second line would begin with SCS-107, and the time stamp would be the interrupt time.

The process entails going back to look at the Continuity loads and inserting the ACIS-Continuity.txt file on THOSE directories.

NOTE: Target Directory Location

2017/MIRROR for the weekly Mirror loads

2016/SUPER for the Super schedule loads. This is assuming the Super Schedule load is a 2016 load.

You can call the subdirectory under MIRROR or SUPER anything you like. I include my initals to show who ran the load and the load name (e.g. JUN0117L). An example in MIRROR is G4_MAY2217L.

NOTE: Soft Link to point to the Resultant Directory

We would like to keep the Production directory fairly clean of test subdirectories.
However, from time to time the directory you just created with the LR run must be used as the Continuity load for a subsequent Test Load..

So create a soft link in the appropriate (2016 or 2017) directory so that the MIRROR or SUPER
directory can be used as a continuity file. The LR format for the soft link name must be followed:

ABCXXYY

ABC represents the month (e.g. JAN, APR, SEP etc); XX the day of month
and YY the year (16 or 17). However you want to be able to distinguish
between these test loads in the 2016 (or 2017) directory and the real thing.
So put something different in the first of the three letters. You can use the "letter" of the load.
So for example, if you are testing the JUL0116U load,
the link can be UUN0116. Just be sure that the starting
letter is not one used for a normal month (e.g. M).

NOTE: Backstop File Location

When you run lr, it tries to help you get the backstop file by printing out a line with the "get". However for MIRROR LOADS this line is in error:

For example, for the JUN1917L load the line it prints out is:

    get /home/SOT_Transfer/JUN1917/JUN1917L_backstop.tar.gz

But that's NOT where the backstop file is located. It will be found here:

    /home/SOT_Transfer/JUN1917L/JUN1917L_backstop.tar.gz

The directory after SOT_Transfer in these mirror loads will have the Load letter ("L" in this case) as part of the name.

When you're done, symlink your test directory to something like XCT1016 so the next person through this way knows what to link to.

Back To Top