I’ve come across a weird (I think) bug when trying to make workflows with reference-based auto select for 2D classification. When I create a new job with all of the defaults in a CryoSPARC workspace, the default maximum alignment resolution is 6 A. However, when I use that exact job to create a workflow, the default maximum alignment resolution changes to 15 A and overwrites the 6 A. See image with the build version of the workspace on the right panel and the workflow on the left panel.
Does this issue happen for every Reference Based Auto Select 2D job that you have tried in a Workflow?
Does this resolve if you refresh the page and try to create the Workflow with the same jobs again?
Does this still happen if you create a brand new Reference Based Auto Select 2D job with all default parameters and then try to create a Workflow with that job?
Have you noticed default parameters in the Workflow dialog diverging from those in the job builder on other job types as well?
If the issue persists after refreshing the page, please can you
i. enable browser console logging
ii. refresh the page
iii. build the workflow
iv. download and send us the console log
I will send the logs separately but wanted to respond here for other users.
Yesterday, the answers to 1, 2, and 3 were yes, no, and yes. I refreshed and re-signed in to CS a couple times and still had the same issue, and I also created multiple workflows with different Reference-Based Auto Select 2D jobs that all had the issue. I didn’t see this issue happening anywhere else with defaults being overwritten to other values, but I didn’t look incredibly closely. However, we restarted our CS instance overnight (unrelatedly to this topic, it was scheduled), and this morning we are no longer having that issue. However, we now have other potentially related issues. These issues are:
(a) [first two images] If we generate a workflow that begins with a 2D streaming classification, we cannot select that workflow after selecting the job in the right-hand panel. However, if we pin the workflow, we can then select it from the … at the top of the 2D streaming classification and run it successfully. Confusingly, this issue does not happen if we take the current tab and pull it into a separate window. It does happen if we make a new tab in the current Firefox instance and re-log in to Firefox. Perhaps it will never come up again if I restart Firefox completely – but since I was already logging, I have logs for both.
(b) [second two images] Once we generate the workflow, when we do deploy the workflow, the Reference-Based Auto Select 2D job is now disabled / grayed out and we can’t change any parameters – even though all parameters are unlocked in the workflow. This happens in both new windows and old windows. It seems to me that any job in our workflows that uses entirely default parameters automatically locks all of the parameters, but jobs that have non-default parameters stay unlocked / not disabled. I don’t think this is the expected behavior?
And a related feature request! Would be great to have an option in reference-based auto select 2D to lowpass filter the input volume to the max alignment resolution (or any user-given resolution) in addition to the default max resolution of 2D classes. Sometimes we run CSLive with defaults but want a first pass of 2D classification to just remove junk or cast a wide net. When the max 2D class resolution is much smaller than the max alignment resolution (4 A vs 10 A, in my instance), a lot of good classes aren’t selected, but if the input volume is instead lowpass filtered to 10 A, all of the good classes are selected. Happy to provide examples of this if needed!
Thank you for the detailed reproduction steps, screenshots, and logs.
We are still investigating the initial issue, where the Maximum alignment resolution default was being incorrectly set to 15. We have so far been unable to reproduce the issue, but continue to investigate potential causes.
In regards to the new issues you have observed:
A) We have been able to reproduce this issue, it is a bug. The data is not being loaded for the selected job in some cases. If the job was not created or interacted with recently, and it was not selected before opening the workflow panel, its data is sometimes not loaded into the application correctly to check for applicable workflows. This will be fixed in an upcoming release of CryoSPARC.
B) This is expected behaviour, but may need to be documented more clearly. The visibility toggle (“Eye” button), not the lock button, is responsible for making the parameter visible in the Apply dialog (the lock button stops the parameter from being modified in the Apply dialog if toggled on). Custom or modified parameters will automatically be toggled visible, locked parameters will also be automatically toggled visible, otherwise the visibility toggle needs to be toggled on manually for each parameter you would like to have shown and editable in the Apply dialog. Here is a link to the part of the workflows documentation covering this system: Link.
I will pass the feature request to on to our compute team for further discussion, thanks for the input!
I understand the eye vs lock now – it would be great if there were a way to toggle the “eye” on for all jobs in a workflow. I’m trying to make my users’ lives easier but don’t want to prevent them from doing what they want, and it’s easier to modify in the workflow screen than not queuing them and modifying them in the job builder.
One last (hopefully) issue I have been having with workflows is that rerouting parent jobs does not seem to be working correctly on my CryoSPARC instance. For example, some of my workflows have parent jobs of a Streaming 2D Classification job (required inputs: particles, templates) and an Import 3D Volumes job (required inputs: volume) [first set of images]. I would think that selecting a “normal” 2D Classification job as an input and a homogeneous refine job would work as parent jobs for rerouting since they provide particles, templates, and a 3D volume. However, neither of these register as suitable parent jobs for rerouting. They do not actually reroute and just give me the orange box specifying missing parent connections [second set of images]. This also happens if I mix-and-match (the exact match will work, but the one I expect to reroute will not).
Is this expected behavior? From the workflows tutorial it appears to me that I should not have to do anything in order for the rerouting to occur. Happy to provide more details if needed.
In regards to the issue with rerouting parent connections, you are correct, the jobs you are attempting to connect to the workflow should reroute the connections as expected.
I have been able to reproduce the issue and it is indeed a bug in the current version of CryoSPARC. This will be be fixed in our next release. Sorry for the inconvenience.
In regards to allowing for the eye to be toggled on for all jobs in a workflow, I think this feature makes a lot of sense. I will add it to our feature tracker for discussion with our team.
