Enhancements to Release 6

Range testing

If are carrying out a simulation, range checking (see section 2.2 of GPD-4) can now apply when automatic accuracy is not being done.

The statements "range test updated values = ... ;" and "range test initial values = ... ;" (see section 2.2 of GPD-4 and page 19-115 of GPD-4) are now extended to add an additional alternative value of "warn". That is, they have the form
range test updated values = updated|extrapolated|both|no|warn ;
range test initial values = yes|no|warn ;

When not doing automatic accuracy, the default value is "WARN" in each case. [When doing automatic accuracy, the default values are still BOTH and YES respectively, as set out in GPD-4.]

When not doing automatic accuracy, if one of the values is out of range,

(i) if the relevant "range test ..." is set at "WARN", then a warning is shown for the first few instances but the simulation carries on as if these warnings were not given.

(ii) if the relevant "range test ..." is set at "YES", then the simulation ends with a fatal error after the value out of range is shown (in the log file). Possibly several out-of-range values of the same type (initial, updated or extrapolated) may be shown before the program stops.

(iii) if the relevant "range test ..." is set at "NO", the relevant testing is not done.

We recommend setting these to "YES" so that simulation results in which a value goes out of range are not reported. [If a value goes out of range, you can increase the number of steps or use automatic accuracy to keep the values in range.]

(a) If "range test updated values = both ;", then both updated and extrapolated values out of range are fatal errors.

(b) If "range test updated values = updated ;", then updated values out of range are fatal errors, and the software merely warns about extrapolated values out of range.

(c) If "range test updated values = extrapolated ;", then extrapolated values out of range are fatal errors, and the software merely warns about updated values out of range.

If automatic accuracy is being done, then "WARN" is a new possible value for these range test ... ;" settings. If the relevant "range test ..." is set at "WARN", a a warning is shown for the first few instances out of range but the simulation carries on as if these warnings were not given. [In particular, the subinterval is not redone.]

The only difference between setting one of these to "NO" or to "WARN" is that in the latter case you see warnings in the log file.

If any range checks are set to be warnings only, a summary at the end tells how range check failures there have been (if there are any). You can check if there have been any by searching for "not in the required range" in your log file.

Assertion failures can now be warnings

There is a new statement
assertions = yes|no|warn ;
available in Command files for TABLO-generated programs and GEMSIM.

(i) The statement "assertions = no ;" is equivalent to the statement "tnas = yes ;". When this is in operation, Assertions are not checked.

(ii) The statement "assertions = yes ;" is equivalent to the statement "tnas = no ;". This is the default. When this is in operation, assertion failures are treated as fatal errors.

(iii) When the statement "assertions = warn ;" is in operation, assertions are checked, but a failure results in a warning only. The first few warnings are shown in detail on the log file.

A summary at the end tells how many assertion failures there have been (if there are any). You can check if there have been any by searching for "assertion failure" in your log file.

Reporting memory used by TABLO-generated programs and GEMSIM

Fortran 90 TABLO-generated programs now give reports as to how much memory is required (or used). GEMSIM (fortran 90 or fortran 77) does the same.

The memory used is reported in two parts (referred to as the TGMEM1 and TGMEM2 parts). For large models, the TGMEM1 part is usually the larger of these.

Note that these reports do not include memory required for the nonzeros generated doing the LU decomposition (where memory is allocated according to the size of the parameters MMNZ and MMNZ1). The amount of memory used for these is

12*MMNZ bytes if MA48 is used,

(4*MMNZ + 8*MMNZ1) bytes if MA28 is used.

The minimum MMNZ and MMNZ1 values required are echoed at the end of the run of these programs.

With these reports you can get a rough estimate of the total memory required to run the program. To do this, add the TGMEM1 and TGMEM2 parts, add the above values for MMNZ,MMNZ1 and then add about 4-5 megabytes for other memory and for memory required for the code itself.

Programs ACCUM and DEVIA

(i) ACCUM can now produce accumulated results as well as side=by-side results. See the new options ACC,ACI.

(ii) DEVIA can now produce year-on-year differences. See the new option NAC.

(iii) DEVIA can now be told the name of a Solution file associated with the results being processed - see new option SOL. If you use this option, DEVIA will correctly process change and percentage-change variables.

(iv) The Release 6.0-001 versions of these programs run considerably more quickly than the Release 6.0 versions. Some bugs have been fixed.

New option ADD when modifying data in MODHAR

When you modify the data on an array using MODHAR, the Release 6.0 version of MODHAR offered the options "r" (replace) or "s" (scale).

The Release 6.0-001 version of MODHAR also offers the new alternative "a" (add). With this option, the numbers entered are added to the values at the original header.

GAMS output from SEEHAR, TABLO-generated programs and GEMSIM

These now add GAMS-type lines at the start and end of the files.

(i) The lines at the start is to make sure that GAMS treats the GEMPACK-style comment lines as comments. This saves users the trouble of removing these lines.

(ii) The lines at the end attempt to return the status at the end of the file to something close to what it was (as far as GAMS is concerned) at the start of the file.

Enhancements (1) and (ii) should make it easier for these files to be joined together with other GAMS files.

Default for levels results and SLTOHT

The Release 6.0 documentation omitted the fact that "NLV" is the default for SLTOHT.

"Check-on-read coefficients" statements

The default value was not specified unambiguously in the Release 6.0 documentation. [On page 5-33 (section 5.2) of GPD-4, the default was stated to be "warn". In chapter 19, page 19-114, of GPD-4, it was stated to be "no".] In Release 6.0-001, the default has been set to "no".

Slight incompatibility between Release 5.2 and 6.0 text files

Release 6.0 programs including SEEHAR writes the coefficient name as part of the "how much data" heading at the start of each array. This coefficient name cannot be read by Release 5.2 GEMPACK programs.