Communicates data between the Matlab world and the GAMS world.

A Database consists of a collection of symbols that allows to iterate conveniently through the symbols in a Database. The symbol types available for a Database correspond to the symbols types known from the GAMS language (Set, Parameter, Variable, and Equation) are represented in Matlab by a derived class (correspondingly Set, Parameter, Variable, and Equation) of Symbol class. Besides the type, a Symbol has a name (this has to match the name inside the GAMS model), a dimension (currently up to 20, see also Globals.MAXDIM) and explanatory text.

Variables and equations also have a subtype: e.g. Binary, Positive, etc. for variables (see globals.VarType) and e.g. E, G etc. for equations (see globals.EquType).

A Database can be created empty, or initialized from existing GDX files or from another Database (copy). Symbols can be added at any time (e.g. with Database.addParameter method), but once a symbol is part of a Database, it cannot be removed. Only its associated data (SymbolRecord) can be purged (see Symbol.clear method) or individually removed (with Symbol.deleteRecord method). A symbol with name '*' is reserved as a special symbol of type Set representing universe set. Individual data elements are accessed record by record. A record is identified by the keys (a vector of strings). The record data varies by symbol type. For example, a parameter record has a Value property, a variable has the properties Level, Lower, Upper, Marginal, and Scale. Adding a record with keys that already exist results in an error. Similar, the unsuccessful search for a record also results in an error.

Symbol implements the Java java.lang.Iterable interface to conveniently iterate through the records of a symbol. However, it is also possible to query all records at once using the Symbol.records property (using the Iterator in the background). There are also sliced access methods to symbol records that allow to iterate through all records with a fixed index at some positions. Database instances can be exported as GDX files for permanent storage. They also manage external resources and need to be properly disposed before the Java garbage collector reclaims the instance (see Database.dispose).

Job.outDB and ModelInstance.syncDB provide instances of Database to communicate results from a GAMS run or a solve. These databases should only be used in the context of the base object (Job or ModelInstance). If a copy of such a database is required the Database constructor that initializes a Database from another database should be used. For instance:

* db = job.outDB;
* newdb = workspace.addDatabase(db);
* 

Database instances often provide the input data for a Job. Such instances are listed in Job.run. Inside the GAMS model source the Database is accessible through a GDX file. The GAMS model source requires a particular file name to connect to the proper GDX file (e.g. $GDXIN filename). A Database can be created with a given name which can be then used inside the model, for instance

* db = workspace.addDatabase('SupplyData');
* 

and then inside the GAMS model source:

* $GDXIN SupplyData
* 

or an automatically generated name can be used. This name can be passed down to the GAMS model by using the Defines list of a Options instance:

* db = workspace.addDatabase();
* opt = workspace.addOptions();
* opt.defines('SupplyDataFileName', db.getName());
* ...
* job.run(opt, db);
* 

Inside the GAMS model source the name is accessed as follows:

* $GDXIN %SupplyDataFileName%
* 

One has to act with some caution when it comes to ordered sets which e.g. allow lag and lead. By not enforcing the 'domain checking' for the Database class we have aggravated the potential problems for ordered sets. For GAMS, the labels of set elements are just strings, so the order of a set is determined by the appearance of its elements. For example, if one has 'set k / 2,3,4,1,5 /', the order of k is exactly given by this sequence. So the lag (k-1) of k=4 is 3 and the lead (k+1) of k=4 is 1.

GAMS performs arithmetic with an extended number range. GAMS has special values for infinity (+INF, -INF), epsilon (EPS), not available (NA), and undefined (UNDEF). When GAMS evaluates expressions with these special values, the calculating engine ensures the correctness of the result (e.g. 5*eps=eps or 5+eps=5). The GAMS model CRAZY in the GAMS Model Library documents the results of the arithmetic operations with respect to special values.

In the GAMS Matlab Control API we map the IEEE standard values for +/-infinity (Inf and -Inf) and NA (NaN) to the corresponding GAMS values. The special value for UNDEF gets unfiltered through the GAMS Matlab API. The internal double value of UNDEF is 1.0E300 (or better use SpecialValues.UNDEFINED_VALUE).

Special attention needs to be given to the value of 0. Since GAMS is a sparse system it does not store (parameter) records with a true 0. If a record with numerical value of 0 is needed, EPS can help. For example:

* set j /1*10 /;
* parameter b(j);
* b(j) = 1; b('5') = 0;
* scalar s,c;
* s = sum(j, b(j));
* c = card(b);
* display s,c;
* 

will result in

* 
* ----      3 PARAMETER s                    =        9.000
* PARAMETER c                    =        9.000
* 

but

* b(j) = 1; b('5') = EPS;
* 

will result in

* ----      3 PARAMETER s                    =        9.000
* PARAMETER c                    =       10.000
* 

What are the consequences for the GAMS Matlab Control API? If we read parameter b in case of b('5')=0, the Database will not have a record for b('5'). In case of b('5')=EPS, the Database will have a record with SpecialValues.EPS value 4.94066E-324. Unlike the IEEE values (e.g. Inf), arithmetic operations in Matlab will modify the EPS value (e.g. 5*Inf==Inf but 5*4.94066E-324 != 4.94066E-324). The same rules apply for preparing input data for GAMS in a Database. If a value of 4.94066E-324 is written, GAMS will see the special value EPS (see SpecialValues). The value used for EPS can be reset using Workspace.eps. All other small values (including 0) will be communicated unfiltered to GAMS. As mentioned before, zeros will not be entered as data records in GAMS. The compiler control $on/offEPS can help to automatically map zeros to EPS.

There is one oddity concerning values smaller than 1e-250 on GAMS input. Consider the following example:

* b = db.addParameter('b', 1, '');
* for i = 1:10
* b.addRecord(int2str(i)).value = 1;
* b.findRecord('5').value = 1E-251;
* job.run(db);
* 

with GAMS code:

* $load j b
* scalar card_b;
* card_b = card(b);
* display card_b;
* b(j) = 2*b(j);
* card_b = card(b);
* display card_b;
* 

A record with values smaller than 1E-250 exists on input in GAMS, but as soon as the record gets updated by GAMS and is still smaller than 1E-250, the record gets removed.

The ordering of a set in GAMS can be non-intuitive: Consider 'set i /5/, j /1*5/;'. Elements '5' gets internal number 1, '1' get 2, '2' gets 3 and so on. The last element of j '5' has already the internal number 1. The sequence of internal numbers in j is not ascending and hence GAMS considers set j as not sorted, i.e. one can't use the ord() function nor the lag or lead (-,–,+,++) operators. If 'j' would have been defined before 'i' in this example, the 'set not ordered' problem would have been avoided.

Please note that the Database actually does not implement a relational model for database management. It should be seen as a data storage or data container.

See also

Equation, Globals, Job, Symbol, Options, Parameter, Set, Variable, Workspace, Workspace.addDatabase