By default, the result files contain all files in the directory where the model was executed. This
includes data files, model files, log and listing files as well as all other files that are required
for or generated during the model run.
You can use GAMS Engine to restrict the files contained in the results archive. This can be used to
reduce the size of the archive. This INEX file has the following schema:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": [
"include",
"exclude"
]
},
"files": {
"type": "array",
"items": {
"type": "string"
},
"required": [
"items"
]
},
"globbing_enabled": {
"type": "boolean",
"default": true
}
},
"required": [
"type",
"files"
],
"additionalProperties": false
}
Let's assume we register the trnsport model from the GAMS model library. We want users to be able to run
this model, but not see our GAMS code. More specifically, we want to exclude all files with the
extensions .gms and .inc from the results returned to the users of our model.
We therefore register the model with the following INEX file:
{
"type": "exclude",
"files": ["*.gms", "*.inc"]
}
When globbing_enabled is true, it enables the
glob patterns
(sometimes also referred to as "wildcards"). This field is optional and it is set to true
when omitted. If you want to specify filenames exactly and do not need this feature you can
set it to false.
Here is an example inex file where the globbing is disabled:
{
"type": "exclude",
"files": ["trnsport.gms", "mydata.inc"],
"globbing_enabled": false
}
You can specify an INEX file both when registering a new model and when submitting a job. When you
submit a new job for a registered model that already contains an INEX file, the results are first
filtered against that file. Only after that, the INEX file sent with the job will be applied. This
means that when you submit a new job, you cannot remove restrictions that are associated with the
registered model.
Warning:
The INEX feature is not sufficient to protect the integrity of your model. Since the data files
are extracted by default after the model files, a malicious user could simply overwrite your
model files with his own and thus execute his own code. To protect yourself from this, you
should set the protect_model_files flag to true when registering/updating
your model.