Feat: Checks before runtime

[arn-all]

As proposed in #10 , a more general idea is to consider checks that could be easily done by the extension when writing a script, to catch errors before runtime :

• Missing or empty input files in read_data or pair_coeff commands
• Non-existing path for output destination (dump, log, write_data)
• Invalid format of input files (pair_coeff, dump files, final neb configuration file, ...)
• Reuse of an ID when declaring a command
• ...

I guess that possibilities are endless, and virtually impossible to automatically find. Though, I am confident that catching the most common ones is always interesting. The list can be completed later...

Edit : some users could be writing template scripts that are to be filled by some template engine (e.g jinja2). Any template markup like {{hello}} should be ignored.

[arn-all]

I'm thinking of a "dry-run" mode, which could be an option to catch many mistakes, but I'm really not sure, as there'd probably be many pitfalls.

The idea is to run lammps in a temporary folder, with a modified version of the lammps script, in which run commands are set to 1 timestep, and minimize or neb commands to a very tolerant criterion. It would allow Lammps to go through the whole script very quickly, and to let it complain about any illegal commands. But I guess that complex runtime structures (loops, ... ) would make it much more complicate to do. Do you think it's worth discussing in a separate issue ?

[ThFriedrich]

Those are some interesting approaches. I am not sure about the dry-run idea. I think there is indeed a lot of pitfalls as you say. Maybe it'd be wise to keep this extension independent of the actual Lammps program unless we were to include some custom debugger functionality at some point. For now, I think it'd be more reasonable to create some kind of Linter to catch common mistakes before runtime. That could be just a set of functions to be run when the document changes and add Problems/Errors via the API. I went ahead and gave that a try, prepared a dedicated module for linting functions, and implemented a check for existing files on read-commands in this commit. It seems to work nicely so far.

However, I am not sure if we could run into performance issues as the number of checks increases. Maybe it is worth considering to set up a language server, which would be running in separate processes. Lammps Scripts are usually not very long though I suppose, so performance may not be much of a concern after all. I don't know.

I created separate issues and a project for all the document checking. I guess this is easier to manage.

Edit: I committed a neater version, also checking directories for write-commands.

[arn-all]

Hi Thomas,

Just letting you know that based on a user request, there is now a kind of dry-run mode for LAMMPS, which can be activated via the CLI (-skiprun). The idea is to set a timeout to 0, so each run/minimize operation will be skipped. It has caveats (e.g conditional execution) but can help spot some mistakes in input files. We could add a Run : Single-Task (dry-run) to task_fncs.ts in the future if you agree (though it won't work for older LAMMPS versions than the patch released on yesterday).

[ThFriedrich]

Hi Arnaud, thanks for the update. Sounds good to me and should be fairly easy to implement. I don't have much time to look into it myself at the moment, but of course I'm always happy about PRs. :) Since also the documentation content updates regularly, it makes sense for users to work with a version of lammps_vscode that corresponds to the version of lammps they're running. So I wouldn't worry too much about backwards compatibility in this case. This feature is not gonna break any other functinoality. A remark in the Changelog/Release Notes would probably be enough.

[ThFriedrich]

The dry-run feature was added in this commit and ships with version 1.7.0