How do we want to structure the data of properties that are defined for certain measurement conditions?

[ipg-jsc]

Most measurements are only valid under certain conditions, that have to be stored alongside. The JSON format allows to store that data in many different structures and hierarchies (any combination of arrays and structs possible).

---

Examples based on the index of refraction:

(Note: BRDF lookups would be another example that could additionally require θ_in, θ_out, φ_out)

Original proposal (special treatment of the wavelength as the lowest level of hierarchy):

"index_of_refraction": [
    {
      "temperature": 300.0,
      "n": [
        [200e-9, 0.110803374],
        [205e-9, 0.111587326]
      ],
      "k": [
        [200e-9, 1.908606137],
        [205e-9, 1.969936987]
      ]
    },
    {
      "temperature": 310.0,
      "n": [
        [200e-9, 0.110803374],
        [205e-9, 0.111587326]
      ],
      "k": [
        [200e-9, 1.908606137],
        [205e-9, 1.969936987]
      ]
    }
  ]

Singular data points with explicit mention of each key:

  "index_of_refraction": [
    {
      "temperature": 300.0,
      "wave_length": 200e-9,
      "n": 0.110803374,
      "k": 1.908606137
    },
    {
      "temperature": 300.0,
      "wave_length": 205e-9,
      "n": 0.111587326,
      "k": 1.969936987
    },
    {
      "temperature": 310.0,
      "wave_length": 200e-9,
      "n": 0.110803374,
      "k": 1.908606137
    },
    {
      "temperature": 310.0,
      "wave_length": 205e-9,
      "n": 0.111587326,
      "k": 1.969936987
    }
  ]

Pure array (meaning of each entry has to derived from the schema)

  "index_of_refraction": [
    [300.0, 200e-9, 0.110803374, 1.908606137],
    [300.0, 205e-9, 0.111587326, 1.969936987],
    [310.0, 200e-9, 0.110803374, 1.908606137],
    [310.0, 205e-9, 0.111587326, 1.969936987]
  ]

Treating each condition as separate hierarchy level (will probably lead to deep nesting)

  "index_of_refraction": {
    "temperature": [
      [
        300,
        {
          "wavelength": [
            [
              200e-9,
              {
                "n": 0.110803374,
                "k": 1.908606137
              }
            ],
            [
              205e-9,
              {
                "n": 0.111587326,
                "k": 1.969936987
              }
            ]
          ]
        }
      ],
      [
        310,
        {
          "wavelength": [
            [
              200e-9,
              {
                "n": 0.110803374,
                "k": 1.908606137
              }
            ],
            [
              205e-9,
              {
                "n": 0.111587326,
                "k": 1.969936987
              }
            ]
          ]
        }
      ]
    ]
  }

---

Do we need a hierarchy in our measurement conditions? Could a mandatory order of elements in a flat hierarchy be an alternative?

Do we want a special treatment of certain conditions (as for the wave length in the original proposal)?

[ClemensLinnhoff]

I would favour either the first or the last approach. Having some form of hierarchy makes it easier to find the parameter combination you are looking for. If it is all in one table, your algorithm has to search through all the rows to find the correct parameter.

Let's discuss this in the meeting on 21.08.

[ClemensLinnhoff]

Preliminary decisions:

• Use pure array formatting for look-up tables
• Parameters in look-up tables (permittivity, permeability, ior, conductivity etc.)
  • Wavelength
  • Temperature
  • Humidity
  • Data tuple: Still open: Grouping of parameters or does every parameter have its own table?
• We need a default value in case a parameter cannot be set. Options: nan, -1, 0.0, null, MAX(float), or specify table headers in a separate field (e.g. ["temp", "wavelength", "ior_img", "ior_real"])

[DavidJRitter904]

Metadata can be added as normal fields with name-value pairs. As far as I have checked, there are no specific header information possible.

Grouping can be made by using another nesting level.

An example with index of refraction could be:

{
  "metadata": {
    "material": "Silicon",
    "description": "Refractive index data for Silicon with temperature and wavelength dependence",
    "units": {
      "temperature": "Kelvin",
      "wavelength": "nanometers"
    }
  },
  "data": [
    {
      "temperature": 300,
      "measurements": [
        {
          "wavelength": 500,
          "n": 4.292,
          "k": 0.0495
        },
        {
          "wavelength": 600,
          "n": 3.948,
          "k": 0.0203
        },
        {
          "wavelength": 700,
          "n": 3.752,
          "k": 0.0092
        }
      ]
    },
    {
      "temperature": 400,
      "measurements": [
        {
          "wavelength": 500,
          "n": 4.301,
          "k": 0.0506
        },
        {
          "wavelength": 600,
          "n": 3.957,
          "k": 0.0210
        },
        {
          "wavelength": 700,
          "n": 3.760,
          "k": 0.0097
        }
      ]
    }
  ]
}

[ClemensLinnhoff]

Metadata can be added as normal fields with name-value pairs. As far as I have checked, there are no specific header information possible.

But this might lead to people thinking these are changeable parameters. I would like to avoid someone adding a material with temperature in Fahrenheit.

[ClemensLinnhoff]

Preliminary decisions:

• Use pure array formatting for look-up tables
• Parameters in look-up table: permittivity, permeability
  • Wavelength
  • Temperature
  • Humidity
  • Permittivity_real
  • Permittivity_imag
  • Permeability_real
  • Permeability_imag
• ior and conductivity are not given as material parameters, because they can be calculated from permittivity and permeability.
• Incidence angle might be added in the future, as several factors (roughness, in-homogenous materials etc.) can lead to different apparent permittivity and permeability.
• We need a default value in case a parameter cannot be set. Options: nan, null, MAX(float), or specify table headers in a separate field (e.g. ["temp", "wavelength", "ior_img", "ior_real"])
  • Try if "null" works
• Add default values to use if a value is not set:
  • Wavelength: mandatory
  • Temperature: 293.15 K
  • Humidity: 50%
  • Permittivity_real: mandatory
  • Permittivity_imag: 0.0
  • Permeability_real: mandatory
  • Permeability_imag: 0.0

[ClemensLinnhoff]

Preliminary decision (still has to be tested and finally discussed in the group and with ASAM):

Use xomp as a file extension. The 'x' stands for OpenX Standard and 'omp' stands for 'OpenMATERIAL parameter'.

Use a suffix for look-up table files e.g. 'aluminum.xomp' for the main file and 'aluminum_permittivity_permeability.xomp', 'aluminum_brdf.xomp' for auxiliary look-up tables.

[ClemensLinnhoff]

Preliminary decision (still has to be tested and finally discussed in the group and with ASAM):

Use xomp as a file extension. The 'x' stands for OpenX Standard and 'omp' stands for 'OpenMATERIAL parameter'.

Use a suffix for look-up table files e.g. 'aluminum.xomp' for the main file and 'aluminum_permittivity_permeability.xomp', 'aluminum_brdf.xomp' for auxiliary look-up tables.

On second thought: It might be easier to use a separate file extension for the look-up tables. The JSON schema validation works by using input files names with wildcards. Since we will have different schemas for the different files, the above example would work for _permittivity_permeability.xomp and _brdf.xomp but when checking the main material file with *.xomp would also apply to the look-up table files.

Just as an example, I will use xomlt as in OpenMATERIAL look-up table as a file extension. @drsftx73 this needs to be discussed in the next meeting.

[ClemensLinnhoff]

To make filenames a bit shorter we could use '_emp' (electro-magnetic properties) as a suffix instead of '_permeability_permittivity'.

[ClemensLinnhoff]

I added the proposal in the pull request linked above.

[DavidJRitter904]

I am in favor to use a different file extension for lookup tables as it you will immediately know, what you are dealing with.

Shorten the filenames enhances the readability but the parameters inside are not only EM-properties as it includes temperature, humidity etc.

[ClemensLinnhoff]

Shorten the filenames enhances the readability but the parameters inside are not only EM-properties as it includes temperature, humidity etc.

But as far as I see it, wavelength, humidity and temperature are only there to pick the correct EM-properties, right?

[drsftx73]

as a group we agreed that there should be two different suffixes - xomp and xompt work well. @ClemensLinnhoff - are you good with xompt vs xomplt?