Downloads:

In order to run the offline tester/visualizer tool, the following command should be executed:

java -jar ISSVis.jar [options]

If you are generating an animation, the tester uses a significant amount of memory. You may need to employ a command such as below to allocate more memory. The actual value depends on the resolution of your images.

java -Xmx1000M -jar ISSVis.jar [options]

Options

Each of the options below can be abbreviated to fewer characters

The tool needs to have access to the file, ISS_simple.model. Once this file is downloaded and placed on your local disk, you can specify its location and name by using the -model option. The default path if the option is not specified is ISS_simple.model in your current working directory.

-model <absolute or relative path>

The tool can work in two modes -- execute solution mode and CSV mode.

1. Execute solution mode.

In this mode, the tester will execute your local solution in a subprocess. It is launched as follows:

java -jar ISSVis.jar -exec <command to execute your solution> [other options]

1.1. Interaction between the tester and your solution in execute solution mode.

Your solution will need to communicate with the tester via standard input/output streams. Here is the complete interaction protocol that you should implement:

Read the value of beta from standard input.
Create an instance obj of your implementation of class ISS.
Call obj.getInitialOrientation(beta) and let yaw be the return value.
Print yaw to standard output.
Flush standard output.

For minute = 0, 1, ..., 91:
    Make sn arbitrary number (possibly 0) of calls to the "library" method. (This is explained in detail below.)
    Call obj.getStateAtMinute(minute) and let ret be the return value.
    Print "1" (quotes for clarity) to standard output on a separate line.
    Print the 20 elements of ret to standard output, one element per line.
    Flush standard output

Each number read from standard input will be on a separate line. Each number you output to standard output must be on a separate line. It is necessary to flush standard output after the data for each step is printed.

If you correctly implement the protocol above, the tester will evaluate your solution. If your answer does not violate any hard constraints, you will see your raw score, otherwise you will see an error message.

By default, your solution is evaluated on beta = 75. It is possible to supply another value of beta using -beta option:

-beta <value of beta angle>.

1.2. Rendering.

The tool will also visualize and animate your solution if you supply the

-rendering

option. You can explicitly tell the tool to draw no visualizations with the

-norendering

option, although this is its default behavior.

Resolution of the rendered picture can be set with -resolution option:

-resolution <resolution in pixels>

The tool renders the ISS from two viewpoints, each of them will have a size of resolution x resolution pixels. The default value of resolution is 501.

The view that is shown at the left is made from a fixed point. The viewer looks towards the origin point. The coordinates of this point can be varied with the -view_alpha and -view_beta options:

-view_alpha <v_alpha angle>

and

-view_beta <v_beta angle>.

The view will be rendered from a point where the sun would be located for alpha = v_alpha and beta = v_beta. The default values are v_alpha = 60 and v_beta = 45. You will probably want to specify a positive value for v_beta when beta is positive and a negative value when beta is negative.

The image that is shown at the right is made with the viewpoint in the direction of the current location of sun. The viewer again looks towards the origin point. Both images are rendered with an orthographic projection (i.e. not perspective). Using both of these views helps you see where shadows are being cast and what objects are casting the shadows.

The quality of picture can be improved with antialiasing. The amount of antialiasing is specified by:

-subsamples <antialiasing level>

The value of 1 (default) means no antialiasing. If you provide a value X > 1, then pixels near edges will be rendered with X*X subsamples.

It should be noted that rendering is quite time consuming. The time required to render a frame is approximately proportional to resolution2 * subsamples2. You can experiment with different settings to find the most appropriate balance of picture quality and rendering speed. Rendering at a resolution of 1000 and subsamples of 3 or 4 produces a very nice looking animation.

The tool will also display the following important data for each frame:

After all minutes are calculated, the display will also include:

The rendering options described in this chapter can be used for CSV mode as well.

Once your solution has completed and all time steps have been rendered, the tester enters animation mode. The display window will cycle through all the rendered frames. The following commands are available in animation mode while the keyboard focus in on the rendering window:

1.3. "Library" method calls.

As stated in the problem statement, the offline tester provides an additional (unnamed) library method that you can use to evaluate arbitrary positions. This method takes 13 angles as input parameters (alpha, beta, yaw, 2 SARJs and 8 BGAs) and calculates the following 696 values as output (in this order):

You can call this library method with any angles, in any sequence, any number of times. In order to make a call, do the following:

Print 2 to standard output.
Print the value of render flag ("1" or "0") to standard output.
Print 13 input parameters of the method to standard output.
Flush standard output.
Read 696 return values from standard input.

Let's call the following order of BGAs standard: 1A, 2A, 3A, 4A, 1B, 2B, 3B, 4B.

The correct order of input angles is: alpha, beta, yaw, starboard SARJ, port SARJ and BGAs (in standard order).

The order of the return values is:

The value of render flag must be 1 if you'd like a frame to be rendered for this library call and 0 otherwise. Rendering will only work if you launched the tool with -rendering option, otherwise the value of render flag will be ignored.

2. CSV mode.

In this mode, the tester/visualizer will read data from a CSV file rather than run your program. It comes in two flavors: strict and relaxed.

In order to launch in this mode, do the following:

java -jar ISSVis.jar -csv <relative or absolute path to a CSV file>

A CSV file in any mode should consist of a header line and several lines with data. The header line is ignored by the tester, so you can put any contents there.

2.1. Strict CSV mode.

In this mode, your CSV is expected to contain a valid solution that satisfies all hard constraints. If it is indeed valid, the tester will display the score value, otherwise an error message will be printed. Essentially, this is similar to execute solution mode, if you made no library calls and your solution was pre-calculated.

The CSV file should contain 1 header line and 92 data lines with 22 columns. The columns are:

beta, yaw, SSARJ angle, SSARJ speed, PSARJ angle, PSARJ speed, BGA 1A angle, BGA 1A speed, BGA 2A angle, BGA 2A speed, ..., BGA 4B angle, BGA 4B speed.

Each of beta and yaw columns must contain the same value in each line, these being the input beta angle and your yaw angle. The next 20 columns contain the angles and angular velocities of all 10 rotation rotary joints. In other words, these columns contain the same 20 values that are returned by the getStateAtMinute method.

2.2. Relaxed CSV mode.

In this mode, your CSV is supposed to contain some data that you'd like to be evaluated or rendered. It can be any data, not necessarily a valid solution.

Now, the CSV file should contain only 13 columns:

alpha, beta, yaw, SSARJ angle, PSARJ angle, BGA 1A angle, BGA 2A angle, ..., BGA 4B angle.

So all velocity data is removed from the file, since it is not necessary for anything except solution validation.

Your CSV file is allowed to contain absolutely any data, as long as all angles are within allowed ranges. The alpha values are now used with the beta values to specify the location of the sun in each frame (not necessiarly at fixed time steps). The beta and yaw columns do not have to have the same values in each line in this mode.

The tool will still evaluate and/or render the data from your CSV as if it represented a valid solution. In particular, it will calculate the power output numbers and show all the same data in rendering mode.

Your CSV file is allowed to contain less than 92 data lines (having more than 92 lines is not supported currently). Also, it is allowed to tell the tester to process only the first several lines of the file. This is done using -frames option:

-frames <number of data lines to process>.

If your CSV file has fewer than 92 lines, then you always need to use this option. Otherwise, the tool will try to process all 92 lines (and fail).

3. Additional options.

Some additional options that you can use are listed below.