modelica-3rdparty / netcdf-datareader

Modelica library for interfacing netCDF files using different interpolation and extrapolation methods

NcDataReader2

Modelica library for interfacing netCDF files using different interpolation and extrapolation methods.

Build status

Library description

NcDataReader2 is a library of C functions to access data stored in netCDF files using different interpolation and extrapolation methods. The aim of this library is to provide access from simulation systems like Modelica to data sets like weather data or measured time rows. As such systems usually require strictly continuity of functions and their derivatives, smooth spline interpolation is included.

For more information and installation instructions please have look at the doc folder.

The original repository is hosted on Bitbucket by Jörg Rädler.

License

NcDataReader2 is released under the terms of the LGPL v2.

Development and contribution

• Jörg Rädler
• tbeu

You may report any issues with using the Issues button.

Contributions in shape of Pull Requests are always welcome.

netcdf-datareader's Issues

OpenModelica compatibility

I am not sure whether this should be filed here or with OpenModelica: The examples are only partly working with OpenModelica.

On Windows 10 64 bit with omc v1.11 32bit:
all three examples fail with the error message:

NcDataReader2/Resources/Library/win32/ncDataReader2.lib(ncDataReader2.dir/Release/csa.obj):
.text[_csa_approximatepoint]+0xf2): undefined reference to _ftol2_sse

When I use a different compiler (Tools->Options->Simulation) I get a different message, but it still does not work.

On Xubuntu 16.04 64 bit with the latest omc nightly 64bit:
the simple example works,
the other two examples fail with

assert | debug | <p>ncDataReader2 | ERROR | 2 | netcdf | No such file or directory<br>
assert | info | <p>simulation terminated by an assertion at initialization</p>
stdout | error | <p>Simulation process failed. Exited with code 255.</p>

Update license

@jraedler In RWTH-EBC/AixLib#313 it was asked to use netCDF-DataReader in a Modelica package licensed under https://www.modelica.org/licenses/ModelicaLicense2, see for example,

package MyMoLic2Package
  AnLGPL2Package.Component useIt;
  annotation(uses(AnLGPL2Package));
end MyMoLic2Package;

To be on the safe side when it comes to distribution of compiled models (e.g., FMUs) we might need to relicense netCDF-DataReader under MPL. What do you think? Any objections? Did you use any LGPL licensed code?

minGW compatibility

I just encoutered an issue with the netCDF-DataReader within the BuildingSystems library using the minGW and minGW64 compiler.

The following error is written to dslog.txt

 
dsmodel.c: In function 'equations_16':
dsmodel.c:7209:47: warning: passing argument 1 of 'StringTemporaryDense' from incompatible pointer type [-Wincompatible-pointer-types]
          StringElement( StringTemporaryDense( &DYNX(DYNAuxStr_,2+DYNStrInit(did_)),
                                               ^
In file included from C:/Program Files (x86)/Dymola 2017 FD01/Source/matrixop.h:11:0,
                 from dsmodel.c:7:
C:/Program Files (x86)/Dymola 2017 FD01/Source/matrixop1.h:490:27: note: expected 'const char **' but argument is of type 'char **'
 DYMOLA_STATIC StringArray StringTemporaryDense(String*d,SizeType ndims,...);
                           ^~~~~~~~~~~~~~~~~~~~
Warning: corrupt .drectve at end of def file
Warning: corrupt .drectve at end of def file
...

it works perfectly using Visual Studio
dslog.txt

MSL version

This is just a question:
We started to use netCDF-DataReader as a library (instead of including the bits and pieces in our own library). Our library uses MSL version 3.2.2, but that is mostly because Dymola is loading that version by default. netCDF-DataReader is using 3.2.1, and every time we open the two libraries together, Dymola wants to run an update script. That script does not really change anything, but it is annoying.
Would it be possible to also use MSL 3.2.2 in netCDF-DataReader or was the version on purpose? Does using one or the other version have any advantages?

Alternatively, I asked a question on stackoverflow, how to suppress the upgrade script dialog:
http://stackoverflow.com/questions/42343160/modelica-libraries-use-different-msl-version

libnetcdf.so error

Hey i just read the information in this issue here. It seems like i have a similar problem. Im trying to run a FMU which uses the netCDF-DataReader. The import informations seems to be:

• program for FMU compilation: Dymola
• System: Linux 64 bit (Red Hat)
• Compiler: gcc (I think that it is the standard compiler for dymola on linux, unfortunaly i can't find out because i only have limited acces to the system) but if it's gcc its version 4.8.5

The FMU get's compiled but when i'm trying to run it with PyFMI i get an arror because of missing libnetcdf.so. The FMUChecker says:

[FATAL][FMICAPI] Could not load the DLL: libnetcdf.so.7: cannot open shared object file: No such file or directory
[FATAL][FMUCHK] Could not create the DLL loading mechanism(C-API) for ME.
[INFO][FMUCHK] Model identifier for CoSimulation: OFHBuildingHiL_OFH_OFH_0HydraulikSQL
[INFO][FMILIB] Loading 'linux64' binary with 'default' platform types
[FATAL][FMICAPI] Could not load the DLL: libnetcdf.so.7: cannot open shared object file: No such file or directory
[FATAL][FMUCHK] Could not create the DLL loading mechanism(C-API) for CoSimulation.

So i searched the internet for a libnetcdf.so for linux 64 bit and i found one here.
But after inserting them into Library/linux64 i still get the error and nothing changed. Is there anything i'm missing? I would also try to compile it myself, but havn't done this before and i'm not even sure if it would help ... Thanks for any help ;)

EDIT: Ok i think i understand the problem now, the compilation seems to be finde, but the DLL is missing on the system where i want to run the simulation, right? So i just copied the dll files to the usage system and ran the fmuchecker again. Now i get the message:
[FATAL][FMICAPI] Could not load the DLL: /usr/lib/libnetcdf.so.7: file too short
[FATAL][FMUCHK] Could not create the DLL loading mechanism(C-API) for ME.
[INFO][FMUCHK] Model identifier for CoSimulation: OFHBuildingHiL_OFH_OFH_0HydraulikSQL
[INFO][FMILIB] Loading 'linux64' binary with 'default' platform types
[FATAL][FMICAPI] Could not load the DLL: /usr/lib/libnetcdf.so.7: file too short
[FATAL][FMUCHK] Could not create the DLL loading mechanism(C-API) for CoSimulation.
So i don't think the problem is due to netCDF Reader, but if you want to provide help i would appreciate that

New release?

@jraedler Do you think we should release a new version?

Compilation error when compiling in JModelica.org

I get the following error when trying to compile the 'Simple example' in the NcDataReader2. Any suggestions on how to resolve this?

CcodeCompilationError                     Traceback (most recent call last)
<ipython-input-3-dad1ff26f4d2> in <module>()
----> 1 netCD = compile_fmu('NcDataReader2.Examples.Simple',r'H:\Modelica\Modelica Libraries\NcDataReader2')
      2 model = load_fmu(netCD)

C:\JModelica.org-2.1\install\Python\pymodelica\compiler.pyc in compile_fmu(class_name, file_name, compiler, target, version, platform, compiler_options, compile_to, compiler_log_level, separate_process, jvm_args)
    139     return _compile_unit(class_name, file_name, compiler, target, version,
    140                 platform, compiler_options, compile_to, compiler_log_level,
--> 141                 separate_process, jvm_args)       
    142 
    143 def compile_fmux(class_name, file_name=[], compiler='auto', compiler_options={}, 

C:\JModelica.org-2.1\install\Python\pymodelica\compiler.pyc in _compile_unit(class_name, file_name, compiler, target, version, platform, compiler_options, compile_to, compiler_log_level, separate_process, jvm_args)
    246     else:
    247         return compile_separate_process(class_name, file_name, compiler, target, version, platform, 
--> 248                                         compiler_options, compile_to, compiler_log_level, jvm_args)
    249 
    250 def compile_separate_process(class_name, file_name=[], compiler='auto', target='me', version='1.0', 

C:\JModelica.org-2.1\install\Python\pymodelica\compiler.pyc in compile_separate_process(class_name, file_name, compiler, target, version, platform, compiler_options, compile_to, compiler_log_level, jvm_args)
    360         process.wait();
    361     finally:
--> 362         return log.end();
    363 
    364 def _gen_compiler_options(compiler_options):

C:\JModelica.org-2.1\install\Python\pymodelica\compiler_logging.pyc in end(self)
    321 
    322         if exception.kind == 'org.jmodelica.util.exceptions.CcodeCompilationException':
--> 323             raise CcodeCompilationError(exception.message)
    324 
    325         if exception.kind == 'org.jmodelica.util.exceptions.PackingFailedException':

Additional files in the Resources folder

Unfortunately, the delivered *.dll files are not sufficient for some of our computers. We would like to ask, if following files can be added in this repo:

• hdf5.dll
• hdf5_hl.dll
• libcurl.dll
• zlib.dll
• netcdf.dll

The files come with the installation of netCDF ( http://www.unidata.ucar.edu/downloads/netcdf/index.jsp ), tested with v. 4.4.1.

conflicts

The .travis.yml file contains some strange characters (lines 28-56) and I cannot pull the latest master anymore.

Annotation with relative Include/Library directories

We are aiming to use the NcDataReader2 library in the AixLib (RWTH-EBC/AixLib#313). Since we found some improvement regarding the annotation to include external files, it is not necessary anylonger to copy the files into the working directory.
The annotation is like:
Include = "#include <ncDataReaderEA.h>", IncludeDirectory = "modelica://NcDataReader2/Resources/Include",
Especially the ...Directory commands are not implemented in the current master.
Similar, but with focus on 32 bit, is done in BuildingSystems: https://github.com/UdK-VPT/BuildingSystems/blob/master/BuildingSystems/Utilities/NcDataReader2/ncEasyGet1D.mo

Additionally, due to the 32/64 bit folder structure, the correct files will be chosen.
This was tested with Dymola 2017.

We could also create our own solution like in BuildingSystems. But in my opinion it is better to keep the dependency to this repo in order to stay up to date.

Is it okay, if we fork a branch and make a PR afterwards?