Project

General

Profile

Actions
Copy link

Bug #1359

closed

stack remake from a stack may have different particle order

Added by Anchi Cheng almost 13 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
High
Assignee:
Anchi Cheng
Category:
Python scripting
Target version:
Appion/Leginon 2.2.1
Start date:
07/15/2011
Due date:
% Done:

0%

Estimated time:
Affected Version:
Appion/Leginon 2.2.0
Show in known bugs:
Yes
Workaround:

Description

Makestack loop through images and box particles that are found in the stack particle database record. If the stack is a combined stack or a junk-sorted stack, the resulting stack would not have the same order as the stack it is meant to be duplicated from.

This is not a problem if the new stack is committed and query is used to match particles but would be a problem if not committed as I intend to do for frealign refinestack.

Files

Download all files
apBoxer.py (4.33 KB) apBoxer.py Amber Herold, 06/19/2012 04:45 PM
apParticleExtractor.py (19.4 KB) apParticleExtractor.py Amber Herold, 06/19/2012 04:45 PM
makestack2Loop.py (42.5 KB) makestack2Loop.py Amber Herold, 06/19/2012 04:45 PM
makestack2.py (193 Bytes) makestack2.py Amber Herold, 06/19/2012 04:45 PM
makestackSorted.py (2.78 KB) makestackSorted.py Amber Herold, 06/19/2012 04:45 PM
Actions
Copy link
 #1

Updated by Neil Voss almost 13 years ago

We have tiltStackSync and I thought we had a defocalStackSync (but I cannot find it) that sorts you stacks after you have made them. Forcing makestack to systemically go to each image in the same order could break other functions, so I would suggest writing a work around that would re-sort the particles in the stack.

Second you have to worry that if increased the boxsize, more particles will be excluded because they are too close to the edge, so you will never get a perfect sync.

Actions
Copy link
 #2

Updated by Anchi Cheng over 12 years ago

  • Category set to Python scripting
  • Status changed from New to Assigned
  • Assignee set to Anchi Cheng
  • Target version set to Appion/Leginon 2.2.0
  • Affected Version changed from Appion/Leginon 2.1.0 to Appion/Leginon 2.2.0 (trunk)

I will start working on this refinestack sync now that frealign is working and I want to test it on combined stacks.

Actions
Copy link
 #3

Updated by Amber Herold about 12 years ago

Anchi, shall we move this to 3.0?

Actions
Copy link
 #4

Updated by Anchi Cheng about 12 years ago

Wish we don't have to. This one need to be listed as known bug. I am sure people will try this in 2.2 but find it not working right.

Actions
Copy link
 #5

Updated by Amber Herold almost 12 years ago

  • Target version changed from Appion/Leginon 2.2.0 to Appion/Leginon 2.2.1
  • Show in known bugs changed from No to Yes

Putting this in known bugs.

Actions
Copy link Download all files
 #6

Updated by Amber Herold almost 12 years ago

This is the issue that is holding back frealign usage.

I've got a bit of a fix for now...but just attaching the files to this issue since I have not had a chance to do complete testing. I'll be out for the next 5 weeks, so hopefully Anchi can pick up where I left off. Need to fix an issue with losing the stack particle data just before callProcessParticles() in apParticleExtractor.py, or find a more efficient way of getting the particle number.

Actions
Copy link
 #7

Updated by Anchi Cheng almost 12 years ago

Because Frealign can not take particles that are not grouped by film number, I have to abandon the original idea of resorting the preped stack to the previous stack order. Instead, the corresponding particle number are saved in a file and matched during the upload of the refinement.
r16897 contains these changes.

Actions
Copy link
 #8

Updated by Amber Herold over 11 years ago

  • Status changed from Assigned to In Test
  • Affected Version changed from Appion/Leginon 2.2.0 (trunk) to Appion/Leginon 2.2.0
Actions
Copy link
 #9

Updated by Anchi Cheng over 8 years ago

  • Status changed from In Test to Closed
Actions
Copy link

Also available in: Atom PDF