• View
• Edit
• History
• Print

Model Inputs

• runme file
  • Grid specification
• Solar wind/IMF data
• Virtual satellite orbits

runme file

The "runme" file contains input parameter definitions for the simulation run (see explanation of runme parameters). This includes the compilation and target machine specifications, grid definition, mhd settings, input and output definition, start and end dates, and ionosphere and inner magnetosphere model specifications. The OpenGGCM distribution comes with a script called "generate_runme" which creates a runme file based on the current default model settings.

   $OPENGGCMDIR/run-template/generate_runme

You will end up manually setting TARGET, TUSER, RUNTIME, the usual grid definitions, STARTTIME, ENDTIME, DIPOLTIME, SWFILE, SWMON to your designated satellite, INPAVE to the averaging interval, IDATA to where your timecoded satellite data resides, f107 to the F10.7cm solar flux during the event, MOX, MOY, MOZ, the satellite position at the time of observation, and others more advanced parameters, if necessary. Below is an example runme file (warning: parameters and/or settings may be old).

• Attach:runme_wiki

Back to top

Solar wind/IMF data

The OpenGGCM requires the input of the following data:

• Time series of solar wind (SW) parameters and interplanetary magnetic field (IMF). These usually come from solar wind monitors such as ACE or WIND. Alternatively one can also use made up SW/IMF data to test model responses or specific processes.
• Solar F10.7 cm radio flux (as proxy for solar UV/EUV radiation). This is a slowly varying parameter.
  • If the RCM is used, sunspot number is also required for charge exchange calculations.

For the time series solar wind and IMF data, the model will either accept a "swdata" file of the format below or separate time series files for each parameter (which will be used to auto-create a "swdata" input file).

An example "swdata" file is shown below:

   -999.00    0.000    3.535  3.535   -400.000     0.000     0.000    7.000    4.000  1.0  0.0  0.0
   120.000    0.000    3.535  3.535   -400.000     0.000     0.000    7.000    4.000  1.0  0.0  0.0
   239.000    0.000    3.535  3.535   -400.000     0.000     0.000    7.000    4.000  1.0  0.0  0.0

Each line of this file corresponds to a different time (data is linearly interpolated to the simulation time steps at the boundary). The columns describe various solar wind parameters:

• Column 1: Time (min)
• Column 2: IMF <math>B_x</math> (nT)
• Column 3: IMF <math>B_y</math> (nT)
• Column 4: IMF <math>B_z</math> (nT)
• Column 5: Solar wind <math>U_x</math> (km/sec)
• Column 6: Solar wind <math>U_y</math> (km/sec)
• Column 7: Solar wind <math>U_z</math> (km/sec)
• Column 8: Solar wind density (particles/cc)
• Column 9: Solar wind pressure (pPa)
• Column 10: X component of sunward boundary plane
• Column 11: Y component of sunward boundary plane
• Column 12: Z component of sunward boundary plane

The alternative to the swdata file is to use actual satellite measurements as the input. Data is available from a variety of sources, such as CDAWeb, but in the end it must be processed into separate time series files for each parameter, such as:

   om2010.btot   om2010.bzgse  om2010.rr     om2010.vygse  om2010.zgse
   om2010.bxgse  om2010.bzgsm  om2010.temp   om2010.vzgse
   om2010.bygse  om2010.np     om2010.vtot   om2010.xgse
   om2010.bygsm  om2010.pp     om2010.vxgse  om2010.ygse

with each file having the following format:

   2010  1  1  0  2  0.000     0.13000000
   2010  1  1  0  3  0.000     0.05000000
   2010  1  1  0  4  0.000     0.07000000
   2010  1  1  0  5  0.000    -0.06000000

with columns for year, month, day, hour, minute, second, and value. The satfilter perl script below can be used to convert native data files from ACE, GEOTAIL, GOES12, OMNI, POLAR, or WIND to these data files while filtering out bad data.

• Attach:satfilter.txt (rename to satfilter.pl)
• Attach:DateConversions.txt (rename to DateConversions.pm)

The runme variables SWMON, SWFILE, INPAVE, and IDATA would need to be set properly to use these inputs.

Back to top

Virtual satellite orbits

The OpenGGCM will retrieve data from the model at a specified location. This can be used to sample the data at a fixed position or in the orbit of a virtual satellite, using actual satellite ephemeris if desired. Ephemeris data for most scientific satellites can be retrieved from http://sscweb.gsfc.nasa.gov/cgi-bin/sscweb/Locator.cgi by following the steps below:

1. Select Satellites and the start-stop range
2. Click the "Ouput Settings" and select GSE coordinates in the XYZ column.
3. Click "Output Units/Filtering"
4. Select yy/mm/dd and hh:mm:ss
5. Enter "8" for the number of decimal places.
6. Click "Submit query and wait for output"

Copy the ASCII output to a file and delete the comments at the top and bottom, leaving only data. Copy the file into the run folder with the name sscweb.txt. Make sure you have a valid runme in the same folder and execute the following command:

   $OPENGGCMDIR/run-template/mak.orbits

This perl script will generate a file called orbits.txt that will be read by OpenGGCM during the run.

Make sure that the ORBITFILE is set to orbits.txt and SATOUT is set to true in your runme.

After the event run has completed, you must postprocess the $RUN.timehistNNNNN files with the following script:

   $OPENGGCMDIR/run-template/mak.timehistplot --run  $RUN --sort

This will create separate output files in a subdirectory called timehist.dir for many MHD parameters (and magnetic field line information, if the RCM is selected to run).

Back to top