[MINC-users] Running MINC tools from the www user

Alex Zijdenbos alex at bic.mni.mcgill.ca
Tue Apr 22 09:20:29 EDT 2008


Andrew Janke wrote:
> I feel like I have just stepped into the middle of something here but
> I would take a punt that this is OSX specific as I cannot seem to
> replicate this under Ubuntu or Debian.   In my case I made a test user
> and sudo'ed to there from root.  All seems to work fine but then
> perhaps I have enough RAM that EBTKS behaves itself.

I *suspect* it is not a memory issue though (but then, any C/C++ problem 
could be a memory problem :). It seems to clearly fail in the generation 
of a temporary file.

> My first suggestion would be to dumb down your command to something like this:
> 
>    sudo -u _www /usr/local/minc2/bin/nu_correct -iterations 1 -verbose \
>    /tmp/abc1.mnc /tmp/abc-out.mnc
> 
> To be sure that there are not permission errors.
> 
>>  5) I don't quite understand the MINC source code just yet (hey, that's a lot
>>  of code), where would I find CachedArray.cc?
> 
> As per Alex said (given that he is the author of EBTKS!) however I
> would be loathe to dig in the innards of that particular library as
> other strange effects may surface elsewhere.

Well there is a reasonable likelihood that the error occurs in  the 
get_temp_filename function from EBTKs' src/FileIO.cc, which is riddled 
with #ifdefs that I'm pretty sure I didn't put there :-)

However, that function is called using

     char path[256];
     get_temp_filename(path);

in CachedArray.cc, which *ick* is of course somewhat bad/volatile if for 
some reason the path generated would be longer than 256 characters. Hey 
when I wrote this memory was still at a premium and I didn't anticipate 
that this would still be in use in the next century :)

>>  Is there a way I could just bypass the call to CachedArray and not bother
>>  with trying to save memory (after all, GBytes are cheaper than the time
>>  we're spending to try to make this work... ;)
> 
> My first suggestion would be to add the -nocache options to all the
> volume_stats calls, I would also do this on a system level ie:
> 
>    cd /usr/local/minc2/bin
>    mv volume_stats volume_stats.orig
> 
>    echo "#! /bin/sh" > volume_stats
>    echo "volume_stats.orig -nocache $*" >> volume_stats
>    chmod +x volume_stats
> 
> If this is still failing there is another option,....  but I will
> likely be castigated for it.  I have long suggested that volume_stats
> should be replaced with mincstats in nu_correct but there are
> differences between the two in how they interpret histogram bins and
> this results in a differing bimodalT for some histograms.  The results
> from using mincstats are comparable to volume_stats but are not the
> same.  It would be a difficult argument to prove which is better given
> the simulations I have done on this so far.

I was thinking the same thing - there appear to be some issues propping 
up now again relating to differences between mincstats and volume_stats, 
but by and large they should be interchangeable, and it seems to make 
more sense to standardize on one. Perhaps a good reason to perform a 
major version upgrade of N3? Although it would be nice to actually 
improve its performance while at it, such it doesn't need to be run 5 or 
10 times in a row to deliver good results. Still hoping to find time to 
deal with that. One of these years...

-- A


More information about the MINC-users mailing list