nomad-FAIR issueshttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues2024-03-01T11:03:51Zhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1886Packages aliases in metainfo2024-03-01T11:03:51ZMarkus ScheidgenPackages aliases in metainfoWe are currently moving a lot of metainfo packages. It is necessary to have some infrastructure that allows to gracefully deprecate old package names. The goal is to not have to reprocess or otherwise migrate data instantly.
"Package al...We are currently moving a lot of metainfo packages. It is necessary to have some infrastructure that allows to gracefully deprecate old package names. The goal is to not have to reprocess or otherwise migrate data instantly.
"Package aliases" would allow to add old package names to a package definition:
- `m_from_dict` will consider package aliases when looking for definition referenced in `m_def`
- the gui will consider package aliases when looking for definitions referenced in `m_def`
- searches targeting `section_defs` will expand into an "or" on all package aliases
- facilities will be made available to clients to easily work with package names and consider package aliases in the process
Property aliases (espsecially for sub sections) is a related functionality, not covered in the issue.Markus ScheidgenMarkus Scheidgenhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1825Include Perovskite Solar Cells Database Pugin2024-01-29T12:56:40ZJose Marquez PrietoInclude Perovskite Solar Cells Database PuginWe would like to include the schema of the [perovskite solar cells database as a plugin](https://github.com/FAIRmat-NFDI/nomad-perovskite-solar-cells-database) and update the published entries to the new m_def. In a separate issue, when ...We would like to include the schema of the [perovskite solar cells database as a plugin](https://github.com/FAIRmat-NFDI/nomad-perovskite-solar-cells-database) and update the published entries to the new m_def. In a separate issue, when everything is tested and proves to work well we will removed the `nomad/datamodel/metainfo/eln/perovskite_solar_cell_database` directory from the nomad-FAIR project.
We need to:
- [x] Include the plugin as a sub-module in `dependencies/schema`.
- [x] Make sure that we can create entries with the update m_def. The easiest way to test this is by creating an entry from schema. You should get a duplicated version of the Perovskite Solar Cell entry.
- [x] Update the .zip file of the two uploads (`FT8UX98FS5KtDbNBw-dU3A`, `2hXmBxK1QdmA13yJCYLxmg`) that contained the currently published data. @josma
- [x] `FT8UX98FS5KtDbNBw-dU3A` [direct download link](https://box.hu-berlin.de/f/a404127136a043d49bf1/?dl=1)
- [x] `2hXmBxK1QdmA13yJCYLxmg` [direct download link](https://box.hu-berlin.de/f/221417dcae0f4936a929/)
@mscheidg, could you please add the necessary points to achieve this? @g-yaruwang will be handling this.Markus ScheidgenMarkus Scheidgenhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1637Some Tabular parser features to revise or add2023-10-05T06:59:56ZAndrea AlbinoSome Tabular parser features to revise or addWhile me and @jschumann were testing independently the parser, we noticed some features to fix or to add:
- the following file has a repeated sub_sub_section along the row (the columns "Element" and "fraction"). If one has only two bloc...While me and @jschumann were testing independently the parser, we noticed some features to fix or to add:
- the following file has a repeated sub_sub_section along the row (the columns "Element" and "fraction"). If one has only two blocks of this sub_sub_section, the parsing is fine. If one adds a third block of columns, some errors are raised.
- the filename of generated entries is currently the name of the m_def class + a sequential number, I think it should be picked from a quantity of the m_def class.
- empty cells in excel file should not raise errors, just not fill the quantity
- after loading and parsing one of this schemas and excel files, if I hit the reprocess button some entries change their process status in failure and opening them the error "Something went wrong in this part of the app (Javascript error)." is displayed.
- These generated entries cannot be singularly deleted until I save them a second time and they are actually written into physical files
To test the issue above, create an entry choosing "CatalystCollection" class and drop the excel file inside there:
[entry_schema_basi.archive.yaml](/uploads/eee887b85facc5f272f06a30f7ff4944/entry_schema_basi.archive.yaml)
[test_upload_w_3_elements.xlsx](/uploads/5ce89535e09f8934f4ba61e6b1cfc7ea/test_upload_w_3_elements.xlsx)
@amgo is following us in testingAmir GolparvarAmir Golparvarhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1634Upload page refactor2023-12-21T15:55:49ZLauri HimanenUpload page refactorWe want to make the upload page more intuitive and also more capable in terms of filtering and interacting with the entries. This refactoring may also affect the terminology (upload vs project?) and how datasets and DOIs are handled.
He...We want to make the upload page more intuitive and also more capable in terms of filtering and interacting with the entries. This refactoring may also affect the terminology (upload vs project?) and how datasets and DOIs are handled.
Here are some initial ideas to keep track of them:
- The user cannot really search for certain entries within an upload directly in the upload page. This might be useful when e.g. deleting or otherwise interacting with the entries. Suggested by @jlehm.
- Add `method_name` and `workflow_name` from results in the table. I really think this should be by default, at least from my side it is complicated to clearly see which entry comes from where, but tbh I think then the layout should change a bit to allocate for this extra info. Suggested by @pizarroj
- Ctrl+click to open tabs into entries. Suggested by @pizarroj
- Drop-zone component for dropping or adding files instead of a button. Suggested by @josmahttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1630Deprecate or extend metadata.domain2023-12-21T16:06:52ZAlvin Noe LadinesDeprecate or extend metadata.domainEntryArchive.metadata.domain currently is either dft/ems. This obviously need to be extended (see e.g. https://github.com/nomad-coe/nomad/issues/64). However, I am not quite sure if this is still relevant and therefore be deprecated. @hi...EntryArchive.metadata.domain currently is either dft/ems. This obviously need to be extended (see e.g. https://github.com/nomad-coe/nomad/issues/64). However, I am not quite sure if this is still relevant and therefore be deprecated. @himanel1 @mscheidg what do you think?https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1603Replace the celery-based example data usage with the ExampleData2023-11-06T14:07:46ZAhmed IlyasReplace the celery-based example data usage with the ExampleDataRelated to #1580Related to #1580Ahmed IlyasAhmed Ilyashttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1506Spectra normalizer2023-08-29T09:27:09ZJose PizarroSpectra normalizerFollowing #1316 I will develop and push a `SpectraNormalizer` and the visualization inside `ElectronicPropertiesCard`. This should:
- [x] Normalize spectra to the max intensity.
- [x] Define `type` for all types of spectra (EELS, XAS, X...Following #1316 I will develop and push a `SpectraNormalizer` and the visualization inside `ElectronicPropertiesCard`. This should:
- [x] Normalize spectra to the max intensity.
- [x] Define `type` for all types of spectra (EELS, XAS, XANES, EXAFS, XPS...).
- [x] Merge EELS data into Spectra.
- [x] ~~Create visualization in between BZ/BandGap and GreensFunctions cards or~~ in its own card `SpectroscopyProperties`
- [x] Add tests for Spectra.
@lucamghi @sanbrock I think at this point you should be informed of my ovjective. This will only affect Area C data, but it might be nice to prepare the changes such that, when Area B wants to tackle this, what I did it is not a complete mess or too different than expected, and that it is easy to extend with extra metainfo :slight_smile:
I will push a branch soon (a couple of weeks max, if the reprocessing does not show too many errors this week).Jose PizarroJose Pizarrohttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1498Bundle format test and documentation2023-12-21T15:39:10ZMarkus ScheidgenBundle format test and documentationWe should try our bundle import and export CLI functionality on our first two example uploads. David implemented this, but I am not sure what we actually have here. I want to see what this can already do and what not. We need this as a s...We should try our bundle import and export CLI functionality on our first two example uploads. David implemented this, but I am not sure what we actually have here. I want to see what this can already do and what not. We need this as a starting point for further discussions on data transfer.
As a side effect, please extend the documentation with a brief "how to import and export uploads". This should cover the commands and a rundown on the bundle format, e.g. what files it contains, whats in the nomad.json, etc. We can put this under "NOMAD Oasis" for now.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1497Store RFC timestamp seed in mongodb2023-05-23T15:06:47ZMarkus ScheidgenStore RFC timestamp seed in mongodbThe source of truth in NOMAD are raw files. And everything that is not in a raw file, gets its truth from mongodb: comments, datasets, references (i.e. urls). Storing the RFC timestamps only in the archive does not fit this policy. Loadi...The source of truth in NOMAD are raw files. And everything that is not in a raw file, gets its truth from mongodb: comments, datasets, references (i.e. urls). Storing the RFC timestamps only in the archive does not fit this policy. Loading it from the old archive upon reprocessing is very ugly. Also these timestamps might become very important and should be handled with proper care.
We should store the RFC timestamp in mongodb, similar to `comment`, `references`, `datasets`, `entry_coauthors`. It does not necessarily need to be the full timestamp section with all properties, but some string that the actual timestamp model in the archive can be re-created from. The archive will still contain the timestamp and from there it is visible in the UI, but it will be read from mongo upon reprocessing and not from an old archive version.Theodore ChangTheodore Changhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1484Rewrite msgpack reader/writer2023-06-23T12:57:15ZTheodore ChangRewrite msgpack reader/writerThe existing msgpack reader ignores fields with primitive values.The existing msgpack reader ignores fields with primitive values.Theodore ChangTheodore Changhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1479Normalization refactor2023-12-21T16:06:50ZLauri HimanenNormalization refactorWe currently have a concept of "normalization" that is separate from parsing. For this we have separate classes that are run in a pre-determined order based on what is configured in nomad.yaml. In addition, schemas may define a "normaliz...We currently have a concept of "normalization" that is separate from parsing. For this we have separate classes that are run in a pre-determined order based on what is configured in nomad.yaml. In addition, schemas may define a "normalize" function that specified schema-specific functionality that is run by a special `MetainfoNormalizer`, typically at the very end.
There are certain limitations to this approach:
- A single global order for the normalizers does not work for every parser and schema.
- The distinction between parsing and normalizing is often blurred.
- It is hard to track the execution order of normalizers
- It is hard to understand the difference between a `Normalizer` and a `normalize`-function.
- It is hard for a plugin developer to make use of the existing normalization code in `nomad.normalizing`.
In order to simplify this, we could think of a simpler strategy, such as:
- All processing of an entry could be moved into a single `normalize`/`parse` function of the schema. In the case of python schemas this is almost the case already. In the case of a parser, we would explicitly define a schema as well that would just combine the contents of the current `metainfo` folder and `parser.py` module. Essentially parser == schema.
- There would no longer be a set of separate `Normalizers` that would be run after parsing: each schema can still make use of their functionaliy, but they would be in full control of the call order.
- For parsers/schemas that behave very similarly (such as all electronic structure parsers) there could be base classes that trigger a common set of normalization procedures, but the schema could overwrite this at any point.
- The current code in `nomad.normalizing` is based on classes that operate on archives. The classes typically contain different methods for processing different parts of the data. It is hard for a plugin developer to use the existing normalization functionality since it is abstracted inside these monolithic classes. The situation could be improved by providing several smaller pure functions inside the `nomad.normalizing.<name>` modules.
I feel that this would bridge the gap between parsers and Python schemas and would make plugin development much more intuitive.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1450embeddedDMFT parser and revisit DMFT metainfo2023-09-05T13:33:19ZJose PizarroembeddedDMFT parser and revisit DMFT metainfoThis issue is to extend the current `DMFT` and `GreensFunctions` metainfo (both in `run` and `results`) for parsing and normalizing w.r.t to the code [eDMFT](http://hauleweb.rutgers.edu/tutorials/index.html).
They have their own [databa...This issue is to extend the current `DMFT` and `GreensFunctions` metainfo (both in `run` and `results`) for parsing and normalizing w.r.t to the code [eDMFT](http://hauleweb.rutgers.edu/tutorials/index.html).
They have their own [database](http://hauleweb.rutgers.edu/database_w2k/) that we can parse too into NOMAD-lab after the eDMFT parser is prepared.
* [x] Add eDMFT parser.
* [x] Clean-up `run.method.dmft` metainfo.
* [x] Add `results.method.dMFT.maxent_analytical_continuation` boolean quantity.
* [x] Add quantities to `run.calculation.greens_functions_electronic` for:
* [x] `greens_function_freq` and `self_energy_freq` (in real frequencies).
* [x] `hybridization_function` for both imaginary and real frequencies.
* [x] \- Im G(w) / pi is directly comparable with DOS -\> parse into Dos.total and Dos.orbital_projected.
* [ ] Extract band_gap_electronic information from `greens_function_freq`.
* [ ] Parse DFT+DMFT workflow:
* [x] Wannier+DMFT workflow ( #1445).
* [x] DMFT+MaxEnt workflow.
* [ ] DFT+DMFT(+MaxEnt) workflow.Jose PizarroJose Pizarrohttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1440Reordering the order of quantities and sections in the ELN2023-12-21T16:04:41ZAndrea AlbinoReordering the order of quantities and sections in the ELNTesting the implementation accomplished after #1305, I noticed that we cannot mix quantities and sections.
Basically, the section are always flushed together at the bottom.
I think the main reason to have this custom ordering touching b...Testing the implementation accomplished after #1305, I noticed that we cannot mix quantities and sections.
Basically, the section are always flushed together at the bottom.
I think the main reason to have this custom ordering touching both sections and quantities is to bring the sections at the beginning of our ELN visualization, and especially to flush at the bottom the giant RichTextEditQuantity, because it hinders the view on everything that is below.
@g-michaelgoette you may comment whether you may find this useful as well or not really.
![Screenshot_from_2023-04-21_13-33-45](/uploads/5ccf66547781482c81d2d1f5cc73e952/Screenshot_from_2023-04-21_13-33-45.png)https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1375Deprecate browse annotation for explicit JSON and HTML metainfo type.2023-12-21T16:04:41ZMarkus ScheidgenDeprecate browse annotation for explicit JSON and HTML metainfo type.This would remove a relatively unknown and superflous annotation. Explicit types would give us more options to check values (e.g. sanitize) on deserialisation.This would remove a relatively unknown and superflous annotation. Explicit types would give us more options to check values (e.g. sanitize) on deserialisation.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1272Formula rendering improvement2023-12-21T16:06:49ZLauri HimanenFormula rendering improvementAll of the chemical formulas we display within non-editable fields should be rendered with subscripts. For editable fields (URLs, search boxes etc.) the plain-text version will still be used.
We need a function to transform a regular pl...All of the chemical formulas we display within non-editable fields should be rendered with subscripts. For editable fields (URLs, search boxes etc.) the plain-text version will still be used.
We need a function to transform a regular plain-text formula to proper formatting + a possible react component for displaying formula. These should be used in several locations, including overview page, search chips, table rows etc.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1271Band gap refactor2023-04-25T06:47:50ZLauri HimanenBand gap refactorThe way we store band gaps should be refactored. Currently, there are different locations for storing this data, depending slightly on what is exactly being measured: `results.properties.electronic.band_structure_electronic.band_gap` for...The way we store band gaps should be refactored. Currently, there are different locations for storing this data, depending slightly on what is exactly being measured: `results.properties.electronic.band_structure_electronic.band_gap` for band gaps extracted from band structure (theory) and under `results.properties.optoelectronic.band_gap_optical` for band gaps extracted using experiments. Instead, the values should be stored in a single location no matter what the methodology for approximating the band gap is.
- [x] Decide a new location for the band gap information. Maybe `results.electronic.band_gap` would make most sense. The description needs to be modified to properly explain what can be stored in this quantity.
- [x] Modify the normalizers to store the band gap information in the correct place, refactor tests and add new ones.
- [ ] Modify also custom normalizers in `nomad/datamodel/metainfo/eln/perovskite_solar_cell_database/__init__.py` and `nomad/datamodel/metainfo/eln/__init__.py`
- [ ] Modify GUI to use the new location.
- [ ] In production, we need to migrate the data to use the new location. This would mean reprocessing the ~420k entries with a band structure + 40k entries from the solar cell data.
- [ ] Remove old metainfo once data has been migrated.
- [ ] Maybe we need new metainfo for `exciton_binding_energy`?Nathan DaelmanNathan Daelmanhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1261Improve the release process2023-12-21T16:06:49ZMarkus ScheidgenImprove the release process- Don't know how to create an actual release with a NOMAD version that matches the tag. You'll always get a version like `1.1.7.dev0+g2ecdd77f8.d20221223`. How to i create a `1.1.6` image and python package?
- There is no docker tag crea...- Don't know how to create an actual release with a NOMAD version that matches the tag. You'll always get a version like `1.1.7.dev0+g2ecdd77f8.d20221223`. How to i create a `1.1.6` image and python package?
- There is no docker tag created for the gitlab tag
- The tag pipeline is not building an image. So I have to re-run the latest `develop` pipeline to build with the new git generated version
- The integrations test don't work. Probably a file is missing from the image that is used to run the integration test client.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1260GUI (explore/entries and explore/materials menus) cleanup2023-04-25T08:56:23ZLuca Massimiliano GhiringhelliGUI (explore/entries and explore/materials menus) cleanup@mscheidg @himanel1 @ndaelman @pizarroj @jrudz @ladinesa .
# GUI cleanup
## General features
- This list of changes has been thoroughly discussed in Area C. The main idea is to remove everything that contains wrong values or denominatio...@mscheidg @himanel1 @ndaelman @pizarroj @jrudz @ladinesa .
# GUI cleanup
## General features
- This list of changes has been thoroughly discussed in Area C. The main idea is to remove everything that contains wrong values or denominations, unless we see easy fixes, in which case, we describe what should be changed.
- This applies to explore/entries and explore/materials views, but other apps that use similar menus may consider to adapt (e.g, solar cells)
- There will be no changes in "results" metadata section, all changes in the GUI itself.
- Allow for subscripts for chemical formulas (**Lauri: tracked in issue #1272**) and (optional) Strukturbericht Designation. This is in the visualization. The search string should be still in line e.g., "C3PO4" or "L10" rather than any tricky way to write the subscripts on the fly. There is no ambiguity in having the subscripts in formulas and Strukturbericht in line, but in the visualization, it makes it appear way more professional.
- The comments are based on what one sees in beta version as of today, December 23, 2022.
- In the future, I propose that changes in NOMAD that reflect into changes in the GUI main page (explore/entries "app", and also explore/materials as the layout of the menus is the same, except for the `Combine results from several entries` option) should be submitted to coordinators (at least ABC) for approval. Also for the beta version, inasmuch it is a version easily publicly accessible from the FAIRmat/NOMAD pages
- Some of the entries may spawn dedicated issues in order to keep the discussion here tidy. In that case, we should add a link to the dedicated issue in the list below.
- Individual entries need to be assigned, probably we meet early next year to discuss who does what and deadlines?
## List of changes
- `Material`
- [x] `structural type`, *rename* into `Dimensionality`. Again: no change in the metadata name at this point, but eventually we should consider renaming when necessary. E.g., `structural type` really tells nothing about what one may find as options.
- [x] Check: `structural type = 2d`, there are no data? It seems that in the prod version there are data under this class. **Lauri: Fixed in #1256**
- [x] In the near future: check `structural type = unavailable`; In principle there should be no unassigned entries according to dimensionality. In particular, to be checked: liquids and solvent in liquids are categorized as? **Lauri: Things can be unassigned, as structural_type != dimensionality. Structural type has additional checks that go beyond dimensionality. For now I'm simply hiding the value unavailable from the menu.**
- [x] `functional type`, remove. [These are from Springer-Materials. It is unclear if we can tell it explicitly, due to copyrights, and also the assignment is often questionable. IMPORTANT: Ask Pepe about "solar cell" (suggestion: only in app) ]
- [x] `compound type`, remove [It needs rethinking. E.g, "chemical element" should be elemental system? "Intermetallic" is not just something containing d-metals; maybe oxide, nitride,and so on are fine, but let's remove it and then work later to make it publishable]
- [x] `material name` -> remove. [it is just the chemical formula in words, not the name of the material. E.g., carbon is not a material. So, the label "material name" is misleading.]
- element formula
- [x] `chemical formula anonymous`: show by default the statistics so that one can see what are the possible search values. Also, improve the description, as at the moment it is unclear what/how to search for. **Lauri: now the placeholder shows examples, improved the metainfo description.**
- [x] IMPORTANTLY: add `IUPAC chemical formula`. I.e., order elements by electronegativity (e.g., Pauling). [This is the only change that requires a normalizer and a new metadata item, but it is long due. This should be also the default formula shown in the `Formula` column in the listed results.] **Lauri: now added IUPAC formula as defined in IUPAC nomenclature of inorganic chemistry 2005. The chemical proportion numbers are not NOT reduced. Note that we should not make the table column shown this formula before most of the entries have it (requires reprocessing or some manual ES scripting.).**
- [x] Add `chemical formula reduced`. This is already created upon normalization, I believe, but it should be made searchable. Note: probably, since the stoichiometric number now would be rational numbers, not necessarily integers, the searched formula should be parsed up to a pre-fixed precision (e.g., 2 decimal points). **Lauri: Now added with examples in the placeholder. We follow the [OPTIMADE definition](https://github.com/Materials-Consortia/OPTIMADE/blob/master/optimade.rst#chemical-formula-reduced) that only allows integer stoichiometry. There is also a bug associated with the reduced formula that is tracked in #1259 and #879 that will be fixed here.**
- `symmetry`
- [x] `structure name`, remove [It needs revision, it is not clear what kind of classification this is and how it is assigned and in general the class names are a heterogeneous lot] **Lauri: As discussed, I merged the Pnma and cubic perovskite definitions into one `structure_name=perovskite` option. This also fixes #520. In the GUI I'm temporarily hiding the cubic perovskite option. This filter is otherwise kept as it is, since it is very useful. Renaming is of course possible.**
- [x] `space group symbol`: move it to 3rd place, after Bravais Lattice and crystal system. Also add statistics by default in order to show options. **Lauri: Reordered, now the placeholder shows examples.**
- [ ] Not the highest priority: correct `Strukturbericht Designation` entries, i.e., with subscripts where necessary. See https://aflowlib.org/prototype-encyclopedia/strukturberichts.html or https://en.wikipedia.org/wiki/Strukturbericht_designation for the correct symbol. **Lauri: tracked in issues #1274**
- [x] `Prototype aflow`, show statistics by default to suggest options. **Lauri: now the placeholder shows examples.**
- `Method`
- [x] Remove `method name` and `workflow name`. This implies that `method` is no longer a menu, just a header of the items below it (`simulation`, etc.).
- `DFT`
- [ ] Remove `xc functional type` and substitute with `Jacob's ladder` **Lauri: this is tracked separately in issue #1167.**
- `EELS`
- [ ] check `Electron Energy Loss Spectrum (EELS) Max Energy (eV)` entries. Apparently, one wrong entry is making the scale unreasonable. In general, for the future: define expected ranges for values to catch bogus entries at parsing/normalization time. It is better to have one/few entry/ies unlisted than having the ranges screwed to accommodate wrong values. **There is already an issue about this in #814. I think the best way to handle this is to not ignore such data but instead sanitize the aggregations by default with some sensible limits.**
- `Properties`.
- [x] remove `Optoelectronic`. [It is a copy of solar cell properties in solar cell app, where it belongs]
- [x] remove `Spectroscopy`. [It is not a property and it is a copy of Experiment / EELS]
- [x] remove from `properties` `Thermodynamics` and `Geometry Optimization` (see next point, where this are moved to)
- [x] Add new section `Workflow` with items:
- [x] `Geometry Optimization`, which is the current `Geometry Optimization` from `Properties`, just moved here.
- [x] `Molecular Dynamics`, which is the current `Thermodynamics` from `Properties`
- [ ] For the future: `Optimade` should rather be an option in the search bar. **This belongs into a larger topic of supporting more complex search queries in the search bar, including the optimade language and possibly some other alternatives as well.**Lauri HimanenLauri Himanenhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1233Optimization for the GUI test2023-05-16T16:11:06ZMohammad NakhaeeOptimization for the GUI testMohammad NakhaeeMohammad Nakhaeehttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1213Client auth from access token in config2022-12-06T22:30:57ZMarkus ScheidgenClient auth from access token in configWe should allow to automatically authenticate (for requests, and `ArchiveQuery`) from an access token that is set in the config (or environment). One use case is that we can pass the access token to the environment in north tools.We should allow to automatically authenticate (for requests, and `ArchiveQuery`) from an access token that is set in the config (or environment). One use case is that we can pass the access token to the environment in north tools.Markus ScheidgenMarkus Scheidgen