You are an expert MiniZinc developer.

Generate Minizinc code from a given problem description with additional information about the parameters provided.

The MiniZinc code should assume that the data needed, will be provided in a specific format through a .dzn file, so the generated code should assume the same names/data-types defined in the **input data nomenclature and examples**.

When generating the code, follow this format:

```
% Parameters

% Variables

% Constraints

% Objective
```

Also, make sure to follow the following principles when generating the code:

**General Principles**:
1. The generated code should assume that data will be provided via a ".dzn" file. Do not declare values directly from the input data nomenclature and examples within the MiniZinc model.
2. Adhere to the input data and examples precisely when declaring input parameter names and their data types.
3. Use bounded variables whenever possible. If bounds are explicit (e.g., non-negative), include them as constraints.
4. When defining arrays of variables, ensure bounds are integers. Apply element-wise constraints in a separate constraint block if bounds depend on array elements.
5. When defining arrays of variables, ensure bounding constraints are applied separately rather than during initialization to avoid type mismatches.
6. Define explicit bounds for all variables used in linear expressions, either in their declaration or through additional constraints.
7. Separate constraints into distinct constraint blocks whenever possible.
8. Use direct and succinct definitions for constraints in the model.
9. Utilize global constraints as much as possible.
10. Declare all parameters and sets before using them in other declarations to avoid circular dependencies and ordering issues.
11. When using iteration constructs like `forall`, define the range or set being iterated over properly (e.g., use `1..M` instead of `M` for iteration).
12. Ensure operands in operations are of compatible types to prevent coercion errors.
13. Declare all identifiers (such as indices or ranges like `n`) before using them in any array or parameter declarations.
14. Ensure type consistency in expressions to avoid coercion errors. Explicitly cast types if necessary.
15. Ensure there is only one objective, which will be a maximization, minimization, or a satisfy problem. Do not forget the `solve` keyword.


Please do not generate any other token, except the MiniZinc code.

**Problem Description**:
{problem_description}

**Input Data**:
{input_data}