Avoid having randomized unittest

GazzolaLab / PyElastica

Python implementation of Elastica, an open-source software for the simulation of assemblies of slender, one-dimensional structures using Cosserat Rod theory.

https://www.cosseratrods.org

MIT License

208 stars 107 forks source link

Avoid having randomized unittest #333

Open skim0119 opened 4 months ago

skim0119 commented 4 months ago

This issue came up on one of the github-action.
Instead of random test, we should have pre-generated set of test cases and known solution.
Precision should be specified.
Best to include corner cases and negative cases (fail case)

https://github.com/GazzolaLab/PyElastica/blob/d12107a2d3ad7228a2893ad55de5da89a9bab87b/tests/test_math/test_timestepper.py#L401-L408

vikas-chaudhary-2802 commented 4 months ago

Hi, I love to work on this issue, Can you please assign me ??

bhosale2 commented 4 months ago

@vikas-chaudhary-2802 the issue has been assigned, please follow these guidelines when working on the issue.

skim0119 commented 4 months ago

@vikas-chaudhary-2802 I included some more explanation above.

vikas-chaudhary-2802 commented 4 months ago

@skim0119 I have made few changes and i wanted to test whether those are working. Do i need to build the project and then run the test using 'make test' command? If yes, how can i build it?

skim0119 commented 4 months ago

@vikas-chaudhary-2802 Repository can be installed using pip or poetry.

vikas-chaudhary-2802 commented 4 months ago

@skim0119 whether I need to build after I make the changes or not ?

skim0119 commented 4 months ago

@vikas-chaudhary-2802 If you have made changes within the tests directory, it won't be necessary to reinstall.

vikas-chaudhary-2802 commented 4 months ago

@skim0119 i added logging line to check the datatype but the logs are not getting printed on the shell when i run - make tests....could you please suggest any other way to debug ?

skim0119 commented 4 months ago

@vikas-chaudhary-2802 You can directly run pytest -s on repository to capture stdout/stderr

vikas-chaudhary-2802 commented 3 months ago

@skim0119 @bhosale2 I'm facing difficulties with certain test cases and despite my attempts, I haven't been able to resolve them. Could you please provide assistance with these specific issues?

skim0119 commented 3 months ago

@vikas-chaudhary-2802 Could you commit your code in your fork that reproduces this error?

vikas-chaudhary-2802 commented 3 months ago

@skim0119 yeah, I am able to commit

vikas-chaudhary-2802 commented 3 months ago

@skim0119 @bhosale2 I Create a PR, Can you please suggest me the changes that i have to do ...so that the failed test cases will resolve and then i will commit the changes again

skim0119 commented 3 months ago

@vikas-chaudhary-2802 I went over your code. The directors passed to the timestepper need to be orthogonal. I think that is why the analytical solution is breaking. Please correct the directors and try to run the test again.

Also, try to format the script before commiting. You can run make format-codestyle.

vikas-chaudhary-2802 commented 3 months ago

Hi, @skim0119 Thank You for your suggestion. I will make the changes as soon as possible

vikas-chaudhary-2802 commented 3 months ago

Hi, @skim0119 @bhosale2 Now the directors passed to the timestepper is orthogonal but still the same test cases failed.... i will attached the changes ....please review it and tell me what i have to do next to pass the test cases as soon as possible

skim0119 commented 3 months ago

@vikas-chaudhary-2802 I would appreciate it if you could attach the actual code, or link the forked script to re-run. I can't help out just looking at the image file. Same for the error message.

Few comments:

I am not sure how you are initializing random_directors. Please re-write them readable and clean. Quickly looking at it, it looks wrong implementation. The final dimension needs to be 3x3xN where N is the number of test cases.
Don't use QR decomposition to orthogonalize them. The whole point of this issue and avoiding randomized unit-test is to test if the code can handle largely expected cases (and corner cases if any). Your approach, in the end, has the same issue as the original implementation: don't know why the test passes or fails.