From douglas.arnold at mcgill.ca  Thu Oct  1 17:27:18 2020
From: douglas.arnold at mcgill.ca (Douglas Arnold, Dr.)
Date: Thu, 1 Oct 2020 21:27:18 +0000
Subject: [Loris-dev] Different StudyInstanceUIDs
In-Reply-To: <CAHaEUvr3vyf_AZN2WwAgh6Fn80LaROOK-bdgiUcE1sLts1m0Eg@mail.gmail.com>
References: <B5E430E5-F3A7-44C0-B8E4-25713CC270A9@bwh.harvard.edu>
 <CAHaEUvrWk3nvJmjrxkv9D6_DTRmXW-1+jirv2XPDxid1bbUoDg@mail.gmail.com>
 <EE23EBDC-E321-450F-B986-56FD3E8436DD@bwh.harvard.edu>
 <BC1475BD-5B21-41D3-8B17-E9180F311C39@bwh.harvard.edu>
 <CAHaEUvo0LHL7QtHK+anzVk0Wrsxs4Y41eVWQVF0U4ce0Pm2fpw@mail.gmail.com>
 <CAFM4iatbTF=knsC+QovHkRE7nmF-_UVB_xynpvUZNmkR7crhog@mail.gmail.com>
 <CAHaEUvr3vyf_AZN2WwAgh6Fn80LaROOK-bdgiUcE1sLts1m0Eg@mail.gmail.com>
Message-ID: <657631CD-7014-41C8-BEB8-C0D3BBC29106@mcgill.ca>

Dear Nicolas
It seems to me that this is a general limitation of LORIS that needs to be fixed on the LORIS side, rather than by modifying DICOM headers after the fact.
Do you have plans for this?
Doug


On Sep 30, 2020, at 09:30, Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:

Hi Samson,

This will not be sufficient as LORIS would expect in this case different SeriesInstanceUID/echo time combinations for these images...Unfortunately, I don't think there is any way around this.


Best,
Nicolas

On Fri, Sep 25, 2020 at 4:47 PM Samson Antel <samson at neurorx.com<mailto:samson at neurorx.com>> wrote:
Hi Nicolas,

The dual echo PD/T2 sequences we are dealing with will indeed have distinct echo times.

We also have some MT-On/MT-Off image pairs that were acquired on Philips scanners using a dynamic sequence.  In those cases, the images will share a SeriesInstanceUID _and_ an echo time.  However, they will contain distinct InstanceNumbers and TemporalPositionIdentifiers; will that be sufficient for LORIS?

Thanks,
Samson


On Fri, Sep 25, 2020 at 4:37 PM Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:
Hi Alfredo,

I am afraid what I said earlier was not 100% correct: each SerieInstanceUID/echo time combo has to be unique. So yeah, you could have two DICOM files associated with different modalities that have identical SeriesInstanceUIDs (in that case though, it is expected that the echo times will be different). I am guessing the studies you are referring to in your email fit that requirement, right?

Apologies for the confusion.


Best,
Nicolas


On Fri, Sep 25, 2020 at 4:29 PM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Hi Nicolas,

We are working on this issue but a question. Sometimes studies have dual echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence produces a PD-weighted image and a T2-weighted image together) that result in in two sequences sharing the same ? SeriesInstanceUID?. This seems to be quite common, don?t you have a workaround already available in LORIS?

Best,
Alfredo.

On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo <AMORALESPINZON at BWH.HARVARD.EDU<mailto:AMORALESPINZON at BWH.HARVARD.EDU>> wrote:

Hi Nicolas,

Thank you for your answer. We?ll handle these cases based on LORIS requirements.

Best,
Alfredo.

On May 1, 2020, at 1:39 PM, Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:


        External Email - Use Caution

Hi Alfredo,

You cannot insert in the database a scan archive containing two different study UIDs: all the scans inside the archive must have the same study UID, that's a LORIS requirement. I suggest you split your original archive into two archives, based on their study UIDs, and then upload/insert both. You could also "hack" you original archive so that all study UIDs are identical but I am not a big fan of this strategy since you are altering the original data you got from the scanner...


Best,
Nicolas

p.s: if you are not comfortable splitting archives, I can help

On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Dear LORIS-Dev Team,

In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs. This leads to an error in the insertion pipeline. The reason for having two different StudyInstanceUIDs is because some acquisitions failed QC and were re-acquired and added to the same study but with a different StudyInstanceUIDs. Here are our questions:

1. Would it be possible to insert a study having acquisitions with two different StudyInstanceUIDs?

2. If we were to change the StudyInstanceUIDs to have only one in a study, would LORIS insert they study with acquisitions having different scan date?

Thank you for your help.

Regards,
Alfredo.


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201001/de755e8c/attachment.html>

From samirdas99 at gmail.com  Thu Oct  1 20:55:50 2020
From: samirdas99 at gmail.com (Samir Das)
Date: Thu, 1 Oct 2020 20:55:50 -0400
Subject: [Loris-dev] Different StudyInstanceUIDs
In-Reply-To: <657631CD-7014-41C8-BEB8-C0D3BBC29106@mcgill.ca>
References: <B5E430E5-F3A7-44C0-B8E4-25713CC270A9@bwh.harvard.edu>
 <CAHaEUvrWk3nvJmjrxkv9D6_DTRmXW-1+jirv2XPDxid1bbUoDg@mail.gmail.com>
 <EE23EBDC-E321-450F-B986-56FD3E8436DD@bwh.harvard.edu>
 <BC1475BD-5B21-41D3-8B17-E9180F311C39@bwh.harvard.edu>
 <CAHaEUvo0LHL7QtHK+anzVk0Wrsxs4Y41eVWQVF0U4ce0Pm2fpw@mail.gmail.com>
 <CAFM4iatbTF=knsC+QovHkRE7nmF-_UVB_xynpvUZNmkR7crhog@mail.gmail.com>
 <CAHaEUvr3vyf_AZN2WwAgh6Fn80LaROOK-bdgiUcE1sLts1m0Eg@mail.gmail.com>
 <657631CD-7014-41C8-BEB8-C0D3BBC29106@mcgill.ca>
Message-ID: <CAF6xo=OdmbVxYe=hs6GUtVnAY1uZ-_-1=t77RPq41SHTrhagEQ@mail.gmail.com>

Hi Doug,

Every so often we encounter a completely new situation in LORIS, and this
seems to be one of those times. We first encountered this situation with
field maps I believe, where within a scanning session multiple acquisitions
would have the same SeriesUID, but they had distinct echo times, so we were
able to distinguish. For this situation, we'll have to make several changes
in LORIS to accommodate this, starting with modifying several tables,
back-populating them, as well as changing several parts of the code. This
isn't trivial, so we'll need some time to implement this. Let me ponder
this a bit more (and discuss with others) in case we can think of a better
solution, and then we'll get back to you.

One question... is there an urgency for this on your side?

Best,

Samir Das





On Thu, Oct 1, 2020 at 5:27 PM Douglas Arnold, Dr. <douglas.arnold at mcgill.ca>
wrote:

> Dear Nicolas
> It seems to me that this is a general limitation of LORIS that needs to be
> fixed on the LORIS side, rather than by modifying DICOM headers after the
> fact.
> Do you have plans for this?
> Doug
>
>
> On Sep 30, 2020, at 09:30, Nicolas Brossard <nicolasbrossard.mni at gmail.com>
> wrote:
>
> Hi Samson,
>
> This will not be sufficient as LORIS would expect in this case different
> SeriesInstanceUID/echo time combinations for these images...Unfortunately,
> I don't think there is any way around this.
>
>
> Best,
> Nicolas
>
> On Fri, Sep 25, 2020 at 4:47 PM Samson Antel <samson at neurorx.com> wrote:
>
>> Hi Nicolas,
>>
>> The dual echo PD/T2 sequences we are dealing with will indeed have
>> distinct echo times.
>>
>> We also have some MT-On/MT-Off image pairs that were acquired on Philips
>> scanners using a dynamic sequence.  In those cases, the images will share a
>> SeriesInstanceUID _and_ an echo time.  However, they will contain distinct
>> InstanceNumbers and TemporalPositionIdentifiers; will that be sufficient
>> for LORIS?
>>
>> Thanks,
>> Samson
>>
>>
>> On Fri, Sep 25, 2020 at 4:37 PM Nicolas Brossard <
>> nicolasbrossard.mni at gmail.com> wrote:
>>
>>> Hi Alfredo,
>>>
>>> I am afraid what I said earlier was not 100% correct: each
>>> SerieInstanceUID/echo time combo has to be unique. So yeah, you could have
>>> two DICOM files associated with different modalities that have identical
>>> SeriesInstanceUIDs (in that case though, it is expected that the echo times
>>> will be different). I am guessing the studies you are referring to in your
>>> email fit that requirement, right?
>>>
>>> Apologies for the confusion.
>>>
>>>
>>> Best,
>>> Nicolas
>>>
>>>
>>> On Fri, Sep 25, 2020 at 4:29 PM Morales Pinzon, Alfredo <
>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>
>>>> Hi Nicolas,
>>>>
>>>> We are working on this issue but a question. Sometimes studies have
>>>> dual echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence
>>>> produces a PD-weighted image and a T2-weighted image together) that
>>>> result in in two sequences sharing the same ? SeriesInstanceUID?. This
>>>> seems to be quite common, don?t you have a workaround already available in
>>>> LORIS?
>>>>
>>>> Best,
>>>> Alfredo.
>>>>
>>>> On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo <
>>>> AMORALESPINZON at BWH.HARVARD.EDU> wrote:
>>>>
>>>> Hi Nicolas,
>>>>
>>>> Thank you for your answer. We?ll handle these cases based on LORIS
>>>> requirements.
>>>>
>>>> Best,
>>>> Alfredo.
>>>>
>>>> On May 1, 2020, at 1:39 PM, Nicolas Brossard <
>>>> nicolasbrossard.mni at gmail.com> wrote:
>>>>
>>>>         External Email - Use Caution
>>>>
>>>> Hi Alfredo,
>>>>
>>>> You cannot insert in the database a scan archive containing two
>>>> different study UIDs: all the scans inside the archive must have the same
>>>> study UID, that's a LORIS requirement. I suggest you split your original
>>>> archive into two archives, based on their study UIDs, and then
>>>> upload/insert both. You could also "hack" you original archive so that all
>>>> study UIDs are identical but I am not a big fan of this strategy since you
>>>> are altering the original data you got from the scanner...
>>>>
>>>>
>>>> Best,
>>>> Nicolas
>>>>
>>>> p.s: if you are not comfortable splitting archives, I can help
>>>>
>>>> On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo <
>>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>>
>>>>> Dear LORIS-Dev Team,
>>>>>
>>>>> In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs.
>>>>> This leads to an error in the insertion pipeline. The reason for having two
>>>>> different StudyInstanceUIDs is because some acquisitions failed QC
>>>>> and were re-acquired and added to the same study but with a different StudyInstanceUIDs. Here
>>>>> are our questions:
>>>>>
>>>>> 1. Would it be possible to insert a study having acquisitions with
>>>>> two different StudyInstanceUIDs?
>>>>>
>>>>> 2. If we were to change the StudyInstanceUIDs to have only one in a
>>>>> study, would LORIS insert they study with acquisitions having different
>>>>> scan date?
>>>>>
>>>>> Thank you for your help.
>>>>>
>>>>> Regards,
>>>>> Alfredo.
>>>>>
>>>>> The information in this e-mail is intended only for the person to whom
>>>>> it is
>>>>> addressed. If you believe this e-mail was sent to you in error and the
>>>>> e-mail
>>>>> contains patient information, please contact the Partners Compliance
>>>>> HelpLine at
>>>>> http://www.partners.org/complianceline . If the e-mail was sent to
>>>>> you in error
>>>>> but does not contain patient information, please contact the sender
>>>>> and properly
>>>>> dispose of the e-mail.
>>>>> _______________________________________________
>>>>> Loris-dev mailing list
>>>>> Loris-dev at bic.mni.mcgill.ca
>>>>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>>>>
>>>>
>>>>
>>>>
> _______________________________________________
> Loris-dev mailing list
> Loris-dev at bic.mni.mcgill.ca
> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201001/5a1996f3/attachment-0001.html>

From douglas.arnold at mcgill.ca  Fri Oct  2 08:54:15 2020
From: douglas.arnold at mcgill.ca (Douglas Arnold, Dr.)
Date: Fri, 2 Oct 2020 12:54:15 +0000
Subject: [Loris-dev] Different StudyInstanceUIDs
In-Reply-To: <CAF6xo=OdmbVxYe=hs6GUtVnAY1uZ-_-1=t77RPq41SHTrhagEQ@mail.gmail.com>
References: <B5E430E5-F3A7-44C0-B8E4-25713CC270A9@bwh.harvard.edu>
 <CAHaEUvrWk3nvJmjrxkv9D6_DTRmXW-1+jirv2XPDxid1bbUoDg@mail.gmail.com>
 <EE23EBDC-E321-450F-B986-56FD3E8436DD@bwh.harvard.edu>
 <BC1475BD-5B21-41D3-8B17-E9180F311C39@bwh.harvard.edu>
 <CAHaEUvo0LHL7QtHK+anzVk0Wrsxs4Y41eVWQVF0U4ce0Pm2fpw@mail.gmail.com>
 <CAFM4iatbTF=knsC+QovHkRE7nmF-_UVB_xynpvUZNmkR7crhog@mail.gmail.com>
 <CAHaEUvr3vyf_AZN2WwAgh6Fn80LaROOK-bdgiUcE1sLts1m0Eg@mail.gmail.com>
 <657631CD-7014-41C8-BEB8-C0D3BBC29106@mcgill.ca>
 <CAF6xo=OdmbVxYe=hs6GUtVnAY1uZ-_-1=t77RPq41SHTrhagEQ@mail.gmail.com>
Message-ID: <D525D609-DC85-4ED1-BB7C-FD002B1E98CE@mcgill.ca>

Thanks Samir
No urgency. I think we can get around it by modifying the DICOM headers.
Samson, correct me if I am wrong.
Best
Doug


On Oct 1, 2020, at 20:55, Samir Das <samirdas99 at gmail.com<mailto:samirdas99 at gmail.com>> wrote:

Hi Doug,

Every so often we encounter a completely new situation in LORIS, and this seems to be one of those times. We first encountered this situation with field maps I believe, where within a scanning session multiple acquisitions would have the same SeriesUID, but they had distinct echo times, so we were able to distinguish. For this situation, we'll have to make several changes in LORIS to accommodate this, starting with modifying several tables, back-populating them, as well as changing several parts of the code. This isn't trivial, so we'll need some time to implement this. Let me ponder this a bit more (and discuss with others) in case we can think of a better solution, and then we'll get back to you.

One question... is there an urgency for this on your side?

Best,

Samir Das





On Thu, Oct 1, 2020 at 5:27 PM Douglas Arnold, Dr. <douglas.arnold at mcgill.ca<mailto:douglas.arnold at mcgill.ca>> wrote:
Dear Nicolas
It seems to me that this is a general limitation of LORIS that needs to be fixed on the LORIS side, rather than by modifying DICOM headers after the fact.
Do you have plans for this?
Doug


On Sep 30, 2020, at 09:30, Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:

Hi Samson,

This will not be sufficient as LORIS would expect in this case different SeriesInstanceUID/echo time combinations for these images...Unfortunately, I don't think there is any way around this.


Best,
Nicolas

On Fri, Sep 25, 2020 at 4:47 PM Samson Antel <samson at neurorx.com<mailto:samson at neurorx.com>> wrote:
Hi Nicolas,

The dual echo PD/T2 sequences we are dealing with will indeed have distinct echo times.

We also have some MT-On/MT-Off image pairs that were acquired on Philips scanners using a dynamic sequence.  In those cases, the images will share a SeriesInstanceUID _and_ an echo time.  However, they will contain distinct InstanceNumbers and TemporalPositionIdentifiers; will that be sufficient for LORIS?

Thanks,
Samson


On Fri, Sep 25, 2020 at 4:37 PM Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:
Hi Alfredo,

I am afraid what I said earlier was not 100% correct: each SerieInstanceUID/echo time combo has to be unique. So yeah, you could have two DICOM files associated with different modalities that have identical SeriesInstanceUIDs (in that case though, it is expected that the echo times will be different). I am guessing the studies you are referring to in your email fit that requirement, right?

Apologies for the confusion.


Best,
Nicolas


On Fri, Sep 25, 2020 at 4:29 PM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Hi Nicolas,

We are working on this issue but a question. Sometimes studies have dual echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence produces a PD-weighted image and a T2-weighted image together) that result in in two sequences sharing the same ? SeriesInstanceUID?. This seems to be quite common, don?t you have a workaround already available in LORIS?

Best,
Alfredo.

On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo <AMORALESPINZON at BWH.HARVARD.EDU<mailto:AMORALESPINZON at BWH.HARVARD.EDU>> wrote:

Hi Nicolas,

Thank you for your answer. We?ll handle these cases based on LORIS requirements.

Best,
Alfredo.

On May 1, 2020, at 1:39 PM, Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:


        External Email - Use Caution

Hi Alfredo,

You cannot insert in the database a scan archive containing two different study UIDs: all the scans inside the archive must have the same study UID, that's a LORIS requirement. I suggest you split your original archive into two archives, based on their study UIDs, and then upload/insert both. You could also "hack" you original archive so that all study UIDs are identical but I am not a big fan of this strategy since you are altering the original data you got from the scanner...


Best,
Nicolas

p.s: if you are not comfortable splitting archives, I can help

On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Dear LORIS-Dev Team,

In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs. This leads to an error in the insertion pipeline. The reason for having two different StudyInstanceUIDs is because some acquisitions failed QC and were re-acquired and added to the same study but with a different StudyInstanceUIDs. Here are our questions:

1. Would it be possible to insert a study having acquisitions with two different StudyInstanceUIDs?

2. If we were to change the StudyInstanceUIDs to have only one in a study, would LORIS insert they study with acquisitions having different scan date?

Thank you for your help.

Regards,
Alfredo.


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev



_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201002/d0348108/attachment-0001.html>

From AMORALESPINZON at bwh.harvard.edu  Mon Oct  5 09:42:49 2020
From: AMORALESPINZON at bwh.harvard.edu (Morales Pinzon, Alfredo)
Date: Mon, 5 Oct 2020 13:42:49 +0000
Subject: [Loris-dev] Error when removing UploadID
Message-ID: <D78C4312-6A05-4254-811A-ADE2DB728CE1@bwh.harvard.edu>

Dear LorisDev team,

I am removing the images from some visits that need to be reuploaded. Out of 1.5K visits I have two of them failing to be removed. I am using the script ?delete_imaging_upload.pl?. Here is the output I am getting:

===
Backing up files related to the upload(s) to delete...
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_flair_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_mtOFF_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_pdw_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1p_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1c_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t2w_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_flair_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_mtOFF_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_pdw_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1p_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1c_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t2w_001.mnc
/aaa/data/assembly/700759/w96/mri/processed/ConsensusGd/IPMSA_700759_w96_t1c_001_gvf_001.mnc.gz
/aaa/data/assembly/700759/w96/mri/processed/NewT2/IPMSA_700759_w96_t2w_001_newt2f_001.mnc.gz
/aaa/data/assembly/700759/w96/mri/processed/T2Vol/IPMSA_700759_w96_t2w_001_ct2f_001.mnc.gz
/aaa/data/assembly/310229/w96/mri/processed/ConsensusGd/IPMSA_310229_w96_t1c_001_gvf_001.mnc.gz
/aaa/data/assembly/310229/w96/mri/processed/NewT2/IPMSA_310229_w96_t2w_001_newt2f_001.mnc.gz
/aaa/data/assembly/310229/w96/mri/processed/T2Vol/IPMSA_310229_w96_t2w_001_ct2f_001.mnc.gz
/aaa/data/pic/310229/IPMSA_310229_w96_flair_001_162722_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_mtOFF_001_162723_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_pdw_001_162724_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_162726_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_gvf_001_285082_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t1p_001_162725_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_162727_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_ct2f_001_285077_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_newt2f_001_285071_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_flair_001_162488_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_mtOFF_001_162489_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_pdw_001_162490_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_162492_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_gvf_001_284706_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t1p_001_162491_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_162493_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_ct2f_001_284699_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_newt2f_001_284693_check.jpg
/aaa/data/tarchive/2010/DCM_2010-05-19_ImagingUpload-16-19-BKCuuy.tar

DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign key constraint fails (`IPMSA_LORIS`.`mri_upload`, CONSTRAINT `FK_mriupload_TarchiveID` FOREIGN KEY (`TarchiveID`) REFERENCES `tarchive` (`TarchiveID`)) at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl line 1612.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=IPMSA_LORIS;host=111.222.333.44;port=3306; at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl line 1612.
Usage: /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl [-profile file] [-ignore] [-backup_path path] [-protocol] [-form] [-uploadID list_of_uploadIDs]
            [-type list_of_scan_types] [-defaced] [-nosqlbk] [-nofilesbk]
===

Any ideas what can be happening?

Regards,
Alfredo.
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at http://www.massgeneralbrigham.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201005/250c7f1b/attachment.html>

From samirdas99 at gmail.com  Mon Oct  5 11:30:13 2020
From: samirdas99 at gmail.com (Samir Das)
Date: Mon, 5 Oct 2020 11:30:13 -0400
Subject: [Loris-dev] Different StudyInstanceUIDs
In-Reply-To: <D525D609-DC85-4ED1-BB7C-FD002B1E98CE@mcgill.ca>
References: <B5E430E5-F3A7-44C0-B8E4-25713CC270A9@bwh.harvard.edu>
 <CAHaEUvrWk3nvJmjrxkv9D6_DTRmXW-1+jirv2XPDxid1bbUoDg@mail.gmail.com>
 <EE23EBDC-E321-450F-B986-56FD3E8436DD@bwh.harvard.edu>
 <BC1475BD-5B21-41D3-8B17-E9180F311C39@bwh.harvard.edu>
 <CAHaEUvo0LHL7QtHK+anzVk0Wrsxs4Y41eVWQVF0U4ce0Pm2fpw@mail.gmail.com>
 <CAFM4iatbTF=knsC+QovHkRE7nmF-_UVB_xynpvUZNmkR7crhog@mail.gmail.com>
 <CAHaEUvr3vyf_AZN2WwAgh6Fn80LaROOK-bdgiUcE1sLts1m0Eg@mail.gmail.com>
 <657631CD-7014-41C8-BEB8-C0D3BBC29106@mcgill.ca>
 <CAF6xo=OdmbVxYe=hs6GUtVnAY1uZ-_-1=t77RPq41SHTrhagEQ@mail.gmail.com>
 <D525D609-DC85-4ED1-BB7C-FD002B1E98CE@mcgill.ca>
Message-ID: <CAF6xo=Mj9ffLSeq4y3YrBwRcEL1_sBGStSS3OoH+-N1p2ooHrw@mail.gmail.com>

Hi Doug,

That probably is the best solution short term. We'll discuss it in our
imaging meetings and add it into the roadmap appropriately.

Best,

Samir Das

On Fri, Oct 2, 2020 at 8:54 AM Douglas Arnold, Dr. <douglas.arnold at mcgill.ca>
wrote:

> Thanks Samir
> No urgency. I think we can get around it by modifying the DICOM headers.
> Samson, correct me if I am wrong.
> Best
> Doug
>
>
> On Oct 1, 2020, at 20:55, Samir Das <samirdas99 at gmail.com> wrote:
>
> Hi Doug,
>
> Every so often we encounter a completely new situation in LORIS, and this
> seems to be one of those times. We first encountered this situation with
> field maps I believe, where within a scanning session multiple acquisitions
> would have the same SeriesUID, but they had distinct echo times, so we were
> able to distinguish. For this situation, we'll have to make several changes
> in LORIS to accommodate this, starting with modifying several tables,
> back-populating them, as well as changing several parts of the code. This
> isn't trivial, so we'll need some time to implement this. Let me ponder
> this a bit more (and discuss with others) in case we can think of a better
> solution, and then we'll get back to you.
>
> One question... is there an urgency for this on your side?
>
> Best,
>
> Samir Das
>
>
>
>
>
> On Thu, Oct 1, 2020 at 5:27 PM Douglas Arnold, Dr. <
> douglas.arnold at mcgill.ca> wrote:
>
>> Dear Nicolas
>> It seems to me that this is a general limitation of LORIS that needs to
>> be fixed on the LORIS side, rather than by modifying DICOM headers after
>> the fact.
>> Do you have plans for this?
>> Doug
>>
>>
>> On Sep 30, 2020, at 09:30, Nicolas Brossard <
>> nicolasbrossard.mni at gmail.com> wrote:
>>
>> Hi Samson,
>>
>> This will not be sufficient as LORIS would expect in this case different
>> SeriesInstanceUID/echo time combinations for these images...Unfortunately,
>> I don't think there is any way around this.
>>
>>
>> Best,
>> Nicolas
>>
>> On Fri, Sep 25, 2020 at 4:47 PM Samson Antel <samson at neurorx.com> wrote:
>>
>>> Hi Nicolas,
>>>
>>> The dual echo PD/T2 sequences we are dealing with will indeed have
>>> distinct echo times.
>>>
>>> We also have some MT-On/MT-Off image pairs that were acquired on Philips
>>> scanners using a dynamic sequence.  In those cases, the images will share a
>>> SeriesInstanceUID _and_ an echo time.  However, they will contain distinct
>>> InstanceNumbers and TemporalPositionIdentifiers; will that be sufficient
>>> for LORIS?
>>>
>>> Thanks,
>>> Samson
>>>
>>>
>>> On Fri, Sep 25, 2020 at 4:37 PM Nicolas Brossard <
>>> nicolasbrossard.mni at gmail.com> wrote:
>>>
>>>> Hi Alfredo,
>>>>
>>>> I am afraid what I said earlier was not 100% correct: each
>>>> SerieInstanceUID/echo time combo has to be unique. So yeah, you could have
>>>> two DICOM files associated with different modalities that have identical
>>>> SeriesInstanceUIDs (in that case though, it is expected that the echo times
>>>> will be different). I am guessing the studies you are referring to in your
>>>> email fit that requirement, right?
>>>>
>>>> Apologies for the confusion.
>>>>
>>>>
>>>> Best,
>>>> Nicolas
>>>>
>>>>
>>>> On Fri, Sep 25, 2020 at 4:29 PM Morales Pinzon, Alfredo <
>>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>>
>>>>> Hi Nicolas,
>>>>>
>>>>> We are working on this issue but a question. Sometimes studies have
>>>>> dual echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence
>>>>> produces a PD-weighted image and a T2-weighted image together) that
>>>>> result in in two sequences sharing the same ? SeriesInstanceUID?.
>>>>> This seems to be quite common, don?t you have a workaround already
>>>>> available in LORIS?
>>>>>
>>>>> Best,
>>>>> Alfredo.
>>>>>
>>>>> On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo <
>>>>> AMORALESPINZON at BWH.HARVARD.EDU> wrote:
>>>>>
>>>>> Hi Nicolas,
>>>>>
>>>>> Thank you for your answer. We?ll handle these cases based on LORIS
>>>>> requirements.
>>>>>
>>>>> Best,
>>>>> Alfredo.
>>>>>
>>>>> On May 1, 2020, at 1:39 PM, Nicolas Brossard <
>>>>> nicolasbrossard.mni at gmail.com> wrote:
>>>>>
>>>>>         External Email - Use Caution
>>>>>
>>>>> Hi Alfredo,
>>>>>
>>>>> You cannot insert in the database a scan archive containing two
>>>>> different study UIDs: all the scans inside the archive must have the same
>>>>> study UID, that's a LORIS requirement. I suggest you split your original
>>>>> archive into two archives, based on their study UIDs, and then
>>>>> upload/insert both. You could also "hack" you original archive so that all
>>>>> study UIDs are identical but I am not a big fan of this strategy since you
>>>>> are altering the original data you got from the scanner...
>>>>>
>>>>>
>>>>> Best,
>>>>> Nicolas
>>>>>
>>>>> p.s: if you are not comfortable splitting archives, I can help
>>>>>
>>>>> On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo <
>>>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>>>
>>>>>> Dear LORIS-Dev Team,
>>>>>>
>>>>>> In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs.
>>>>>> This leads to an error in the insertion pipeline. The reason for having two
>>>>>> different StudyInstanceUIDs is because some acquisitions failed QC
>>>>>> and were re-acquired and added to the same study but with a different
>>>>>>  StudyInstanceUIDs. Here are our questions:
>>>>>>
>>>>>> 1. Would it be possible to insert a study having acquisitions with
>>>>>> two different StudyInstanceUIDs?
>>>>>>
>>>>>> 2. If we were to change the StudyInstanceUIDs to have only one in a
>>>>>> study, would LORIS insert they study with acquisitions having different
>>>>>> scan date?
>>>>>>
>>>>>> Thank you for your help.
>>>>>>
>>>>>> Regards,
>>>>>> Alfredo.
>>>>>>
>>>>>> The information in this e-mail is intended only for the person to
>>>>>> whom it is
>>>>>> addressed. If you believe this e-mail was sent to you in error and
>>>>>> the e-mail
>>>>>> contains patient information, please contact the Partners Compliance
>>>>>> HelpLine at
>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to
>>>>>> you in error
>>>>>> but does not contain patient information, please contact the sender
>>>>>> and properly
>>>>>> dispose of the e-mail.
>>>>>> _______________________________________________
>>>>>> Loris-dev mailing list
>>>>>> Loris-dev at bic.mni.mcgill.ca
>>>>>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>> _______________________________________________
>> Loris-dev mailing list
>> Loris-dev at bic.mni.mcgill.ca
>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201005/dd784b24/attachment-0001.html>

From nicolasbrossard.mni at gmail.com  Mon Oct  5 12:22:02 2020
From: nicolasbrossard.mni at gmail.com (Nicolas Brossard)
Date: Mon, 5 Oct 2020 12:22:02 -0400
Subject: [Loris-dev] Error when removing UploadID
In-Reply-To: <D78C4312-6A05-4254-811A-ADE2DB728CE1@bwh.harvard.edu>
References: <D78C4312-6A05-4254-811A-ADE2DB728CE1@bwh.harvard.edu>
Message-ID: <CAHaEUvrg=23=XGYHMKR5GvAXXTcouk6SRTbfZQAEqBZXqChOxQ@mail.gmail.com>

Hi Alfredo,

Here's what I think is happening:

You have two uploads (say A and B) in table mri_upload tied to the same
archive (say X) in table tarchive. In other words, these two uploads have
the same tarchive ID. You delete archive A and everything related to it:
the delete script throws an error because it can't delete archive X, since
upload B is still attached to it.

The solution:

For both the uploads that you could not delete (process them one at a time):

1. Find the tarchive ID associated to this upload:

SELECT TarchiveID FROM mri_upload WHERE UploadID =
<ID_of_the_upload_that_cant_be_deleted>

2. Find all the uploads with that specific tarchive ID

SELECT UploadID FROM mri_upload WHERE TarchiveID =
<whatever_was_reported_in_1>

3. Delete all the uploads associated with the TarchiveID reported in 1 with
the delete script. Note that the argument to option -upload_id for this
invocation will be the comma separated list of upload IDs reported in 2.


I hope this makes sense. Let me know how it goes.


Best,
Nicolas

On Mon, Oct 5, 2020 at 9:43 AM Morales Pinzon, Alfredo <
AMORALESPINZON at bwh.harvard.edu> wrote:

> Dear LorisDev team,
>
> I am removing the images from some visits that need to be reuploaded. Out
> of 1.5K visits I have two of them failing to be removed. I am using the
> script ?delete_imaging_upload.pl?. Here is the output I am getting:
>
> ===
> Backing up files related to the upload(s) to delete...
> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_flair_001.mnc
> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_mtOFF_001.mnc
> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_pdw_001.mnc
> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1p_001.mnc
> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1c_001.mnc
> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t2w_001.mnc
> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_flair_001.mnc
> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_mtOFF_001.mnc
> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_pdw_001.mnc
> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1p_001.mnc
> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1c_001.mnc
> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t2w_001.mnc
>
> /aaa/data/assembly/700759/w96/mri/processed/ConsensusGd/IPMSA_700759_w96_t1c_001_gvf_001.mnc.gz
>
> /aaa/data/assembly/700759/w96/mri/processed/NewT2/IPMSA_700759_w96_t2w_001_newt2f_001.mnc.gz
>
> /aaa/data/assembly/700759/w96/mri/processed/T2Vol/IPMSA_700759_w96_t2w_001_ct2f_001.mnc.gz
>
> /aaa/data/assembly/310229/w96/mri/processed/ConsensusGd/IPMSA_310229_w96_t1c_001_gvf_001.mnc.gz
>
> /aaa/data/assembly/310229/w96/mri/processed/NewT2/IPMSA_310229_w96_t2w_001_newt2f_001.mnc.gz
>
> /aaa/data/assembly/310229/w96/mri/processed/T2Vol/IPMSA_310229_w96_t2w_001_ct2f_001.mnc.gz
> /aaa/data/pic/310229/IPMSA_310229_w96_flair_001_162722_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_mtOFF_001_162723_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_pdw_001_162724_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_162726_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_gvf_001_285082_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_t1p_001_162725_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_162727_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_ct2f_001_285077_check.jpg
> /aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_newt2f_001_285071_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_flair_001_162488_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_mtOFF_001_162489_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_pdw_001_162490_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_162492_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_gvf_001_284706_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_t1p_001_162491_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_162493_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_ct2f_001_284699_check.jpg
> /aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_newt2f_001_284693_check.jpg
> /aaa/data/tarchive/2010/DCM_2010-05-19_ImagingUpload-16-19-BKCuuy.tar
>
> DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign
> key constraint fails (`IPMSA_LORIS`.`mri_upload`, CONSTRAINT
> `FK_mriupload_TarchiveID` FOREIGN KEY (`TarchiveID`) REFERENCES `tarchive`
> (`TarchiveID`)) at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl
> line 1612.
> Issuing rollback() due to DESTROY without explicit disconnect() of
> DBD::mysql::db handle database=IPMSA_LORIS;host=111.222.333.44;port=3306;
> at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl line 1612.
> Usage: /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl [-profile file]
> [-ignore] [-backup_path path] [-protocol] [-form] [-uploadID
> list_of_uploadIDs]
>             [-type list_of_scan_types] [-defaced] [-nosqlbk] [-nofilesbk]
> ===
>
> Any ideas what can be happening?
>
> Regards,
> Alfredo.
> The information in this e-mail is intended only for the person to whom it
> is addressed. If you believe this e-mail was sent to you in error and the
> e-mail contains patient information, please contact the Mass General
> Brigham Compliance HelpLine at
> http://www.massgeneralbrigham.org/complianceline . If the e-mail was sent
> to you in error but does not contain patient information, please contact
> the sender and properly dispose of the e-mail.
> _______________________________________________
> Loris-dev mailing list
> Loris-dev at bic.mni.mcgill.ca
> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201005/2d2d362c/attachment.html>

From AMORALESPINZON at bwh.harvard.edu  Tue Oct 13 17:24:25 2020
From: AMORALESPINZON at bwh.harvard.edu (Morales Pinzon, Alfredo)
Date: Tue, 13 Oct 2020 21:24:25 +0000
Subject: [Loris-dev] Error when removing UploadID
In-Reply-To: <CAHaEUvrg=23=XGYHMKR5GvAXXTcouk6SRTbfZQAEqBZXqChOxQ@mail.gmail.com>
References: <D78C4312-6A05-4254-811A-ADE2DB728CE1@bwh.harvard.edu>
 <CAHaEUvrg=23=XGYHMKR5GvAXXTcouk6SRTbfZQAEqBZXqChOxQ@mail.gmail.com>
Message-ID: <EBB85C66-238D-4707-8CC3-579D8FC75264@bwh.harvard.edu>

Hi Nicolas,

I tried using both UploadIDs in the command and it worked. Thank you very much.

Best,
Alfredo.

On Oct 5, 2020, at 12:22 PM, Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:


        External Email - Use Caution

Hi Alfredo,

Here's what I think is happening:

You have two uploads (say A and B) in table mri_upload tied to the same archive (say X) in table tarchive. In other words, these two uploads have the same tarchive ID. You delete archive A and everything related to it: the delete script throws an error because it can't delete archive X, since upload B is still attached to it.

The solution:

For both the uploads that you could not delete (process them one at a time):

1. Find the tarchive ID associated to this upload:

SELECT TarchiveID FROM mri_upload WHERE UploadID = <ID_of_the_upload_that_cant_be_deleted>

2. Find all the uploads with that specific tarchive ID

SELECT UploadID FROM mri_upload WHERE TarchiveID = <whatever_was_reported_in_1>

3. Delete all the uploads associated with the TarchiveID reported in 1 with the delete script. Note that the argument to option -upload_id for this invocation will be the comma separated list of upload IDs reported in 2.


I hope this makes sense. Let me know how it goes.


Best,
Nicolas

On Mon, Oct 5, 2020 at 9:43 AM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Dear LorisDev team,

I am removing the images from some visits that need to be reuploaded. Out of 1.5K visits I have two of them failing to be removed. I am using the script ?delete_imaging_upload.pl<http://delete_imaging_upload.pl/>?. Here is the output I am getting:

===
Backing up files related to the upload(s) to delete...
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_flair_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_mtOFF_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_pdw_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1p_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1c_001.mnc
/aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t2w_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_flair_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_mtOFF_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_pdw_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1p_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1c_001.mnc
/aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t2w_001.mnc
/aaa/data/assembly/700759/w96/mri/processed/ConsensusGd/IPMSA_700759_w96_t1c_001_gvf_001.mnc.gz
/aaa/data/assembly/700759/w96/mri/processed/NewT2/IPMSA_700759_w96_t2w_001_newt2f_001.mnc.gz
/aaa/data/assembly/700759/w96/mri/processed/T2Vol/IPMSA_700759_w96_t2w_001_ct2f_001.mnc.gz
/aaa/data/assembly/310229/w96/mri/processed/ConsensusGd/IPMSA_310229_w96_t1c_001_gvf_001.mnc.gz
/aaa/data/assembly/310229/w96/mri/processed/NewT2/IPMSA_310229_w96_t2w_001_newt2f_001.mnc.gz
/aaa/data/assembly/310229/w96/mri/processed/T2Vol/IPMSA_310229_w96_t2w_001_ct2f_001.mnc.gz
/aaa/data/pic/310229/IPMSA_310229_w96_flair_001_162722_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_mtOFF_001_162723_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_pdw_001_162724_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_162726_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_gvf_001_285082_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t1p_001_162725_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_162727_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_ct2f_001_285077_check.jpg
/aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_newt2f_001_285071_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_flair_001_162488_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_mtOFF_001_162489_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_pdw_001_162490_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_162492_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_gvf_001_284706_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t1p_001_162491_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_162493_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_ct2f_001_284699_check.jpg
/aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_newt2f_001_284693_check.jpg
/aaa/data/tarchive/2010/DCM_2010-05-19_ImagingUpload-16-19-BKCuuy.tar

DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign key constraint fails (`IPMSA_LORIS`.`mri_upload`, CONSTRAINT `FK_mriupload_TarchiveID` FOREIGN KEY (`TarchiveID`) REFERENCES `tarchive` (`TarchiveID`)) at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl<http://delete_imaging_upload.pl/> line 1612.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=IPMSA_LORIS;host=111.222.333.44;port=3306; at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl<http://delete_imaging_upload.pl/> line 1612.
Usage: /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl<http://delete_imaging_upload.pl/> [-profile file] [-ignore] [-backup_path path] [-protocol] [-form] [-uploadID list_of_uploadIDs]
            [-type list_of_scan_types] [-defaced] [-nosqlbk] [-nofilesbk]
===

Any ideas what can be happening?

Regards,
Alfredo.
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at http://www.massgeneralbrigham.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at http://www.massgeneralbrigham.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201013/76ad156b/attachment-0001.html>

From nicolasbrossard.mni at gmail.com  Tue Oct 13 18:53:30 2020
From: nicolasbrossard.mni at gmail.com (Nicolas Brossard)
Date: Tue, 13 Oct 2020 18:53:30 -0400
Subject: [Loris-dev] Error when removing UploadID
In-Reply-To: <EBB85C66-238D-4707-8CC3-579D8FC75264@bwh.harvard.edu>
References: <D78C4312-6A05-4254-811A-ADE2DB728CE1@bwh.harvard.edu>
 <CAHaEUvrg=23=XGYHMKR5GvAXXTcouk6SRTbfZQAEqBZXqChOxQ@mail.gmail.com>
 <EBB85C66-238D-4707-8CC3-579D8FC75264@bwh.harvard.edu>
Message-ID: <CAHaEUvpQkM++ekvVeHPhROtEHzw6w7Sx9EpunMcSj3x_vM7_kA@mail.gmail.com>

Hi Alfredo,

Awesome! Let me know if you have other issues.



Best,
Nicolas


On Tue, Oct 13, 2020 at 5:42 PM Morales Pinzon, Alfredo <
AMORALESPINZON at bwh.harvard.edu> wrote:

> Hi Nicolas,
>
> I tried using both UploadIDs in the command and it worked. Thank you very
> much.
>
> Best,
> Alfredo.
>
> On Oct 5, 2020, at 12:22 PM, Nicolas Brossard <
> nicolasbrossard.mni at gmail.com> wrote:
>
>         External Email - Use Caution
>
> Hi Alfredo,
>
> Here's what I think is happening:
>
> You have two uploads (say A and B) in table mri_upload tied to the same
> archive (say X) in table tarchive. In other words, these two uploads have
> the same tarchive ID. You delete archive A and everything related to it:
> the delete script throws an error because it can't delete archive X, since
> upload B is still attached to it.
>
> The solution:
>
> For both the uploads that you could not delete (process them one at a
> time):
>
> 1. Find the tarchive ID associated to this upload:
>
> SELECT TarchiveID FROM mri_upload WHERE UploadID =
> <ID_of_the_upload_that_cant_be_deleted>
>
> 2. Find all the uploads with that specific tarchive ID
>
> SELECT UploadID FROM mri_upload WHERE TarchiveID =
> <whatever_was_reported_in_1>
>
> 3. Delete all the uploads associated with the TarchiveID reported in 1
> with the delete script. Note that the argument to option -upload_id for
> this invocation will be the comma separated list of upload IDs reported in
> 2.
>
>
> I hope this makes sense. Let me know how it goes.
>
>
> Best,
> Nicolas
>
> On Mon, Oct 5, 2020 at 9:43 AM Morales Pinzon, Alfredo <
> AMORALESPINZON at bwh.harvard.edu> wrote:
>
>> Dear LorisDev team,
>>
>> I am removing the images from some visits that need to be reuploaded. Out
>> of 1.5K visits I have two of them failing to be removed. I am using the
>> script ?delete_imaging_upload.pl?. Here is the output I am getting:
>>
>> ===
>> Backing up files related to the upload(s) to delete...
>> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_flair_001.mnc
>> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_mtOFF_001.mnc
>> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_pdw_001.mnc
>> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1p_001.mnc
>> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t1c_001.mnc
>> /aaa/data/assembly/700759/w96/mri/native/IPMSA_700759_w96_t2w_001.mnc
>> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_flair_001.mnc
>> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_mtOFF_001.mnc
>> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_pdw_001.mnc
>> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1p_001.mnc
>> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t1c_001.mnc
>> /aaa/data/assembly/310229/w96/mri/native/IPMSA_310229_w96_t2w_001.mnc
>>
>> /aaa/data/assembly/700759/w96/mri/processed/ConsensusGd/IPMSA_700759_w96_t1c_001_gvf_001.mnc.gz
>>
>> /aaa/data/assembly/700759/w96/mri/processed/NewT2/IPMSA_700759_w96_t2w_001_newt2f_001.mnc.gz
>>
>> /aaa/data/assembly/700759/w96/mri/processed/T2Vol/IPMSA_700759_w96_t2w_001_ct2f_001.mnc.gz
>>
>> /aaa/data/assembly/310229/w96/mri/processed/ConsensusGd/IPMSA_310229_w96_t1c_001_gvf_001.mnc.gz
>>
>> /aaa/data/assembly/310229/w96/mri/processed/NewT2/IPMSA_310229_w96_t2w_001_newt2f_001.mnc.gz
>>
>> /aaa/data/assembly/310229/w96/mri/processed/T2Vol/IPMSA_310229_w96_t2w_001_ct2f_001.mnc.gz
>> /aaa/data/pic/310229/IPMSA_310229_w96_flair_001_162722_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_mtOFF_001_162723_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_pdw_001_162724_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_162726_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_t1c_001_gvf_001_285082_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_t1p_001_162725_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_162727_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_ct2f_001_285077_check.jpg
>> /aaa/data/pic/310229/IPMSA_310229_w96_t2w_001_newt2f_001_285071_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_flair_001_162488_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_mtOFF_001_162489_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_pdw_001_162490_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_162492_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_t1c_001_gvf_001_284706_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_t1p_001_162491_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_162493_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_ct2f_001_284699_check.jpg
>> /aaa/data/pic/700759/IPMSA_700759_w96_t2w_001_newt2f_001_284693_check.jpg
>> /aaa/data/tarchive/2010/DCM_2010-05-19_ImagingUpload-16-19-BKCuuy.tar
>>
>> DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign
>> key constraint fails (`IPMSA_LORIS`.`mri_upload`, CONSTRAINT
>> `FK_mriupload_TarchiveID` FOREIGN KEY (`TarchiveID`) REFERENCES `tarchive`
>> (`TarchiveID`)) at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl
>> line 1612.
>> Issuing rollback() due to DESTROY without explicit disconnect() of
>> DBD::mysql::db handle database=IPMSA_LORIS;host=111.222.333.44;port=3306;
>> at /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl line 1612.
>> Usage: /bbb/IPMSA/bin/mri/tools//delete_imaging_upload.pl [-profile
>> file] [-ignore] [-backup_path path] [-protocol] [-form] [-uploadID
>> list_of_uploadIDs]
>>             [-type list_of_scan_types] [-defaced] [-nosqlbk] [-nofilesbk]
>> ===
>>
>> Any ideas what can be happening?
>>
>> Regards,
>> Alfredo.
>> The information in this e-mail is intended only for the person to whom it
>> is addressed. If you believe this e-mail was sent to you in error and the
>> e-mail contains patient information, please contact the Mass General
>> Brigham Compliance HelpLine at
>> http://www.massgeneralbrigham.org/complianceline . If the e-mail was
>> sent to you in error but does not contain patient information, please
>> contact the sender and properly dispose of the e-mail.
>> _______________________________________________
>> Loris-dev mailing list
>> Loris-dev at bic.mni.mcgill.ca
>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>
>
> The information in this e-mail is intended only for the person to whom it
> is addressed. If you believe this e-mail was sent to you in error and the
> e-mail contains patient information, please contact the Mass General
> Brigham Compliance HelpLine at
> http://www.massgeneralbrigham.org/complianceline . If the e-mail was sent
> to you in error but does not contain patient information, please contact
> the sender and properly dispose of the e-mail.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20201013/2869c4e8/attachment.html>