[MINC-development] MINC2 and required NetCDF version

[Andrew Janke]

>>First why 4.x? :)
>
> For the same reason I'm not using MINC 1.x. :)

Orright, point taken...

> That would work great.  I had actually done that (though without the
> else) in a previous test.
>
> However, one could argue that since MAX_NC_OPEN is gone from NetCDF (I
> searched the whole NetCDF 3.6.3 source tree and MAX_NC_OPEN appears only
> where it's defined, in other words, it's deprecated in 3.x also.) that
> it would be better to purge MINC of this constant.  Its current value of
> 32 will never change.

True and from a search of the CVS tree (not only of MINC) no-one else
seems to have ever used it.  Still it _does_ have a use and
predominately in voxel_loop which things like mincaverage use. In this
case removing it will have nasty effects specifically in things like
mincaverage. Take the case of where you are averaging 2000 files and
you attempt to open the first chunk of all of them.  Before you
realise it you are out of RAM...  Mind you this is somewhat broken
with HDF files anyhow but that is another issue.

So from a dig in the code the only problem I see in removing it is here:

libsrc/image_conversion.c:

 218       /* How much space will be needed? */
 219       new_nalloc = minc_icv_list_nalloc + MI_MAX_NUM_ICV;

In which the list of open icvids is dynamically increased with
realloc. So we could probably just change this to 1 or 10 if we want
to kid ourselves that this will optimise something.

Still if we do this I would prefer to keep the limit (of 32 or
something like it) in voxel_loop.c

Claude?

Your proposal is insufficient since MAX_NC_OPEN is used not only to
define MI_MAX_NUM_ICV but used elsewhere too.

True, if we remove it though it is all sort of moot.. :)



--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883