{"action":"created","issue":{"url":"https://api.github.com/repos/Unidata/netcdf-c/issues/148","labels_url":"https://api.github.com/repos/Unidata/netcdf-c/issues/148/labels{/name}","comments_url":"https://api.github.com/repos/Unidata/netcdf-c/issues/148/comments","events_url":"https://api.github.com/repos/Unidata/netcdf-c/issues/148/events","html_url":"https://github.com/Unidata/netcdf-c/issues/148","id":116150451,"number":148,"title":"request increase in NC_MAX_DIMS, NC_MAX_VARS ","user":{"login":"gdsjaar","id":12431173,"avatar_url":"https://avatars.githubusercontent.com/u/12431173?v=3","gravatar_id":"","url":"https://api.github.com/users/gdsjaar","html_url":"https://github.com/gdsjaar","followers_url":"https://api.github.com/users/gdsjaar/followers","following_url":"https://api.github.com/users/gdsjaar/following{/other_user}","gists_url":"https://api.github.com/users/gdsjaar/gists{/gist_id}","starred_url":"https://api.github.com/users/gdsjaar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gdsjaar/subscriptions","organizations_url":"https://api.github.com/users/gdsjaar/orgs","repos_url":"https://api.github.com/users/gdsjaar/repos","events_url":"https://api.github.com/users/gdsjaar/events{/privacy}","received_events_url":"https://api.github.com/users/gdsjaar/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Unidata/netcdf-c/labels/type/feature%20request","name":"type/feature request","color":"f7c6c7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":20,"created_at":"2015-11-10T16:57:05Z","updated_at":"2015-11-12T20:12:25Z","closed_at":null,"body":"As you are probably aware, Sandia's exodus database uses netcdf, but for exodus, we need to increase the values of NC_MAX_DIMS and NC_MAX_VARS to store reasonably-sized models.  In the past, this \"locally-modified\" netcdf library was OK; however, recently, the use of exodus has spread to more projects and people have started to provide binary packages for Ubuntu and other systems.  \r\n\r\nIt is difficult (or impossible) in these cases to separate the \"local netcdf\" from  a system-wide netcdf library and we therefore end up either modifying the default system-wide netcdf library, or we end up using the default system-wide netcdf library with default dimensions and that limits the complexity of the models that can be stored in exodus.\r\n\r\nI have a couple proposals for changes. \r\n * Increase the NC_MAX_DIMS and NC_MAX_VARS values as recommended by exodus.  \r\n * Add an api function which would turn on/off the check for exceeding NC_MAX_DIMS and NC_MAX_VARS.  The exodus library could call this function prior to writing the database.\r\n\r\nNeither of these solutions is optimal.  The api function could cause memory issues in an application which attempted to read a file with large dim and var counts.  The first option would possibly break backward compatibility (In that an application that statically allocates data based on these values could possibly run out of memory when linked to a new library where it ran with no problem on the older library)\r\n\r\nThere may be another solution to this issue that someone smarter than me can come up with; if so, please let me know.\r\n\r\nI realize that if I use the non-classic netcdf-4 interface, the limits are not checked; however, we still have use cases where we want to use classic.\r\n\r\nThanks,\r\n..Greg"},"comment":{"url":"https://api.github.com/repos/Unidata/netcdf-c/issues/comments/156221157","html_url":"https://github.com/Unidata/netcdf-c/issues/148#issuecomment-156221157","issue_url":"https://api.github.com/repos/Unidata/netcdf-c/issues/148","id":156221157,"user":{"login":"gdsjaar","id":12431173,"avatar_url":"https://avatars.githubusercontent.com/u/12431173?v=3","gravatar_id":"","url":"https://api.github.com/users/gdsjaar","html_url":"https://github.com/gdsjaar","followers_url":"https://api.github.com/users/gdsjaar/followers","following_url":"https://api.github.com/users/gdsjaar/following{/other_user}","gists_url":"https://api.github.com/users/gdsjaar/gists{/gist_id}","starred_url":"https://api.github.com/users/gdsjaar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gdsjaar/subscriptions","organizations_url":"https://api.github.com/users/gdsjaar/orgs","repos_url":"https://api.github.com/users/gdsjaar/repos","events_url":"https://api.github.com/users/gdsjaar/events{/privacy}","received_events_url":"https://api.github.com/users/gdsjaar/received_events","type":"User","site_admin":false},"created_at":"2015-11-12T20:12:25Z","updated_at":"2015-11-12T20:12:25Z","body":"Yes they are.  If you grep the source code, there are many arrays statically allocated as \"my_array[NC_MAX_DIMS]\"\n..Greg\n\n--\n\"A supercomputer is a device for turning compute-bound problems into I/O-bound problems\"\n\nFrom: DennisHeimbigner <notifications@github.com<mailto:notifications@github.com>>\nReply-To: Unidata/netcdf-c <reply@reply.github.com<mailto:reply@reply.github.com>>\nDate: Thursday, November 12, 2015 at 2:41 PM\nTo: Unidata/netcdf-c <netcdf-c@noreply.github.com<mailto:netcdf-c@noreply.github.com>>\nCc: \"Sjaardema, Gregory D\" <gdsjaar@sandia.gov<mailto:gdsjaar@sandia.gov>>\nSubject: [EXTERNAL] Re: [netcdf-c] request increase in NC_MAX_DIMS, NC_MAX_VARS (#148)\n\n\nThe question for NCO is: are they allocating space using some form of\n[NC_MAX_DIMS] or [NC_MAX_VARS] as opposed to using malloc.\nIf the former, then there is a potential memory issue.\n\n-\nReply to this email directly or view it on GitHub<https://github.com/Unidata/netcdf-c/issues/148#issuecomment-156212621>.\n"}}