Dear Chintan,
Thanks for the extra information.
I think it would be better to change the sign of your
displacements to match the RPI convention.
All the best,
Mark
On 15 Sep 2011, at 23:44, Chintan Shah wrote:
> Hi again Mark (and the list),
> Though I sent you a separate email with that additional info, I have
> another follow up question with regard to this.
> What are possum's direction conventions for motion? It seems I had to
> convert my RAI oriented input object to RPI, which matches the
> convention of the MNI template provided.
>
> Is possum's convention for motion also RPI? (+x=R to L, +y=P to A, +z=I to S)
> If so, then I will also have to modify my motion input files, as they
> were generated from volumes with an RAI convention (I would have to
> change y displacements to -y and Ry to -Ry, assuming that rotation is
> still defined with a R-hand rule about the +axis).
>
> Thanks!
> - Chintan
>
> On Thu, Sep 15, 2011 at 12:22 PM, Mark Jenkinson <[log in to unmask]> wrote:
>> Dear Chintan,
>>
>> It is good news that everything is now working well.
>> Actually, I'm completely unaware of any limitation on the orientation.
>> It might help us if you could send us some more information on this
>> as I guess it is something that hasn't been tested before.
>>
>> All the best,
>> Mark
>>
>>
>> On 15 Sep 2011, at 16:29, Chintan Shah wrote:
>>
>>> Hi Mark,
>>>
>>> Thanks for looking into my issues!
>>>
>>> I ran some simulations yesterday with the MNI template instead of out
>>> patient-specific tissue priors and found that it worked for small and
>>> large nproc. Investigating further I realized that the MNI template
>>> has a different convention and orientation than our input, and was
>>> able to fix it using fslorient and fslswapdim. I ran another
>>> simulation overnight and all is well. It seems like POSSUM only takes
>>> input in the "radiological" convention and in a specific orientation
>>> ("RPI")? Of course I probably should have realized this earlier, but
>>> it might still be useful for beginners to POSSUM to include the
>>> orientation requirements in the fsl/possum/input website. (Just a
>>> suggestion!)
>>>
>>> Thanks again for your time!
>>> - Chintan
>>>
>>> On Thu, Sep 15, 2011 at 9:36 AM, Mark Jenkinson <[log in to unmask]> wrote:
>>>>
>>>> Dear Chintan,
>>>>
>>>> You can ignore the extra job, or better still make the change from -le to -lt.
>>>> This is already in our internal code but unfortunately has not yet made it to a patch.
>>>>
>>>> As for the problems you are seeing, have you checked that all the individual
>>>> processes are completing correctly and without errors? We see this sort of
>>>> behaviour when individual processes fail to generate correct output (or any
>>>> output). If this is not the case then please give us some more details about
>>>> the set up of your possum job (the saved GUI settings, along with the fslhd
>>>> output from any customised input images, would be most useful).
>>>>
>>>> All the best,
>>>> Mark
>>>>
>>>>
>>>> On 14 Sep 2011, at 17:48, Chintan Shah wrote:
>>>>
>>>>> Hi all,
>>>>> I am having a few problems with running possum in a cluster environment that I was hoping I could get some help with.
>>>>> First, I noticed that possumX was creating an extra job (i.e. 101 jobs for 100 procs) and was wondering whether this was a problem or not. I found the post below (from several years ago) in which I noticed that the line
>>>>> for ((procnum=0; procnum < $nproc; procnum++)) ; do
>>>>> was replaced with
>>>>> procnum=0
>>>>> while [ $procnum -le $nproc ]
>>>>> It looks like -le was used instead of -lt and so it produces an extra job. I don't think this makes a difference, as looking into possum_sum it seems like it only uses partial signal files from 0 to nproc-1. I just wanted to point it out and also ask if there are any known issues related to it, since I'm not sure exactly how possum splits up jobs.
>>>>>
>>>>> My main issue is also with regard to how possum splits up jobs. I'm slowly scaling up to run a larger simulation with motion on our cluster, but I first tried a small sim with just a single volume. When I run it with 8 processors it works fine. However when I run the exact same setup with 40 processors, it produces strange, almost rectangular output (in the axial view), which becomes even more distorted with nproc=100. I've attached some images to help describe what I'm talking about. Has anyone else run into a similar issue with changing the number of processors? or does anyone have a suggestion? Any help/comments would be appreciated!!
>>>>>
>>>>> Thanks,
>>>>> Chintan
>>>>> <axial_8.png><axial_40.png>
>>>
>>
>
|