-
Notifications
You must be signed in to change notification settings - Fork 52
Structure of the Database
The MaCFP database is organized around specific phenomena or unit problems in fire physics. Each problem has a directory at the root level of the database. And each problem is assigned task leaders to gather and present the available target experimental data. The database structure for a given problem is ultimately the choice of the task leaders. But below we provide a suggested structure, which we followed in setting up the Extinction benchmarks.
.
+---Buoyant_Plumes
+---Extinction
| +---UMD_Line_Burner
| +---Computational_Results
| +---YEAR
| +---INSTITUTION 1
| +---INSTITUTION 2
| +---Documentation
| +---Experimental_Data
| +---Plots
| +---Scripts
+---Gaseous_Pool_Fires
+---Liquid_Pool_Fires
+---Utilities
+---Wall_Fires
Under a unit problem we have directories for each experiment. Let's look at the UMD_Line_Burner experiment.
This is an empty directory that will be used to store submissions for computational results locally. The processing scripts (discussed below) will have relative paths already set up to look in this directory for computational results. Under Computational_Results are subdirectories for each year of the workshop and under each year are the contributions from each institution.
This directory should have a one to two page abstract of the experimental setup and computational targets for the experiment. Did you measure gas temperature or thermocouple temperature? If thermocouples were used, give details of the measurements (material, size, emissivity, etc.). Put yourself in the modelers' shoes; what information would you need to model this experiment? Make sure this information is in the documentation.
The easiest way to add the documentation is with a README.md file. This is a basic text file that can be formatted with Markdown syntax. The advantage of using the name "README.md" for the file is that GitHub recognizes that this is important information for you as a website visitor and displays the Markdown automatically when you are in this directory.
IMPORTANT: Put BibTeX references to any papers in the /macfp-db/Utilities/macfp_refs.bib file (discussed below). This will make life easy for those who wish to cite the work done by this workshop.
This is the life blood of the database, your experimental data. This needs to be stored in simple comma-delimited, ascii text files. Use one or two lines for column headers. Make column labels short but descriptive and unique. The same with names of the data files.
DO NOT dump your raw 1000 channel LabView file. Files should be no more than 10-20 columns. If the data is not clear from the filenames and column headers, provide a README.txt file in the Experimental_Data folder to help the modelers understand what it meant by the data. Ultimately, we want to be able to run the processing scripts provided to plot the experimental data (even without computational results). So, the simpler you make the data files, the easier it will be to write the processing scripts. Think in terms of being able to regenerate all the plots you put in a paper.
Like Computational_Results, this is an empty folder used by the processing scripts. After you run the processing scripts, look here for the plots.
Here put Matlab or Python scripts that can be used to read the experimental data and generate the target plots you envision the modelers to use to compare their results. The UMD_Line_Burner we have also uploaded a set of preliminary computational data (to the Computational_Results folder) and added lines in the processing scripts that other modelers can copy to plot their own results.
For consistency in formatting the plots, it is suggested that you add the script Utilities/plot_style.m to the top of your Matlab scripts. Additionally, Utilities/loose_inset.m sets the correct paper size for pdf plots using Matlab.
This folder lives at the root level because it holds files that may be needed by all the benchmark cases in the database. In particular, the macfp_refs.bib file will grow to hold all papers and other references related to this project and will therefore be extremely handy for those who want to reference this work in publications.
Keep in mind that everything is subject to revision and improvement. Mistakes can be fixed. Commit early and often---that is the motto of open source project development. The more eyes you have looking at your work the faster you find problems and can fix them.