Exodus Capacity

Excerpt from an email that explains details about the Exodus use of various netCDF options. Needs cleaning up, but is helpful as is.

---

You should be able to use a 32-bit netcdf-4 format file inside YourApp with just a change to a current NetCDF library compiled with the NetCDF-4 (HDF5) capability. This will give you the option of going up to 2.1 Billion nodes / elements.

If you stay with the 32-bit native NetCDF-3 format, then the maximum size is typically limited by keeping the nodal coordinate dataset below 2^32 bytes –

2^32 bytes / (8 bytes/node) == 536.9 Million nodes.

You also will need to limit the number of elements / element block to:

	2^32 bytes / (4 bytes/node id) / (8 nodes / hex) == 134.2 Million Hexes per element block.

This should be the largest model you can create with “native” NetCDF-3 format.

---

There are a few ways to determine the format being used in the exodus/netcdf file: exo_format {file.g}. 8-block.g is an EXODUS file, version 7.13

	IDs are stored as 32-bit integers
	Map entries are stored as 32-bit integers
	Bulk data are stored as 32-bit integers

	Maximum name length is 8

	File size attribute is 'large model'
	NetCDF Variant is '64-bit offset'
	Underlying data format is netcdf

	Number of dims = 29
	Number of vars = 107

Same mesh using 32-bit ints and NetCDF-4:

tmp.g is an EXODUS file, version 7.14

	IDs are stored as 32-bit integers
	Map entries are stored as 32-bit integers
	Bulk data are stored as 32-bit integers

	Maximum name length is 8

	File size attribute is 'large model'
	NetCDF Variant is 'netCDF-4 classic'
	Underlying data format is hdf5

	Number of dims = 29
	Number of vars = 107

Same mesh using 64-bit integers and NetCDF-4 tmp.g is an EXODUS file, version 7.14

	IDs are stored as 64-bit integers
	Map entries are stored as 64-bit integers
	Bulk data are stored as 64-bit integers

	Maximum name length is 8

	File size attribute is 'large model'
	NetCDF Variant is 'netCDF-4'
	Underlying data format is hdf5

	Number of dims = 29
	Number of vars = 107

YourApp with no modifications can read the first file. If YourApp is built with a NetCDF-library with NetCDF-4 capabilities compiled in, it should be able to read the second mesh with no other modifications.

---

Another way to determine the file format if you don’t have ‘exo_format’ is to us the “octal dump” program ‘od’:

	s1018191:build(master)> od -c 8-block.g |head -1
0000000    C   D   F 002  \0  \0  \0  \v  \0  \0  \0  \n  \0  \0  \0 

	s1018191:build(master)> od -c tmp.g |head -1
0000000  211   H   D   F  \r  \n 032  \n  \0  \0  \0  \0  \0  \b  \b  \0

In the above output, “8-block.g” is a NetCDF-3 native format with the normal “64 bit offset” option (supported by YourApp today). ‘tmp.g’ is a NetCDF-4 HDF5-based file. Cannot tell from above whether it uses 32-bit or 64-bit integers.

---

Yet another way to determine is using the ‘ncdump’ program:

Doing ncdump -k {file.g}, you will see “64-bit offsets” for the first file and “netcdf-4” for the second two files above.

If you do ncdump -h {file.g} | grep “int64_status” then it will show either “0” if 32-bit ints or non-zero (typically 7168) for 64-bit integers.

If you have a file that is using 64-bit integers, but does not need to use 64-bit integers, then you can convert the file using “io_shell –32 {in-64.g} {out-32.g}”

If the mesh exceeds the capabilities of the native netcdf-3 format, you should see something similar to:

Exodus Library Warning/Error:
	Error: failed to complete variable definitions in file id 65536
	NetCDF: One or more variable sizes violate format constraints

I guess this email probably has much more information in it than you really need and isn’t probably the easiest formatting to read, so if you have any questions or comments, let me know. I would be willing to talk in person to YourApp team if they have any questions.

..Greg