Correction of initial sample mass in README of FM data set

[TristanHehnen]

Initial sample mass in the README.md corrected, by subtracting the last data point from the first to remove the mass of what is presumably the sample holder.

[rmcdermo]

@leventon This is a test to see if you get an email notification. Please respond here if so. Thanks

[leventon]

Tristan,

Although the correction that you made makes sense (reported sample mass that you have here is now more meaningful than before) I'm not convinced that we need to include initial sample mass in the README files for g-scale tests.

Now that we have most all of our data uploaded here, I can compare across datasets to see if we're reporting things consistently; I'll be able to make minor formatting/content tweaks accordingly, when data is available, so that each README is as similar as possible. For TGA/DSC data, initial sample mass is relevant and something that I definitely want to include in the test setup description. For these bench-scale tests, it looks like only Aalto and FM datasets include initial mass in the README.

Initial mass can be calculated, if needed, from measured values in the .csv files for all datasets. I'm more inclined to actually remove the initial sample mass list in the READMEs of both Aalto and FM data and only keep test name and heating conditions in that table (the README is there mostly as reference/for test setup) and let users find measurement data just in the .csv file. In terms of managing the repo, if this is our end goal, I'd rather not make this edit (the pull request you suggest) only to remove it again later.

[rmcdermo]

@leventon
"Initial mass can be calculated, if needed, from measured values in the .csv files for all datasets."
How? by extrapolation?
It does not seem like it could hurt anything to be explicit about this.

[leventon]

Notification received.

…

On Wed, Mar 11, 2020, 12:23 Randy McDermott ***@***.***> wrote: @leventon <https://github.com/leventon> This is a test to see if you get an email notification. Please respond here if so. Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBUSGPELJVDWVCXV2ZTQ73RG63H5ANCNFSM4LFR5RQQ> .

[leventon]

@rmcdermo
It doesn't necessarily hurt but it's not information that was explicitly provided in the test setup/description files provided by most labs either and I am not inclined to manually calculate it and then write that value into the README for each of the bench scale datasets submitted by the other 12 labs. When Morgan and I have the chance to organize the scripts that we'll use to analyze / post-process data, initial & final mass, total mass loss, char yield.. all of these things might pop out as outputs, but I'm not sure the README file is the best place to store them, especially given that that'd require a lot of manual editing.

For a TGA/DSC test, I'd want to know immediately if sample mass was ~2-8 mg (or some other small enough value given the heating rate) so that I can confirm that samples are thermally thin and not worry about transport errors in my measurement data. Hence, we have that initial mass in the mg-scale section of our READMEs. I don't really need that quick check in my sample description for cone/gasification tests where everyone used 6 mm thick slabs.

There's nothing wrong, per se, with adding this here; I just don't think the README file is necessarily the best place for that info, I don't want to add it manually for every other README file (though I'd like these files to be as consistent as possible), and that information is available elsewhere as part of the actual measurement data (.csv) files.

[rmcdermo]

OK, then let's close this and Tristan can comment on the processing scripts you and Morgan put together. Thanks

[TristanHehnen]

I was a bit busy so I had this nearly finished response sitting here for hours... :)

(The following doesn't really matter anymore) The primary reason for this pull request is, that I found missing data earlier in the readme, following the scheme provided in the original file, and added it since I was working on it anyway. I now realised I made a mistake and I'm trying to correct it.

To the point of more streamlined readme files and processing scripts:
I've set up a Python dictionary containing the information provided from the experiments, to streamline my own workflow. I could provide this dictionary to this repo, if it is of interest. Also, when you set up a script to parse the files it could be interesting to extend the dictionary to incorporate all the experimental (meta) data.

[rmcdermo]

@TristanHehnen Thank you very much for your kind offer. I hope Isaac et al. will welcome help in setting up processing scripts for this repo. Perhaps we should get a video conference together soon to discuss this? Tristan, I will also send you an invite to be a team member.

[leventon]

That sounds like it would be quite helpful, yes. I'll echo Randy's thoughts and say thank you for that.

I should have the chance to sit down with all the submitted data/info this weekend. Though we tried to be consistent with what was uploaded, I'll make some last minor changes so that everything is as similar as possible. Hopefully that doesn't significantly affect your current scripts // it helps moving forward so that they work more consistently between all datasets. Also, in the near future, it looks like I should have the chance for some extended time teleworking so I'll be out of lab during the day and will have more time to focus on this repo.

[TristanHehnen]

Thank you very much for the invitation to become a team member, even though I'm not sure how much help I can provide.

I'm open to a video conference, maybe we could discuss about it via email.

For now, I've not managed to set up any automatic scripts to process the MaCFP repo. The mentioned dictionary was written by hand. It is based on the README files and aims to mimic their structure. I'll open a new issue, such that a discussion about it could take place there. Furthermore, I'll upload said dictionary to my own Git repo, such that you can have a look at it and decide if it is useful.

[TristanHehnen]

Link to the new discussion: #27