Skip to content

Conversation

@ycexiao
Copy link
Collaborator

@ycexiao ycexiao commented Aug 18, 2025

What problem does this PR address?

Address the second item in #241.

What should the reviewer(s) do?

Please check the modifications.

@codecov
Copy link

codecov bot commented Aug 18, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.92%. Comparing base (6fdc0af) to head (daf51c3).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #249      +/-   ##
==========================================
+ Coverage   99.22%   99.92%   +0.70%     
==========================================
  Files          23       23              
  Lines        1285     1318      +33     
==========================================
+ Hits         1275     1317      +42     
+ Misses         10        1       -9     
Files with missing lines Coverage Δ
tests/test_refine.py 100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ycexiao ycexiao marked this pull request as ready for review August 18, 2025 20:57
@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 18, 2025

@sbillinge, it's ready for review.

@Sparks29032
Copy link
Collaborator

Sparks29032 commented Aug 20, 2025

Make sure that the argument parser captures the error in morphapp.py. Since the parser works on command line, you want to use its inbuilt error function (though I believe there is also a custom error function). The end result on the CLI side should be to throw exit 1 rather than a Python error, but the Python side should be fine now. The user will not see the error on CLI if there is no exit.

I would also like it if there was a test that this error is indeed being captured? Maybe one test for the CLI side and one for the morphpy side?

@sbillinge
Copy link
Contributor

@ycexiao @Sparks29032 I don't really mind where the error is caught in python or in CLI as long as the help message helps the user as much as possible to come up with a fix. Saying "adjust somethihng" is not so helpful because what do I adjust it to? or how do I figure out what to adjust it to? @Sparks29032 is there a way to know and suggest what adjustment will fix this? If it is trial and error to try and fix it, or the user can plot the polynomial and see where it goes negative or some such thing, this is helpful information to help them debug. We don't want to write a book, but some brief and hdlpful explanation would be good.

Yes, we need a test for this. If we implement it as a check in the CLI we could test that there too. As a rule we have not been doing much validation at all in the CLI. The main reason is just not enough time in the day. So I would not really prioritize that that atm unless it is quick and painless.

@Sparks29032
Copy link
Collaborator

What I am saying is that the error is not going to display to a CLI user if we do not exit. We want a wrapper around the refine call in the morphapp.py file that checks if we have a Python error and throws an exit.

@sbillinge
Copy link
Contributor

aren't we raising an exception? Are saying the exception gets caught and handled somewhere higher up in the code stack? If not then it will crash with the exception (which would be the desired behavior)?

@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 20, 2025

Saying "adjust something" is not so helpful because what do I adjust it to? or how do I figure out what to adjust it to?

How about "Please make sure the overlapping domain between the morphed function and the target function is sufficiently large, or reduce the number of parameters?"

aren't we raising an exception? Are you saying the exception gets caught and handled somewhere higher up in the code stack? If not, then it will crash with the exception (which would be the desired behavior)?

I will make sure both the CLI user and the scripts user will see the error message.

I would also like it if there were a test that this error is indeed being captured? Maybe one test for the CLI side and one for the Morphpy side?

Yes, I will add a test for it.

@Sparks29032
Copy link
Collaborator

Sounds good for the adjustment. Would also be helpful to mention the size of the function and number of parameters you are optimizing to the user so they can see exactly how many more parameters they must reduce by.

Copy link
Collaborator Author

@ycexiao ycexiao left a comment

Choose a reason for hiding this comment

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

@sbillinge @Sparks29032, it's ready for review.


if len(rvec) < len(pvals):
raise ValueError(
f"\nNumber of shared grid points: {len(rvec)}\n"
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Print the size of the function and the number of parameters.

Copy link
Contributor

@sbillinge sbillinge left a comment

Choose a reason for hiding this comment

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

nice work everyone

raise ValueError(
"Not enough shared grid points between morphed function "
"and target function to fit the chosen parameters. "
"Please adjust the functions or "
Copy link
Contributor

Choose a reason for hiding this comment

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

Nicely done. Is there a way to give guidance on how the to "adjust the functions"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The current error message is: "Please make sure the overlapping domain between the morphed function and the target function is sufficiently large, or reduce the number of parameters."

"Not enough shared grid points between morphed function "
"and target function to fit the chosen parameters. "
"Please adjust the functions or "
"between morphed function and target function to fit "
Copy link
Contributor

Choose a reason for hiding this comment

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

please check, is "between morphed function" repeated here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, it is a typo. It is fixed in a newer commit.

Copy link
Collaborator Author

@ycexiao ycexiao left a comment

Choose a reason for hiding this comment

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

@sbillinge @Sparks29032, it's ready for review.

@Sparks29032
Copy link
Collaborator

Sparks29032 commented Aug 21, 2025

I'm not sure the following lines are being run in the test (see CodeCov).

actual_error_message = str(error.value)
assert actual_error_message == expected_error_message

When the error is thrown and Pytest catches it, the lines below where the error is thrown are not run.

You will need some other way to check the error message is correct.

Otherwise, I have no other comments, seems good.

Copy link
Collaborator Author

@ycexiao ycexiao left a comment

Choose a reason for hiding this comment

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

@sbillinge @Sparks29032, it's ready for review.

ValueError,
) as error:
refiner.refine(*refpars)
actual_error_message = str(error.value)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

These two lines were skipped because of the wrong indentation. It is fixed now.

Copy link
Contributor

@sbillinge sbillinge left a comment

Choose a reason for hiding this comment

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

I am not sure I like this. Why are we doing this? Lot's of extra complicated code to maintain, but what benefit does it get us exactly? Let's discuss a bit. I am happy to be convinced, but in general, simpler is better for a research group like ours.....

@Sparks29032
Copy link
Collaborator

Two main reasons why I'd like this PR:
(1) When this error occurs, a quite unhelpful leastsq error message pops up and it is not too clear what one needs to fix in the case that the user really has an exorbitant number of parameters say in their funcxy function.
(2) When I ran into this error, it was because I was reading the transpose of the two-column array lists. In other words, rather than getting 4000 grid points, I am getting 1. Seeing this error and letting me know that my grid overlap is some absurdly small number like 1 or 0 lets me know that the error has to do with my data preprocessing/obtaining, not some weird regressor fault, which a random leastsq error message may imply to a user who is not too familiar w/ debugging.

@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 22, 2025

I am not sure I like this. Why are we doing this? Lot's of extra complicated code to maintain, but what benefit does it get us exactly? Let's discuss a bit. I am happy to be convinced, but in general, simpler is better for a research group like ours.....

@sbillinge, are you referring to the commit "use a custom error to stop leatsq"? Actually, it is not a good fix and it is reverted. The actual modification is from chore: fix the code indentation. where only the code indentation is changed so it is not complicated.

@sbillinge sbillinge merged commit 3908d63 into diffpy:main Aug 23, 2025
5 checks passed
@sbillinge
Copy link
Contributor

ok, sounds good all around

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.

3 participants