Index: /reasoner/mainAlgorithms.tex =================================================================== --- /reasoner/mainAlgorithms.tex (revision 191) +++ /reasoner/mainAlgorithms.tex (revision 192) @@ -34,5 +34,5 @@ In the \textbf{full reasoning part}, data structures are set up to store constraints for reuse in the incremental part (if $reuse$ is enabled), here for storing a copy of the constraint base ($base_c$) as well as $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$ storing specific constraint relations. $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$ are important for efficient access to constraints during constraint re-scheduling, i.e., when variable values change as a side effect of value propagation. $\relevantConstraintsPerDeclaration$ is a mapping that links a variable declaration to the constraints using the variable. $\relevantConstraintVariables$ is a bi-directional mapping between constraint values assigned to configured decision variables. $base_{\relevantConstraintsPerDeclaration}$ and $base_{\relevantConstraintVariables}$ are the respective copies if $reuse$ is enabled. -The resoning process takes each individual project (as top-level evaluation scope) into account and evaluates the constraints defined by the respective project. However, as projects can depend on each other, the reasoning process must follow the import dependencies of the projects starting at those without imports continuing with the dependent projects up to the top-level project in the given configuration $c$. In general, the imports of IVML projects can form a graph with loops, because imports my be cyclic \cite{IVML-LS} as required in complex topological models. Thus, we determine the project sequence through a cycle-free depth-first traversal of the import graph, i.e., we pretend that the import graph is a tree and ignore imports of already seen projects. The traversal determines the project sequence, a partial ascending order of projects according to their (number of) dependencies. In this sequence, projects with no imports are at the beginning of the sequence and projects with imports are are listed after all their depending projects. line \ref{algMainLoopDiscover}, $discoverProjects(cfg)$\footnote{The algorithm is not further detailed in this document} determines the project sequence of all projects involved in $c$. The loop in lines \ref{algMainLoopStart}-\ref{algMainLoopEnd} processes this project sequence as long as no timeout occurred (global flag $hasTimeout$) or the user stops the reasoning process (global flag $stop$). +The resoning process takes each individual project (as top-level evaluation scope) into account and evaluates the constraints defined by the respective project. However, as projects can depend on each other, the reasoning process must follow the import dependencies of the projects starting at those without imports continuing with the dependent projects up to the top-level project in the given configuration $c$. In general, the imports of IVML projects can form a graph with loops, because imports my be cyclic~\cite{IVML-LS} as required in complex topological models. Thus, we determine the project sequence through a cycle-free depth-first traversal of the import graph, i.e., we pretend that the import graph is a tree and ignore imports of already seen projects. The traversal determines the project sequence, a partial ascending order of projects according to their (number of) dependencies. In this sequence, projects with no imports are at the beginning of the sequence and projects with imports are are listed after all their depending projects. line \ref{algMainLoopDiscover}, $discoverProjects(cfg)$\footnote{The algorithm is not further detailed in this document} determines the project sequence of all projects involved in $c$. The loop in lines \ref{algMainLoopStart}-\ref{algMainLoopEnd} processes this project sequence as long as no timeout occurred (global flag $hasTimeout$) or the user stops the reasoning process (global flag $stop$). \begin{algorithm}[H] @@ -124,16 +124,16 @@ \subsubsection{Scope Assignments}\label{sectScopeAssignments} -Due to the potentially nested nature of IVML projects, the knowledge about when an assignment for a variable has been made cannot be maintained by a simple flat mapping. This requires a data structure, which stores information about assignments per project (scope). This structure is important to detect invalid variable re-assignments, i.e., to figure out whether a variable assigned more than once per scope~\cite{IVML-LS}. - -The scope assignments structure of the IVML reasoner (usually named $\scopeAssignments$ for assignments) provides the following operations: +Another essential information for the IVML reasoner is to know whether a value was was assigned to a variable during the reasoning process (in contrast to frozen or user-assigned variables). This information is important to detect invalid variable re-assignments, i.e., to figure out whether a variable shall be assigned more than once per scope. Such invalid assignments shall cause a reasoning failure~\cite{IVML-LS}. Due to the potentially nested nature of IVML projects and the interaction of variables among projects through constraints, this knowledge cannot be maintained by an ordinary flat mapping (Section \ref{sectNotationConstraints}). This requires a data structure that allows for scoped assignments, i.e., the assignments made per project. + +The scope assignments structure of the IVML reasoner (usually named $\scopeAssignments$) provides the following operations: \begin{itemize} - \item $setAssignmentScope(\scopeAssignments, c)$ defines the scope of constraint $c$ as the actual assignment scope. Adding and checking assignments rely on the actual scope. Here, the scope of $c$ is the top-level parent of $c$, i.e., the containing project. + \item $setAssignmentScope(\scopeAssignments, c)$ defines the top-level parent of constraint $c$, i.e., containing project, as the actual assignment scope. \item $addAssignment(\scopeAssignments, v)$ indicates that variable $v$ was changed through an assignment within the actual scope. - \item $wasAssigned(\scopeAssignments, v)$ returns whether variable $v$ was assigned in the actual scope. This operation is used to validate an assignment before it is performed out by the expression evaluator. - \item $clearAssignments()$ clears all assignments in all scopes. + \item $wasAssigned(\scopeAssignments, v)$ returns whether variable $v$ was assigned in the actual scope. This operation is used to validate an assignment before it is performed by the expression evaluator ($\evaluator$). + \item $clearAssignments(\scopeAssignments)$ clears all assignments in all scopes in order to reuse the $\scopeAssignments$ instance. \end{itemize} -\subsection{Top-level Constraints Translation}\label{sectTopLevelConstraintsTranslation} +\subsection{Top-level Constraint Translation}\label{sectTopLevelConstraintsTranslation} The core idea of the constraint translation is to collect the constraints following the structure of an IVML model and to replace each type-related variable by the correct accessor expression for a global variable in the current scope. According to the IVML specification~\cite{IVML-LS}, the relevant top-level elements are variable declarations, global constraints, annotation assignment blocks and eval-blocks. Type definitions are considered when when processing variable declarations, as the individual type of a variable indicates the specific constraints to be collected and instantiated.