[MINC-users] minc "make check" error -- not just a Snow Leopard problem

[Claude LEPAGE]

Hi Andrew,

I compiled minc on snow leopard with Jim on Monday. minc 
seems to work, although make check fails. Failure seems
to occur while compiling a test program. I suspect a
problem with a #define or #ifdef that causes different 
code to be compiled. How about a diff of config.h for
OSX vs Linux? On Linux 32 and 64, the tests compile and
run to completion, reporting 1 failure out of 7 (not the
same failure as experienced on OSX). I reproduced the
same Linux behaviour on CYGWIN. :-) This seems to be an
OSX specific problem. 

I don't have much spare time to look into this. Moreover,
I don't have access to OSX unless Nic brings his laptop 
to work. Maybe install OSX as a virtual machine on my 
Linux workstation? :-)

Claude

> Hi Jim,
>
> > =A0 Here's what seems to be happening:
> >
> > (1) Looking at the test volume "t3_grid_0.mnc" we see:
> >>mincinfo -dimnames t3_grid_0.mnc
> > vector_dimension zspace yspace xspace
> >
> >>mincinfo -varnames t3_grid_0.mnc
> > rootvariable zspace yspace xspace image-min image-max image
> >
> > Note that the "vector_dimension" dimension does not have a matching
> > variable of that name, whereas the spatial dimensions do.
>
> I reckon you are onto something here... I'm surprised this hasn't
> caused problems as of yet.
>
> > Solutions:
> > (1) a quick and easy solution to the current problem would be to
> > reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called
> > "vector_dimension"
> >
> > (2) since this affects all of David MacDonald's code, we might
> > consider implementing a rule that, for minc volumes, all dimension
> > names *must* have a matching variable onto which one could attach
> > attributes. This is usually indeed the case, but it might be helpful
> > to make this explicit.
> >
> > (3) one could implement code changes to enforce (2), i.e. do not
> > permit the creation of minc volumes that have dimension names without
> > matching variable names (David's code already explicitly assumes
> > this).
>
> I'm all for #3. It should not be that hard to fix given that all is
> required is a few lines of extra code in the output_*_minc functions.
> We would also have to include some sanity checking in open_volume or
> perhaps in MINC proper to deal with older volumes that have been
> created like this.  From my initial look at the code this should not
> cause a problem with NetCDF/HDF5 interaction when converting a volume.
>
> So who wants to do it? :)
>
>
> -- =
>
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Brisbane->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>