The Graphical User Interface for CAPRI version 2013 (pdf, 6 MB, 146 pages)

The aim of the Graphical User Interface (GUI) is threefold. Firstly, it serves as a tool to support the user in controlling the different work steps in CAPRI:

• Data base generation, from global to regional, and to 1×1 km grid scale
• Generation of the baseline
• Defining and running scenarios

That task is eased by the storing meta-data information along with the quantitative results of the different work steps.

Secondly, it allows to exploit the results via tables, graphs and maps. And thirdly, it offers certain services as batch execution, checking meta data, viewing GDX files, generation of HTML base documentation for the GAMS code or integrating GIS geometries into the exploitation tools.

Technically, in order to steer the different working steps, the GUI generates small snippets of GAMS code which are specific for a specific run such as the Member States included, or the base year chosen, and then starts GAMS. That concept allows to run CAPRI completely outside the GUI, e.g. in batch mode. The different tasks are defined as objects with specific properties (base year, simulation year, scenario ..) which can be modified by the user. Methods allow to retrieve the quantitative results generated by the task as well as meta information.Read more ..

The GUI comprises a generic and powerful tool for exploitation of results. Results from the different work steps of CAPRI generated by GAMS are stored in GDX format (see also next section) as multi-dimensional sparse data cubes. A single scenario run at the NUTS 2 level will generate close to 5 Mio non-zero data cells, a run at farm type level around 16 Mio non-zero. The regional time series data base of CAPRI covers almost 15 Mio non-zeros, and downscaling the regional scenario results to the 1×1 km grid resolution will generate close to 30 Mio non-zero values. In order to access these huge data quantities in a user-friendly and efficient way, an XML file defines views in the data.

Each view is firstly characterised by a selection or filter for the different dimensions such as regions, activities, items or scenarios. Secondly, a pivot is defined which maps the data base dimension to viewport dimensions, such as the columns or rows of a table, or the regions shown in a map. And thirdly, it defines the view type: a table, different type of graphs or a map. Fourthly, views may comprise links to other views, similar to the concept of hyperlinks in WEB pages, which allows a “drill-down” like exploitation from general to specific aspects, or vice versa. The hyperlinks can also be used to refer to tables with supporing information. And lastly, the view may comprise supporting information as e.g. units used for specific elements or long text descriptions.

But the user maintains his freedom: he may tune the view to his own needs, by adding his own selections, change the pivot or the view type. Equally, fonts, color, cell sizes or properties of the graphs may be set by the user. His personal settings can be stored for future session. And finally, the mapping viewer allows for rather flexible classifications and coloring options. The details with examples are discussed in a chapter of the CAPRI documentation 2005.

For more then a decade, CAPRI used a Data Base Management System (DBMS) realized in FORTRAN, developed by the Institute for Food and Resource Economics specifically for agricultural sector models. With the new GUI becoming operational, using a SQL based DBMS was discussed. However, as all data and results in CAPRI are processed and produced by GAMS programs, a SQL solution would require generation of intermediate temporary files to pass results back and forth between the DBMS and GAMS.

Fortunately, GAMS offers with the GDX format an interface to quickly pass data in and out, along with a native interface definition to exchange data with applications. For a GAMS base system, storing all data in GDX seemed therefore a good alternative. It allows using CAPRI solely building on GAMS, which eases porting CAPRI to other Operation Systems. Equally, GDX files can be accessed by the GDX viewer shipped with GAMS, but also with external tools.

The final concept hence let each working step in CAPRI produce GDX files. Consecutive step read those results as input. The native interface of GDX is used in the JAVA based GUI to read, and where appropriate, merge the content of several GDX files in memory, and pass it to exploitation tools.

Last Updated:Tuesday, October 12, 2010