Closed kyleniemeyer closed 6 years ago
OK, there's a lot here... helpfully, they numbered the comments for us!
Beginning a few thoughts:
Any ideas for a figure? I agree that it would be nice to have one, though we do have a lot of code snippets and such. Maybe we could add plotting of calculated ignition delays to the example at the end, and actually show such a figure? Or, we could include some sort of workflow diagram? The first half of the paper is probably what needs one the most, just to break up text, but I don't have any good ideas.
We do have the converters, but we don't (yet) have anything that helps create files from scratch... perhaps we should? The GUI work can be ongoing, but just something that prompts for entries or something (with the ability to specify a CSV file for volume history, e.g.).
I can add mention of the future plans to the Conclusions section, and we should also add that to the roadmap here... wow this reviewer is really looking into everything!
Both reviewers seem to be taking a very literal definition of "human-readable", in that XML is written in ASCII rather than binary... however this one does agree that YAML is more readable, which of course is our point. I think we can emphasize that we mean understandable rather than technically readable, and that in relative terms YAML is better here.
I agree with the reviewer here—reference
shouldn't be required. We already started discussing some related topics in https://github.com/pr-omethe-us/PyKED/issues/69 and privately; my suggestion is that we drop it as a required field, but validate it as we do now if given. I've started an issue on that here: https://github.com/pr-omethe-us/PyKED/issues/76
Do we need both atomic-composition
and elemental-composition
, or could we just pick one?
Regarding two composition
blocks inside common-properties
, I think this would be possible, as long as field are given different YAML tags. Perhaps we should add a test for this.
While I agree that submitted PRs on GitHub is less efficient than just uploading files willy-nilly, I think that there still needs to be some sort of human curation involved. However, one major benefit is that we have a tool that checks for basic errors, and also the submission happens in the open.
We've already talked about the less-than-useful error messages that Cerberus gives; I'm not sure if there's anything we can do here other than address the issue and say we plan to improve these in the future.
We already somewhat-address backwards compatibility by putting ChemKED versions in the files, but don't actually do anything with this yet... right? Also, the older versions of PyKED are all archived and still available.
I agree that we should be consistent about using hyphen, underscore, or nothing in fields with multiple words. I like hyphens.
I'm not sure that we gain any readability by combining volume_history
and the compressed conditions, other than grouping RCM-specific stuff. Any thoughts?
Online lookup could slow things down a bit, if that's important—perhaps we should mention the "hidden" disable_validation
feature we added, when performance is important? Also, we can mention that our validation steps that require online lookup fail gracefully with no internet.
I think there are some valid use cases for creating another file, for example when you have manipulated a ChemKED
object and want to write it. However, what do think about this idea of printing summary statistics?
23--26 I should be able to fix.
Ohh, I think for
- I think it would be more clear if
volume_history
,compression_time
,compressed_temperature
, andcompressed_pressure
would be combined. The line: ‘if the ChemKED file encodes an RCM experiment’ is unnecessarily repeated.
the reviewer meant just in the text, since those are all conditional on the file being for an RCM experiment—I don't think it's a suggestion on combining in ChemKED itself.
Maybe we can separate the RCM-specific stuff into a separate list, with some explanatory text? Otherwise we could lump into a single bullet, but I don't think that improves clarity.
Reviewer #2 done!
Abstract and introduction
In my opinion the YAML format resembles the XML format strongly. XML format is human-readable, however, because of the html-tags and ‘<>’ characters, the YAML format might be easier to read. If XML would lack human readability as it is stated in the article, it would not be such a popular format, and I don’t think PrIMe and ReSpecTh would be using it.
Overview of ChemKED format
reference
should not be a required mapping of an experimental dataset. If the intention is to make the community to adopt the ChemKED file structure, it might be easier to do so if experimentalists can use the structure internally as well, i.e. to read, store, and share non- published internal data.atomic-composition
andelemental-composition
exist as synonyms? Wouldn’t it be clearer if only one of the two can be used as a valid input?common-properties
composition
blocks A and B and refer to them in theDataPoint
keys?PyKED architecture
mole-percent
,mole-fraction
, andmass-fraction
include a dash in their name, whereas this is not the case for the example on page 5 line 48 and in the description of the composition element on page 4, line 47.volume_history
,compression_time
,compressed_temperature
, andcompressed_pressure
would be combined. The line: ‘if the ChemKED file encodes an RCM experiment’ is unnecessarily repeated.write_file()
function. Creating a summary excel/CSV file would be more useful.Usage examples
RCM modelling with varying reactor volume
Shock tube modelling with constant volume
Conclusions and future work