nomad-FAIR issueshttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues2023-12-21T15:39:04Zhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/319A more flexible and more celery-tonic processing module2023-12-21T15:39:04ZMarkus ScheidgenA more flexible and more celery-tonic processing moduleThis is a pre-requisite for #251
@himanel1 already started the implementation. I think this looks good and retains all features we had before. Here are some furhter todos that I see:
@mscheidg
- [x] add a redis to helm
- [ ] run some...This is a pre-requisite for #251
@himanel1 already started the implementation. I think this looks good and retains all features we had before. Here are some furhter todos that I see:
@mscheidg
- [x] add a redis to helm
- [ ] run some large scale processing
@himanel1
We should do the refactoring all the way. I think you should organize the submodules based on the processed entities Calc and Upload rather then trying to separate mongo from celery. A typical submodule structure that we also use in other modules would be:
* `processing/__init__.py` - Only docs and imports to expose to other modules
* `processing/processing.py` - All celery setup suff
* `processing/common.py` - Common sutff, the mongoengine base, our custom celery tasks/request, shared constants, etc., Pipeline, PipelineContext, Stage, empty_task
* `processing/calc.py` - Including the "celery task" `comp_process` (don't like the name, btw.)
* `processing/upload.py` - Including upload_cleanup, pipelines, get_pipeline, run_pipline
* I think we can move the tests into a singular module, or rename test_base->test_common, test_data->test_upload
upload can depend on calc; upload and calc can depend on common; all can depend on processing; no other dependencies between submodules should be necessary
In the future we could think about replacing: @process, current_process, process_status with celery. But at the moment its very convinient to use mongodb query to check on the processing status of all entities. I feel celery wasn't really designed with persistent tasks in mind. Also we would need to be far more regid with the celery infrastructure and add persistence to rabbitmq and redis.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/666Refactor "owner"2023-12-21T15:39:03ZDavid SikterRefactor "owner"The "owner" field, used in many api calls, uses terminology that doesn't fit so well after the changes done to the permission structure. A suggestion for improvement would be to call it "scope", rather than "owner" and change some of the...The "owner" field, used in many api calls, uses terminology that doesn't fit so well after the changes done to the permission structure. A suggestion for improvement would be to call it "scope", rather than "owner" and change some of the values, for example something like this:
|old name |suggested new name |
|---------|-------------------|
| public | public |
| staging | staging |
| all | **visible** |
| visible | **fully_visible** |
| user | **main_author** |
| | **writer** |
| shared | **viewer** |
| admin | admin |
The new values could first be introduced as synonyms for the existing values, to make the transition in steps.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/627Consistent component for "loading ..." status2023-12-21T15:39:03ZMarkus ScheidgenConsistent component for "loading ..." statusAt some point we discussed that we should use some consistent mechanism for placeholders while data is loading.
This was moved from #619At some point we discussed that we should use some consistent mechanism for placeholders while data is loading.
This was moved from #619https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/581CLI command for downloading from aflow needs to be updated2023-12-21T15:39:01ZDavid SikterCLI command for downloading from aflow needs to be updatedThe CLI command **synchdb** defined in **nomad.cli.client.update_database** needs to be updated to run in nomad v>=1.0.0, if not else because it sets metadata during publish which should no longer be supported.The CLI command **synchdb** defined in **nomad.cli.client.update_database** needs to be updated to run in nomad v>=1.0.0, if not else because it sets metadata during publish which should no longer be supported.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1184Use CLI to start nomad services in docker-compose2023-12-21T15:38:47ZMarkus ScheidgenUse CLI to start nomad services in docker-composeThe docker-compose using different scripts and commands to start the services (app, worker, north). Instead, it should simply use `python -m nomad.cli admin run ...`. This would give us more control and flexibility to change how the serv...The docker-compose using different scripts and commands to start the services (app, worker, north). Instead, it should simply use `python -m nomad.cli admin run ...`. This would give us more control and flexibility to change how the services are started without needing to update installations. Would also be more consistent with how we run services in development and the bare-metal installation.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/1009Metainfo data type improvements2023-12-21T15:38:46ZLauri HimanenMetainfo data type improvementsOur metainfo has some inconsistencies in how the different data types are handled. Here are some observations which could be broken down into separate issues if we decide to act on them:
- Units are ignored for primitive python numeric ...Our metainfo has some inconsistencies in how the different data types are handled. Here are some observations which could be broken down into separate issues if we decide to act on them:
- Units are ignored for primitive python numeric types (#1006).
- Units cannot be assigned to non-numpy 1D arrays (`pint` does not allow assigning units to regular python 1D lists).
- Units can be assigned to non-numeric quantities (maybe a `@constraint` would help here).
- Possible precision loss in downcasting is not handled consistently. For primitive types, one cannot assign values whose values do not match the target data type. This ensures that no precision is lost, but is too strict (cannot assign int to float). For numpy data types, there is no check for precision loss, and values can be casted freely. E.g. storing a float array to an int array does not raise any errors.
- The differences between some of the data types are quite vague. We do support both 32 and 64 bit `int` and `float` numbers, but is this difference realized when we are saving the archive to disk? How does the fact that Javascript only deals with one numeric 64 bit numeric type (`Number`) affect things when reading/saving data in an ELN?
- Arrays with dimensions > 1 can only be created for quantities that have a numpy data type. This is causing some confusion especially for people who do not know what numpy is.
My gut feeling would be that many of these issues would if we used numpy internally when storing all numeric values, no matter what shape (0D, 1D, ND). This way our metainfo would have one "normalized" form for all numeric data, but the user could use any compatible data type in assignments (we would check the compatibility automatically). This would also mean that upon accessing numeric data, the user would always get a numpy data back. Whether this is confusing or not is hard to say. This change would also mean that we could simplify the supported numeric data types. How far we simplify them is an open question. One extreme is to only support two numeric types: `int` (64 bit integer) and `float` (64 bit float). Another option would be to keep support for different variants (`int32`, `int64`, `float32`, `float64`, `uint32`, `uint64` etc.) but maybe use simple strings instead of the actual numpy data type objects, as it may be confusing for ELN users.
All of this is open for discussion and any comments are welcome.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/617Use current ASE2023-12-21T15:38:43ZAlvin Noe LadinesUse current ASEWe are currently using ase==3.19.0 but I need ase==3.22.0 for ASR to work. I tried to fix the dependency issues on the parser side but there seems to be an interdependency issue in the packages when installing nomad.We are currently using ase==3.19.0 but I need ase==3.22.0 for ASR to work. I tried to fix the dependency issues on the parser side but there seems to be an interdependency issue in the packages when installing nomad.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/634Refactor config "api" keys2023-12-21T15:38:38ZMarkus ScheidgenRefactor config "api" keysThe configuration of API related keys is very confusing. The path is always the same, but host/port have three different meanings that need to be supported by three different keys:
- to use by nomad client
- to return for external use
- ...The configuration of API related keys is very confusing. The path is always the same, but host/port have three different meanings that need to be supported by three different keys:
- to use by nomad client
- to return for external use
- to access the API via the internal server side network between different app container
Another thing is GUI vs API (which makes a difference in dev mode).
Similar internal vs external distinction is necessary for files (inside container, outside container).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/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/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/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/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/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/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/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/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/1111Revise and formalize annotations2023-02-22T10:04:52ZMarkus ScheidgenRevise and formalize annotationsThere are lots of annotations that are just dictionary types key-value pairs. Often without checks or documentation. Many of those have questionable or incomplete functionality.
- [x] eln
- [x] hide
- [x] table, tabular
- [x] plot
For...There are lots of annotations that are just dictionary types key-value pairs. Often without checks or documentation. Many of those have questionable or incomplete functionality.
- [x] eln
- [x] hide
- [x] table, tabular
- [x] plot
For these we should:
- establish proper classes that can be used in python and that check yaml definitions
- these classes should by pydantic models ... with documentation
- find a way to include the documentation in our docs.Markus ScheidgenMarkus Scheidgenhttps://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/308Band structure: normalizer and metainfo update2023-01-10T09:54:38ZLauri HimanenBand structure: normalizer and metainfo updateThe band structure processing should be refactored. This would consist of the following steps:
* [ ] Update band structure metainfo so that the duplicate normalized values are removed (`section_k_band` vs `section_k_band_normalized`) a...The band structure processing should be refactored. This would consist of the following steps:
* [ ] Update band structure metainfo so that the duplicate normalized values are removed (`section_k_band` vs `section_k_band_normalized`) and add new metainfo for the reciprocal cell and band gaps. The metainfo for `k_band_path_normalized_is_standard` should be renamed and moved to `section_k_band`. Also, the name of the whole section could be renamed, as `section_k_band` to me implies a single band, whereas in reality it contains all the bands. I would suggest "electronic_band_structure" (I think phonon band structure should be put under a "phonon_band_structure" instead of using a flag to separate between different kinds.
* [ ] The shape of the energy values is currently [number_of_spin_channels, number_of_k_points_per_segment, number_of_band_segment_eigenvalues]. This makes sense from a parser perspective, as the output is typically stratified over k-points. However, when the band should be analyzed or visualized it makes more sense to store it in shape [number_of_spin_channels, number_of_band_segment_eigenvalues, number_of_k_points_per_segment]. This way the bands would be stored as a contiguous block of memory and can be easily and effectively looped over for visualization or band gap analysis. On the parser side, this would only require swapping the axes 1 and 2 in the numpy array before storing the values.
* [ ] Create a BandStructureNormalizer that will:
* [x] Calculate band gaps
* [ ] Add labels for high-symmetry points according to the Setyawan/Curtarolo standard. There is a partial implementation in the VASP parser. It, however, supports only a subset of Bravais lattices for some reason.
* [ ] Check if the path follows the Setyawan/Curtarolo standard.https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/issues/856Revise version information2022-12-19T11:42:42ZMarkus ScheidgenRevise version information- The current NOMAD version is stated a many places throughout the source code. This is annoying to change.
- The documentation has no version statement
- The GUI could have a more prominent statement
- The API does not give any metadata...- The current NOMAD version is stated a many places throughout the source code. This is annoying to change.
- The documentation has no version statement
- The GUI could have a more prominent statement
- The API does not give any metadata with its responsesAdam FeketeAdam Fekete