FREQUENTLY ASKED QUESTIONS:
Are there plans in
the future to provide the source code in another language such as C?
There are C-versions of some of the earlier IRI codes. But I am not aware of a C Version for IRI-2012.
I am entering my own
solar index values but do not see changes in the F peak density NmF2
For the F peak plasma frequency, foF2, and therefore also
for the related F peak density, NmF2,
the solar cycle variation is described with the help of the ionospheric
global index IG that is based on measurements from of foF2 by selected ionosonde stations. IRI uses the 12-month running mean of
IG. Changing the solar 10.7 cm radio flux index F10.7 or the sunspot number R
will not affect foF2 and NmF2. You have to enter your own values for IG12 to see
the effect on foF2 and NmF2. Because the profile is
normalized to NmF2 this will also affect the electron density in the bottomside and topside F-layer.
Starting with IRI-2016 the correlation between IG12 and R12 is used to change also IG12 if a user provides R12 and vice versa.
I am not sure which one
of the solar indices in the IG_RZ.DAT and APF107.DAT files are definitive and
which are predicted
All indices in the APF107.DAT file are definitive except for the last two values in each line which are the 81-day average of the solar 10.7cm radio flux F10.7 (F5.1) and the 365-day average of F10.7 centered on the date of interest (F5.1). At start and end of the index file the 81-day and 365-day averages are calculated taking only the available indices, e.g. for the first date the 81-day average is only over 40 F10.7 values and over 41 values on the 2nd date. In the IG_RZ.DAT (also ASCII) the release date is given in the first line in the form Month, Day, Year. Next is a blank line and than Start_Month, Start_Year, End_Month, End_Year for the indices given in the file. The indices provided are the 12-month running means therefore the last definitive is the one six month before the given release date, so for a release date of Jan 2013 the first predicted index is the one for July 2012.
What is the format of
the APF107.DAT file and which parameters are included
The format of the file is explained in subroutine APF in IRIFUN.FOR: year(I3), month(I3), day(I3), 3-hour Ap indices for the UT intervals (0-3), )3-6), )6-9), .., )18-21), )21-24( in an array of dimension 8 (8I3), daily Ap (I3), -11(I3), F10.7 radio flux for the day (F5.1), 81-day average of F10.7 radio flux (F5.1), 365-day average of F10.7 centered on the date of interest (F5.1). At start and end of the index file the 81-day and 365-day averages are calculated taking only the available indices, e.g. for the first date the 81-day average is only over 40 F10.7 values and over 41 values on the 2nd date.
What is the format of
the IG_RZ.DAT file
The indices file IG_RZ.DAT contains
the 13-month running mean of the ionosphere global (IG) index (IG13) and of the
sunspot number (Rz13). IG is based on foF2 measurements from selected ionosonde stations The file is structured
as follows (values are separated by comma) line by line:
month,day,year of the last update of this file,
a blank line
start month, start year, end month, end year,
a blank line
the IG13 index for December of start
year - 1 (needed for interpolation)
the 12 IG13 indices (13-months running
means) for start year,
the 12 IG13 indices for the second year
.. and
so on until the end year,
the IG13 index for January of end year
+ 1 (needed for interpolation)
a blank line
the Rz13 index for December of start
year - 1 (needed for interpolation)
the 12 Rz13 indices for the start year,
the 12 Rz13 indices for the second year
.. and so on until the end year.
the Rz13 index for January of end year
+ 1 (needed for interpolation)
A negative Rz13 index means that the
given index is the 13-months- running mean of the solar radio flux (F10.7). The
close correlation between Rz13 and F10.7_13 is than used
to compute the Rz13 indices. An IG index of -111 indicates that no IG13 values
are available for the time period. In this case a correlation function between IG12
and Rz12 is used to obtain IG12.
Have there been
efforts to assimilate data into IRI or to update IRI with measured data
There are quite a number of different mathematical methods
for data assimilation and model updating. Here are a few references:
Assimilation: (1) Yue
Xinan, William S. Schreiner, Ying-Hwa
Kuo, Douglas C. Hunt, Wenbin
Wang, Stanley C. Solomon, Alan G. Burns, Dieter Bilitza,
Jann-Yenq Liu, Weixing Wan,
Jens Wickert, Global 3-D Ionospheric
Electron Density Reanalysis based on Multi-Source Data Assimilation, J. Geophys. Res., 117, A09325, doi:10.1029/2012JA017968,
2012.
(2) Galkin, I. A., B. W. Reinisch,
X. Huang, and D. Bilitza (2012), Assimilation of GIRO
data into a real-time IRI, Radio Sci., 47, RS0L07, doi:10.1029/2011RS004952.
(3) Schmidt, M., D. Bilitza, C.K. Shum, and C. Zeilhofer, Regional 4-D modeling of the ionospheric
electron density, Adv. Space Res. 42, #4, 782–790, doi:10.1016/j.asr.2007.02.050,
2008
Updating: (1) Hernandez-Pajares M., J. Juan, J. Sanz, and
D. Bilitza, Combining GPS measurements and IRI model
values for Space Weather specification, Adv. Space Res. 29, #6, 949-958, 2002.
(2) Bilitza, D., S. Bhardwaj,
and C. Koblinsky, Improved IRI predictions for the
GEOSAT time period, Adv. Space. Res. 20, #9, 1755-1760, 1997.
Why do I have to
specify a height even if I generate a height profile of an IRI parameter
This question relates to the IRIweb online interface as well as the IRI_WEB subroutine in IRISUB.FOR. In both cases you can decide what type of profile you want to generate. This can be a latitudinal, longitudinal, diurnal, etc profile of an IRI parameter. If you select a latitudinal profile you than have to select the begin, end, and stepsize for the latitude interval. You still have to also enter a latitude in the earlier part of the IRIWeb interface or the IRI_WEB subroutine arguments, but this value will be ignored. The same hold true for any other type of profile, e.g. altitude.
Why do I get
discontinuities in the height-derivative of electron density at the E-valley top
The E-region valley electron density profile is modeled by a 5th order polynomial that is defined by the following constraints: (1) Takes the value NmE at hmE and has derivative=0 there; (2) Produces valley with given WIDTH, so density at hmE+WIDTH is NmE; (3) Reaches the lowest density at height h_deep with derivative=0 at that point; (4) Valley has the DEPTH=(NmE-N(h_deep))/NmE; (5) Derivative at valley-top divided by NmE is DLH. Coefficients A(2:5) are determined from given WIDTH, DEPTH, HD=h_deep-hmE, and DLH. The transition at the valley top is continuous in value but not in derivative, because the DLH is given as input and not determined from the F1-region profile function.
Why do I get discontinuities
at sunrise and/or sunset in the diurnal variation of electron density in the
E-valley region?
Because of the very deep night valleys we had to switch to a logarithmic
representation at nighttime. Please also see answer to “Why do I get
discontinuities in the height-derivative of electron density at the E-valley
top”.
I am getting a NaN
for electron density
In some rare cases,
when computing the electron density, a NaN can be obtained. It was found that in the computation of the
magnetic inclination DIP= ASIN(BDOWN/ BABS) in the igrf_dip subroutine of the
igrf.for file the argument BDOWN/BABS of ASIN can be slightly larger than
1.0, thus generating the NaN. This has to do with the compiler used and the
system on which the program is being run, because the same rare case did not
case problems for other configurations.
A simple fix is to change
the statement
DIP=ASIN(BDOWN/BABS)
into the following four statements
argasin=BDOWN/BABS
if(argasin.gt.1.0) argasin=1.0
if(argasin.lt.-1.0) argasin=-1.0
DIP=ASIN(argasin)
Problem with blank COMMON being initialized
twice
Some compilers
complain about the blank COMMON being initialized in two subroutines (SHAMDB0D
and SHAB1D of IRIFUN.FOR) . Here is a step-by-step solution to the
error:
Open
irifun.for:
Replace
lines 5388-5389, 5560-5561, and 5734-5735 with:
"
COMMON /bnew/BINT,BEXT,RE,TZERO,IFIT,IB,KINT,LINT,KEXT,"
"
* LEXT,KMAX,FN"
Replace
lines 5392-5394 and 5566-5568 with:
"
THETA = 180."
"
ICEN = 0"
"
IREF = 0"
Add
the following subroutine just above SUBROUTINE SHAMDBOD on line 5356:
"
SUBROUTINE INITB ()
"
PARAMETER (IBO=0,JBO=1,KDIM=6,LDIM=4,L=-1)
"
DIMENSION FN(0:KDIM,0:KDIM), CONST(0:KDIM,0:KDIM)
"
DIMENSION BINT(0:KDIM,0:KDIM,1-IBO-JBO:LDIM),
"
* BEXT(0:KDIM,0:KDIM,1-IBO-JBO:LDIM)
"
COMMON /bnew/BINT,BEXT,RE,TZERO,IFIT,IB,KINT,LINT,KEXT,
"
& LEXT,KMAX,FN
"
DATA RE,TZERO,IFIT,IB,KINT,LINT,KEXT,LEXT
"
* /6371.2,1.0, -1, 2, 6, 4, 0, -1/
"
RETURN
"
END
Save
and close irifun.for and open irisub.for
Add
the following line after line 1293:
"
CALL INITB()"
Save
and close irisub.for
Run
compilation/link command in Fortran
I get WARNINGS when compiling
IRIDREG.FOR
The
large BLOCKDATA statement used for the FIRI model for the D-and E-region causes
some compilers problems. The WARNINGS mostly are due to the fact that such
large BLOCKDATA statements slow down the program and take lots of memory.