Geometry calculation returns negative pretilt regardless of positive/negative pretilt.

[bbarad]

Depending on how my lamella specimens are oriented, the calculated geometry from the GUI always returns a negative pretilt. This means that if the sample is actually inserted with a positive pretilt, tracking is initially quite poor. We have mitigated this by always inserting with negative pretilt, which makes tracking work quite nicely, but I wanted to raise this issue since I suspect we aren't the only ones who had previously preferred positive pretilt since the + direction on our stage is a bit more stable and we can go further on that side by starting at -9 rather than +9º.

[bbarad]

I am taking out my samples in the morning unfortunately - but I'll give it a shot next time I am on unless you've updated before then!

[eisfabian]

Hi Ben!

Wow! This is indeed not ideal and I am surprised it didn't come up before. Thanks a lot for letting me know!

Looks like

tilty = -np.degrees(np.arctan(np.linalg.norm(norm[0:2])))

should be

tilty = np.degrees(np.arccos(norm[2]))
tilty = -tilty if tilty < 90 else -tilty + 180

to consider the sign properly.

I want to give it a test run though. Please let me know if you get a chance to try it before me!

Thanks again and best wishes, Fabian

PS: Sorry for the edit...

[bbarad]

I really appreciate the fast response! I'll do a quick test of this with my negative pretilt grid in the morning to make sure it still reports -9, and try a positive pretilt grid next time I'm on.

[bbarad]

The new math works properly with a negative pretilt grid - we'll load a positive pretilt grid early next week and report back! The result seems to be slightly different - -8.8 instead of -8.7 - but I am not sure which is the "correct" value and both seem fine to me.

[eisfabian]

Thanks! Good to hear! Were the different values from different measureGeometry runs? Or did you do the math with the same normal vector? If the values are from independent measurements, there will probably some fluctuations.

[bbarad]

I just echoed the old math instead of using it and saved and used the new math! So a single normal vector.

On Thu, Apr 27, 2023 at 5:37 PM eisfabian @.***> wrote:

Thanks! Good to hear! Were the different values from different measureGeometry runs? Or did you do the math with the same normal vector? If the values are from independent measurements, there will probably some fluctuations.

— Reply to this email directly, view it on GitHub https://github.com/eisfabian/PACEtomo/issues/16#issuecomment-1526818321, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKJDT4DUGQTDPR5QYQXOULXDMGN7ANCNFSM6AAAAAAXNF7YC4 . You are receiving this because you authored the thread.Message ID: @.***>

-- Benjamin Barad, PhD Postdoctoral Fellow Grotjahn Lab @ Scripps Research He/His/Him

[bbarad]

We loaded in a positive pretilt grid, and unfortunately are still measuring a negative pretilt. Looks like this isn't closed out. Obviously we're just loading negative pretilt for now (or swapping manually)

[eisfabian]

Thanks for testing! Do you have the log file with the measurements by any chance?

[bbarad]

We didn't save it but still have the grid in and can do a new measure geometry routine - I could also do a new measure-geometry routine with a few extra print statements thrown in if it would help - are there specific variables I should print out?

[eisfabian]

Just all the autofocus values and the norm vector should be enough. But if you want, you could also print the geoXYZ list! It's just good to have an example with a certain positive tilt.

[bbarad]

Logfile attached!

fit.log

[eisfabian]

Thanks so much!

Okay, I've been thinking about this some more and decided to simply determine the sign depending on the y-value of the normal vector:

sign = 1 if norm[1] <= 0 else -1
tilty = sign * np.degrees(np.arccos(norm[2]))

This should hopefully take care of it!

[bbarad]

Our krios is down, I'll test when its back 😂