Collect ideas for PFHub schema improvment

[wd15]

Please answer three questions:

• How can we improve the PFHub phase field schema?
• What data and metadata should PFHub require?
• How would you imagine querying the data? What questions would you ask?
• What publication could you generate given better data / metadata?

Current examples of our latest schema are here and here.

Here are some ideas to get started:

• Descriptions of discretization methods (FD, FV, FE, Spectral, ...)
• Nominal order of accuracy, nominal DOF, meshing strategy
• Description of linear solvers, preconditioners, non-linear strategy
• Time stepping strategy (implicit v explicit)
• Field variables at various times for statistical post-processing
• Links to input files (rather than just the implementation repository)
• Container (Docker build, Singularity build, Nix build)
• What about the actual problem being solved?

Ideas for queries:

• Show dendrite curves for all finite difference methods
• Show the transient free energy curve for all results with nominal O(h⁴) accuracy
• Show the resource usage per nominal DOF
• Characterize Ostwald ripening simulations by a length scale associated with the microstructure
• Color data points in an efficiency plot based on numerical method or meshing strategy

[wd15]

This is aimed at the simulation and the code used for the simulation rather than the benchmark specification or defining a phase field problem.

[wd15]

Remi: uses PFHub to verify (in a loose way) development of his codes.

[tkphd]

Comment from the PFHub XV Zoom:

Shall we define a PF Code (sets of rules that tell you what you need to do) and PF Standards (how to execute the codes), which each case will each be a function of the problem to be solved and the accuracy ( and thus available resources)?

[tkphd]

Comment from the PFHub XV Zoom:

I think from an ontology Point of view it makes sense to separate the following aspects: mathematical/physical model and the corresponding numerical implementation. Furthermore, a simulation comprises Input, the numerical implementation and Simulation Output. The least PFHub does is provide the Information about the mathematical problem and then collect processed simulation output. If there are seperate data collections for the code that would complement the Information and it accounts for the fact that the same code can be used for multiple Simulation runs. So, the code metadata can be linked to simulation results meta data then. As a result PFHub would sort of feature a library of codes or at least metadata of various codes. The Question is if that is wanted or not.

[tkphd]

Comment from the PFHub XV Zoom:

suggest numerical method rather than discretization method

[tkphd]

In that regard i don't think we should create an exhaustive list of methods. We can prepopulate the list with some well known existing ones, but it should allow for people to develop new ones and contribute

[tkphd]

Comment from the PFHub XV Zoom:

In our code our input deck is actually separated into these categories: physical model inputs, numerical implementation model inputs (solver type, time stepping, discretization scheme), boundary conditions. We also have a log file that capture the # of proc and runtime for that specific simulation.

[wd15]

From the discussion it seems having metadata with stored with phase field codes might help. It would make filling out a more complicated YAML file with additional data more tractable.

[wd15]

@rdingre ideas

I believe that a schema for PF should have four rubriques:

• Physical model
  • This one is harder to describe because it would be problem specific...maybe just ask for some documentation?
• Numerical methods
  • Spatial discretization
  • Time discretization
  • Solver type (FE, FD, FV, spectral, ML, other?)
  • Numerical algorithms and optimization algorithms? (Newton, etc..)
  • Initialization of numerical scheme used
  • Convergence analysis
  • Accuracy
• PDE
  • Initial conditions
  • Boundary conditions
  • Order
  • Type: elliptic, parabolic, hyperbolic
• Computational resources used
  • CPU, GPU
  • Number of cores