Closed trappitsch closed 6 months ago
Here's an example of the current json
file that the rimsschemedrawer
uses. The settings
entry can probably be neglected, since we will standardize the plotting with useful default values. However, the settings
should be there in case the user wants it!
{
"scheme": {
"gs_level": "0",
"gs_term": "3F2",
"ip_level": "55074",
"ip_term": "",
"step_level0": "170.15",
"step_level1": "386.88",
"step_level2": "21469.5",
"step_level3": "45498.85",
"step_level4": "56844.45",
"step_lowlying0": true,
"step_lowlying1": true,
"step_lowlying2": false,
"step_lowlying3": false,
"step_lowlying4": false,
"step_term0": "3F3",
"step_term1": "3F4",
"step_term2": "3G3",
"step_term3": "3G4",
"step_term4": "",
"unit": "cm<sup>-1</sup>"
},
"settings": {
"arrow_head_width": "0.6",
"arrow_width": "0.2",
"fig_height": "8",
"fig_width": "5",
"fs_axes": "12",
"fs_axes_labels": "14",
"fs_labels": "12",
"fs_title": "14",
"headspace": "2700",
"ip_label_pos": "Top",
"line_breaks": false,
"plot_title": "",
"prec_level": "0",
"prec_wavelength": "3"
}
}
The current proposal for a json
format to serve RIMS schemes:
{
"rims_scheme": {
"scheme": {
...
},
"settings": {
...
}
},
"saturation_curves": {
"First Transition, 319.215 nm": {
"unit": "W * cm^-2",
"data": {
"x": [
...
],
"y": [
...
],
"y_err": [
...
]
}
}
},
"notes": "Overall notes for the scheme.",
"references": [
"doi number 1", "doi number 2", ...
]
}
This json
file is very minimal. The red dots indicate where the data goes. The only key that is mandatory is the "rims_scheme"
.
Keys:
rims_scheme
: Dictionary with the entries directly from the RIMSSchemeDrawer
json. Note that only the scheme
entry is mandatory, the settings
have all default values.saturation_curves
: Each entry will produce one saturation curve with the key as the title. Each entry consists of the unit
to be used on the x axis, and the a data
entry which contains lists for x
data, y
data, and uncertainties in x and y (not mandatory!).notes
: Overall notes for the scheme.references
: DOI numbers with references. See #7 for details on how we could proceed with those.To be discussed:
A filled json
file can currently be found here
As of #22, the RIMSSchemeDrawer should now be able to take most schemes and display them nicely. The database now contains no more "settings"
data for these schemes and should only contain those if the default settings do for some reason not work.
After considering https://github.com/RIMS-Code/rimsdb_scheme_submission/issues/3, we need to change the saturation curve entries:
{
"saturation_curves": [
{
"title": "First Transition, 319.215 nm",
"unit": "W * cm^-2",
"data": {
"x": [
...
],
"y": [
...
],
"y_err": [
...
]
}
}
]
}
Once this is fully figured out, we need a writeup in a discussion or wiki about the detailed format
This is now written up in the wiki, see here
This is an idea gathering list on what we must have for a scheme database. Most entries will probably be optional.
All of these fields should be saved in a
json
file for automatic reading and generation of the website.Title
Element name and number (subsequent) for multiple scheme separation
Reference A reference with doi and title, etc., to the publication that provides the information for this scheme! Need to have the capability of submitting more than one scheme.
Notes
Any kind of experimental notes that the submitter wants to communicate to the user. The more detail the better.
One thing that could be important here as well is, how this scheme compares to others that are already in the database. For example, there are people who have multiple schemes for the same element and each of them has some up and downsides. For example, more non-resonant ionization vs. less laser need to be used to get this work. Notes are definitely crucial.
Scheme and drawing
rimsschemedrawer
package.rimsschemedrawer
json file directly in here instead of typing in all of the data. That would allow as well for less issues with the automatic plotting, since default values are sometimes difficult.Saturation curves
The data should be automatically fitted with a standard saturation curve and then we can print this result out as well! If the fit fails, maybe just leave it out?
Multiple saturation curves must be allowed, maybe subsections with a given title, e.g., the wavelength? And then we sort them by step or something similar?
The data should be shown as:
We should also allow for uncertainties in the signal, x and y probably? This might be a bit difficult to do. Maybe some true/false questions for the user to answer?
Name/handle of the submitter
Who submitted the scheme? This could be important to find out who to get in touch with, etc. This should not necessarily be the github username of whoever submitted it, then it would also allow to have schemes submitted, e.g., by the management team of the database. Ultimately, there will always be people who don't want to submit schemes online but just send data by e-mail. They should still be the "submitter", even if they don't put it themselves on the website.
GitHub submitter
Handle of the person that submitted the actual scheme via PR or via direct addition.