CDO

I'd like to bump this as I'm experiencing this issue. What exactly is the yaxt library/header? Is this a new prerequisite of CDO? I thought because it's in the libcdi directory that using "--disable-cdi-lib" would avoid it, but that was just wishful thinking.

If this is a new prerequisite, where can I get the yaxt library? I found this page: https://redmine.dkrz.de/doc/yaxt/html/index.html but I can't seem to find a download link...

Thanks for any help,
Matt

Okay, I took a closer look at this, and it seems to almost be an issue in the libcdi/configure script. I've detailed my investigation in Bug #4064. It looks to me like the libcdi/configure.ac test for "--enable-mpi" is broken and it always assumes "--enable-mpi" is set...at least for me.

Hmm. Okay, I might not be there yet. Even though USE_MPI is now not set, and so there isn't an error in configuring libcdi, I still get:

mpicc -std=gnu99 -DHAVE_CONFIG_H -I.  -I../libcdi/src <snip>
  -fPIC  -D_POSIX_C_SOURCE=199309L  -MT cdo-Importcmsaf.o -MD -MP -MF .deps/cdo-Importcmsaf.Tpo -c -o cdo-Importcmsaf.o `test -f 'Importcmsaf.c' || echo './'`Importcmsaf.c
../libcdi/src/cdi.h(231): catastrophic error: cannot open source file "yaxt.h" 
  #  include <yaxt.h>
                     ^

compilation aborted for Importcmsaf.c (code 4)

I think this is because libcdi/src/cdi.h has:

 229 /* parallel IO routines */
 230 #ifdef MPI_VERSION
 231 #  include <yaxt.h>
 232 #endif

So if MPI_VERSION is defined (as it is if you compile with mpicc), then you need to have yaxt.h available.

Okay, I found I can get past the Importcmsaf.c error if I surround the MPI_VERSION section in libcdi/src/cdi.h with an #ifdef USE_MPI:

 229 /* parallel IO routines */
 230 #ifdef USE_MPI
 231 #ifdef MPI_VERSION
 232 #  include <yaxt.h>
 233 #endif
 234 
 235 #ifdef MPI_VERSION /* make_fint keep */
 236 void     pioEndDef             ( void );
 237 void     pioEndTimestepping    ( void );
 238 void     pioFinalize           ( void );
 239 /*      pioInit: initialize I/O server processes and communication */
 240 MPI_Comm pioInit(MPI_Comm commSuper, int nProcsIO, int IOMode,
 241                  int *pioNamespace, float partInflate);
 242 void     pioWriteTimestep();
 243 
 244 void     streamWriteVarPart    (int streamID, int varID,
 245                                 const void *data, int nmiss,
 246                                 Xt_idxlist partDesc);
 247 
 248 #endif /* make_fint keep */
 249 #endif

My guess is this is just a stopgap, though the cdo executable produced seems to do what I need it to (diffn, sinfo, etc.). I'm not sure what Importcmsaf.c does and why it reacted to this when all the other ones didn't...since they all include cdi.h...

Happy new year, Matthew!

yaxt is a MPI-based library, which is used for the parallel IO-mode of CDI (the IO backend of CDO). CDO does not make any use of MPI, so you do not need to compile it with the MPI-compiler-wrapper mpicc. If you do, then CDI is compiled with the same compiler and MPI is switched on and yaxt is needed. My recommendation is to use the plain C compiler instead of MPI-wrapper.

best wishes
ralf

Ralf,

Well, the issue for me is that I compile HDF5 in parallel, so I need to use mpicc, etc. That also means netCDF is compiled with mpicc. Thus any attempt to link to netCDF (which I assume CDO does) requires that the MPI libraries be linked in...and compiling CDO with mpicc is the best way to do that. That's why I think the #ifdef USE_MPI in cdi.h is an okay solution since that means unless you pass --enable-mpi to the libcdi configure, it won't try to build for MPI.

Matt

Matthew Thompson wrote:

Ralf,

Well, the issue for me is that I compile HDF5 in parallel, so I need to use mpicc, etc. That also means netCDF is compiled with mpicc. Thus any attempt to link to netCDF (which I assume CDO does) requires that the MPI libraries be linked in...and compiling CDO with mpicc is the best way to do that. That's why I think the #ifdef USE_MPI in cdi.h is an okay solution since that means unless you pass --enable-mpi to the libcdi configure, it won't try to build for MPI.

Matt

good solution, AFAIK, it's already included in the current dev tree. Thanks!