Further improvements for InputField

[sebproell]

We added the new InputField feature in #866 and its input in #890. A lot of people are interested in this feature and quickly found some issues that we still need to fix:

• Support for large meshes: this wastes too much memory right now since we cannot partition the field alongside the discretizaion.
  (e.g. @maxfirmbach 5e6 elements, with 9 values per element, not readable on 40 ranks -> out of memory)
• Hard to use if element ids are inside an EXODUS file or generated from a domain generator (@gilrrei)

Note: you cannot use this feature with dat, but this was never intended.

[sebproell]

@maxfirmbach One possible way to improve the large mesh situation: the InputField is probably tied more closely to a discretization than anticipated. If we manage the input field alongside the discretization, we could wait until the discretization is partitioned, then read the file and partition the data accordingly. However, this would require a different way to access the data e.g. inside a material (the one use case we currently had).

[gilrrei]

Global ID questions:

• Do they start at 0? (I think so)
• Are they continuous if in the input file they are not continuous? (I don't think so)
• Is there a particular order to read them?

[sebproell]

@gilrrei I would say that all of the above are unspecified. In fact, we should try not to rely on any of the implementation answers to these questions. See e.g. #733 where I tried to change something and (so far) failed.

[maxfirmbach]

@maxfirmbach One possible way to improve the large mesh situation: the InputField is probably tied more closely to a discretization than anticipated. If we manage the input field alongside the discretization, we could wait until the discretization is partitioned, then read the file and partition the data accordingly. However, this would require a different way to access the data e.g. inside a material (the one use case we currently had).

@sebproell I'm fine with any first solution that makes the input field work on large scale.

[lauraengelhardt]

Summary from our discussion @sebproell @maxfirmbach on how to tackle supporting input fields for large meshes

• Have a top level input field section (similar to functions)
  • Define fields with a name that should be read from json files (name: file_path)
  • In the future reading the input field from a mesh could also be supported
  • Example:

    fields:
      - young_field: 
          from_file: "field_path.json"
      - young_field_stored_in_mesh: 
          from_mesh: ... (maybe in the future)
    

• Refer to fields in that section within the input_field spec
  • Example:

      YOUNGS: 
        constant: 3 
      YOUNGS:
        field: "young_field"
      YOUNGS:
        function: 8
    

• Enhance InputField with a function for parallel redistribution according to a map
• Call input field redistribution after setting up the discretization

[maxfirmbach]

@lauraengelhardt @gilrrei @sebproell The input_field read-in for the .json file for ~20 million elements, each with 9 material parameter components, needs roughly 12 minutes (I don't have an exact timer though, just take this as estimate). I'm not sure if the expected and frequent users of this feature do simulations in that size range, such that this matters. Of course it runs and works, but one has to be aware of the read-in time. So I'm not sure if it is worth making this process faster by e.g. allowing for binary data read-in.