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

Release v202211.1 #558

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

BenjaminRodenberg
Copy link
Member

@BenjaminRodenberg BenjaminRodenberg commented Aug 27, 2024

See precice/precice.github.io#414 for the motivation for this bugfix release.

I'm creating this branch and PR to start collecting relevant changes. Note that it is still unclear if and how we actually would merge these changes into master.

ToDos:

Checklist:

  • I added a summary of any user-facing changes (compared to the last release) in the changelog-entries/<PRnumber>.md.
  • I will remember to squash-and-merge, providing a useful summary of the changes of this PR.

@@ -75,7 +75,7 @@ def determine_gradient(V_g, u, flux):
# Error is bounded by coupling accuracy. In theory we can obtain the analytical solution.
error_tol = 10 ** -6
alpha = 3 # parameter alpha
beta = 1.3 # parameter beta
beta = 1.2 # parameter beta
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need to change a model parameter in a bugfix release? I know that this was changed in the v202404, but wouldn't this confuse users if v202211.0 and v202211.1 have different values?

Copy link
Member Author

Choose a reason for hiding this comment

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

The parameter was not consistent with literature. So I would consider it as a bug that we can also fix in a bugfix release. But let's continue this discussion in #378.

@BenjaminRodenberg
Copy link
Member Author

BenjaminRodenberg commented Aug 29, 2024

Additionally, if we want to make sure v202211.1 is future-proof --- respectively even working with Ubuntu 24.04 --- we also could consider backporting #547. This also means that we would need to modify the folder structure of some cases or implement a solution that supports the old structure.

Looks to me like a rabbit hole: Therefore, I would leave things as they are. The user would have to do the venv stuff manually. This is to some degree also consistent with the v202211.1 policy "make sure that your python environment works; we do not even provide the requirements.txt for some cases".

@BenjaminRodenberg BenjaminRodenberg self-assigned this Sep 2, 2024
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.

2 participants