MMSP spinodal decomposition benchmark, periodic domain

meta.yml

---
metadata:
  # Describe the runtime environment
  summary: MPI parallel workstation benchmark with MMSP, periodic domain
  author: Trevor Keller
  email: trevor.keller@nist.gov
  date: Wed, 04 Jan 2017 19:30:31 -0500
  hardware:
    # Required hardware details
    architecture: x86_64
    cores: 6
    # Optional hardware details
    details:
      - name: clock
        value: 3600.078
        units: MHz
  software:
    name: Mesoscale Microstructure Simulation Project (MMSP)
    url: https://github.com/mesoscale/mmsp
    version: 4
    repo:
      url: https://github.com/mesoscale/mmsp/tree/develop
      version: 8f29eb47146b9fbbdcd17b08d12e06fceb3ed728
      branch: develop
  implementation:
    end_condition: time limit
    repo:
      url: https://github.com/mesoscale/MMSP-spinodal-decomposition-benchmark/tree/master/periodic/
      version: 1de1abe6dc9a7d7251ec44e6ee18db907f84543e
      branch: master
    details:
      - name: mesh
        value: uniform rectilinear
      - name: numerical_method
        value: explicit finite difference
      - name: compiler
        value: GNU mpic++
      - name: parallel_model
        value: MPI

benchmark:
  # Specify the problem
  model: spinodal decomposition
  boundary_condition: periodic
  id: 1a
  domain:
    - name: geometry
      value: square
    - name: origin
      value: [0, 0]
    - name: size
      value: [200, 200]
    - name: resolution
      value: [1, 1]

data:
  # Gather simulation output
  - name: timestep
    value: 0.00195312
  - name: free energy
    # JSON list of {time, energy} pairs
    value: [{"x":0, "y":319.094}, {"x":1.95312, "y":318.909}]
  - name: run time
    value: 65.48
    unit: seconds
  - name: memory usage
    value: 27280
    unit: KB

A few things:

• the name and email will go in the metadata segment
• the name: domain data item is redundant as we know which example this is
• the data segment is for data generated by the simulation -- things needed to specify the problem go in the benchmark section, while things required to specify the code and run time environment go in the meta_data section.
• also the solver goes in the metadata segment as it's knows at the start even better in the code segment` as it is unique to MMSP
• likewise for timestep if it's know beforehand

This is making more sense.

• code should be software for the framework, and repo should be code for the implementation.
• The benchmarks are called by name on the Web site, you have to dig a bit to find a number and letter. It would make sense to Hackathon participants, but not everyone will be among those. Is a number+letter sufficient identification, or should we ask for both an ID and a name for redundancy in the parsing stage?
• name: size and name: spacing are written by the code at runtime, hence data in my opinion. We know what we want the code to do, but it's good to make sure the code understood and reports the right settings.
• solver probably does belong in meta_data, but timestep is computed at runtime, could change, and is data.
• architecture should be x86_64, ARM, PowerPC, etc., not necessarily the make and model of the CPU.

Thanks, very nice, I think the specification of the benchmark is very good.

I think that

 - name: origin
    value: [0, 0]
  - name: size
    value: [200, 200]

should go in the benchmark specification and I also don't think we need origin. It stuff that's know beforehand. Agreed on timestep, max timestep', 'min timestep etc should definitely be in data.

I put the origin and size in a list of domain details, which should be considered optional. If a pedant wants to include it, there's no harm, right? Same for a lot of the other details, such as clock speed, compiler, numerical method... Only important to someone who's curious enough about particulars to open one of these files.

I'm trying to use the vega data format for free energies. It passes the YAML lint test, but I'm still not 100% sure this is proper syntax. I have a sneaking suspicion that the entire data section belongs in a JSON block, but we can iterate on that.

The pieces are now in a different order since I have the governor script writing metadata, initialization code writing the benchmark, and the timestepper writing the data section. I believe this is irrelevant to the YAML parser, and it makes automatic generation of meta.yml easy (on GNU/Linux systems).