Add configuration options to dictate solving a full-order model for snapshot creation

[IshaanDesai]

This issue is mainly to discuss how the configuration functionality to dictate solving a full-order model for snapshot creation would look like.

[tjwsch]

In the following a few ideas for the configuration, sticking with the "json"-configuration and not adding another configuration file for the input parameters for now. It could make sense to include an option at the beginning of the config file to switch between snapshot creation and coupled simulation, as some configurations necessary for the coupling case are unnecessary for the snapshot computation and vice versa. This could look something like this:

"simulation_type": "snapshot"
 "simulation_type": "coupling"

Alternatively, the executed class (MicroManager/ SnapshotComputation) could transmit information internally to the Config class by adding another argument to the constructor

Config(logger, config_filename, config_type) where the type is either snapshot or coupling depending on the execution, making this change to the config file redundant. I am in favor of the second option.

Looking at the input parameters in On-the-Fly Adaptive Twoscale Simulations, there are two options to configure the macro data: Either the set of directions $D_d$ and the set of amplitudes $Dr$ are separate inputs and the snapshot computation computes the strain data set $D\varepsilon$ internally by multiplying each direction with every amplitude. This method could have the advantage that both parameter sets could be written to the configuration file as simple interval + number of points and complete lists, respectively. The snapshot generation could internally create a uniformly distributed mesh of directions from the interval. This would somewhat complicate the handling of the parameters in the snapshot computation and make it more problem-specific but the configuration in the json file could be simple. This could in a first draft look something like this:

  "snapshot_params": [{
    "macro_data": "direction",
    "relation": "base",
    "operation": "mesh", 
        "input_type": "interval",
    "data": [["start", "end", "number"], ["start", "end", "number"]]
    },
    {
    "macro_data": "amplitude",
    "relation": "foreach",
    "operation": "plain",
    "input_type": "list",
    "data": [["x_1"], ["x_2"], ["x_3"]]
    } 
    ]

where "foreach" tells the snapshot computation to multiply each amplitude value with every direction value and "mesh" makes the snapshot data create a mesh with the data points. Each set [start, end, number] describes the interval in one dimension. Or the input parameters could consist of the dataset $D_\varepsilon$. On the one hand, this would be much easier to handle internally in the snapshot computation and more easily generalizable to other simulation scenarios, e.g. two-scale-heat-conduction. On the other hand, however, I do not yet see a sequential structure in the data that would allow us to give an interval and step size instead of the complete input data for this concrete example. The option to input intervals could still exist. This could look like this:

    "snapshot_params": {
    "macro_data": "strain",
    "input_type": "interval",
    "data": [["start", "end", "number"], ["start", "end", "number"]],
}

The intervals could alternatively be specified as

"input_type": "interval",
    "data": {
         "start": ["start1", "start2"],
         "end": ["end1", "end2"],
        "number": "num"
         }

and the alternative with a complete list:

    "input_type": "list",
    "data": [["x_1", "y_1"], ["x_2", "y_2"]],

Furthermore, storing the data in a separate configuration file could make sense from the beginning to keep configuration and parameters separate. Besides a clear separation, it would make exchanging data possible with next to no change to the configuration file. In this case, the configuration file would need information about where to find the "data" parts:

"parameter_file_name": "parameters.yaml".

[tjwsch]

A complete configuration file for the snapshot parameter configuration could be

{

"micro_file_name": "full_order_model",

 "snapshot_params": {
    "read_data_names": {"strain": "vector"},
    "write_data_names": {"stress": "vector", "stiffness": "vector"}
    },
"snapshot_data": {
    "macro_data": "strain",
    "input_type": "interval",
    "number_of_steps": 10,
    "data": ["[start, end]", "[start, end]", "[start, end]", "[start, end]", "[start, end]", "[start, end]"],
    }
}

where read- and write_data_names specific input and output parameters, respectively. The output parameters could indicate what data is written to the database. snapshot_data gives specific information about the macro parameters. Here, whether the input is an interval or a list (input_type) is determined. An interval also requires information about the number of steps (number_of_steps). During snapshot computation, this is turned into a complete parameter set. The input parameters are written in data. For an interval input, they specify start and end points for each dimension.

The configuration would be easily extendable to multiple input parameters by adding it to write_data_name and adding another block to snapshot_data. However, this would require some notion of how the parameters are related, e.g. each of one is used with every of the other or there is a one-to-one relation (each parameter 1 has a corresponding parameter 2 and the input is paired).

When the entire sequence of parameters is given as input, the configuration could have the following form:

{

"micro_file_name": "full_oder_model",

 "snapshot_params": {
    "read_data_names": {"strain": "vector"},
    "write_data_names": {"stress": "vector", "stiffness": "vector"}
    },
"snapshot_data": {
    "macro_data": "strain",
    "input_type": "list",
    "data": ["[x1, x2, x3, x4, x5, x6]", "[y1, y2, y3, y4, y5, y6]"],
    }
}

Alternatively, if parameters are stored in a separate file, the configuration could look like this:

{

"micro_file_name": "full_order_model",

 "snapshot_params": {
     "parameter_file_name": "parameters.file",
    "read_data_names": {"strain": "vector"},
    "write_data_names": {"stress": "vector", "stiffness": "vector"}
    }
}

[uekerman]

Good concepts, but feels a bit too tailored towards the materials usecase. Maybe sth programmable could be better for the time being, not to over-engineer too early. Programmable could here also mean to keep it in Python. Or to generate all strain samples in pre-processing and store those (already in hdf5?).

Maybe, I have overlooked this, but the rescaling is currently missing, meaning equation (16) in Fritzen et al. 2019.

[tjwsch]

My understanding from an in-person discussion is that, for the moment, the JSON configuration file should only provide an hdf5-file name and location telling the snapshot tool where to read macro parameters from and where to write micro outputs. The dataset in the hdf5 file will be set up in preprocessing. Thus, for the moment, the configuration file for the snapshot computation would look as follows:

{

"micro_file_name": "full_order_model",

 "snapshot_params": {
     "parameter_file_name": "parameters.hdf5",
    "read_data_names": {"macro_parameter1": "vector", "macro_parameter2": "scalar"},
    "write_data_names": {"micro_parameter1": "vector"}
    }
}

Providing information in read_data_names and write_data_names about what data to read and write from and to an hdf5-file is necessary.

[uekerman]

Providing information in read_data_names and write_data_names about what data to read and write from and to an hdf5-file is necessary.

But these should already be covered through the "normal" configuration, right? I would not duplicate these as they would stay the same for most applications?