Leginon

I (Minghui Hu) imported the new Robot_MSI_Screen_1st_Pass.xml application, and a message showed up at the bottom, saying the same application with version 8 already exits. I looked at the application list on the left, and found the application with version 1, 7, 8, 8, 9, 10, 11. There are two version 8. The date information in the 1st 8 was 08/31/2009, while the date in the 2nd 8 was 11/20/2009. Then, the 2nd one should be newly loaded one.

One more thing confused me since the newest one is supposed to be version 8, but I have another 8, and 9, 10, and 11. I don't know where these versions come from. Is this because I edited one version where I enabled the Z-focus adjustment. Then, the version built up to 9 from 8. Maybe I edited the application for several times, this is why I got the version up to 11.

Again, I tried to start leginon and load the application, but the application can no start, which is the same as before. Then, I restored the leginon back to our working version before svn update and application import, and imported the old working version of the Robot_MSI application. When I started leginon and the application, it even didn't work. I appreciate any advice.

Minghui,

Yes, the newer versions are automatically incremented when you edited the application at your end. We will have to make the new upload unique by advancing further.

From what you have here, the most recent version is 11. Go ahead and modify the xml file you want to import to version 12 and then load it into the database through the web admin tool page. I think it should work this way.

Instruction in how to change the version in the xml:

http://ami/documentation/leginon/bk02ch07s03.php

Anchi

Thank you, Anchi. Problem solved!!!! It is also interesting that all of the Z-focus setting I set before was there, and I didn't lose them. I need further testing to see whether the two new functions, minimum Stddev and Mid Mag Filter, work well or not, and check if the Z-focus works as well as before.

Hi Anchi,

I had one more problem running the MSI_1st_screening 1.6 program. It stops at mid mag survey after taking the first image in the mid mag survey node. The message in the upper window said, "processing: waiting for 7685 to be processed". I checked the configuration menu, and saw that the checkbox of "Waiting for a node to process the image" was checked. I also checked the node connection using application editor. In the mid mag survey, there are five entries,

TargetListDoneEvent to node Mid Mag Traget Filtering
TransformTargetEvent to node Target Adjustment
ImageTargetListPublishEvent to node Z Focus
ChangePresetEvent to node Presets Manager
MoveToTargetEvent to node Navigation

This problem happened with or without mid mag survey filtering bypassed. Thank you for any suggestion.

Minghui

Minghui,

"Waiting for a node to process the image" is used in the intermediate steps of an MSI when it is operated in "Depth-First" traversal.
http://ami/documentation/leginon/bk01ch12s12.php
so that the acquisition node with several targets would not process the next target after the image of the previous target is acquired. By waiting, the targeting/acquisition go down deeper level.

In "Robot MSI 1st screening", Mid_Mag_Survey is the last of the MSI level which means that you no longer pick targets on the image it acquired in this application. Therefore, "Waiting for a node to process the image" should not be checked. If you want focusing done by Z Focus node before acquiring images at Mig_Mag_Survey, the one you want to activate is "Publish and wait for rejected target". If you want to do your Beam Fixing with reference target, you should activate "Publish and wait for reference target".

I am a surprised that the settings you've used in your early versions of the same application, if have been working, did not come out right immediately when you run this new version. Let me know if you notice other wrong settings. It might be something that we need to look into. It could also be that you did add a new level of MSI sequence in your earlier version that is now gone because the new import replaces the old one as what is run by Leginon. Our application import mechanism is not smart enough to merge changes.

Anchi

Hi, Anchi,

Now the application can run through its cycle. However, the mid mag filter didn't work properly. I set it to 5 targets among total over 20 target candidates. It only selected two positions, and took one image at 1st position, four same images at 2nd position. When I bypassed the filter, there were no duplicated images. Also, I am wondering if you can select the targets based on their pixel values, not based on the distance. Sometimes, all bad points I want to remove are all at the center.

Minghui,

The target filter is only meant to filter by position. If you want to avoid target by value, shouldn't it already been removed in the step before when the targets were picked?

The duplication problem may be because somehow there were 4 targets at the same positions because I can't repeat your error here. You can check that by turning on user verification at the filter and try to remove targets by right clicks. If more than one targets are at the same position, there will be another one displayed as if you didn't remove them. In addition the filter class is exactly the same as the one used in Square_Target_Filtering. You should have gotten this problem before.

Anchi

Hi, Anchi,

I understand what you mean, but would like to add some explanation.

Because of the beam instability of our Jeol1230, there is quite large brightness deviation among grids even in one-grid screening experiment. The target finder works very well to discriminate the broken carbon areas and grid bars. However, I find the target finder always give some fault selections, in many cases, empty areas. By removing all of empty areas, I might end up with no target selected for other square areas. Or by only including an appropriate number of negative stain areas, I always end up with many selected empty areas. It doesn't depend on how many grids or square areas I manually check before I run the automation mode. I think it will help me a lot if we can use a filter based on pixel values to limit the image target. It also enables me to finish one grid within a predictable time and with some meaningful images for sure. Otherwise, I would rather turn the filter off because distance based selection might just include all empty area, but exclude all negative stain areas away from the center for some "unlucky" cases. It might be flexible if you provide a radio box selection between distance and pixel. So the users can decide which filter type to use.

I haven't tried the filter again, but will let you know the results if I finishes.

Minghui,

I think I understand what you want: An additional value histogram filter to pick the "best" targets off the acceptable ones if there are too many. This can be implemented but a definition of best is the hard part. You will need a scoring system. We can teach you how to make a new target filter class
and you can then rank the targets yourself.

Anchi