HardData should be used where there are a number of alternative products/fixed data among which the solver needs to select one. Each row in the table will contain the parameters defining each product/fixed data.

The HardData endpoint provides a RESTful interface to interact with HardData objects in the database. It allows authenticated users to create, update, and delete their own HardData objects.

The base URL for the HardData endpoint is https://datamanagerapi.solver-ai.com/api/data/hard-datas/.

• GET hard-datas: Retrieves a list of all HardData objects associated with the authenticated user.
• POST hard-datas: Creates a new HardData object associated with the authenticated user.
• GET hard-datas/{id}: Retrieves the HardData object with the specified id.
• PUT hard-datas/{id}: Updates the HardData object with the specified id.
• PATCH hard-datas/{id}: Updates part of a HardData object with the specified id.
• DELETE hard-datas/{id}: Deletes the HardData object with the specified id.

A HardData can be set up via the Browsable API (2 - Module Management) or programmatically (more on this here).

The parameters required for creating a HardData module via the HardData Browsable API are:

• Name: Unique name identifying the HardData.
• Csv: Path to the csv file.
• VectorizationIndices (optional): Indices used for vectorizing the HardData.

Notice that no variable names are specified for HardData variables. The HardData only has output variables, where the names are the headers that you must provide in the first row of the csv file.

Following is an example of the data when setup through the Browsable API:

Name:Example Hard Data
Csv: C:/test/data.csv
VectorizationIndices: 3-5

In this example, the data.csv file contains HardData, with the output variables being the names of the headers of the first row.

More on VectorizationIndices

The VectorizationIndices work similarly to the Equation and all the other modules.

In the example, the VectorizationIndices field is set to '3-5', indicating that this hard data should be vectorized over the indices 3, 4, and 5. This would be equivalent to defining three separate HardData tables: 'hard_data_3', 'hard_data_4', and 'hard_data_5'. For each of which, all of the variables (header strings) will be appended with _3, _4 and _5, respectively.

If VectorizationIndices is left empty, then the HardData will not be vectorized and will remain as defined in Csv. As a result all of the headers of the Csv files will be used as variables with the strings unchanged.

The CSV file contains a table of values that represent HardData for a problem. Each row in the table represents a different instance of hard data, and each column represents a different variable or parameter in the problem. The first row of your CSV file must contain unique headers. These names will be used as variable names in the HardData module. It’s crucial that this header row accurately reflects the data contained in each column.

For illustration purposes, let's consider the following example. Suppose you're tasked with designing an electric car and have a variety of alternative motors to choose from. Each motor has distinct specifications, a potential CSV file for this scenario could look like something like this:

With such a table, once integrated with other SOLVER-AI modules, you could task SOLVER-AI to determine the best engine to be used for satisfying specific requirements.

When working with multiple tables of HardData, if multiple tables share the same header names, only valid combinations where the column data is consistent among the tables will be considered.

For instance, let's consider another table related to our car design problem. This table contains information about different fictional battery models that can be paired with the motors.

In this table, the power_coupling column appears in both the motor and battery tables. Therefore, SOLVER-AI will only take into account motor and battery combinations for rows which have matching values of power_coupling.

Only authenticated users can interact with this endpoint, this can be done via the API page or programmatically via a token, which can be obtained from the Account page.

All HardData created will be associated with the authenticated user, and and will not be accessible by other users.

• If you attempt to delete a HardData that is used in a problem, the request will be denied with a 403 Forbidden status code.
• For information on setting the same programmatically follow the documentation relative to the API Clients.