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

Andrew Janke a.janke at gmail.com
Wed Feb 23 23:43:33 EST 2011


Hi Jim,

>   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


More information about the MINC-users mailing list