I have a new parser for OpenMX DFT code http://www.openmx-square.org/, living at GitHub - ondracka/nomad-parser-openmx and similarly to the LOBSTER parser I would like it to be included into upstream nomad (we have some publications nearing completions for which we would like to dump some OpenMX data to upstream archive).
The current status is that basic parsing of scf and MD stuff works: system, forces, velocities, method, sampling_method, eigenvalues, etc. Some examples of missing items are DOS and bandstructure parsing. All supported stuff should be quite thoroughly tested, however the code quality and especially cleanliness is likely not too good. Longterm I would like for the parser to be incorporated to the NOMAD CoE and Laboratory repo at github and I’d be willing to do some further cleanups if requested.
Thank you for this contribution. @ladinesa should have a look at it. We can probably include it in an upcoming release. Currently things are very slow due to vacation season. Will get back to you early August.
I suggest we proceed after refactoring the metainfo.
We are still in the middle of this refactoring. Our next major release (which could contain your parser) will not be before October.
Let us know, if you want to have this more urgently, e.g. to publish data. In this case we might put it into a patch release of our current system.
So unfortunately, it looks like October will be too late, the manuscript is almost ready now and will be probably submitted before the end of the month. I would really like to get a DOI in there to a dataset with many OpenMX calculations. Therefore, I would be very grateful, if the OpenMX parser could be included in the next 0.10.x point release.
@ladinesa can you prepare a merge request based on the current master? This would be for the old metainfo and you probably can take Pavels parser as is.
I put a version that includes the parser on our “beta” installation: NOMAD
@Pavel_Ondracka Could you test your upload there? Be aware it will add the data to the actual NOMAD as well, if you decide to publish already. If it works for you, I do the actual release.
Yes, it works. I have some failures (3 out of 110), but that is just some small problem with the parser, which I’ll fix later. However everything is detected so I’m happy.
BTW I’m having issues uploading the tar.gz file with all calculations with curl streaming. It gets stuck at 865MB every time (the file has 1.4GB). This was both with the beta and also with the production server, but it works fine if I upload to our local oasis. So I tested just with a smaller part of the whole dataset for now. Could you please check if there is some problem on Nomad side?
I just did a few test with larger files, which worked fine. I cannot find your upload attempts in our web server logs. I was looking for any use of upload tokens. The logs go back to Sept 4th.
Can you clarify which command you used and what “gets stuck” means?
It works today… with identical file and commands, strange 
@mscheidgen Could you please take a look at the upload ID D8WwfYo8RYOOCwcYaUN_OQ at the beta server? The upload went fine (with some parsing failures, but that were problems with my parsers that I’ll fix later) than I edited some metadata, that also seem to work OK, however after that the upload started to show “Upload processing has errors: AssertionError:” and now I can’t publish.
I understood from the comment #8 that I can test the upload at the beta server, and if it is OK, the publish should work and will move it to the main server? But maybe I misunderstood? So should I just redo the upload at the main server?
For some reason, the editing of metadata triggered the “lift_embargo” operation on the upload. This is what caused the error, because “lift_embargo” is not possible on non-published uploads. Hence the assertion. This should not have effected the rest of the edit operation and all your other edits were probably performed correctly.
Did the edit dialog offer you the lift embargo option and did you activated it? This would be a bug and we have to have add a check for that.
I removed the error from the upload. You should be able to publish now.
The beta and production installations are just running different software versions on the same data. Operations on either of them are immediately visible on the other.
Yes, your analysis is correct. There was the lift embargo checkbox (which I probably used) and now I confirmed with other upload that when I check it (together with some other metadata edits) and click submit, it will trigger the assertion.
Ok, then this is a bug (Lift embargo triggered for unpublished uploads during edit (#606) · Issues · nomad-lab / nomad-FAIR · GitLab). I’ll change the implementation to only lift embargo on those parts of an edit, where it is appropriate.