xa30a cmrr_mbep2d_bold crashes after 55 volumes #338
Comments
|
There is nothing unusual about that protocol, so I would assume it is most likely some issue specific to your scanner. If you can get a savelog right after one of these crashes I can look at it and see jf there is a useful error message. |
|
Dear Eddie and CMRR
interestingly, this problem cannot be reproduced on a phantom...
So either there is some strange link with the SAR
or some relationship to the timing of the experiments...
phantom tests are done in the evenings while human subjects are acquired during normal
working hours... It this time correlation is true, this would indicate some problem either with cooling or power...
will watch more ..
getting the error now a bit tricky because the projects which used that protocol stopped human scanning and are waiting for a "solution"...
Lazar
…________________________________________
From: Eddie Auerbach ***@***.***>
Sent: Saturday, November 4, 2023 11:23
To: CMRR-C2P/MB
Cc: Fleysher, Lazar; Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
USE CAUTION: External Message.
There is nothing unusual about that protocol, so I would assume it is most likely some issue specific to your scanner. If you can get a savelog right after one of these crashes I can look at it and see jf there is a useful error message.
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CMRR-2DC2P_MB_issues_338-23issuecomment-2D1793474008&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=-GukimnJdBPqaFchq3-YZ3OcfW_Gm9htRQQ7SUXRNfE3V234XDi4DhmQ-3p1t71E&s=wv33hGuYUS0gaJWgOVJwqHk2BPM5pE8GSc35YnQS3JI&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADWOZ63UV25N44AOE3XPKRDYCZMYFAVCNFSM6AAAAAA65IS6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGQ3TIMBQHA&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=-GukimnJdBPqaFchq3-YZ3OcfW_Gm9htRQQ7SUXRNfE3V234XDi4DhmQ-3p1t71E&s=_BvYQiAhIU3v37C5o4CBRQBPtxLb3ioWLeYuHiATdT4&e=>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Dear Eddie and CMRR
The problem happened on a human and I have saved a log file
crash happened after 55th volume and was reproducible.
However, I cannot share the logs here.
Eddie, if you do not mind, I will share it with you separately
Thank you very much for your kind help
Lazar
…________________________________________
From: Fleysher, Lazar ***@***.***>
Sent: Saturday, November 18, 2023 23:21
To: CMRR-C2P/MB; CMRR-C2P/MB
Cc: Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
Dear Eddie and CMRR
interestingly, this problem cannot be reproduced on a phantom...
So either there is some strange link with the SAR
or some relationship to the timing of the experiments...
phantom tests are done in the evenings while human subjects are acquired during normal
working hours... It this time correlation is true, this would indicate some problem either with cooling or power...
will watch more ..
getting the error now a bit tricky because the projects which used that protocol stopped human scanning and are waiting for a "solution"...
Lazar
________________________________________
From: Eddie Auerbach ***@***.***>
Sent: Saturday, November 4, 2023 11:23
To: CMRR-C2P/MB
Cc: Fleysher, Lazar; Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
USE CAUTION: External Message.
There is nothing unusual about that protocol, so I would assume it is most likely some issue specific to your scanner. If you can get a savelog right after one of these crashes I can look at it and see jf there is a useful error message.
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CMRR-2DC2P_MB_issues_338-23issuecomment-2D1793474008&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=-GukimnJdBPqaFchq3-YZ3OcfW_Gm9htRQQ7SUXRNfE3V234XDi4DhmQ-3p1t71E&s=wv33hGuYUS0gaJWgOVJwqHk2BPM5pE8GSc35YnQS3JI&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADWOZ63UV25N44AOE3XPKRDYCZMYFAVCNFSM6AAAAAA65IS6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGQ3TIMBQHA&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=-GukimnJdBPqaFchq3-YZ3OcfW_Gm9htRQQ7SUXRNfE3V234XDi4DhmQ-3p1t71E&s=_BvYQiAhIU3v37C5o4CBRQBPtxLb3ioWLeYuHiATdT4&e=>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Dear Eddie and CMRR
I was able to reproduce the problem on a phantom which allowed an investigation of a problem.
I have noticed that the crash depends on slice orientation but in a very strange way.
axial acquisition works and the "live-view" window updates the images as they are acquired and reconstructed.
but if slices are oblique, the "live-view" window does not update, the sequence acquires 54 volumes and crashes on the 55th
one. About 10 seconds after the crash, the "live-view" window is updated and all 54 reconstructed images are cycled through that window.
So there is some sort of coupling between protocol parameters, slice orientation and siemens image-handling infrastructure.
I know that there was a problem with "view&go" application but I thought it was corrected (we have a patch installed) and closing "view&go" did not resolve this crash...
does anyone have any ideas what might be causing this??
Thank you very much for your kind help
Happy New Year
Lazar
…________________________________________
From: Fleysher, Lazar ***@***.***>
Sent: Thursday, December 21, 2023 00:08
To: CMRR-C2P/MB; CMRR-C2P/MB
Cc: Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
Dear Eddie and CMRR
The problem happened on a human and I have saved a log file
crash happened after 55th volume and was reproducible.
However, I cannot share the logs here.
Eddie, if you do not mind, I will share it with you separately
Thank you very much for your kind help
Lazar
________________________________________
From: Fleysher, Lazar ***@***.***>
Sent: Saturday, November 18, 2023 23:21
To: CMRR-C2P/MB; CMRR-C2P/MB
Cc: Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
Dear Eddie and CMRR
interestingly, this problem cannot be reproduced on a phantom...
So either there is some strange link with the SAR
or some relationship to the timing of the experiments...
phantom tests are done in the evenings while human subjects are acquired during normal
working hours... It this time correlation is true, this would indicate some problem either with cooling or power...
will watch more ..
getting the error now a bit tricky because the projects which used that protocol stopped human scanning and are waiting for a "solution"...
Lazar
________________________________________
From: Eddie Auerbach ***@***.***>
Sent: Saturday, November 4, 2023 11:23
To: CMRR-C2P/MB
Cc: Fleysher, Lazar; Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
USE CAUTION: External Message.
There is nothing unusual about that protocol, so I would assume it is most likely some issue specific to your scanner. If you can get a savelog right after one of these crashes I can look at it and see jf there is a useful error message.
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CMRR-2DC2P_MB_issues_338-23issuecomment-2D1793474008&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=-GukimnJdBPqaFchq3-YZ3OcfW_Gm9htRQQ7SUXRNfE3V234XDi4DhmQ-3p1t71E&s=wv33hGuYUS0gaJWgOVJwqHk2BPM5pE8GSc35YnQS3JI&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADWOZ63UV25N44AOE3XPKRDYCZMYFAVCNFSM6AAAAAA65IS6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGQ3TIMBQHA&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=-GukimnJdBPqaFchq3-YZ3OcfW_Gm9htRQQ7SUXRNfE3V234XDi4DhmQ-3p1t71E&s=_BvYQiAhIU3v37C5o4CBRQBPtxLb3ioWLeYuHiATdT4&e=>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
That is interesting. In the logs I see a memory allocation error. If I am reading the logs correctly it looks like not quite 64 GB of memory is in use when it throws the error, which is a strange limit since your MaRS has 128 GB of memory installed. I am not entirely familiar with how XA30 is set up so maybe the other 64 GB is reserved for the system and this is normal. But it is strange that so much memory is in use. Normally over the course of the scan as each repetition is acquired the system allocates enough memory for that repetition, reconstructs the repetition, then releases the memory once the images are sent to the database. So even though your per-repetition data size is large (~344 MB per repetition), at any given time there should not be more than a few repetitions in memory. Even accounting for multiple copies of each repetition being held in memory temporarily for intermediate calculations, that should only be a few GB total, not anything close to 64 GB. Your observation that the images are not shown in real time in the inline display would seem to indicate that the images are not being sent to the database at the end of the chain for some reason, which could mean that they are piling up in memory until it runs out and crashes. 54 volumes * 344 MB is under 20 GB, so even that doesn't seem right, but it isn't impossible there are 3 temporary copies in use for calculations which would get up in the 60 GB range. So maybe that is it. It looks like you are using the 64-channel head coil, so a quick way to check if this is the case would be to try the same protocol with a coil with fewer channels that uses less memory (e.g. the 32-channel or 20-channel coil). Or enable the "Matrix optimization" option to compress the channels (we generally recommend always doing this with the 64-channel head coil for performance reasons). If memory is the limit then with fewer coil elements it should crash instead after 90-100 volumes or more. But the real question is why the reconstruction is hanging up. I have only seen this happen before when physiology logging is enabled with the DICOM export option. But that issue was fixed in R017pre7. So if you have the DICOM physiology export option enabled and are using R017pre6 or older, that may be the problem. Otherwise, there must be a new problem, and to troubleshoot further I would probably need a meas.dat file from one of your failed acquisitions. |
|
Dear Eddie
Thank you very much for looking into this.
I have removed the old save logs from the shared directory and put new ones with the corresponding *dat file
https://mtsinai-my.sharepoint.com/:f:/r/personal/lazar_fleysher_mountsinai_org/Documents/WORK/CMRR?csf=1&web=1&e=6tctoj
Maybe this could help to understand the cause of the issue.
I also start to suspect that the behavour may have something to do with PNS safety monitoring.
The current protocol has PNS level at about 95-96%, but maybe after 54 volumes, some sort of hardware/software
controller makes a decision that this is too dangerous and kills the acquisition.
Again, thank you very much for your kind help
Lazar
…________________________________________
From: Eddie Auerbach ***@***.***>
Sent: Friday, January 5, 2024 20:05
To: CMRR-C2P/MB
Cc: Fleysher, Lazar; Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
USE CAUTION: External Message.
That is interesting. In the logs I see a memory allocation error. If I am reading the logs correctly it looks like not quite 64 GB of memory is in use when it throws the error, which is a strange limit since your MaRS has 128 GB of memory installed. I am not entirely familiar with how XA30 is set up so maybe the other 64 GB is reserved for the system and this is normal.
But it is strange that so much memory is in use. Normally over the course of the scan as each repetition is acquired the system allocates enough memory for that repetition, reconstructs the repetition, then releases the memory once the images are sent to the database. So even though your per-repetition data size is large (~344 MB per repetition), at any given time there should not be more than a few repetitions in memory. Even accounting for multiple copies of each repetition being held in memory temporarily for intermediate calculations, that should only be a few GB total, not anything close to 64 GB.
Your observation that the images are not shown in real time in the inline display would seem to indicate that the images are not being sent to the database at the end of the chain for some reason, which could mean that they are piling up in memory until it runs out and crashes. 54 volumes * 344 MB is under 20 GB, so even that doesn't seem right, but it isn't impossible there are 3 temporary copies in use for calculations which would get up in the 60 GB range. So maybe that is it.
It looks like you are using the 64-channel head coil, so a quick way to check if this is the case would be to try the same protocol with a coil with fewer channels that uses less memory (e.g. the 32-channel or 20-channel coil). Or enable the "Matrix optimization" option to compress the channels (we generally recommend always doing this with the 64-channel head coil for performance reasons). If memory is the limit then with fewer coil elements it should crash instead after 90-100 volumes or more.
But the real question is why the reconstruction is hanging up. I have only seen this happen before when physiology logging is enabled with the DICOM export option. But that issue was fixed in R017pre7. So if you have the DICOM physiology export option enabled and are using R017pre6 or older, that may be the problem. Otherwise, there must be a new problem, and to troubleshoot further I would probably need a meas.dat file from one of your failed acquisitions.
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CMRR-2DC2P_MB_issues_338-23issuecomment-2D1879471922&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=oswrCgyXsivfQTC9JSIiyn0PHUPZE1WhiU7S4XfLL5iipUPST1ap-rM0itqprh9I&s=fC2M344Dbry3fgsuPhSXM6flRP86vCP5jxvALrY_uhA&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADWOZ63YZB6TTHRLDOQQYGDYNCPMFAVCNFSM6AAAAAA65IS6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGQ3TCOJSGI&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=oswrCgyXsivfQTC9JSIiyn0PHUPZE1WhiU7S4XfLL5iipUPST1ap-rM0itqprh9I&s=E7yLxh1-xx6upi08AySHsdmsNHXzMcy0uNzbh6m9ZW4&e=>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
We experienced this same issue on our Prisma at UAB running XA30a. We were using the 64-channel head coil, running HCP-like resting state fMRI with MB factor = 8. We wound up doubling the TR and halving the MB factor. I plan to try matrix optimization and 20-channel coil in the future. I can share .dat files and savelogs if it is helpful. Here is relevant text from UTrace file: Thank you, |
|
We have exactly the same problem on XA30A and 64 channel coil. By rotating the FOV I can easily reproduce the error after 2-3 iterations. However, with the Matrix Optimization set to Performance it seems to work correctly even without restarting the MARS. Please confirm if we can go on with the study like that. |
|
Yes, Matrix Optimization = Performance is recommended with the 64 channel coil. |
|
Dear Eddie
What does "matrix optimization" do?
If it is memory management to speed things up,
how is it related to the slice orientation? Is it because the coil sensitivity calibration and the actual scan are
acquired with different orientations?
regardless, it appears that there is a memory leak somewhere because there should not be a necessity to keep
all imaged volumes in RAM. Maybe there is a leak in the Siemens infrastructure which reveals itself via this application.
Lazar
…________________________________________
From: Eddie Auerbach ***@***.***>
Sent: Wednesday, May 8, 2024 15:54
To: CMRR-C2P/MB
Cc: Fleysher, Lazar; Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
USE CAUTION: External Message.
Yes, Matrix Optimization = Performance is recommended with the 64 channel coil.
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CMRR-2DC2P_MB_issues_338-23issuecomment-2D2101320778&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=Cnut_kYh3gv4mi8resdBO6dkX1DreG0lVeTjsEnV6SxFMLrVxF48x34cQ9Oc3t6k&s=-xaZYqMNIZ-5j9QdLmbqjzOdy85CI3i4F98gBaOMIyU&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADWOZ63GCNIPZ6RIPWZ7LPTZBJ7JFAVCNFSM6AAAAAA65IS6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBRGMZDANZXHA&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=Cnut_kYh3gv4mi8resdBO6dkX1DreG0lVeTjsEnV6SxFMLrVxF48x34cQ9Oc3t6k&s=4Cab-xO1eJZG2x5RQd24x5uSidt_ZpRkqHUP06qrTvw&e=>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Matrix optimization is channel compression, which combines non-overlapping coils early on in the reconstruction, reducing memory and computational requirements. For the 64-channel head coil we usually find that channel compression reduces the number of logical coils to 34 or so, which makes a significant difference in the reconstruction performance. As I tried to describe above, the images are reconstructed one repetition at a time on the MaRS and then sent over the network to the host to be stored in the database. Normally there should only be a couple repetitions in memory at a time on the MaRS, since the memory is released after each repetition is sent on its way to the host. But in XA versions (XA20/30/50/60) the host is unusually slow in receiving images. It is a serious fundamental architectural problem that we are working with Siemens to try to fix. It is absolutely a new issue with XA; it did not happen like this in VB/VD/VE. I believe the problem here is the delay on the host computer in receiving images accumulates over the course of the scan, and the images pile up on the MaRS. Eventually the MaRS runs out of memory to hold them all and the reconstruction stops. Matrix optimization does not directly fix this problem, but it cuts the memory used by the reconstruction in half, leaving much more of a buffer on the MaRS. My image reconstruction code is essentially identical across all versions: VB/VD/VE/XA. This problem only exists in XA, so the idea it is due to a memory leak in the reconstruction on the MaRS does not make sense. We do not see this in VB/VD/VE. In VB/VD/VE in most cases the image reconstruction can keep up in real time. One of the new problematic things that happens on the host in XA is that apparently it creates an additional resampled version of every volume on the fly, I guess for use in View&Go. This clearly must slow things down, but currently there is no way to disable it. It is plausible that if you acquire volumes with an oblique rotation, this resampling process is even slower (e.g. if orthogonal images use a simple linear interpolation, vs. obliques requiring a more complicated resampling). |
|
Dear Eddie
I apologize, when I wrote "memory leak somewhere" and "Maybe there is a leak in the Siemens infrastructure which reveals itself via this application" I did mean your code, I meant the Siemens infrastructure .
Originally, when the problem was observed and after I was able to reproduce it and you pointed out to the memory problem,
I spoke with Siemens and specifically
told them that it looks to me that there is a problem with the infrastructure not the custom ice program.
and argued specifically that ice does not care about image orientation. And even if there coil sensitivity and actual images
are acquired on different grids then it would not produce a reproducible crash at a specific volume...
I argued that there is a problem with the infrastructure. You had debugged this much more than me and narrowed down
the area of the infrastructure which needs attention from Siemens.
I do see a "delay" in how raw data are flowing and I suspect this is somehow related to the PNS monitoring....
As to display image interpolation, I have noticed that Siemens is interpolating images for display purposes since VA-series software...
Maybe they have changed the method of doing it which slows down export of images from recon, but it is again an infrastructure problem...
Again, thank you very much for your kind help
Lazar
…________________________________________
From: Eddie Auerbach ***@***.***
Sent: Friday, May 10, 2024 13:35
To: CMRR-C2P/MB
Cc: Fleysher, Lazar; Author
Subject: Re: [CMRR-C2P/MB] xa30a cmrr_mbep2d_bold crashes after 55 volumes (Issue #338)
USE CAUTION: External Message.
Matrix optimization is channel compression, which combines non-overlapping coils early on in the reconstruction, reducing memory and computational requirements. For the 64-channel head coil we usually find that channel compression reduces the number of logical coils to 34 or so, which makes a significant difference in the reconstruction performance.
As I tried to describe above, the images are reconstructed one repetition at a time on the MaRS and then sent over the network to the host to be stored in the database. Normally there should only be a couple repetitions in memory at a time on the MaRS, since the memory is released after each repetition is sent on its way to the host.
But in XA versions (XA20/30/50/60) the host is unusually slow in receiving images. It is a serious fundamental architectural problem that we are working with Siemens to try to fix. It is absolutely a new issue with XA; it did not happen like this in VB/VD/VE.
I believe the problem here is the delay on the host computer in receiving images accumulates over the course of the scan, and the images pile up on the MaRS. Eventually the MaRS runs out of memory to hold them all and the reconstruction stops. Matrix optimization does not directly fix this problem, but it cuts the memory used by the reconstruction in half, leaving much more of a buffer on the MaRS.
My image reconstruction code is essentially identical across all versions: VB/VD/VE/XA. This problem only exists in XA, so the idea it is due to a memory leak in the reconstruction on the MaRS does not make sense. We do not see this in VB/VD/VE. In VB/VD/VE in most cases the image reconstruction can keep up in real time.
One of the new problematic things that happens on the host in XA is that apparently it creates an additional resampled version of every volume on the fly, I guess for use in View&Go. This clearly must slow things down, but currently there is no way to disable it. It is plausible that if you acquire volumes with an oblique rotation, this resampling process is even slower (e.g. if orthogonal images use a simple linear interpolation, vs. obliques requiring a more complicated resampling).
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CMRR-2DC2P_MB_issues_338-23issuecomment-2D2105006779&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=pYYjvHIrHm_9hDoPboTtbLs2AZZMydojyMhYc4JPafCX9QsSJvzkjJtekgxWjvXh&s=1aCNhbYsr0X2Cb8HEoJBZWnjgb7_Jv5vx7T2tTeNpf4&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADWOZ64JIPROZ52I74RNHO3ZBUANDAVCNFSM6AAAAAA65IS6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGAYDMNZXHE&d=DwMCaQ&c=shNJtf5dKgNcPZ6Yh64b-ALLUrcfR-4CCQkZVKC8w3o&r=WGq7KIBmy8I7ufgxRyjhHvdCAqZQXGxGk-JvRxYMzXw&m=pYYjvHIrHm_9hDoPboTtbLs2AZZMydojyMhYc4JPafCX9QsSJvzkjJtekgxWjvXh&s=RBZedBnoT9URQ8cV7ox5z1X3oodRcMb2YB7_Mve-KnM&e=>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
dear CMRR
I have experienced a very strange problem when the epi acquisition aborts on the 55th volume when running on Prisma (not sure if this is important), XA30A software.
rfMRI_REST_PA.pdf
Attached to this post is the pdf file of the protocol.
this is very reproducible but not 100%. Sometimes the acquisition finishes normally.
increasing TE or TR by a few ms does not resolve the problem. Rotating slices does not resolve.
I could not find anything obvious in the scanner log files, but there was a message about an unhandled exception.
What is so magical in 511 ? or is it 96 which is magical?
Thanks
Lazar
The text was updated successfully, but these errors were encountered: