Handle the deprecated parameters of individual entries to a list entry

acdaigneault commented 3 months ago

Description

Parameters are often changed as refactoring in the DEM solver, but it causes issues when running simulation with old parameter files. Those files get incompatible with the latest version of the code and need to be updated by the user. There is a function in deal.II (called declare_alias()) that allows to still use old parameters as alias, but need to be the same type so the parsing stays the same. Also, it can give a warning about the deprecated file. We started, and we are planning, to convert some old individual parameter entries to one parameter that is a list of values. It means 3 parameters of double will be changed to one parameter of a list of double. In order to avoid the above, this refactoring aims to handles those old parameters. The only issue with the current implementation is there is no way to assert if the new parameter is set as a double. Also, this PR applies those changes to the gravity force in DEM.

Testing

New test deprecated_parameter uses the old gx, gy, gz parameters. The old parameters (in 2d or 3d) were tested and it works well and gives a warning for the deprecated parameter.

Documentation

The parameters gx, gy and gz are now g.

Miscellaneous (will be removed when merged)

I suggest we update the same test if we use other deprecated parameters I changed the g parameter because I wanted to add a function version for my example, but I realised that it won't be very effective. So I drop this idea, but kept the list parameter. I added a way to use deprecated parameters because the gravity parameter is in every DEM prm file and the change may annoyed people (meeee the first!)

Checklist (will be removed when merged)

See this page for more information about the pull request process.

Code related list:

[x] All in-code documentation related to this PR is up to date (Doxygen format)
[x] Lethe documentation is up to date
[x] The branch is rebased onto master
[x] Code is indented with indent-all and .prm files (examples and tests) with prm-indent

Pull request related list:

[x] No other PR is open related to this refactoring
[x] Labels are applied
[x] There are at least 2 reviewers (or 1 if small feature) excluding the responsible for the merge
[x] If this PR closes an issue or is related to a project, it is linked in the "Projects" or "Development" section
[x] If any future works is planed, an issue is opened
[x] The PR description is cleaned and ready for merge

acdaigneault commented 3 months ago

@blaisb Above the change log entry, I will update the PR template. Do you prefer I do it in this PR or in another very small PR, let's say without other reviewers?

blaisb commented 3 months ago

@blaisb Above the change log entry, I will update the PR template. Do you prefer I do it in this PR or in another very small PR, let's say without other reviewers?

Whatever you think is best, both for me are OK. I generally prefer seperated PRs, but if its really minor, go ahead and do it in this one.

chaos-polymtl / lethe