Experiments
Experiments are the principle structures of the electronic labbook. There is no longer a "book" that is bound per experiment or per person. Instead, each procedure done in the lab should be an Experiment entry.
They must be a complete chronological protocol of what you did and contain "all relevant information necessary to verify and evaluate the result" [translated from DFG].
The collection in "books" will be replaced by linking the appropriate entries. For example, the information in a "Chamber Labbook" can be found by displaying all entries related (linked) to the Chamber Database Entry. A "Personal Labbook" can be found by displaying all entries of a user. Therefore it is of utmost importance that appropriate links are assigned when writing entries!
Information should not be scattered across several entries. Sometimes, standard procedures might be written down in Database Items, they might then be linked or even copied into the Experiment entry.
Title Conventions
Use this naming convention for Experiment titles:
"YYYY-MM-DD - SampleSystem - ChX - Blabla"
The parts are:
YYYY-MM-DD: The start date in isoformat.
SampleSystem: A short version of the sample system measured, like T4PT/Co/Au(111) or AuBowties_on_ITO
ChX: The experiment like Ch7, PEEM, STM, ...
Blabla: A short description of the Measurement, like "Evaporation Temperature Study"
Experiment Entry Types
An Experiment in elabftw does not always have to be a measurement in the lab. Procedures that should be logged in an Experiment entry can be for example:
The most obvious case: An experiment consisting of a sample preparation, laser alignment and a photoemission measurement.
The full procedure should be documented and the used Database Items should be linked.
In the images, all fields with light-blue headers represent Experiment entries! Arrows represent Links! Grey fields represent Tags!
A more involved maintenance procedure, like a chiller-replacement or cavity realignment of a laser, a filament replacement of a UHV Chamber, ... Everything that needs to be protocolled, but is too long to put it in the log of the respective Database Item. In those logs, the Experiment entries should be properly linked and only the most important resulting parameters copied. Such types of Experiment entries should be assignedthe ''Maintenance'' and/or ''Repair'' tag.
A numerical simulation in a commercial Software like Lumerical or a self-written one. (External) links to self-written scripts and other source codes on Gitlab should be included where appropriate. Simulation-type Experiment entries should be assigned the ''Simulation'' tag.
A sample preparation procedure not directly linked to an experiment (yet), like batch-production in the NSC or a fancier polishing procedure. Sample entries should be linked, obviously. This type of Experiment entries should be assigned the ''Preparation'' tag.
The setup and/or characterization of a new experimental assembly, like the building of a new Interferometer, the replacement of optics in a Beamline,... Depending on what's more accurate, tags like ''Buildup'', ''Maintenance'', ''Repair'' should be assigned.
An evaluation procedure can also be documented as an experiment entry. The corresponding entries where the data was measured should be linked and the ''Evaluation'' tag should be assigned.
In a larger measurement session, atomic procedures that would bloat the main entry can be written in their own Experiment entries and appropriately linked. The session is then considered a series and should get the ''Series'' tag.
A big project that is worked on over a longer period of time can have an overviewing Experiment entry, where the several entries of work procedures performed for the project are linked. The project entry should get the ''Project'' tag.
In the images, all fields with light-blue headers represent Experiment entries! Arrows represent Links! Grey fields represent Tags!