Freqently Asked Questions

GESOP is the Graphical Environment for Simulation and Optimization. ASTOS is the Analysis, Simulation and Trajectory Optimisation Software for Space Applications.
 
ASTOS is a multi-purpose tool for space applications. It was originally designed for trajectory optimization but now it provides a variety of analyss, simulation and design capabilites for the whole space project life-cycle. The optimization software GESOP is still used inside the core of ASTOS.

GESOP is the software system for trajectory analysis of whatever dynamic systems governed by a set of nonlinear differential equations, associated boundary conditions, path constraints and cost functions. GESOP includes several different optimization techniques, an initial guess generator, a simulation program and several evaluation tools.  It combines all this together in a graphical user interface. Only the program code of the optimization problem has to be written in Fortran 77, Ada 95, C or Matlab outside this environment. Simulink models can also be optimized after they have been exported using the Real-Time Workshop.

ASTOS incorporates all the GESOP features plus a myriad of other features which make it a really powerfull tool. ASTOS includes an extensive set of libraries for environment models, aerospace vehicle components, sensors, ground stations, complex constraints and cost fuctions, differential equations for 3-DOF and 6-DOF, and many, many other features and capabilites: a powerful batch mode inspector tool (which allows monte carlo simulations and orchestration of a complex data chain), mission analysis features (coverage, navigation, visibility, eclipse, link analyses, etc.), system concept analysis (power, data and thermal systems) , plotting and animation tools and a multitude of export capabilites. Using ASTOS is more user friendly and provides a lot more features even just for optimization. The user does not have to code anything. As example, several launch and mission analysis scenarios are provided with the installation of ASTOS.

 

1. batch - includes the configuration files needed to run a batch mode as well as homotopy.xml a file containing the batch variables and their values
2. gismo - contains the files used for the optimization iteration history plots. These files contain key parameters of the optimization scenario for stored iterations at a user defined frequency.
3. integ - contains the results of the simulation or analysis: simulation.struct or some_analysis.struct
4. model - contains the xml files with the configuration done in the modelling tree
5. plot - contains configuration files for diagrams and plots shown in Viewer and the settings made in Astroview
6. reports - contains created reports templates and figures used in the reports
7. geometry - contains geometry files with 3D models of spacecrafts and their components
8. exports  - is the default target for an export
9. input.tops - is the file containing simulation settings, grids and (optimal) optimization variable values and bounds
10. error.log - is a file containig a more detailed log of the errors displayed in the execution log; the errors displayed here can help identify more easily the main source of why you have an error
 

From Version 7, ASTOS and GESOP are available as multi-platform:

• Windows (XP, VISTA, WINDOWS 7)
• Linux (tested on Debian squeeze KDE, Ubuntu 11.4 and Kubuntu 11.4)
• Mac OSX (tested on 10.6)

Windows allows the folder name to include special characters and empty spaces. Unfortunately this support is not complete: two characters present in the keyboard and accepted in the folder name are not correctly managed by the batch routine.

Due to this incompatibility, GESOP/ASTOS will not work if installed in a folder that includes the character "&" or "^" in its path. Moreover the name of the working folder (whatever.gtp) of GESOP/ASTOS cannot include these characters ("&" or "^") in its path.

To illustrate this, you can install ASTOS in "C:\Program Files\my programs\ASTOS" or work in a folder called "C:\my work\a!~`#$%()_-+={}[]';.,äëöüéèàá.gtp", but you cannot work in a folder called "C:\my work\Launch&reentry.gtp".

GESOP/ASTOS saves the license position in the registry. If your user does not have the rights to write in the registry (i.e. it is not an administrator), this information is lost and at the next action (simulation, initialization, optimization) you will be requested to provide again this information.

The solution is to launch GESOP/ASTOS as an administrator once, perform one action and provide the position of the license file.

If you are using "VISTA Home Basic" please contact us at service@astos.de, since this version of the operating system is not applying correctly the administrator rights.

In case the optimization feature is enabled, the user can use either of the three options: Simulate Multiple Shooting, Simulate Single Shooting, Simulate Connected Phases.
In case the optimization feature is disabled, there is a single button for simulation, which is equivalent with Initial guess and Simulate Connected Phases with Normalized time.
The differences between them are explained in Help, chapter 6.5 of the User Manual (Optimization> Integration Settings)

Perigee and apogee altitudes are always computed with respect to the equatorial radius of the planet. Only the vehicle altitude considers the ellipsoid defined by the planet's object.

In the case of a spherical planet, there is no difference. This is also true in case of an ellipsoidal planet with an equatorial orbit. In all other cases the altitude and the orbit altitude plot will differ up to the difference between polar and equatorial radius (22 km in the case of Earth).

The Load_Factor (g) computation inside ASTOS (the constraint and the auxiliary functions) is the ratio between the total_forces acting on the vehicle and the gravity force. The total force does not contain the gravity force.

This is inline with the common understanding of Load factor, two examples can explain the situation:

• free-fall without drag, g=0, only the gravity force is present, but since it is not included in the total force, g is equal to 0.
• object fixed on the ground, g =1, the total force acting on the object is the reaction of the ground equal to the gravity Force, so
  total force = gravity force, g = 1.

The Trim_6dof aerodynamic model needs to be used with a 6DoF equation of motion (Inertial_velocity_6DOF and Flightpath_6DOF ), otherwise some variables cannot be computed correctly.

Whenever a normal 3DoF equation set is used, the following error is displayed in the ASTOS program log:

NaN value(s) found in phase 1 at t = 0.00000000000000E+00:
Algebraic function XXX is NaN! Reset it to Zero.

Where XXX is an integer (usually around 120).

The simulation is correctly computed, only the function XXX (Pitch_moment) is set to 0.0 at the initial time.

The attitude control should be set to "Uncontrolled_Euler_Angle" or to "Uncontrolled_Aero_Angles".

In a launcher long coast arc, typically between the first upper stage burn and the second one, the attitude control is modelled as "Reduced Euler Angle" linear-law.

What happens is that the flight-path angle is very low (2 degrees), the pitch is low (5 degrees) but the angle_of_attack is quite large, in the order of 40-50 degrees.
This seems "strange", but it is inline with the definition of "Reduced Euler Angle" (see ASTOS Model Library 12.4, reduced Euler angle control). The angle_of_attack considers the angular distance between two frames: the body-axis and the velocity-frame. In this situation not only flight-path angle and pitch are considered, but also yaw and flight-path azimuth. The yaw is defined as a linear law to link the previous phase final value with the initial value of the next phase (the two burn phases), but on the ground-track the vehicle is passing over the pole: the flight-path azimuth changes considerably. The difference between yaw and flight-path azimuth increases the angle_of_attack (as defined in case of reduced Euler angel control). This becomes clear when plotting the yaw and flight-path azimuth.
 
This situation will happen every time the user uses this type of control (reduced Euler) in a coast arc where the flight-path azimuth changes considerably (over the pole passage or simply at a very long phase). Since the normal application of this attitude control is in phases where there are no aerodynamic effects and where the vehicle is axial-symmetric, a large angle of attack will not affect the computation.

A Vertical Ascent in ASTOS is modelled as follows:
 

• EOMs are inertial velocity in local horizontal axis system (radial, east, north) and relative position (radius, longitude, declination),
• The heading angle or azimuth is not defined as long as the flightpath angle is 90deg,
• Attitude controls are yaw counted from the north and pointing to the direction of initial heading. During the vertical ascent pitch is constant 90 deg.

Pitch and Yaw are defined in the local horizontal axis frame which is oriented at the spherical planet but not at the oblate body!

Two different problems can be observed during the vertical ascent:

   1. Problem: Longitude gets smaller, Rocket starts westwards

It can also be explained in the following way: The rocket ascents vertically with the inertial east velocity component of the launch site. There is no change to this velocity component and so the requirement V_east = R*omega for a vertical ascent is violated. The planet turns below the rocket. This leads to a small offset of the rocket to the west during the vertical lift-off and therefore the x-axis of the aerodynamic and body axis-system do not longer coincide.

   2. Problem: Pitch is not oriented at Oblate Horizontal Plain

Under real conditions the rocket is oriented vertically, where thrust TO and gravity G act contrary as shown by the red vectors. In the mathematical model the gravity force has the same direction in both frames but not the thrust vector TL, which is oriented along the radial axis of the L-frame. As the EOMs are computed in the L-frame it is clear, that gravity and thrust are not acting in the same line, which results in an angle of attack not equal zero. The deviation from zero is about 0.1deg.

For more information, please contact  service@astos.de.
 

Let's use an example: the objective is to stop a phase when the Mach number becomes greater than 3. This is expected to happen at around 95 seconds.

The steps are:

1. In Phases & Common Settings go to the phase where Mach number becomes greater than 3. Insert a phase end time higher than the time when a Mach number of 3 is expected (e.g. 150 seconds).
2. Then enable the Additional phase end conditions and select Add to add a Mach number condition.  Select Phase ends if: value equal or greater than reference and insert 3 for Reference. 
3. Initialize and simulate. (just simulate, if optimization is disabled)

The final/initial boundary checks the function value at the end/beginning of the specified phase(s) comparing to the reference value; the path constraint instead checks the selected function during the specified phase(s). The user should insert constraint "grids" (constraint evaluation points) where the path constraint is checked.

Please note that the path constraint cannot be used to check a function at beginning or at the end of a phase.

The constraint is still associated to a not existing phase, therefore a warning is printed in the execution log.

The solution is to go through all the constraints and identify the ones defined in the non existing phases. To get rid of the warning, you can either delete the constraint, or assign it to an existing phase. 

During your work with ASTOS (or GESOP), if you experience the following error:

Exception:
java.lang.OutOfMemoryError: Java heap space
....

It means that the memory allocated for Java is completely used.
The setting of ASTOS/GESOP should prevent this error for most of the applications, but if you experience it you can increase the memory allocated.

1. Please open the "start.bat" file from the installation path of ASTOS/GESOP with a text editor.
2. Search for the line ":run_astos" (:run_gesop).
3. In the following line insert "-Xmx1600m" instead of "-Xmx1024m" (-Xmx512m for GESOP).
4. Save the file and restart ASTOS/GESOP

If when Initializing (or simulating) a test-case, you receive the error message:

"Updating C:\working_folder\test_case.gtp\model
Process terminated with status -2147483648"

You don't have the writing permission on the folder where the case is placed (C:\working_folder\test_case.gtp), or the files of the folder are read-only.

Solution:

• In the file explorer of windows, right click on the folder (C:\working_folder\test_case.gtp), 'Properties', eliminate the 'Read-only' flag (let this apply to the full folder and sub-folders).
• Copy your test-case in a folder where you have writing permission, ask your IT administrator in case.

Other print out errors caused by a read-only folder could be:

Gesop_Main   : exception 'ADA.IO_EXCEPTIONS.USE_ERROR' caught while writing simulation file. Sim_Data_Util.Write_Graphics_File: exception caught.

This error refers to the impossibility to open a dll.

With ASTOS5, when you try to run a case, if you get the following error:

Gesop_Model  : initializing.
DLL_Open: Cannot load library 'Y:\gesop\bin\WindowsNT\ASTOS_Model\gesop_model.dll'
C:\ASTOS\bin\WindowsNT\gesop_main.exe: exception `DLL_LOADER.DLL_LOADER_ERROR' caught.
   Further Info: Exception name: DLL_LOADER.DLL_LOADER_ERROR
Message: dll_loader.adb:98

Process terminated with status 1

The cause is the "Read-only" flag on the test case (the gtp folder). Remove it and the case will work properly.

If it is the first time that you run GESOP, this error is normally caused by a missing compiler in your system.

As a GESOP first user, you run the Bryson-Ho tutorial and when trying to Initialize, a cmd-window opens and says:

Cannot open file 2 'gesop_model.dll'! (6)

The cmd-window include also some text explaining that "cl" is not recognize as internal or external command. And finally

ERROR #9009 OCCURRED

GESOP requires the user to write his model in C, Ada or Fortran. A compiler is then required then to produce a dll and GESOP will interface with this DLL.

"cl" is the C compiler command, please install a C compiler on your computer. We suggest "Microsoft visual C++ Express edition" (free edition).

Perhaps you need to change some of your windows variables: the path and the include one. Here after an extract on some variables that should be present in you windows (just write "set" in a cmd-window to receive your complete list):
"DevEnvDir=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE
INCLUDE=C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE;
LIB=C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;
LIBPATH=C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;
Path=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program
Files\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files\Microsoft
Visual Studio 9.0\Common7\Tools;C:\Program Files\Microsoft Visual Studio
9.0\VC\VCPackages;C:\WINDOWS\system32;C:\WINDOWS;
VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0\VC
VS90COMNTOOLS=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\
VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0"

A similar solution is required for Ada and Fortran.

On some Windows XP computers, we experienced strange errors when the test case (gtp folder) is located in a long path with empty spaces.

The error message displayed is not related to the real error, but it could include information about integration problem or model errors.

In case the test case should work properly: it is included in the ASTOS installation or it was working on another computer, please try to place the gtp folder in a shorter path (e.g. C:\work\example.gtp).

In Linux and MAC, the test case (gtp folder) cannot be placed in path with empty spaces. This is a limitation independent from ASTOS.

Phase Overview presents a list of all the phases with the initial and final independent variable (time) values.

In case the font dimension is too big, instead of the phase number three dots are displayed (...), this is the situation in case of a default Ubuntu installation (GNOME).

In order to solve the problem, please change the application font dimension to 10 (default is 11) and restart GESOP/ASTOS.

The same solution applies to the numeric cells of Tool Inspector - Optimize and - Result summary.

• Windows (DOS) uses CR+LF
• Linux uses LF
• MAC uses CR

Where LF = Line Feed; CR = Carriage Return.

The parsing function implemented in the programming language used by ASTOS requires LF: text files created by Windows and Linux are properly working, but text files created by MAC not.

A solution is to use a text editor in MAC able to insert LF at the end of the lines.

The initialization settings are present in the Optimization tab

There, after pressing Update Model Data the list of Phases is updated with the list of Phases inserted in the Modelling Tree. \
The grids (major grid nodes, control refinement points and constraint evaluation points) for each phase can be set as well as the option to initialize from file or from control law.

Note: the number of grids to add is something that can affect your optimization in a complex manner. Too many is bad, too few, is also bad. The "right" amount comes with experience. As rule of thumb you can use 1 major grid node for every 50 second in a phase (sometimes less, sometimes more, it depends a lot on the problem). Phases where a lot of control is needed should have more control refinement nodes, but adding too many may create a "chattering" attitude profile. For constraint evaluation point, you should add as many as required to keep the specified value in the limits. If this discretization is not enough you can always add more, later. Starting with less grids can help make your problem simpler.

After this is setup, just press Initialize in the lower right part of the window, or from the main ribbon. The action is the same. 

 

During a complex optimization task it could happen that the found trajectory differs a lot from the initial guess one. The states present in the equation of motion need major grid nodes in order to be handled by the solver and each grid node has bounds. The solver can modify each major grid only between the upper and lower bound.

During the initialize process the state bounds are automatically set, wide enough to avoid any problem during the optimization process, but in case of a final trajectory very different from the initial guess it could happen that a major grid node is at its bound.

In this situation it is useful to select "Update State Bounds" from the Optimization ribbon.

This question applies to ASTOS 7 versions (Astos Amateur Rocket Edition included)

To deselect a component in the "Jettisoned_Component" table of the phase panel of Model Browser, simply keep the CTRL button of the keyboard pressed and reselect the component.
Follow the same procedure to make a multiple selection: keep the CTRL button pressed while selecting components with the mouse.

In Astos 8 and later versions the selection/deselection of a jettisoned assembly  is done via a checkbox.

1. Go to main ribbon Database Connections. Under Connections click on Add. Type the database name and select the location of the file.
2. Go to your profile table, right click. Select Create Variable and Link. Select Database Variable and for DB Connection ID select the name given in step 1. Type also the name you want for the variable.
3. Go to Variables tab > Database Variables and type the Excel query for your data.
4. Press Update values to populate the table.
5. Each time the Excel file is changed, an update is required.
6. Save. Initialize/Simulate/Optimize. The excel data will be used for your profile.

• my_worksheet!A1 or my_worksheet!c1r1 for a scalar floating pointvalue variable from the first cell
• my_worksheet!A1:C10 or my_worksheet!c1r1:c3r10 for a profile datatable variable with values from the first 3 columns and first 10 rows
• my_worksheet!A1:A10;my_worksheet!C1:C10 or my_worksheet!c1r1:c1r10;my_worksheet!c3r1:c3r10 for a profile datatable variable with values from the first column and from the third one (non consecutive range)and first 10 rows.

In Phases & Common Settings, at the end of the window there is a list of all phases created (just below the simulation settings). There is a menu which permits the user to Merge, Split, Move a phase up or down, or Delete a phase.
Alternatively, by right clicking on a phase name in the list of phases in Phases & Common Settings you can Clone, Delete, Rename, Merge with next or Split a phase.

The typical interpolation tool inside ASTOS is used to define profiles for all the topics: components, propulsion, aerodynamics etc. It is available only for specific elements through selecting Defined by: Profile instead of Value.
Chapter 2.10.2 Profile Data Tables inside the Help > User Manual details on the use of Profile.

You can interpolate with many columns. For example, you can insert a profile of an aerodynamic coefficient with altitude, time, mach number derivative of another coefficient. So the capability to do multi table interpolation is present.

Note: whenever time is used in a profile table, the values inserted have to be monotonically increasing. (i.e. the sequence 0 5 10 20 7 25 for time is not allowed) Also you cannot add negative time. 
 

In a simple case without any constraint, CAMTOS is unable to optimize:

Model_Integration.Build_Coupling_Grid: WARNING:
parameter 1 has no constraint coupling!
Density of Jacobian : +Inf**%
Model_Integration.Constraint_Derivative: Unknown exception caught during
variation of parameter # 1
Model_Integration.SNOPT_Opt.Run: exception CONSTRAINT_ERROR caught.
gesop.exe: Unknown exception caught.
CONSTRAINT_ERRORException name: CONSTRAINT_ERROR
Message: model_integration-constraint_derivative.adb:186 index check failed

Simply add a constraint to solve the problem.

• during the initial guess. the constant value inserted will be used (e.g. 30 degree)
• during the optimization, this angle will change to any profile to achieve the optimal

• optimizable as control - will allow the solver to use any profile to be used for that control (i.e. a complicated curve)
• optimizable as parameter - will only allow a linear profile to be used for that control (this can and should be used for example in coasting phases, where control is not effective, to link the final value of an attitude angle from the previous phase to the initial value of the same attitude angle in the next phase)

A control grid consist of major nodes and control refinement points.

Go to Attitude in a specific phase in Vehicle & POIs Dynamics and for a given angle (i.e. yaw) check the box Optimizable. Select Optimizable as: Control.
Save. 
Go to the Optimization tab, and then to Initialization Settings.
Click on Update Model Data. Then go to the specific phase where you have inserted the control (yaw) and expand the tree. You should see the selected angle as one of the controls, in this case YAW. Click on it (check the checkbox) and in the right side add as many nodes as required.

The alternative way is to add the control refinement points from the Grids, inside the Optimization tab. Go to Grids, select the specific phase, double click YAW from the list of controls and click on Show or Show in New Tab (to add a new tab in the Viewer). Then, by double clicking on the figure you can add control refinement points.
 

Starting from Windows Vista, there is a new option to stop the working process of your computer: Sleep.

With this option the computer will require a small amount of electrical power, but can recover itseft in a very short time (this is the default status when you close the monitor of a Laptop). Unfortunately, due to the action order performed by Windows, this operation cannot be performed during an optimization task.

The optimization will be interrupted and GESOP/ASTOS itself could become unstable and not responding after the recover of the computer.

As solution use Hibernation: no power consumption is required and the optimization will continue as soon as the computer will be recovered.

During the optimization process, the solver prints on the ASTOS main window several information that can be used to understand if the optimization is proceeding in the right direction. The Help details on the meaning of that in Optimization Theory and Description of Methods > Monitoring Optimization Iterations.

Inside the Viewer there is also a button called Review Iterations. This will show incrementally the evolution of different parameters (i.e. cost function, real parameter, step size, etc) with every step of the optimization (the frequency of the output can be selected inside the Optimization Settings > Iterations Review Plots. (default value is 5 - which means every 5 iterations a plot is produced)

 

The Optimize tab (just below the Modelling tab) allows you to set all the options specific to this action.

The transcription method can be selected (it is called optimization method in the user interface; examples are TROPIC, SOS, CAMTOS, etc), the solver (NLP solver; examples include WORHP, SNOPT, MIDACO, etc,) as well as typical values related to the constraint and optimization tolerances can be set. In case of CAMTOS phase specific settings are available in the bottom part of the window.

The collocation methods are identified by the word "Colloc", e.g. Colloc Hermite; the others are multiple shooting methods, e.g. Runge Kutta 45.

For some transcription methods (i.e. CAMTOS) you can set up phase specific settings for the integration (i.e. Integration Method, ODE Tollerance, integration errors). These are different than the integration settings from Phases & Common Settings! Some are used for the integration during optimization, the other for integration during simulation, which are different topics of ASTOS.

Finally, the Optimization ribbon has the Optimize (Cold Start) which is the button the user should use after the Initialization is done and the user is satisfied with the Initial Guess (a too bad initial guess will almost never converge; i.e. if your vehicle flies to the middle of the earth, you will not get geostationary by pressing Optimize!)

• heavily negative mass in the initial guess
• flying towards the center of the Earth due to wrong definition of dynamics, ineffective thrust or starting gravity turn too early and trying to achieve an orbital trajectory
• impossible to satisfy constraints
• phase bounds defined incorectly (lower/upper bound reached - unable to improve the solution); use check bounds after each optimization
• not enough freedom in control or lack of control in a phase where it is needed
• large disconnections in state, controls or real parameters
• complete lack of discretization (no major grid nodes, no control refinement nodes, no path constraint evaluation points)
• vehicle too heavy (unable to fly fast enough)
• too little mass in the upper stage burn (thrust to weight ratio becomes very large when the mass of the last stage goes towards zero)
• ignoring the optimization tutorial and tips inside the help

• Select "Map Plot" (or "3D Map Plot") as "Plot Type" in the Viewer or Results > Curve Plots.
• Insert "longitude" and "latitude" (and "altitude" for 3D Map Plot) --> Show
• In the viewer window, form the "Data" menu, select "Auxiliary Items..."
• Activate the desired ones.

If "Auxiliary Items..." is gray, verify the splash-down constraint in Optimization > Constraints; it needs to be present in Constraints Info.

If this constraint is "Enabled" the user can choose to avoid an area (like an island, restricted area, a populated region or a heading line) in which the falling stage is not allowed to fall. If successful, the optimization will be done in such a way that the falling stages will respect this constraint.

The trajectory plotted in the Viewer (from Quick View) contains only the output points specified in the "Simulate" tab of "Tool Inspector".
In particular, if the "Output Spacing" is set to "Interval Length = 1.0" this will produce one output point at each unit of the independent variable:

• in case of NOT normalized time = 1 output point every second OK
• In case of normalized time = 1 output point every phase NOT GOOD

In case of Normalized time, simply switch the "Output Spacing" to "Number of Points = 101" to obtain enought output points.

There are 2 ways to check the range in ASTOS:

1. with Horizonal range.
Go to Vehicle & POIs Dynamics > your Vehicle. Go to Default settings and scroll down.
At the bottom of this page there will be a list of Auxiliary states. One of them is Horizontal Range. If you enable this state, you will get it in the list of States in the viewer.
Horizontal range integrates the distance along the trajectory. 

The disadvantage of this is that a new state is introduced and this adds complexity to the optimization problem. If just a simulation is needed, then it is not a problem.

2. with Target Distance 

The alternative is to add target distance path constraint, active in all the phases, not enforced. The information to be inserted as latitude and longitude are the coordinates of the launch-pad. This will output the surface distance between the launchpad and the projection of the vehicle on the surface. The reference can be zero, as this constraint will not be used in the optimization, but just to create the auxiliary output called target distance.

The disadvantage of this is that it can be used only with Optimization. You cannot add constraints in a Simulation.

Note:
There are other outputs in Distances (Auxiliary functions) which could be confused with the range described above in points 1 and 2. They are:

• arc length
• cross range (distance between current point (i.e. landing site) and the initial orbital plane
• down range (distance between the initial point (i.e. entry point) and the projection of the considered point (i.e. landing site) on the initial orbital plane
• great circle distance (distance between the entry point and the current point (i.e. landing site) measured along the great circle that connects both these points

Cross, down and great circle ranges are measured in inertial space and are not the relative distances measured along the rotating celestial body!
 

Most of the functionalities of the Viewer are described in Help in Chapter 2.2 Viewer of the User Manual.

The usual definition of downrange is the projection on the ground of the Launch Vehicle distance from the launch site.
However, in ASTOS, when plotting the Aux Function called down_range~Vehicle_Name you can expect something else.

The short answer is you should never use cross_range, down_range and great_circle_distance to compute distances for launchers, these are only usable for reentry cases.

ASTOS computes these ranges differently in 3 places: as constraints, as cost functions and as output auxiliary functions. Internally, ASTOS computes all of these as angles, derived from inertial vectors.

• for constraints, the angles get multiplied by the planet local radius
• for cost functions, they are directly the angles
• for output auxiliary functions, they get multiplied by the equatorial radius

As a relationship, the great circle distance is the spherical angle sum of the cross range and down range:

cos(great_circle) = cos(down_range)*cos(cross_range)

What should you use instead for a launcher?

1. Run a tracking analysis, (after having added a Launch facility/Ground Station at the initial launch site). From its output, take that great_circle_distance instead of the one in the Auxiliary functions of ASTOS, which is in the Distances category.
Please note they are slightly different in naming convention:

i.e.
great_circle_distance->Launch_Point~Vega_Rocket§Tracking. (vs great_circle_distance~Vega_Rocket ).

Please note that across multiple ASTOS versions, the naming convention might change. You can still expect the name of the Analysis to be appended to the function name, as well as to find this output in the correct category of Auxiliary functions (i.e. Analyses).

2. Activate the Horizontal Range Auxiliary State. This is done in the Vehicle & POIs Dynamics, in the Default Settings.

Auxiliary States are not recommended for Optimization unless needed. They can always be activated later, after the optimization is done.

Please note, the 1st method produces an output which is decreased once the vehicle turns "on the other side" of the Central Body. The second method keeps integrating the range.

Some of the elements of the Model Browser are associated to real parameters. Thus, changing the name of one element could lead to a change in the name of a Real parameter. 
This is done automatically by ASTOS when either Simulate/Optimize button is pressed.
The Structure Mapping popup window appears, letting the user know that there is a discrepancy between the TOPS file and the model data, with a yellow warning flag coresponding to each phase where there is a discrepancy.
The user needs then to manually add the missing link between the TOPS and model different names (by clicking once on the TOPS parameter name and once on the Model parameter name). 
Then the user is asked if he would like to create the same link in all the other phases.In this way the value of the newly-named parameter is copied from the value of the old parameter, without any loss of information.
If this modification is not performed manually by the user, ASTOS has no information about the new parameter and the mission will be reinitialized (with Control Law or from file) with the consequent loss of the current solution (the trajectory is reinitialized).
 

This question window pops up automatically when a connected real parameter is manually modified by the user using the Real Parameters tool inside the Optimization tab.
Usually the answer should be "YES"; GESOP/ASTOS will change the value of the connected parameter (with the same name) in all the phases.

The automatic update is based on the parameter name, but there is an important exception: when a linear law is used as control law (i.e.pitch), the connection is between PITCH and final_PITCH/initial_PITCH of the previous phase/next phase (the name is different, therefore no auto-update is done in cases like this). 

Some real parameters are created with the bounds defined by the definition of the related angles: pitch is defined from +90 to -90 degree, therefore at the beginning of the pitch-over phase the parameter is at its upper bound (90 degree).
Check bounds will therefore show a warning regarding this. To get rid of this warning, the user can set the initial_PITCH from Real Parameters to not be optimizable: simply uncheck the Optimize parameter box. Performing check bounds after this will not show a warning anymore.