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

Copy mesh upon creating Mover #48

Merged
merged 3 commits into from
Jan 25, 2024
Merged

Copy mesh upon creating Mover #48

merged 3 commits into from
Jan 25, 2024

Conversation

jwallwork23
Copy link
Member

Closes #45.

Copy the mesh that gets passed to a Mover so that the original remains unmodified.

@jwallwork23 jwallwork23 added the bug Something isn't working label Jan 23, 2024
@jwallwork23 jwallwork23 added this to the Version 1 milestone Jan 23, 2024
@jwallwork23 jwallwork23 self-assigned this Jan 23, 2024
Comment on lines -49 to -52
# Continue with a new Mover
mover = MongeAmpereMover(
mesh, ring_monitor, method=method, rtol=rtol, phi_init=phi, sigma_init=sigma
)
Copy link
Member Author

Choose a reason for hiding this comment

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

It doesn't really make sense to 'continue' the mesh movement by creating a new Mover with the computational mesh being the adapted mesh from an earlier Mover. They have different baselines.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah yes, I was wondering about that/discussing with Matt: in our current implementation we are always working with a uniform mesh as the baseline right? And so the monitor we provide is specifying the required variation in the output physical mesh regardless of the previous state of the mesh (when calling the mover multiple times). We could also imagine a different approach where the monitor expresses the variation with respect to the previous mesh, where if the mesh is already optimal the monitor would be constant.

Copy link
Collaborator

@stephankramer stephankramer left a comment

Choose a reason for hiding this comment

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

Looks good - I think this will indeed be clearer from the user perspective: with an input mesh that remains unchanged and a separate (iteratively improved) output mesh

@jwallwork23 jwallwork23 merged commit cf31dd0 into main Jan 25, 2024
1 check passed
@jwallwork23 jwallwork23 deleted the 45_mesh_copy branch January 25, 2024 16:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix docstrings so they come out properly on pyroteus.github.io
2 participants