Benchmark configuration JSON-LD schema?

[jpthiele]

I'm not 100% sure if we discussed this already at some point but maybe it would be worthwhile to write a generic metadata schema for the JSON input files as a JSON-LD file. As an example you could have a look at the codemeta scheme.

Something like the material parameters would then be a list of schema.org quantitative value (similar to author being a list of person in codemeta).

Note: This somewhat came up in #58 but is not directly related to the meshing question so I think it's better to discuss this here.

[srosenbu]

I like the idea. The question for me is, if we want this for validating inputs and showing a user which values they need to set or as an additional semantic description. For the first case, a schema without context from schema.org would be enough.

[joergfunger]

I agree to this, the idea is related to describing the benchmark in a semantic way, then these parameter configurations automatically get a corresponding context. Let's talk to @doigl and @M-Jafarkhani in the next meeting, because that is quite overlapping.

[M-Jafarkhani]

I believe this is exactly what @doigl and I are working on. Our goal is to use a semantic representation of a benchmark as input, which already includes information about parameters and metrics.

Currently, I am working on converting the JSON-LD file into Python domain classes so that parameters can be accessed directly as Python objects. In this approach, we would no longer need to include duplicate parameters.json files within the benchmark ZIP archive. Instead, this file could be generated automatically during the benchmark run.

[joergfunger]

In the current pull request #86 by @div-tyg , there is a discussion on the sensor definition, and where to place that - either directly in the parameters.json, or in another file, and this also relates to the structure/information. It would be nice if @doigl, @M-Jafarkhani, @berndflemisch, @Sarbani-Roy and @jpthiele could comment on that discussion.

[joergfunger]

Here is a potential structure on what I think might be relevant to be stored in the semantic representation (as discussed with @doigl). For each sensor we store on what geometrical entity something is measured (point, surface, volume), and then the corresponding information (coordinates, surface_ids, ..). In addition, we have to specify what is physically measured (expression), and for our surface/volume measures we somehow have to specify how we post-process/integrate the actual expression to get to a metric (so e.g. l2, l_inf). In addition, we need the unit, and we need a trigger that specifies, when we should measure something. The latter could be directly a list of time steps, or a starting point in time and a frequencies, or just something like before/after the experiment/simulation. For adaptive time stepping (there is no fixed time step, but the solver chooses that), I added something like step_end, which means compute each step (time step is based on solver choice), and after each time step, store the result. In our static linear case, we only have a single step anyway, so there is no difference between step_end and after the simulation.

I was not really sure how to handle the expressions that are measured, and in particular how to include them in the operator equations (e.g. displacement - displacement_exactt). (so measured- analytical solution)

{
  "sensors": [
    {
      "id": "disp_top_right",
      "on": {
        "point": {
          "coordinates": [1.0, 1.0, 0.0]
        }
      },
      "expression": "displacement",
      "unit": "m",
      "trigger": "step_end"
    },
    {
      "id": "l2_error_displacement",
      "on": {
        "volume": "all"
      },
      "expression": "displacement - displacement_exact",
      "operator": "l2",
      "unit": "m",
      "trigger": "step_end"
    },
    {
      "id": "linf_error_displacement",
      "on": {
        "volume": "all"
      },
      "expression": "norm(displacement - displacement_exact)",
      "operator": "max",
      "return_location": true,
      "unit": "m",
      "trigger": "step_end"
    },
    {
      "id": "reaction_force_y",
      "on": {
        "surface": "support_boundary"
      },
      "expression": "traction_y",
      "operator": "integral",
      "unit": "N",
      "trigger": "step_end"
    },
    {
      "id": "number_of_dofs",
      "expression": "number_of_dofs",
      "unit": "1",
      "trigger": "simulation_end"
    }
  ]
}