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

linear sum input order #660

Open
wants to merge 7 commits into
base: develop
Choose a base branch
from
Open

linear sum input order #660

wants to merge 7 commits into from

Conversation

maggul
Copy link
Collaborator

@maggul maggul commented Feb 4, 2025

An N_VLinearSum input/output issue arises when N_VLinearCombination is not provided by the user or when N_VLinearSum follows a different path than the one followed by SUNDIALS. The output is allowed as an input only in the first component for external library compatibility.

To that end, we have changed the order of inputs if the output vector is in the second component.

N_VLinearSum(a, x, b, z, z) →N_VLinearSum(b, z, a, x, z)

@maggul maggul marked this pull request as ready for review February 4, 2025 20:20
Copy link
Collaborator

@Steven-Roberts Steven-Roberts left a comment

Choose a reason for hiding this comment

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

You mentioned that some external libraries do not support certain orderings of inputs and output. Could you add a comment in the nvector implementations that have this constraint?

Also the changelog will need to be update.

CHANGELOG.md Outdated
@@ -6,6 +6,10 @@

### New Features and Enhancements

The `N_VLinearSum` and `N_VLinearSumVectorArray` operations now assume that the output
can be used as input only in the first component, ensuring compatibility with external
Copy link
Member

Choose a reason for hiding this comment

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

This seems sort of like we are breaking the API, which would require a new major version. The reason I say "sort of" is because the existing vectors would still work since our change is in the assumption not the implementations. However, the change in the assumption now instructs us to create new vectors that would possibly not work with old code.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I disagree, since nothing about this PR breaks any existing/working code.

The only thing that would "break" is if a user creates an N_Vector that works with SUNDIALS v7.2.1, and then tries to use that same vector with an older version of SUNDIALS. If anything, the documentation update could add a .. versionchanged comment to note that previous SUNDIALS versions required that all vectors support the case where either input could also be the output.

Copy link
Member

Choose a reason for hiding this comment

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

I disagree, since nothing about this PR breaks any existing/working code.

That why I said it was "sort of" a breaking change. It changes the contract of the API, therefore pedantically speaking it is a breaking change to the API. However, in practice, its impact is more like a "new feature".

@drreynolds
Copy link
Collaborator

You mentioned that some external libraries do not support certain orderings of inputs and output. Could you add a comment in the nvector implementations that have this constraint?

Also the changelog will need to be update.

Mustafa was not referring to external libraries with NVector implementations that are included in SUNDIALS; this comment is relevant to user-supplied NVector interfaces to external libraries (in this case, Gkeyll). I do not see any need to add comments to any NVector implementations in the SUNDIALS repository, only to make the assumptions on the SUNDIALS end clear.

Copy link
Collaborator

@drreynolds drreynolds left a comment

Choose a reason for hiding this comment

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

Here are a few suggestions to resolve @balos1's concern about this PR being a kind-of breaking change.

Copy link
Collaborator

@drreynolds drreynolds left a comment

Choose a reason for hiding this comment

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

A couple more changes to the CHANGELOG to make it clearer that this PR is not a breaking change.

Copy link
Collaborator

@drreynolds drreynolds left a comment

Choose a reason for hiding this comment

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

I think this now looks good. If another developer wants to take a second look and approve, I think it's ready to merge.

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.

4 participants