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

[EJ Nikelski]

Hi All,

   OK, back in snowy Victoria after a lovely Montreal visit. There
were actually a few new developments since my last post, including an
appearance by the mythical Peter Neelin, who suggests ...

<Neelin>
My rather old version of the minc/volume_io software has the following
bit of code:

       dimvar = ncvarid( file->cdfid, file->dim_names[d] );
       if( dimvar != MI_ERROR )
       {
etc.

This is quite correct. If I recall correctly, the vector_dimension is
not allowed to have a dimension variable (you would have to have a
look at the programmer's reference, I think that it is in there - yup
just confirmed). In this case dimvar will have value MI_ERROR and the
code that looks for attributes will not be executed. There may be
other bugs that assume that the step and start are set, but that would
surprise me. In other words, it was certainly quite normal in minc 1
to get error return values back from functions like this as an
indication that there was no variable.
</Neelin>

   So, given the thumbs down from Peter, I looked a bit closer. As it
turns out, on Snow Leopard, even after ncopts=0 prior to the call to
ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e.,
display error message and *do not return* to calling program. So the
error return handling code is never entered.  Funnily enough, as this
works correctly under Linux, this *does* appear to be a Snow Leopard
problem after all. Perhaps related to the stoopidity that is Snow
Leopard, i.e. building 64-bit apps, but still running a 32-bit kernel
( sizeof(int)=4, not 8 on Snow Leopard on my MacBook ).

   So there you have it. Looks like it's a SL problem. It would be
interesting if the MacPros or MackBook Pros that have been coerced to
run a 64-bit kernel (hold down the "6" + "4" keys at boot) still show
the same problem.


-jim




On Thu, Feb 24, 2011 at 11:02 AM, Nicolas Kassis <nic.kassis at gmail.com> wrote:
> Hi Claude,
>
> There is an available Mac here in the office we can play with and I
> can make it available to your through VNC. A virtual OSX installation
> is more work than it's worth ;p (Using OSx86 is which is not optimal).
> It would be interesting to be able to make a linux, mac (windows?)
> available for build testing. Linux is easy, the mac is a little bit
> more work considering we need a physical machine.
>
> Nic
>
> On Thu, Feb 24, 2011 at 12:35 AM, Claude LEPAGE
> <claude at bic.mni.mcgill.ca> wrote:
>> 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
>>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>
>
> --
> -----------------
> Nicolas Kassis
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University