Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check "IsStable" before preprocessing #4

Open
bkossows opened this issue Mar 27, 2019 · 5 comments
Open

Check "IsStable" before preprocessing #4

bkossows opened this issue Mar 27, 2019 · 5 comments

Comments

@bkossows
Copy link
Contributor

bkossows commented Mar 27, 2019

One should check in sentinel.sh whether patient does not acquire new images.

http://localhost:8080/patients/patient_id
-> IsStable

@bkossows bkossows changed the title IsStable Check "IsStable" before preprocessing Mar 27, 2019
@bkossows
Copy link
Contributor Author

bkossows commented Mar 28, 2019

If not, we could remove existing output (subject’s nifti and .heudiconv) and then convert from scratch

@bkossows
Copy link
Contributor Author

For studies with pause (and closed) and coil exchange (also closed) we can then check OnStablePatient. This way we prevent from converting the same subject (heudiconv crash) multiple times.

@mslw
Copy link
Member

mslw commented Mar 28, 2019

Seems like a good idea. Just one additional thing to take care of. When converting multiple sessions at once, we would have to take care to specify session for heudiconv if there are two of them in the same dicom folder, otherwise it would complain about conflicting session IDs, see #3

@bkossows
Copy link
Contributor Author

OnStable time has been changed to 30 min. Although there is enough time for most cases, repeated conversions may still happen. In that case:

  1. we should really think about clearing .heudiconv before,
  2. we could potentially stop any running processes (?)

@mslw
Copy link
Member

mslw commented Apr 25, 2019

Great, this should cover most cases. I'd still give it an hour, but maybe you're right that we should solve the issue at its root.

Do we know what exactly crashes when new scans arrive after OnStable time (when the machinery is already running)? I think it's heudiconv.

I remember that running heudiconv on the files in /opt/.trash gave me an error about conflicting study IDs. However, is it possible that different study IDs would be generated when files are being sent (potentially) a few times from PACS to mibackup? I might be confusing something here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants