Activity for Daniel Neumann
-
Daniel Neumann posted a comment on discussion Open Discussion
Cool. Thanks.
-
-
Cool. Thanks!
-
Thanks, Charlie, for the rapid reply. Unfortunately, there is no nco.html in the doc folder of the tar ball (all other html files are there). Building the html documentation via make nco.html (as documented in some manual) yields make: *** No rule to make target 'nco.html'. Stop.
-
Hi Charlie, is it possible to download the HTML documentations of previous NCO version? I tried to get the documentation of the current stable release (4.7.9) but only found the doc of the beta 4.8.0. I wanted to add the HTML page to our NCO installation directory to have an offline version of the documentation fitting to the installed version. I have also an old NCO version installed, in which the --no_abc switch was not introduced in order to be able to run old scripts without having to modify...
-
Actually, I am confused about the usage of ram_delete(). I understood the definition ram_delete() Deletes a RAM variable or an attribute as delete a RAM variable or delete any attribute (not a newly created attribute). But global@vert_coord.ram_delete(); yields ncap2: WARNING utl_cls::fnd(): ram_delete unable to find variable: global@vert_coord
-
Hi Henry, Thanks for the quick reply. you need to replace the "." with @ the "." in ncap2 is used to specify a ncap2 method. e.g SURF_ugN_NOX@coordinates="abc"; or 'global@'SURF_ugN_NOX.coordinates'.ram_delete(); To use the "." in a name you need to quote the var/att name with "'" as I have done above. Unfortunately, both solutions do not work (global@SURF_ugN_NOX@coordinates and 'global@'SURF_ugN_NOX.coordinates'; see bottom of this post). Probably, I explained my issue wrongly. This is my cdl file...
-
Hi Henry, Thanks for the quick reply. I just realized that I mixed something up. I wanted to remove an attribute. But ram_delete() is for deleting variables. I meant --VAR@ATT; instead of VAR@ATT.ram_delete(). Just in case someone else reads my question and is confused ... . you need to replace the "." with @ the "." in ncap2 is used to specify a ncap2 method. e.g SURF_ugN_NOX@coordinates="abc"; or 'global@'SURF_ugN_NOX.coordinates'.ram_delete(); To use the "." in a name you need to quote the var/att...
-
Hey, Happy new year! Some global attributes of a netCDF I am working with contain a dot in their name. E.g.: SURF_ugN_NOX.coordinates="abc"; I would like to work with these global attributes in a ncap2 scripts. But none of these solutions work: global@SURF_ugN_NOX.coordinates.ram_delete(); global@`SURF_ugN_NOX.coordinates`.ram_delete(); global@"SURF_ugN_NOX.coordinates".ram_delete(); global@'SURF_ugN_NOX.coordinates'.ram_delete(); Does there exist a workaround? Or should I rename these attributes...
-
Here it is (of the NCO version of the Ubuntu 18.04 package repository): NCO netCDF Operators version 4.7.2 built by buildd on lcy01-amd64-004 at Jan 25 2018 19:04:04 ncks version 4.7.2 Linked to netCDF library version 4.6.0 compiled Feb 9 2018 19:21:24 ... Build-engine: Autoconf Mnemonic: Sapiens Configuration Option: Active? Meaning or Reference: Check _FillValue Yes http://nco.sf.net/nco.html#mss_val DAP support Yes http://nco.sf.net/nco.html#dap Debugging: Custom No Pedantic, bounds checking (slowest...
-
Ubuntu probably does not use the--enable_*_custom switches, Sounds reasonable. I will probably not change the source code to ncap_lex.l, because many users are stuck with older versions of flex. I fully understand.
-
I have to correct my previous posts with respect to the compiler-depency of the issue. Sorry for the confusion. I did not realize that ncap_lex.c is auto-generated by flex. The issue seems to be caused by flex. I installed the most recent flex version (2.6.4) on my Ubuntu 16.04 mashine and, now, get the same issue as on my Ubuntu 18.04 mashine. Summary of observation Ubuntu 16.04 with flex 2.6.0 (default version) and gcc 5.4.0 => no issue Ubuntu 18.04 with flex 2.6.4 (default version) and gcc 7.3.0...
-
I have to correct my previous posts with respect to the compiler-depency of the issue. Sorry for the confusion. I did not realize that ncap_lex.c is auto-generated by flex. The issue seems to be caused by flex. I installed the most recent flex version (2.6.4) on my Ubuntu 16.04 mashine and, now, get the same issue as on my Ubuntu 18.04 mashine. Summary of observation Ubuntu 16.04 with flex 2.6.0 (default version) and gcc 5.4.0 => no issue Ubuntu 18.04 with flex 2.6.4 (default version) and gcc 7.3.0...
-
I just realized that in my Ubuntu 16.04 test case there are some more differences in the code. I will have a more detailed look into it tomorrow ... .
-
I just tested the compilation of NCO 4.7.6 with my old Ubuntu 16.04 (same configure call as before). No issues occured. Summary: GCC 5.4.0 of Ubuntu 16.04 compiles NCO 4.7.6 fine. GCC 7.3.0 of Ubuntu 18.04 throws an error with respect to the conflicting type when it compiles NCO 4.7.6.
-
I realized (according to the comments in ncap_lex.c) that the type declaration seems to be quite controversal between different flavours and operating systems :-D . The problematic declaration occurs only if configure is called with --enable-optimize-custom or --enable-debug-custom. Probably, the error was not thrown for the official Ubuntu 18.04 builds because they were performed with neither of these flags?
-
I realized (according to the comments in ncap_lex.c) that the type declaration seems to be quite controversal between different flavours and operating systems :-D . The problematic declaration occurs only if configure is called with --enable-optimize-custom or --enable-debug-custom. Probably, the error was not thrown for the official Ubuntu 18.04 builds because they were performed with neither of these flags?
-
Following the error and the notes, I replaced yy_size_t in all declarations/definitions of yyget_leng by int. Now, it compiled fine. I will run the tests later and see if some new issues arise from this change.
-
Hi Charlie, Thanks for the reply. You can also try this: cd ~/nco;make OMP=Y OPTS=D UDUNITS=Y UBUNTU_440=Y allinone allinone does not seem to be a target in the Makefile in the root directory. I set environment variables for udunits2 etc. (UDUNITS_INC, GSL_INC, NETCDF_ROOT, ...) and ran cd bld; make OMP=Y OPTS=D UDUNITS=Y UBUNTU_440=Y allinone Then I get some reference-not-found errors with respect to GSL and BLAS. So, probably I forget an environment variable ... . What is your compile command?...
-
Hm ... . I rebuild NCO v 4.7.2 and now get the same error as for 4.7.6. However, the NCO version in the ubuntu package repository is also 4.7.2. I use my own netCDF (4.6.1), HDF5 (1.8.21), udunits (2.2.26) and GSL (2.5). But I also tried the GSL from the ubuntu package repository (2.3) with no difference.
-
Hi, I am compiling NCO on my newly set-up Ubuntu 18.04. When I compile version 4.7.6 the following error is thrown: ncap_lex.c:194:20: error: conflicting types for ‘nco_yyget_leng’ All required packages are installed (flex, bison, curl, ...). NCO 4.7.2 compiles fine. Some test in 4.7.2 produce errors but I am looking into that later. Cheers, Daniel
-
Is there a best practice for converting time to double on mulitple files? I would do it via a bash script. Something like ncap2 -s 'time=time.double() *.nc won't work. -- Correct me, if I am wrong. 1 2 3 4 5#!/bin/bash for iFile in `ls *.nc`; do ncap2 -O -s 'time=time.double()' ${iFile} d_${iFile} done
-
Thanks for accepting my pull request. Charlie, this ticket can be closed.
-
Thanks for adding the fix. Strange ... . On my system, the files are scripts. The binaries are located in src/nco/.libs . I attached a screenshot, in which the first five lines of the ncatted and ncbo scripts in src/nco are printed. If there are systems like yours and mine, which handle this situation differently, the test head -1 $MY_BIN_DIR/ncatted makes sense. Either the binaries are already located in src/nco (and we link ncdiff, nces and ncrcat to them) or they are scripts, which then call binaries...
-
In bm/NCO_bm.pm there are the following lines: # Create symbolic links for testing # If libtool created shared libraries, then point to real executables # in ../src/nco/.libs my $dotlib = ''; $dotlib = ".libs/lt-" if `head -1 $MY_BIN_DIR/ncatted` =~ m/sh/; $sym_link{ncdiff}=$dotlib . "ncbo"; $sym_link{nces}=$dotlib . "ncra"; $sym_link{ncrcat}=$dotlib . "ncra"; foreach(keys %sym_link){ system("cd $MY_BIN_DIR && ln -s -f $sym_link{$_} $_ || (/bin/rm -f $_ && ln -s -f $sym_link{$_} $_)"); } Is there...
-
Pull request with a fix for the in_4c.nc is sent.
-
I will have a look, if I can prepare a fix. Would it be enough to test, whether the lt-* binaries exist and, if not, create a link to the "normal" binaries (those in the folder above). Or do the lt-* files like lt-ncbo different from the files without 'lt-' like ncbo?
-
Hi Charlie, Thanks for the fast feedback. I am quite impressed what you do on your own (including answering questions here). And thanks for your make test output. My 'best case' is close to it :-) . I will see whether I can fix the issue regarding the in_4c.nc file. Daniel
-
When I run "make test" on OpenSUSE 42.2, the "lt-" files in "src/nco/.libs" are not created. The commands "ncdiff", "nces", and "ncrcat" in "src/nco" are linked to lt-ncbo and lt-ncra, which do not exist. A a result some tests fail (1x ncrcat test, 1x ncra, 3x ncb, 1x ncflint). When I link "src/nco/ncbo" to "src/nco/.libs/lt-ncbo" and do the same for ncra, the tests paths fine (except those mentioned here: https://sourceforge.net/p/nco/discussion/9830/thread/b96a91e6/). When I do "make install",...
-
The test file in_4c.nc, which is used for running some of the NCO tests, is not always generated. When I build NCO v4.6.7 on my local machine with xUbuntu 16.04, the file is generated. When I build NCO v4.6.8-alpha01 on my local mchine with xUbtuntu 16.04, the file is not generated. When I build NCO v4.6.7 for my institutions software server with my xUbuntu 16.04 (but different netCDF, HDF, GSL, ... libraries; same versions but different locations), the file is not generated. As a result, three of...
-
configure: if GSL_LIB is set, GSL is not properly included
-
The file in_4c.nc, which is used for running some of the NCO tests, is not always generated. When I build NCO v4.6.7 on my local machine with xUbuntu 16.04, the file is generated. When I build NCO v4.6.8-alpha01 on my local mchine with xUbtuntu 16.04, the file is not generated. When I build NCO v4.6.7 for my institutions software server with my xUbuntu 16.04 (but different netCDF, HDF, GSL, ... libraries; same versions but different locations), the file is not generated. As a result, three of the...
-
I tested the latest NCO version available at GitHub. It configures and compiles fine.
-
Ahhhh. Ok. I got it. I have to fork the NCO project first. Then it works fine. Thanks for the help.
-
It seems that I do not have permission to submit files to the github NCO repository. Into which branch should I submit the modified files?
-
I forgot: nco version: 4.6.7 OS: xubuntu 16.04 and OpenSUSE 42.2
-
NCO test suite: $nco_D_flg not "-O" => ncks test #19 hangs
-
I just included the first part if test -d "${UDUNITS2_PATH}/`basename $libdir`"; then LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/`basename $libdir`" else LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/lib" fi and testet in on OpenSUSE 42.2 and xUbuntu 16.04. There are no problems on both systems and I don't see a reasonable situation in which this approach fails. I will try to commit it to GitHub. Never tried it before ... .
-
It works fine on SUSE and I will test it on ubuntu later on.
-
It works fine on SUSE and I will test it on ubuntu later on.
-
I don't have much experiance with autoconf. However, I just read a bit about this problem. As far as I understand it, there is no straightforward solution. Some systems seem to have a environment variable $CONFIG_SITE, which points to ascript which helps finding out whether we need /lib or /lib64. See e.g. https://stackoverflow.com/q/9247769/4612235 . There seem to be also different philosophies (to what extend should the configure script do the work of the user / decide for the user). My (maybe...
-
I don't have much experiance with autoconf. However, I just read a bit about this problem. As far as I understand it, there is no straightforward solution. Some systems seem to have a environment variable $CONFIG_SITE, which points to ascript which helps finding out whether we need /lib or /lib64. See e.g. https://stackoverflow.com/q/9247769/4612235 . There seem to be also different philosophies (to what extend should the configure script do the work of the user / decide for the user). My (maybe...
-
I am not sure whether it is a good idea to test whether we compile for SUSE or not. If we cross-compile for 32-bit or compile on a 32-bit system, we probably need the .../lib dir. The variable $libdir should contain the NCO library path. If --libdir is not specified in the ,/configure call, then: it is set to ${exec_prefix}/lib64 on my SUSE system (via a script to which $CONFIG_SITE points) it is set to ${exec_prefix}/lib on my Ubuntu system. Even when --libdir was specified by the user we could...
-
I am not sure whether it is a good idea to test whether we compile for SUSE or not. If we cross-compile for 32-bit or compile on a 32-bit system, we probably need the .../lib dir. The variable $libdir should contain the NCO library path. If --libdir is not specified in the ,/configure call, then: it is set to ${exec_prefix}/lib64 on my SUSE system (via a script to which $CONFIG_SITE points) it is set to ${exec_prefix}/lib on my Ubuntu system. Even when --libdir was specified by the user we can assume...
-
Hi Charlie, Thanks for the fast reply.
-
I don't have much experiance with autoconf. However, I just read a bit about this problem. As far as I understand it, there is no straightforward solution. Some systems seem to have a environment variable $CONFIG_SITE, which points to ascript which helps finding out whether we need /lib or /lib64. See e.g. https://stackoverflow.com/q/9247769/4612235 . There seem to be also different philosophies (to what extend should the configure script do the work of the user / decide for the user). My (maybe...
-
Dear NCO Development Team, I just compiled nco 4.6.7. Two tests unexpectedly fail. I am not sure if there is a test.log file, in which I can find details on the failed test. The configure and compile process went fine. The operating system is xubuntu 16.04. Netcdf 4.4.1.1, hdf5 1.8.18 and udunits 2.2.24 are installed. The errors are ncap2 test 13: Run script to to test casting, hyperslabbing and intrinsic functions............... FAILED! ERR: FAILURE in ncap2 failure: Run script to to test casting,...
-
Dear NCO Development Team, I just compiled nco 4.6.7 a two tests unexpectedly fail. I am not sure if there is a test.log file, in which I can find details on the failed test. The configure and compile process went fine. The operating system is xubuntu 16.04. Netcdf 4.4.1.1, hdf5 1.8.18 and udunits 2.2.24 are installed. The errors are ncap2 test 13: Run script to to test casting, hyperslabbing and intrinsic functions............... FAILED! ERR: FAILURE in ncap2 failure: Run script to to test casting,...
-
NCO configure does not recognize alternative UDUNITS2 library path
-
Hi, I recently had the same error. It occured because ncgen was not found during...
-
I know that the post above is quite old and my answer will not help Jerry but maybe...
1