-
Notifications
You must be signed in to change notification settings - Fork 10
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
Tem with install dependancies #47
Conversation
…th_config yaml. added local sim path
This branch contains the remaining implementation for the tem wrapper (along with some tweaks to existing methods). The methods added in the PR require a local installation for tem wrapper and hence the associated unit tests will fail. |
Good work guys. I suggest doing the containerization ASAP, and then merging this after. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! Nothing to say code-wise 💯
Design-wise, the two functions:
- run
- get_image_data
are misleading for an external user, because: - their main (computationally expensive) objective is to run the simulator, yet only one of these functions is called
run
, - the keyword
get_
is usually used to denote a function/method that returns an object (.e.gimage_data
) that has already been computed. It is misleading to name a functionget_
and actually have this function do a real big computation.
I would suggest the following design:
def run
with a parameter denoting in which format we want the output of the simulation (.mrc? micrograph? particles?)
-def _run_executable
only containing the beginning ofget_image_data
such that:- the core work is done by the executable
- the format conversions of inputs/outputs are done in the
run
function.
But we can merge this PR first, and address the design's questions next week when I review the whole codebase 🎉
Congrats again, great work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, requesting changes since we need the tests to pass :/ I am assuming that this is passing with your local installation of the TEM, but not passing with the GitHub actions.
Yes I'm hoping to get to that by end of week... |
Hi @arjunsingh3600 ! Now that #50 has been merged into master, we're merging master here which will relaunch the checks. Let's see how that goes! I'll start reviewing once the checks pass. |
Codecov Report
@@ Coverage Diff @@
## master #47 +/- ##
=======================================
Coverage 97.20% 97.20%
=======================================
Files 8 8
Lines 285 285
=======================================
Hits 277 277
Misses 8 8
Continue to review full report at Codecov.
|
…oint is not working in Singularity, we need to provide the full path to the TEM-simulator executable.
@arjunsingh3600 thanks for looking into it earlier, you were on the right track! Hope you don't mind if I take over - should be done soon. |
Hmmm I spoke too fast, I don't really understand why this (https://github.com/compSPI/simSPI/runs/4924673073?check_suite_focus=true) is failing:
I tried on SDF and the tests pass:
I am tempted to remove the workflow that tests in Singularity container: @ninamiolane would you be OK with that? As long as the tests pass in the Docker container, we know the code works - and it's up to the user to figure out things with Singularity. |
…ests pass in Docker containers is proof enough and streamlines checks.
OK, we're good for review now! @ninamiolane @geoffwoollard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
kwargs | ||
Arbitrary keyword arguments. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this? I don't see them passed in the function?
pad : double, (default = 5) | ||
Pad to be added to maximal dimension of the object read from pdb_file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it in pixel or physical (Angstrom) unit?
@@ -2,7 +2,7 @@ name: "Linting and Testing (Singularity)" | |||
|
|||
on: | |||
push: | |||
branches: [temsim-test-in-container] | |||
branches: [simspi-test-singularity] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be called test-container? (I thought we removed singularity?) we also do not need simspi
, since it is on the simSPI repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah good point!
I kept the test_singularity workflow but it's only triggered if we push on this branch.
So maybe in terms of renaming:
test_singularity.yml
(keep name): rename trigger branch totest-singularity
test_docker.yml
: I will split it in a way similar to what you did on ioSPI once we merge this branch (linting decoupled from testing). The trigger branch will be renametest-container
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I made comments on the design of the run
and get_image_data
functions on another PR: it would be good to have a look at them to clean the architecture of the functions within the codebase.
I'll merge now and do the linting/testing decoupling in a different PR. |
No description provided.