Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update restart files of application tests for p4est 2.3.6 #1181

Merged
merged 14 commits into from
Jul 1, 2024

Conversation

acdaigneault
Copy link
Collaborator

@acdaigneault acdaigneault commented Jun 28, 2024

Description

deal.II changed the version of the dependancy p4est to 2.3.6 for their docker master-focal (the one we use for our CI with deal.II version master). We were using p4est 2.3.2, which makes some of our application-test restart files not compatible with the new p4est version.
Unfortunately, the previous restart files were generated a long time ago (> 9 months). The .prm has not been updated since then and they were a bit all over the place.

Solution

Update the .prm files with the proper parameter names.
Update the restart files that were failling.
Gather the .prm for the lethe-fluid-particles and lethe-fluid-vans .prm generator in the generator folder.
If the .prm restart generator file was not there, new ones have been created trying to replicated it.

Testing

All tests pass on CI with deal.II version master and they are now disabled with deal.II version 9.5.0.

Documentation

The next PR will modify the installation doc according to p4est 2.3.6

Miscellaneous (will be removed when merged)

Important note: The adaptive sparse contact test with lethe-fluid-particles is now a dummy test since it does not test all the mobility status anymore. I can say if it is a bug, if the .prm files to generated the restart files were wrong or if the small modification in DEM change the status in cfd-dem. I will open an issue about it since the mechanism is not properly tested at the moment see #1182

I kept all the generated restart files (even .pvdhandler) in case someone wants output from restarts

Checklist (will be removed when merged)

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

Code related list:

  • All in-code documentation related to this PR is up to date (Doxygen format)
  • Lethe documentation is up to date
  • Fix has unit test(s) (preferred) or application test(s)
  • The branch is rebased onto master
  • Changelog (CHANGELOG.md) is up to date
  • Code is indented with indent-all and .prm files (examples and tests) with prm-indent

Pull request related list:

  • Labels are applied
  • There are at least 2 reviewers (or 1 if small feature) excluding the responsible for the merge
  • If this PR closes an issue or is related to a project, it is linked in the "Projects" or "Development" section
  • If the fix is temporary, an issue is opened
  • The PR description is cleaned and ready for merge

@acdaigneault acdaigneault added Bug Something isn't working Maintenance WIP When a PR is open but not ready for review labels Jun 28, 2024
Clean up in .prm files
All has been moved to folder generator and path to the restart folder has been add in the .prm
Some .prm are missing
Tests has changed, the restarts files were pretty old >9 months, so hard to say if this is an issue or just the DEM has changed to much
@acdaigneault acdaigneault requested review from hepap and removed request for OGaboriault June 28, 2024 21:44
@acdaigneault acdaigneault changed the title Update restart files of application test for p4est 2.3.6 [wip] Update restart files of application test for p4est 2.3.6 Jun 28, 2024
@acdaigneault acdaigneault added Ready for review and removed WIP When a PR is open but not ready for review labels Jun 28, 2024
Copy link
Collaborator

@OGaboriault OGaboriault left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny comment. I think I will work on a script to automatically generate the restart files for every application tests we have.

CHANGELOG.md Outdated Show resolved Hide resolved
@acdaigneault
Copy link
Collaborator Author

@OGaboriault cool! Also, I did not redo all the restart files, only the ones that were failling and a few more. If we want fully automated generation of everything, we have to regenerate all restart and have a standardization to target them.
I was also thinking about having the restart files generator included in the check parameter script for examples. But the CI job for that one would need a new name

@acdaigneault acdaigneault added CI and removed Bug Something isn't working labels Jun 29, 2024
@acdaigneault acdaigneault changed the title Update restart files of application test for p4est 2.3.6 Update restart files of application tests for p4est 2.3.6 Jun 29, 2024
Copy link
Collaborator

@OresteMarquis OresteMarquis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not much to say, If all the test work its good for me :) It seems like a lot of reorganization, I like it! Congrats Audrey, It was probably a pain to update everything, thanks for your work :)

@@ -73,9 +76,13 @@ jobs:
ctest -N --exclude-regex ${{ env.MULTI_CORE_TESTS_REGEX }}
# Run in parallel
ctest --output-on-failure -j${{ env.COMPILE_JOBS }} --exclude-regex ${{ env.MULTI_CORE_TESTS_REGEX }}


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add an error when matrix.dealii_version != 'master' for clarity.
Something like:

Suggested change
if: ${{ matrix.dealii_version == 'master'}}
run: ...
else:
error:
message: "Version of deal.ii for tests is not the same as their master image."
code: 1
details: "Restart files are not compatible with deal.ii v9.5.0"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a cool suggestion.... as long as that does not throw an error I am down for that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a documentation of the else statement and error? I don't find it in the GitHub action documentation.
Also, giving an error won't failed the check?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it gives an error it would indeed fail the check.
To keep the PR finalized because it's a critical one, let's postpone this check to a next PR. We can open an issue ot keep track of this idea, but to be honest, right now just writing a comment is all good for the time being. Throwing an error would break the CI and so code: 1 would most likely give an error.
Let's postpone that for the future

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I don't change anything at the moment?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, let's not change anything. Let's merge the PR as-is when you are ready with the current feature set. Then if we want to change other stuff, let's make small PRs for them

@@ -84,4 +91,4 @@ jobs:
# Print the tests to be executed
ctest -N --tests-regex ${{ env.MULTI_CORE_TESTS_REGEX }}
# Run sequencially
ctest --output-on-failure --tests-regex ${{ env.MULTI_CORE_TESTS_REGEX }}
ctest --output-on-failure --tests-regex ${{ env.MULTI_CORE_TESTS_REGEX }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add the same else error as the previous comment here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the new p4est version cause the changes in the application_tests? Or did the tests have been changed change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case I'm not sure, but I don't think so. A few things have changed in the DEM solver that causes tiny differences. The mobility status can change in one iteration.
I build this test and it was pretty hard to get all the status with a very small number of particles. The test is probably very sensitive to the initial condition. Or the generation files in the repo were not the good ones.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just curious, I don't even know what it does, but why does the output frequency has been set to 0?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It means that we do not generate output files. It's not a good idea to generate output files in the tests since i tends to slow down the CI significantly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, in fluid it does otuput the one at time = 0. Would it be better to write -1 for all tests? In DEM writing 0 does not generate outputs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's maybe do that in another PR where we just do that. For the time being let's keep this PR at the curent level it is.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, we don't test .vtu anymore?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this test was testing that, especially since the test to not write any .vtu. But this is a very good point since no other test seems to test that for lethe-fluid!
And yeah, I just saw the person that did that was Audrey in 2020, and I guarantee that I did not really know what I was doing back then haha
Do you think it's a good idea to add them back and add outputs to the test?

@AmishgaAlphonius AmishgaAlphonius mentioned this pull request Jun 29, 2024
9 tasks
Copy link
Contributor

@blaisb blaisb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll merge directly after you have addressed @OresteMarquis last suggestion. Very good work. Thank you so much for having taken care of this.

@@ -73,9 +76,13 @@ jobs:
ctest -N --exclude-regex ${{ env.MULTI_CORE_TESTS_REGEX }}
# Run in parallel
ctest --output-on-failure -j${{ env.COMPILE_JOBS }} --exclude-regex ${{ env.MULTI_CORE_TESTS_REGEX }}


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a cool suggestion.... as long as that does not throw an error I am down for that.

@blaisb
Copy link
Contributor

blaisb commented Jun 30, 2024

@acdaigneault Good to merge on my side, I'll wait for your final GO and then I'll merge

@blaisb blaisb merged commit 4dd53b3 into master Jul 1, 2024
8 checks passed
@blaisb blaisb deleted the update_restart_files branch July 1, 2024 07:42
blaisb pushed a commit that referenced this pull request Jul 1, 2024
Description
This PR follows #1181 and updates documentation related to the installation of Lethe. More specifically, it corrects the version of p4est to be installed to 2.3.6.

Co-authored-by: Olivier Guévremont <guevremont.o@gmail.com>
blaisb pushed a commit that referenced this pull request Jul 20, 2024
Description
The ASC applications was not testing all the mobility status after the change of restart files in PR #1181.

Solution
Change the granular temperature threshold to get the 3 mobility status at the start of the simulation and output the status sooner.
Close issue #1182.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants