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

Advection updates #245

Merged
merged 32 commits into from
Sep 27, 2024
Merged

Advection updates #245

merged 32 commits into from
Sep 27, 2024

Conversation

lmoresi
Copy link
Member

@lmoresi lmoresi commented Sep 18, 2024

Bring over some of the bug-fixes in meshing / labelling / mesh distribution.

Lots of work to understand the SLCN advection solver and get it under control.

Added the Quickstart notebooks for quarto

lmoresi and others added 23 commits August 26, 2024 10:21
Major bug (totally my fault) in which I failed to account for particles being reordered after sending and receiving. We now store the node and process for each particle which means we can take small substeps to the sample point and then snap back directly to the launch point.

This includes JC's swarm wormhole teleportation code which is required for long trajectories.

I'm turning off all smoothing for projection operators which was introduced to counter numerical problems which turned out to be related to this bug.

Also, added the possibility to use a sample swarm based on a discontinuous underlying variable. This gives a good spread of points and means that corners / facets where particles may be lost are avoided by particle paths.
There are (value related) failures in the advection tests. Of course, advection tests are a bloody nightmare since advection schemes are problematic to validate.

Need to understand this before merging PR
posixpath - not sure why this import is present
epsilon in boxmesh return-coords-... - no need to complicate things
Arise from convection benchmark models.
…rals

The surface integral code falls over if a label is not present on one of the processes. This is identified in issue #240. This workaround adds element-volumes (all of them) to each boundary label. These are not used in the surface integral code in 2D / 3D so they do not change the result. @knepley - we've discussed this issue in the past ... we should figure out the actual origin of the problem.
Add a parallel_view() function to see the number of labels on each processor. In response to #240

returns something like this:

| Boundary Name            | ID    | Size | Proc ID      |
| ------------------------------------------------------ |
| Bottom                   | 11    | 2        | 0        |
| Top                      | 12    | 2        | 0        |
| Right                    | 13    | 3        | 0        |
| Left                     | 14    | 0        | 0        |
| All_Boundaries           | 1001  | 4        | 0        |
| Bottom                   | 11    | 2        | 1        |
| Top                      | 12    | 2        | 1        |
| Right                    | 13    | 0        | 1        |
| Left                     | 14    | 3        | 1        |
| All_Boundaries           | 1001  | 4        | 1        |
| ------------------------------------------------------ |
Not a fix, just examining potential workaround choices
Put most stuff back together. Improve the view() a little bit. Fix the problems with expressions (sympy merging expressions with same symbol - FFS!)

Somthing odd with dm re-distribution that should not have been happening.

Also fixing up the object id things that are not being respected by sympy.
Also adding rendering hints in the notebooks for quarto
@lmoresi lmoresi changed the base branch from main to development September 19, 2024 00:15
@lmoresi
Copy link
Member Author

lmoresi commented Sep 19, 2024

Changing the base to development (PR generated automatically from GitHub desktop !).

8 notebooks added which demonstrate various parts of the uw3 machinery plus the rendering code to put them on github pages as a quickstart guide.

I still need to update the scripts to launch on binder.
Not zapping the kdtree properly when deforming the mesh. I guess this was a problem in free surface models so I am surprised it was not reported before - is there an open issue about particles added to a deforming mesh ?

Minor detail: using invisible hspace in place of the \,\! strings. The width of the hspace is the unique ID / 100 in points. It still looks weird but the code is readable. I tried labels and other things but they break the rendering. There is probably a better way.
Fixes to advection and expressions to make examples and tests work.
@lmoresi
Copy link
Member Author

lmoresi commented Sep 27, 2024

OK - tests passing and this is now working again with the conda version of PETSc.

I plan to merge so that this is not blocking. I have been mostly working on the docs and all the bug fixes have been to solve problems encountered along the way. Advection was the main one, but many minor(ish) things too.

@lmoresi lmoresi merged commit 7c5692a into development Sep 27, 2024
2 checks passed
@lmoresi lmoresi deleted the advection_updates branch September 27, 2024 02:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants