Functional overview of nFIESTA

The basic logic of the nFIESTA application can be described by the schema in Figure 1.

Estimates of target parameters can be produced in a chain of six interlinked processes shown by the functional schema and described below:

1. Node No. 1 – the user configures a one-phase estimation task (no auxiliary data is considered for one-phase estimation). The configuration itself consists in the specification of the estimation cell(s), time frame (in terms of one or several calendar years) and the target variable. The user can choose from a list of options reflecting the current content of the nFIESTA database.
2. Node No. 2 – the user decides whether any (wall-to-wall) auxiliaries can and should be used to get more accurate estimates. This decision can hardly be automated as the system 'does not know' what auxiliaries could be useful for what target variables. It is a sole judgment of the nFIESTA user.
3. Node No. 3 – (after deciding to use auxiliaries) the user has to specify which auxiliaries will be used (explanatory variables), how the (linear) working model will be specified and what region(s) will be used for the working model parametrization. The choice of parametrisation region D_+ is generic in the sense that the user only chooses the type (or level) of parametrisation region. All parametrisation regions are defined in terms of unions of estimation cells and the particular type of parametrisation region represents a set of spatially congruent parameterisation regions. Once the type of parametrisation regions is chosen the system can automatically identify a parameterisation region for each of the considered estimation cells. The specification of auxiliaries and the working regression model needs to be done by the user.
4. Node No. 4 – nFIESTA automatically checks whether the \boldsymbol{\tilde{G}_{\beta_{t+}}} matrices are already available for the combination of parametrisation region, set of auxiliaries and working model. The beta-matrices are used to estimate coefficients of the working model in a parametrisation region in an efficient way. They depend on auxiliaries and working model specification but they are independent on the choice of the target variable. Because potentially many estimation tasks may use the same auxiliaries and working model but different target variables, the nFIESTA strategy of storing once calculated beta-matrices saves potentially many (unnecessary) computations. Consequently the requested estimators can often be produced in a (much) shorter time. Further details on the construction of the \boldsymbol{\tilde{G}_{\beta_{t+}}} can be found in a technical report by adolt_et_al_2018 (p. 21).
5. Node No. 5 – nFIESTA calculates the beta-matrices for each parametrisation region (based on the working model specification). The list of parameterisation regions for which these matrices need to be evaluated is determined based on the linkage of cells and parametrisation regions of the selected type (see node No. 3). Finally the matrices are stored in the database so they can be found and used for similar configurations (but different target variables).
6. Node No. 6 – if the overall process reaches this node all necessary data and metadata (estimate configuration) is passed to the estimation functionality so the estimates are produced and stored in the corresponding part of the database. This node can be reached either directly from node No. 2 (one-phase estimation using only field plot data), or via node No. 4 (estimators which use auxiliaries, beta-matrices already available) or through node No. 5 (estimators which use auxiliaries, beta-matrices have just been calculated).

As it can be seen in figure Figure 1 nFIESTA can be broken down in to three logical parts: 1) Data storage, 2) Estimates configuration and 3) Estimates calculation.