[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