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>
>>
>