Add the LammpsRawCalculation and LammpsRawParser plugins

[sphuber]

These CalcJob and Parser plugins provide a bare-bones interface to running any LAMMPS calculation. The CalcJob just requires the script input which takes a complete LAMMPS input script. The files namespace can be used to add additional input files to the working directory.

[sphuber]

I added a separate parser plugin because the LammpsBaseParser is tightly coupled to LammpsBaseCalculation. It assumes a bunch of attributes will be set (such as the names of the various output files) which don't apply to the LammpsRawParser. At the very least, I think we can factor out the parsing of the log file output (which is reused in the LammpsRawParser) but before doing so I wanted to first pass the generic design of review.

Alternatively, we could try to make the LammpsBaseParser a bit more generic such that it is usable by both calcjob plugins.

[codecov]

Codecov Report

Merging #80 (814453b) into develop (2b98d35) will increase coverage by 0.31%.
The diff coverage is 94.80%.

@@             Coverage Diff             @@
##           develop      #80      +/-   ##
===========================================
+ Coverage    88.80%   89.11%   +0.31%     
===========================================
  Files           17       19       +2     
  Lines         1384     1461      +77     
===========================================
+ Hits          1229     1302      +73     
- Misses         155      159       +4     

Flag	Coverage Δ
pytests	89.11% <94.80%> (+0.31%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
aiida_lammps/parsers/raw.py	84.61% <84.61%> (ø)
aiida_lammps/calculations/raw.py	100.00% <100.00%> (ø)

[JPchico]

Looks good. One question is it possible to somehow parse the trajectories? I think that the log file and the trajectories are what most users will be interested in.

[JPchico]

ping @sphuber , did yo have a chance to look at my question? Otherwise I think this is ready to merge if there is no way to parse the trajectory.

[sphuber]

Didn't have the time yet, but I just checked and don't think it is possible by default because not all scripts print trajectory data that can be parsed. Take for example this benchmark script of the LAMMPS website itself: https://www.lammps.org/inputs/in.lj.txt

It will produce the two output text files
log.lammps.txt
and
lammps_output.txt
(Minus the .txt extensions which are necessary to upload them here). Neither seem to contain parsable trajectory data to me, but I could be missing it.

I think that if you don't explicitly instruct LAMMPS to print it in the input script, it doesn't print it by default? And not sure if there is a default output format that we can have the parser try and detect. I am not familiar enough with LAMMPS to know in what ways trajectory info can be printed out.

[JPchico]

I think that if you don't explicitly instruct LAMMPS to print it in the input script, it doesn't print it by default? And not sure if there is a default output format that we can have the parser try and detect. I am not familiar enough with LAMMPS to know in what ways trajectory info can be printed out.

I think that you are right, if one does not set the dump command I think that the trajectories are not printed.

One could try checking but considering that the script could assign any name or any format to the trajectory it would be basically impossible (unless one sets it somewhere in the setting maybe?) to know what file is the trajectory.

Worst case it should be possible to modify the list of retrieved files at submission time right? Of that way the user could specify which files should be put in the retrieved and then the user could do whatever they want with them.

[sphuber]

Worst case it should be possible to modify the list of retrieved files at submission time right? Of that way the user could specify which files should be put in the retrieved and then the user could do whatever they want with them.

Exactly, they can also do this and then parse manually with a calcfunction after the CalcJob finishes.

[JPchico]

I also see that the documentation is failing. It is complaining about the docstring in the parser/raw.py but I do not see the offending line.

[JPchico]

For my part if you figure out the mysterious doc failure, I'm all for merging.

What do you think @chrisjsewell ? Does this address the concerns you had?

[sphuber]

For my part if you figure out the mysterious doc failure, I'm all for merging.

It makes no sense to me whatsoever, because the CalcJobNode class is not mentioned anywhere in the added docstrings. So I just added a nitpick ignore statement

[JPchico]

For my part if you figure out the mysterious doc failure, I'm all for merging.

It makes no sense to me whatsoever, because the CalcJobNode class is not mentioned anywhere in the added docstrings. So I just added a nitpick ignore statement

Yeah that was my thought, but I was wondering if I was going even more blind.

Thanks for checking!

@chrisjsewell unless you object I think we should merge this, probably today, since I think it is pretty ready.

[JPchico]

@sphuber I think that there are no objections to this PR so I'll merge it.