-
-
Save tkphd/29e7c07825e818ad62de337d395cf5df to your computer and use it in GitHub Desktop.
--- | |
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 |
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).
This is making more sense.
code
should besoftware
for the framework, andrepo
should becode
for the implementation.number+letter
sufficient identification, or should we ask for both an ID and a name for redundancy in the parsing stage?name: size
andname: spacing
are written by the code at runtime, hencedata
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 inmeta_data
, buttimestep
is computed at runtime, could change, and isdata
.architecture
should bex86_64
,ARM
,PowerPC
, etc., not necessarily the make and model of the CPU.