Skip to content

Alpha Release of v3.3.0

Pre-release
Pre-release
Compare
Choose a tag to compare
@brtnfld brtnfld released this 21 Sep 14:20
v3.3.0-alpha.1
795f2d4

NOTE: We really need Fortran users of CGNS to test this release.

CGNS version 3.3.0

INTRODUCTION

This document describes the difference between CGNS 3.2.1 and
CGNS 3.3.0, and contains information on known problems in CGNS 3.3.0.

Links to the CGNS 3.3.0 source code can be found at:

 http://cgns.org/download.html

User documentation for the current release can be found at:

 http://cgns.org/CGNS_docs_current/midlevel/index.html

For more information, see the CGNS home page:

 http://cgns.org

CONTENTS

  • New Features
  • Support for new platforms and languages
  • Bug Fixes since CGNS 3.2.1
  • Known Problems

New Features

Configuration:
-------------
* Example build scripts for supercomputer systems can be found in src/SampleScripts 
  of the CGNS source code. They include scripts for building zlib, 
  hdf5 (assuming the user does not already have them installed system wide) 
  and a script for building CGNS. All the scripts use autotools; cmake remains untested.

Library:
--------
* Replaced the hid_t to double (and vice-versa) utilities to_HDF_ID and to_ADF_ID 
  from a type cast to a function which uses memcpy for the conversion. This is needed 
  for the upcomming release of HDF5 1.10 where hid_t was changed from a 32 bit integer 
  to a 64 bit integer. Should be transparent to user.

* Implemented CPEX0039 : To enable with CGNS_ENABLE_BASE_SCOPE

* Implemented CPEX0038 : Quadratic Elements for High Order


Parallel Library:
-----------------
* The default parallel input/output mode was changed from CGP_INDEPENDENT 
  to CGP_COLLECTIVE.

* A new function was added for passing MPI info to the CGNS library:
  cgp_mpi_info (cgp_mpi_info_f)

* A new parallel example benchmark program, benchmark_hdf5.c, was added 
  to directory ptests.

* The cgp_*_read/write_dataset APIs now excepts non-allocated arrays, or NULL, 
  as valid parameters for the datasets. Additionally, the dimensional arrays, 
  rmin and rmax, can also be NULL. If the data array is NULL and the dimensional 
  arrays are not NULL, then the validity of the dimensional arrays, rmin and rmax, 
  is not checked. For collective parallel IO, this is used as a mechanism to 
  indicated that processes with NULL API parameters will not write any data to the file.

* cgp_queue_set and cgp_queue_flush were depreciated in this release.

Fortran Library:
----------------
* SUPPORT WAS DROPPED FOR NON-FORTRAN 2003 COMPLIANT COMPILERS.

* Configure was changed to check if the Fortran compiler is Fortran 2003 compliant.

* The predefined CGNS constant parameters data types were changed from 
  INTEGER to ENUM, BIND(C) for better C interoperability. The users should use the 
  predefined constants whenever possible and not the numerical value represented by 
  the constants. A variable expecting an enum value returned from a Fortran API should be 
  declared, INTEGER(cgenum_t).

* INCLUDE "cgslib_h" was changed in favor of using a module, USE CGNS.
  - This allows defining a KIND type for integers instead of 
    the current way of using the preprocessor dependent cgsize_t.

* The user should be sure to declare the arguments 
  declared int in the C APIs as INTEGER in Fortran. The ONLY 
  Fortran arguments declared as type cgsize_t should be the 
  arguments which are also declared cgsize_t in the C APIs. This 
  is very important when building with option --enable-64bit. The 
  test programs were updated in order to conform to this convention.

* Assuming the rules in step [enu:int64] were followed, users 
  should not need to use parameter CG_BUILD_64BIT since Fortran's 
  cgsize_t is now guaranteed to match C's cgsize_t. 

* Fortran programs defining CGNS data types with a default 
  INTEGER size of 8 bytes also then need to compile the CGNS 
  library with the default INTEGER size of 8 bytes. This is 
  independent of whether or not --enable-64bit is being used. For 
  clarification, using --enable-64bit allows for data types (i.e. 
  those declared as cgsize_t) to be able to store values which 
  are too large to be stored as 4 byte integers (i.e. numbers 
  greater than 2,147,483,647). It is not necessary, or advisable 
  (since it waste memory), to have CGNS INTEGER types (types 
  declared int in C) to be 8 bytes; the variables declared as 
  cgsize_t will automatically handle data types that can not be 
  stored as 4 byte integers when --enable-64bit is being used. If 
  the CGNS library was not compiled with a default INTEGER of 8 
  bytes, but the calling program was, then all integers passed to 
  CGNS with C type int should be declared INTEGER(C_INT).   

* A new Fortran API was added for determining the CGNS data type of a 
  variable which is interoperable with the C data type. 

  Function cg_get_type(var)
     type, INTENT(IN) :: var
     INTEGER(KIND(enumvar)) :: cg_get_type

  An example of using the new function to automatically specify the CGNS 
  type corresponding to the Fortran data type is,

     INTEGER, DIMENSION(1:10) :: Array_i
     CALL cgp_array_write_f("ArrayI",cg_get_type(Array_i(1)),1,INT(nijk(1),cgsize_t),Ai, err)

Tools:
------
 - None

Bug Fixes since CGNS 3.2.1 release

Configuration:
-------------
* Fixed issue with autotools putting a blank "-l" in "MPILIBS =" when compiling the library
  using mpi.

Library:
-------

* Generally improved the performance of cgp_open (cgp_open_f).

Fortran:
--------
- Fixed cgnslib_f.h to be both free and fixed form compatible.

Tools:
------
- None

Known Problems

  • Building CGNS with Fortran enabled is not working on Windows.
Assets 2