Closed mpm896 closed 2 months ago
mpm896
commented
2 months ago Also, is there a way to specify the CPU count in WarpTools for parallel processing? ~10 minutes for it to reach this error on a bin 4 tomogram (not even finishing patch tracking) is pretty slow
alisterburt
commented
2 months ago @mpm896 thanks for the report - I'll look into the tilt axis angle issue and make sure it's being passed down to etomo properly.
It's typically recommended to use 10-15 A/px for patch tracking, you're tracking a lot of patches at 5Apx making them all large, hence the slowdown. When run in the expected way everything runs quickly enough - it's possible IMOD has some environment variables you can set to force things to run the way you want within the wrapper. You are also not forced to use our wrappers and can run tilt series alignment however you see fit, see here for details
alisterburt
commented
2 months ago no idea what's going on with your preali file - IMOD creates those internally, we simply call batchruntomo
mpm896
commented
2 months ago Hey Alister, thanks for the feedback. I agree about the patches - I'll increase the binning or patch size, however it's about 10 minutes to arrive at the patch tracking and then aborting before patch tracking because the preali.mrc is an unknown format.
Regarding this problem, I'll do a bit more testing to see why batchruntomo is outputting a bad preali.mrc and reach out to David Mastronarde with this issue. Thanks!
mpm896
commented
2 months ago Also meant to ask - to help with this, can you point me to where I can find that .adoc that Warp uses for batchruntomo? The log points to it in /tmp but it seems to be getting deleted after the process exits
alisterburt
commented
2 months ago mpm896
commented
2 months ago Thanks! I had also just found this and also somehow missed the batchDirective.adoc in each processing directory
mpm896
commented
2 months ago Just to update, the issue with speed and my preali file were because I've been doing all my data processing on data stored on an AWS S3 (object storage), which does not behave like a normal file system. Some things work, others do not apparently, and everything is slower. Transferring to a network file system solved these problems
alisterburt
commented
2 months ago Good to know! thanks again for reporting back
alisterburt
commented
2 months ago I'm unable to reproduce your error on 2.0.0dev18
running
WarpTools ts_etomo_patches \
--settings warp_tiltseries.settings \
--angpix 10 \
--patch_size 500 \
--initial_axis 35 \
--output_processing ts_initial_axis_test35yields a batchdirective.adoc with the line
setupset.copyarg.rotation = 35which matches what the imod documentation says it expects https://bio3d.colorado.edu/imod/doc/directives.html
and is as bad as expected when the wrong values are used
Going to close based on this test - please reopen if needed
Hello,
I'm running
ts_etomo_patcheswith the following command:Despite specifying the tilt axis of 3.00, it appears that etomo is being fed a value of -86.68, which is the value from the mdoc. However since this data was collected with Tomography 5, the reported tilt axis is different than serialEM (sigh) and so for the purpose of IMOD, the input tilt axis should be 3 (90 + tilt axis reported from Tomo 5 = 90 - -86.68 ~~ 3).
In addition to this, it appears that
prenewstis producing an invalid mrc file? I get a log fromtiltseries/logswith the following output:If I open the etomo gui and generate coarse aligned stack, it works fine and I can open up the resulting coarse aligned stack. However if I try opening the preali.mrc file produced through running
WarpTools ts_etomo_patches ..., it tells me it's an invalid file format. It's kind of odd, because when I manually generate the coarse aligned stack for this same tilt series, theprenewst.comandprenewst.logare nearly identical.Let me know if you've run into something similar before or have any advice, thanks!