Third Party development documentation


SPENVIS model interface requirements

In a nutshell

Models implemented within SPENVIS are accessed through a web interface. For each model, the system provides the user with one or several HTML forms to enter the model inputs.

Two types of input are foreseen:

  1. model parameters: in SPENVIS, these are inputs given by by the user in HTML forms and written to a FORTRAN namelist file, which is then read by the model;
  2. data files produced by other models, e.g. an ephemeris file written by the orbit generator.

The output produced by the model can be divided into two categories:

  1. results of model calculations in the form of report files (in HTML format) and ASCII data files to be used for plotting or as input to other models or applications;
  2. warning and error messages to the user.

Some details

A. Model execution

A.1 Execution errors

When an error is detected during the model execution, the model code should generate an ASCII file spenvis.err containing the error message and should exit with a normal status code (i.e. 0). After the model execution, the SPENVIS system will detect the existence of the file spenvis.err and will return the error message to the user. When the model code exits with a non-zero status code, a generic error message is returned by SPENVIS to the user.

B. FORTRAN Namelist file: spenvis.nml

All the model parameters should be read from one or more FORTRAN namelists stored in the file spenvis.nml located in the user directory. Generally only one namelist is used.  Two illustrations:

B.1 Example of a namelist used by TREPPOS (Earth trapped radiation on a coordinate grid)

 &treppos
 SPECIES = 'P'
 TRPMOD = 2
 MINDP = 1
 ENP = 50.0
 ALPHA = 90.0
 IMAP = 2
 /

B.2 Example of a namelist used by SEP (Solar energetic ions)

 &sep
 FLAMOD = 4
 ITFLARE = 0
 ISTART = 0
 FLPROB = 95.0
 HIFLUENCE = 1
 ION1 = 2
 ION2 = 3
 IFLATT = 1
 ISTORM = 1
 NENERS = 45
 ENERFL(1) = 0.1
 ENERFL(2) = 0.5
 << 42 lines removed >>
 ENERFL(45) = 500.0
 /

Inside the model, default values should be defined for all the parameters. For example the model accepting the namelist of example 2 should also work properly with the following namelist file:

 &sep
 /

When the model is implemented into SPENVIS, the namelist parameters are documented in TN1.

C. HTML Report file: spenvis_xxp.html

Each model should produce a report file in HTML format, which summarizes the model inputs and results.

The report file may contain hyperlinks to report files produced by other models in order to reduce the length of the report (using relative URLs).

The report file should be named spenvis_xxp.html where 'xx' identifies the model (for already existing 'xx', see http://www.spenvis.oma.be/help/models/outputs.html).

The report source code should look like

<html>
  <head>
     <title> ${PROGRAM_NAME} </title>
  </head>
  <body bgcolor="white" link="blue" vlink="blue" alink="blue">
    <center>
      <table border="0" cellspacing="2"> <tr>
          <td align="left"> <b> SPENVIS ${SPENVIS_VERSION} </b></td>
          <td align="right"> <b> ${EXECUTION_DATE} ${EXECUTION_TIME} </b> </td>
        </tr> <tr>
          <td colspan="2" align="center"> <b> ${PROGRAM_NAME} </b> </td>
        </tr> <tr>
          <td colspan="2" align="center"> <b> Project: ${USER_PRODEF} </b> </td>
        </tr> <tr>
          <td colspan="2" align="center"> <b> ${USER_TITLE} </b> </td>
      </tr> </table>
    <center>
    <p>
    ${REPORT_BODY}
    </p>
  </body>
</html>
where ${USER_PRODEF} and ${USER_TITLE} are the user's project name and title, which could be obtained from either the namelist (parameters PRODEF and TITLE) or an input data file (meta variables PRJ_DEF and PRJ_HDR).

D. Input/output "MF" data files

In order to facilitate both the data transfer between models and the creation of graphs, a generic ASCII tabular format has been defined during the TREND-4 project, firstly to be used within the UNIRAD package and afterwards largely applied to SPENVIS models. As far as possible, the output data file(s) produced by the model should be compliant with this format. Basically each output file is divided in blocks; each block contains several sections:

  1. one header line providing information on the sizes of the other sections
  2. one or more comment lines
  3. a set of meta variables (such as PRJ_DEF and PRJ_HDR)
  4. a private section, used by SPENVIS to store PostScripts annotations
  5. the description of the variables stored in the body section
  6. the body section containing the values associated to all the variables of the dataset
  7. one footer line, indicating the end of both the body section and the block

An overview of the format is provided at http://www.spenvis.oma.be/help/models/outputs.html, more details are available at http://trend.aeronomie.be/trend4/format/.

In the framework of SPENVIS:

D.1 Example 1

'*',    90,     1,    40,    47,     1,    45,    -1,     0
'SPENVIS 4.6.3.1825           - 24-Feb-2010 12:41:03'
'PRJ_DEF', -1,'PROJECT'
'PRJ_HDR', -1,'My title'
'MOD_ABB', -1,'SEP'
'MIS_PLA',  1,    3,' '
'MIS_NTR',  1,    1,' '
'MIS_STA',  1,  20819.00000000,' '
'MIS_END',  1,  21184.00000000,' '
'MIS_DUR',  1, 3.650000E+02,'days'
'ORB_HDR', -1,'Geo at 120'
'ORB_TYP', -1,'GEO'
'ORB_MJD',  1,  20819.00000000,' '
'ORB_YEA',  1, 2007,' '
'ORB_MON',  1,  1,' '
'ORB_DAY',  1,  1,' '
'ORB_HOU',  1,  0,' '
'ORB_MIN',  1,  0,' '
'ORB_SEC',  1,  0.0,' '
'ORB_APO',  1, 3.579323E+04,'km'
'ORB_PER',  1, 3.579323E+04,'km'
'ORB_INC',  1,     0.00,'deg'
'ORB_RAA',  1,    99.54,'deg'
'ORB_ARG',  1,     0.00,'deg'
'ORB_TRA',  1,   120.00,'deg'
'ORB_PRD',  1, 2.393444E+01,'hrs'
'ORB_DUR',  1, 1.994537E+01,'days'
'ORB_TSE',  1,  21184.00000000,' '
'ORB_AXM',  1,  2,' '
'ORB_MJR', -1,'1 Jan 1950, 00:00 UT'
'ORB_GDR', -1,'Astron. J. 66, 15, 1961'
'SEP_MOD', -1,'ESP total fluence'
'SEP_TMI',  1,  0.0,'years'
'SEP_TMA',  1,  1.0,'years'
'SEP_DUR',  1,  1.0,'years'
'SEP_NCY',  1,  2,' '
'SEP_NOR',  1,  0,' '
'SEP_NAL',  1,  0,' '
'SEP_PRB',  1,  95.0,'%'
'SEP_OMN',  1, 1, ' '
'ENERGY', 45,   0.10,   0.50,   1.00,   2.00,   3.00,   4.00,   5.00,   6.00,   8.00,  10.00,  12.00,  15.00,  17.00,  20.00,  25.00,  30.00,  35.00,  40.00,  45.00,  50.00,  60.00,  70.00,  80.00,  90.00, 100.00, 120.00, 140.00, 160.00, 180.00, 200.00, 220.00, 240.00, 260.00, 280.00, 300.00, 320.00, 340.00, 360.00, 380.00, 400.00, 420.00, 440.00, 460.00, 480.00, 500.00,'MeV'
'RIGIDITY', 45,  13.65,  30.52,  43.16,  61.06,  74.80,  86.39,  96.62, 105.87, 122.31, 136.82, 149.96, 167.79, 178.73, 194.01, 217.20, 238.24, 257.67, 275.83, 292.94, 309.19, 339.59, 367.75, 394.16, 419.14, 442.94, 487.69, 529.41, 568.79, 606.27, 642.18, 676.79, 710.27, 742.78, 774.44, 805.36, 835.61, 865.26, 894.38, 923.02, 951.21, 979.00,1006.42,1033.50,1060.26,1086.74,'MV'
'PS Annotation',  8,  2
<< 8 lines removed >>
'PS Annotation', 24,  1
<< 24 lines removed >>
'PS Annotation', 12,  0
'Solar proton model: ESP total fluence'
 0.05, 2.00, 0.00
'Mission duration: 1.00 years, spanning 2 solar cycles'
 0.10, 1.50, 0.00
'0.00 years in solar maximum'
 0.15, 1.50, 0.00
'1.00 years in solar minimum'
 0.15, 1.50, 0.00
'Confidence level: 95.000%'
 0.10, 1.50, 0.00
'Geomagnetic shielding: disturbed magnetosphere'
 0.10, 1.50, 0.00
'Attenuation',' ', 45,'Attenuation Factor for ','ENERGY'
 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943
<< several lines removed >>
0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943, 0.9943
'End of File'
  

E. External data files

For SPENVIS, it is recommended to include most model data inside the model code.  When it is not possible, the absolute path to either the external data file or the folder containing the data files should be specified as a string parameter of the main Namelist section (see B.).This can be illustrated by the following example:

 &devicesum
 NDEVICES = 2
 LETFLAG = 0
 EXTRADEV = '/data/www/www.spenvis.oma.be/www-4.6.3_RC03_20100205-MK/data/upseto/Devices.nml'
 /
 &upseto
 INDEX = 1
 DEVICE = 'D424100V'
 IU = -1
 IB = 1
 PLDISTR = 0
 DMATERIAL = 'Si'
 /
 &upseto
 INDEX = 2
 DEVICE = '01G9274'
 IU = -1
 IB = 1
 PLDISTR = 0
 DMATERIAL = 'Si'
 /
  

F. Model implementation

Most of the models available in SPENVIS are implemented in FORTRAN. The SPENVIS CGI script allows to handle something implemented as a binary executable (e.g. when developed in FORTRAN), as PHP script or as BASH shell script. The first option is preferred while the last option is not recommended. Tools are currently available to support an implementation in FORTRAN or PHP (less documented).

In order to facilitate the compilation of the model by SPENVIS, it is recommended to collect all the source files in a single folder and to include a makefile named MODEL.mak (where 'MODEL' identified the model).

As an illustration we provide the makefile used to compile SHIELDOSE2:

FC      ?= gfortran
FFSTAT  ?= -fno-automatic
IFLAGS  ?= -I../..
LD       = $(FC)
LDFLAGS ?= -static
RM       = rm -f

SRCS   = sd2.for doscon.for protbd.for elbrbd.for utils.for \
         ../../putils.for ../../format.for
OBJS   = $(SRCS:.for=.o)
MAIN   = ../../../bin/sd2

$(MAIN): $(OBJS)
    $(LD) $(LDFLAGS) -o $@ $(OBJS)          

.phony: clean
clean:
    $(RM) $(OBJS) $(MAIN)

%.o: %.for ../../interface.h
    $(FC) -c $(IFLAGS) $(FFLAGS) $(FFSTAT) $< -o $@

In the above illustration, the files putils.for, format.for and interface.h are part of the SPENVIS toolkit. The other FORTRAN files are specific to the SHIELDOSE model.

The following environment variables are used for the FORTRAN compilation:


Template Quick Reference - Directives


Directives oriented towards the developer:


Directives internally used by the system:


General construction:


Functional directives:


Logical directives:


Iteration directives:


Variable:




baseURL




browseDir




cgi_extract




cgi_info




dataFile




define




expression




fileContent




fileExist




formErrorMsg




getLastSaved




hasRun




import




include




isDefined




isPackage




loop




loopCgi




loopProjects




loopResults




menuBar




package




packageName




projectTitle




selectCase




scriptURL




thisProject


Template Quick Reference - Actions


Actions oriented towards the developer:


Actions oriented towards the user:


Actions internally used by the system:




deleteFile




mergeForm




namelist




resetToPrevious




removeResult




runIDL




runModel




saveForm




sendPage




properties




sendResult


Annex: trend.aeronomie.be/trend4/format/

TREND-4 MF format: File specifications

The (new) UNIRAD tabular outputs are sequentially organised files consisting of variable-length records whose length is indicated by an explicit terminator embedded in the data. The record terminator is the 2-character sequence consisting of a carriage-return and a line-feed (ASCII codes 13 and 10, respectively). Except for the 2-character terminator, the records only include readable ASCII characters with code between 32 and 127. Such files can be created by a FORTRAN programme with the following statement:
      OPEN(UNIT=n, FILE='project.csv', FORM='FORMATTED', 
     :     ORGANIZATION='SEQUENTIAL', RECORDTYPE='STREAM')
where the text in italics depends on the user application.

Each record contains comma (,) separated values that can be read by a FORTRAN list-directed READ statement. The integer and floating values are represented by their decimal forms (e.g. 123, -98, 734.5, -3.2345E+10, +6.2345D+68), optionally preceded by white space characters (ASCII code 32). The character strings are delimited by apostrophes (') without other characters before or after the apostrophes. When an apostrophe has to be included in the character string, it is represented by two consecutive apostrophes.

Example

The use of the file specifications is illustrated by the following FORTRAN programme.
      PROGRAM sample_1
C
      INTEGER      k1, k2
      REAL         r1, r2
      CHARACTER*32 s1
C
      DATA k1, k2, r1, r2/ -547, 12, -5.978E-18, 6371.2/
C
C     File creation
C
      OPEN(UNIT=1, FILE='sample_1.txt', FORM='FORMATTED', 
     :     ORGANIZATION='SEQUENTIAL', RECORDTYPE='STREAM')
      WRITE(1,1000) k1, r1, k2, r2
      CLOSE(1)
C
C     format
C
 1000 FORMAT( i6, 1h,, 1p, e13.6, 0p, 2h,', 
     :        'Text with an apostrophe:''''.', 2h',, i8, 1h,, f10.3)
C
C     File read
C
      OPEN(UNIT=1, FILE='sample_1.txt', STATUS='OLD')
      READ(1,*) k1, r1, s1, k2, r2
      CLOSE(1)
C
      PRINT*,k1
      PRINT*,r1
      PRINT*,s1
      PRINT*,k2
      PRINT*,r2
      END
When imported in a spreadsheet programme, the content of the sample_1.txt file appears as

Internal organisation

A UNIRAD output file contains one or more independent parts, each being associated with a section of the corresponding UNIRAD namelist. Note that, for some applications, more than one part can be associated to a single section of the namelist. Each part includes three sections: a header, a body, and a footer. The following sub-sections describe the general structure of these three sections.

The general structure is illustrated with the help of an example file.

Header section

The records included in the header section contain general information on the data (project title, main parameters of the programme used to generate the data,...), and a description of the content of the body section. The header section includes also a reserved area that can be extended for futur usage. The following table give a detailled description of the structure of the header section. Note that the number of records varies with the application.

RecordElementsDescription
1'*', nheader, ntext,
nmeta, nfut, nvar,
ncol, nbody, npart
The first record of the header section consists of a character string and eight integers. The character string serves as guard and shall always be set to a single asterisk ('*'). The integers provide the information on the size of the header and body sections:
  • nheader is the total number of records of the header section (including this record);
  • ntext is the number of text lines included in the first part of the header section;
  • nmeta is the number of metavariables;
  • nfut is the number of records added to the header section with a format specific to the application (normally nfut is equal to 0);
  • nvar is the number of variables in the body section;
  • ncol is the number of columns in the body section;
  • nbody is the number of records in the body section (set to -1 when the length of the body section is unknown);
  • npart is the number of remaining blocks associated to the current namelist section.
Note that part of the information is redudant since
nheader = 1 + ntext + nfutur + nmeta + nvar.
2 ... (ntext+1) atext Each record includes a single character string. These character strings can be used to indentify the programme used to produce the file (e.g. 'UNIRAD v3.1 - SAPRE - OpenVMS (BIRA/IASB)'), the project title, or other information such as the name of the model used to produce the data.
(2+ntext)
... (1+ntext+nmeta)
ameta, ktyp, val_1,
val_2, ...
Each record contains the information on a specific metavariable, and starts by a character string (ameta) followed by an integer (ktyp). The string ameta contains the name of the metavariable. The integer ktyp specifies the type of the metavariable. When ktyp is equal to -1, the metavariable contains a character string, the value of which is set in the third element of the record (val_1). When ktyp is greater than 0, the metavariable contains a vector of ktyp real numbers, the values of which are set in the third and following elements of the record (val_1 ... val_[ktyp]).
(2+ntext+nmeta)
... (nheader-nvar)
not defined This area is reserved for future usage and is therefore usually not present in the header section.
(nheader-nvar+1)
... nheader
aname, aunit, nelem, atitle Each record includes information on a specific variable of the data set. A variable is defined as a single real number or as a vector of real number. Each record contains four elements:
  • aname, a character string with the name of the variable (in uppercase);
  • aunit, a character string with the units of the variable
  • nelem, an integer with the number of elements of the vector (set to 1 when the variable is a single real number);
  • atitle, a character string with a title for the variable that can be used on plot axes;
  • optionally, the string atitle can be followed by a set of character strings with metavariable names (see below).
Note that the sum over the nvar records of the nelem value shall be equal to ncol.

The header section is directly followed by the body section.

Future extension

According to the above specification, the body can only include single real variables or one dimensional variables. In future developments, multi-dimensional variables could be introduced. In that case, nelem should correspond to the total number of elements and information on the dimensions can be added after the argument atitle. For instance: a list of metavariables, each one of which corresponds to one of the dimensions and contains as many elements as the corresponding dimension. For example, a density map could be stored in a variable defined as 'DENS','cm-3', 200,'Density','LATITUDE','LONGITUDE' where LATITUDE and LONGITUDE are metavariables that contain a set of 10 latitudes and 20 longitudes, respectively (10 x 20 = 200).

Body section

Each record of the body section contains the values associated to all the variables of the data set. All records of the body section have the same structure: they contain a suite of real numbers, the number of which is specified by the 7th element of the first record of the header section (ncol). For the sake of clarity, the values are usually written in field with fixed with such that the fields from the different records are aligned in columns. In each record, the values are ordered with the same order that the variables are listed in the header section.

The number of records contained in the body section is not explicitly determined. An expected value of this number is given by the 8th element of the first record of the header section (nbody). Practically, the end of the body section is defined by the detection of the footer section.

Footer section

The footer section consists of a single record that contains a character string. This character string shall not start with an asterix (*) and is used to detect the end of the body section. The text of the footer string can be use to pass information on the next part of the output file. Note that both character strings '*ERROR*' and '*CONTINUE*' will be used by IDL and FORTRAN interface routines.

For the sake of uniformity the following character strings are suggested:

The usage of the header, body and footer sections are illustrated by an example file.

Example file

This small example illustrates the specifications on the UNIRAD output file structure. Different colors have been used in order to better highlight the different part of the structure.

 1:'*',  13,   2,   3,   4,   3,   8,  -1,   0
 2:'Title of this project'
 3:'This is an example file'
 4:'EPOCH',   1,  1995.0
 5:'ENERGY',  6,  0.10,  0.50,  1.00,  2.00,  5.00, 10.00
 6:'MODEL',  -1,'IRI-90'
 7:##########################
 8:# Specific area reserved #
 9:#     for futur use      #
10:##########################
11:'AMJD    ','day    ', 1,'Modified Julian Day'
12:'FLUX_EL ','1/cm2/s', 6,'Integral electron flux'
13:'L       ','Re     ', 1,'McIlwain''s shell parameter'
14: 17888.07465, 1.2E+06, 1.0E+06, 5.4E+05, 2.9E+05, 4.2E+04, 9.8E+03,  2.067
15: 17890.78901, 6.0E+05, 5.0E+05, 2.7E+05, 1.4E+05, 2.1E+04, 4.9E+03,  1.076
16: 17892.87572, 3.2E+05, 2.0E+05, 2.4E+05, 1.9E+05, 2.2E+04, 4.8E+03,  1.085
17: 17894.36543, 1.2E+04, 1.0E+04, 5.4E+03, 2.9E+03, 4.2E+02, 9.8E+01,  2.094
18: 17896.43453, 6.0E+05, 5.0E+05, 2.7E+05, 1.4E+05, 2.1E+04, 4.9E+03,  3.103
19: 17898.88785, 1.2E+06, 1.0E+06, 5.4E+05, 2.9E+05, 4.2E+04, 9.8E+03,  3.112
20: 17900.68776, 1.2E+04, 1.0E+04, 5.4E+03, 2.9E+03, 4.2E+02, 9.8E+01,  2.121
21: 17902.76786, 6.0E+05, 5.0E+05, 2.7E+05, 1.4E+05, 2.1E+04, 4.9E+03,  1.130
22:'End of Block'

Comments

The figure below illustrates the transfer of the output file into a spreadsheet programme. The same colors have been applied for the sake of clarity.