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

Refactor Ersilia test command #1224

Merged
merged 48 commits into from
Aug 19, 2024
Merged

Refactor Ersilia test command #1224

merged 48 commits into from
Aug 19, 2024

Conversation

kurysauce
Copy link
Contributor

@kurysauce kurysauce commented Aug 8, 2024

Thank you for taking your time to contribute to Ersilia, just a few checks before we proceed

  • Have you followed the guidelines in our Contribution Guide
  • Have you written new tests for your core changes, as applicable?
  • Have you successfully ran tests with your changes locally?

Description

Refactor the Ersilia test command to run in 100% completion for correctly incorporated models. Currently stops prematurely at the check_example_input test method.

Changes to be made

Ensure correct return values and flags are appropriately passed to methods in Model Tester class. Debug other methods as test command runs closer to completion.

EDIT: Completed

Status

  1. Added correct returns and flags to all methods
  2. Fixed path parsing in run_bash method
  3. Corrected original model size calculation implementation by implementing get_directories_sizes() method and associated helper functions.
  4. Updated check_consistent_output method by calculating Spearman's Correlation & Mean Relative Absolute Value thresholds, replacing 5% difference threshold due to false positive failed test cases
  5. Refactored read_csv method to handle differences in column parsing with Ersilia output and Bash output
  6. Specified output file generation + time stamp at completion of a successful test run on model

To do

Must test updated command on multiple models to ensure robustness. Ensure diversified outputs are tested. Test command may reveal hidden flaws from previous model incorporations (non-existent run.sh files, inconsistent outputs comparisons, execution errors in run.sh files that reveal problems in model's main.py script, etc...), open issues for specific models as needed. Seeking help from community members to test models!

Models must be fetched using --from_github or --from_s3 flag, or else test script will fail.

Is this pull request related to any open issue? If yes, replace issueID below with the issue ID

Related to #1203 , #1222, #1221

DhanshreeA and others added 30 commits July 26, 2024 17:30
* WIP Add session management utils

* Create a session at ersilia cli initialization

* Remove unused code

* start an ersilia session in a dedicated sessions dir that is mapped to the parent process' id which ran the given ersilia command, this will generally be a shell process inside a terminal, but it can also be a process from a bash script

* declare session specific defaults

* Run all ersilia commands within a single process during standard example run, otherwise ersilia run command does not find a served model bec of running in a different process and therefore in a different session

* Move the currently served model's pid to its dedicated session directory

* WIP Logging

* Redirect tmp logs to model's session logs

* catch permission error

* Redirect tmp logs to model's session logs

* don't use ersilia exception management because we don't exactly want the ersilia process to exit
.devcontainer/devcontainer.json Show resolved Hide resolved
ersilia/io/input.py Outdated Show resolved Hide resolved
ersilia/publish/test.py Outdated Show resolved Hide resolved
ersilia/publish/test.py Outdated Show resolved Hide resolved
ersilia/publish/test.py Outdated Show resolved Hide resolved
@kurysauce
Copy link
Contributor Author

Updated PR @miquelduranfrigola

@DhanshreeA
Copy link
Member

Hi @kurysauce - I've gone through your refactor of the test command and I think this is very much headed in the right direction. I have a small concern - I am unsure if we are accounting for output types within the check for consistent outputs - the code seems to be written only for dealing with numeric output types, as I don't see any check on the output type anywhere. Is that indeed the case?

@DhanshreeA
Copy link
Member

@kurysauce I've another request for you for this PR. The previous contributors left a lot of print statements within the code, which is generally not a good practice. Would it be possible for you to replace them with debug and info logs? :)

@kurysauce
Copy link
Contributor Author

kurysauce commented Aug 14, 2024

@kurysauce I've another request for you for this PR. The previous contributors left a lot of print statements within the code, which is generally not a good practice. Would it be possible for you to replace them with debug and info logs? :)

@DhanshreeA here is the link to the completed Google Doc. Additionally, I replaced the print statements with debug and logging. I don't think I see anything else on my end to update on the test script for now.

@kurysauce
Copy link
Contributor Author

kurysauce commented Aug 14, 2024

Hi @kurysauce - I've gone through your refactor of the test command and I think this is very much headed in the right direction. I have a small concern - I am unsure if we are accounting for output types within the check for consistent outputs - the code seems to be written only for dealing with numeric output types, as I don't see any check on the output type anywhere. Is that indeed the case?

@DhanshreeA I believe the test commands tests string as well in these spots: 1 and 2

@DhanshreeA
Copy link
Member

@kurysauce I've another request for you for this PR. The previous contributors left a lot of print statements within the code, which is generally not a good practice. Would it be possible for you to replace them with debug and info logs? :)

Sounds good @DhanshreeA ! Just to clarify, what would be appropriate to print vs log? (outputs from failed runs, output from successful runs, indication of new test check, etc...)?

Generally speaking, there should be no print statements and everything that needs to be logged onto the terminal should essentially be done through a logger and not through print. :)

@miquelduranfrigola
Copy link
Member

Yes indeed, generally speaking we want to log information instead of printing. Note that logging is activated only with the -v flag, though. So, to show on screen print-like messages, we can use the echo command from the click library as done by the ersilia CLI.

In any case, there are plenty of examples within the Ersilia codebase as to how we should be logging messages. Usually, they are accessible via the self.log.debug/info/warning methods if ErsiliaBase is used as a parent class.

I hope this helps!

@DhanshreeA DhanshreeA merged commit 2a0ba90 into ersilia-os:master Aug 19, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants