Runtime error on MacOSx with nlohmann::json, out_of_range exception: key 'NUOPC' not found #311

natalie-perlin · 2024-10-22T16:45:44Z

natalie-perlin
Oct 22, 2024

Requirements

Reviewed NUOPC Reference Manual
Searched GitHub Discussions

Affiliation(s)

NOAA EPIC

ESMF Version

v8.6.0

Issue

ESMF v8.6.0 is built on MacOS as a part of a software stack for the ufs_weather model; it is
built with clang/clang++ v14.0.0, gfortran v12.3, openmpi/1.4.6.
All the exhaustive multi-processor unit and system tests (14K+) pass successfully.
Runtime error is as follows:

 MPI Library = Open MPI v4.1.6, package: Open MPI [email protected] Distribution, ident: 4.1.6, repo rev: v4.1.6, Sep 30, 2023 
MPI Version = 3.1
libc++abi: terminating with uncaught exception of type nlohmann::json_abi_v3_11_2::detail::out_of_range: [json.exception.out_of_range.403] key 'NUOPC' not found

There is another GitHub discussion on the issues with running ufs_weather_model on MacOS, which boil down to the same error:
ufs-community/ufs-weather-model#2371

Any further leads on how to diagnose the exact issue and solve the problem is extremely valuable!.. This appears to be stuck for few months.

Autotag

@danrosen25

danrosen25 · 2024-10-22T17:57:48Z

danrosen25
Oct 22, 2024
Maintainer

Hi @natalie-perlin
I'm including @billsacks because he has worked on the json framework and nlohmann namespace requirements on a Mac in the past. We need a little more information before we can dig into this issue.

What version of MacOS are you running?
What processor do you have in your machine (M2, M3, etc)?
Have you installed XCode, the XCode Command Line tools, and accepted the ULA?

I think the issue may have to do with the libc++abi library and namespaces.

If there are any WARNINGs or ERRORs in the PET*ESMF_LogFile files they may help.

0 replies

natalie-perlin · 2024-10-23T14:03:08Z

natalie-perlin
Oct 23, 2024
Author

@danrosen25 @billsacks
MacOS Monterey (x86_64), MacOS Sonoma (M2)
Yes, XCode, Command Line tools installed

SDKROOT set,
libc++, libc++abi llvm built additionally (in attempt to resolve the issue)
nlohmann-json library built additionally (in attempt to resolve the issue)

No any warnings were issued. All PET files were identical to:

20241022 094408.475 INFO             PET0 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
20241022 094408.476 INFO             PET0 !!! THE ESMF_LOG IS SET TO OUTPUT ALL LOG MESSAGES !!!
20241022 094408.476 INFO             PET0 !!!     THIS MAY CAUSE SLOWDOWN IN PERFORMANCE     !!!
20241022 094408.476 INFO             PET0 !!! FOR PRODUCTION RUNS, USE:                      !!!
20241022 094408.476 INFO             PET0 !!!                   ESMF_LOGKIND_Multi_On_Error  !!!
20241022 094408.476 INFO             PET0 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
20241022 094408.476 INFO             PET0 Running with ESMF Version   : 8.6.0
20241022 094408.476 INFO             PET0 ESMF library build date/time: "Oct 22 2024" "06:51:44"
20241022 094408.476 INFO             PET0 ESMF library build location : /Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0
20241022 094408.476 INFO             PET0 ESMF_COMM                   : openmpi
20241022 094408.476 INFO             PET0 ESMF_MOAB                   : enabled
20241022 094408.476 INFO             PET0 ESMF_LAPACK                 : enabled
20241022 094408.476 INFO             PET0 ESMF_NETCDF                 : disabled
20241022 094408.476 INFO             PET0 ESMF_PNETCDF                : disabled
20241022 094408.476 INFO             PET0 ESMF_PIO                    : disabled
20241022 094408.476 INFO             PET0 ESMF_YAMLCPP                : enabled

0 replies

danrosen25 · 2024-10-23T16:57:21Z

danrosen25
Oct 23, 2024
Maintainer

Thanks @natalie-perlin
We're not sure if this is an ESMF issue. We think it's related to which linker gets selected during the linking step in CMake.
Can you you turn on VERBOSE=1 during the make step so that we can see the linking call for the UFS executable?

Then we can also try adding the following to the CMakeLists.txt for UFS. Probably best before the project call.
set(CMAKE_LINKER_TYPE "SYSTEM")

8 replies

SamuelTrahanNOAA Oct 23, 2024

The "undefined reference to main" means you aren't linking against the Fortran libraries. They provide the C-style main wrapper around the Fortran program block. Using the Fortran linker is an easy way to get the Fortran libraries. Without that, you'll need to find the right linker flags to get gfortran's libraries. (C++ also has libraries you'll need at linker time.) I'm sure there's a way to tell cmake to figure out the right libraries.

I'm seeing the word "exceptions" but not what sort of exceptions. Passing C++ exceptions through another language's call stack won't work, in general. Some compilers may support it, but it isn't part of any standard. A mix of two different compilers certainly won't support it.

billsacks Oct 23, 2024
Maintainer

The "undefined reference to main" means you aren't linking against the Fortran libraries. They provide the C-style main wrapper around the Fortran program block. Using the Fortran linker is an easy way to get the Fortran libraries. Without that, you'll need to find the right linker flags to get gfortran's libraries. (C++ also has libraries you'll need at linker time.) I'm sure there's a way to tell cmake to figure out the right libraries.

The simple example I put together demonstrates how this inter-language stuff can work with CMake: CMake does seem able to find the needed libraries in this case with a C++ linker, at least with some compilers:

https://github.com/billsacks/esmfprojects-test_cxx_fortran_exceptions_with_cmake/blob/main/CMakeLists.txt

The ESMF build configurations also determine the needed libraries, at least to pass all of the ESMF tests. So another way to get these libraries is to use what's available from the esmf.mk file.

I'm seeing the word "exceptions" but not what sort of exceptions. Passing C++ exceptions through another language's call stack won't work, in general. Some compilers may support it, but it isn't part of any standard. A mix of two different compilers certainly won't support it.

Yes, this is referring to C++ exceptions. The issue isn't passing C++ exceptions up through Fortran, but simply catching C++ exceptions in C++ code. In our ESMF testing, the only way we've been able to reliably get C++ exceptions caught from within other C++ code, on a Mac using gfortran+clang, is by using clang++ as the linker. In theory it seems like this should work by specifying the right linker flags to pick up the needed C++ libraries using a Fortran linker, but we couldn't get this to work... I forget the details but it may have been that the Mac-provided clang C++ libraries were buried somewhere that we couldn't easily find?? That said, I was doing this without much experience in this area, so it may be that I just didn't know where to look (though I did spend a while digging, if I remember right). If anyone else has been able to get this to work - i.e., using a Fortran linker with the necessary linker flags for C++ with clang on a Mac - I'd be interested to hear what you've done.

natalie-perlin Oct 31, 2024
Author

@billsacks -
Testing the functionality of the code on a Mac (x86_64, Monterey), I've got the output prompt as shown below. Is it as expected?

[Natalie@Mac:~/esmfprojects-test_cxx_fortran_exceptions_with_cmake]$ mpirun -np 4 ./testprog 
Hello from processor            3
Hello from processor            0
WJS: caught error!
Hello from processor            1
WJS: caught error!
Hello from processor            2
WJS: caught error!
WJS: caught error!
1.0000  2.0000  3.0000  4.0000  5.0000
1.0000  2.0000  3.0000  4.0000  5.0000
WJS: caught error!
1.0000  2.0000  3.0000  4.0000  5.0000
WJS: caught error!
2.0000  3.0000  4.0000  5.0000  6.0000
1.0000  2.0000  3.0000  4.0000  5.0000
WJS: caught error!
2.0000  3.0000  4.0000  5.0000  6.0000
WJS: caught error!
WJS: caught error!
3.0000  4.0000  5.0000  6.0000  7.0000
3.0000  4.0000  5.0000  6.0000  7.0000
WJS: caught error!
2.0000  3.0000  4.0000  5.0000  6.0000
WJS: caught error!
3.0000  4.0000  5.0000  6.0000  7.0000
2.0000  3.0000  4.0000  5.0000  6.0000
WJS: caught error!
3.0000  4.0000  5.0000  6.0000  7.0000

billsacks Oct 31, 2024
Maintainer

Yes, that looks correct. Sorry that the expected output is poorly documented. The key part is that it actually catches the exception rather than aborting with an uncaught exception.

natalie-perlin Oct 31, 2024
Author

@danrosen25

From the ufs_model build, the linking step (kinda long...)

/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/openmpi-4.1.6-vygxndf/bin/mpifort -L/usr/local/opt/curl/lib -L/usr/local/opt/openssl@3/lib -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/llvm-openmp-16.0.0-dlw4guw/lib -lomp -Wl,-rpath,/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/llvm-openmp-16.0.0-dlw4guw/lib -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/jasper-2.0.32-6czmzxu/lib -ljasper -Wl,-rpath,/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/jasper-2.0.32-6czmzxu/lib -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/libpng-1.6.37-xhqhm5f/lib -lpng -Wl,-rpath,/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/libpng-1.6.37-xhqhm5f/lib -I/usr/local/include -ggdb -fbacktrace -cpp -fcray-pointer -ffree-line-length-none -fno-range-check -O2 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk CMakeFiles/ufs_model.dir/driver/UFS.F90.o -o ufs_model libufs.a /Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/lib/libO/Darwin.gfortranclang.64.openmpi.default/libesmf.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/w3emc-2.10.0-h623r4g/lib/libw3emc_d.a FV3/libfv3atm.a stochastic_physics/libstochastic_physics.a FV3/atmos_cubed_sphere/libfv3.a /Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/lib/libO/Darwin.gfortranclang.64.openmpi.default/libesmf.a -Wl,-rpath,/Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/lib/libO/Darwin.gfortranclang.64.openmpi.default -L/Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/lib/libO/Darwin.gfortranclang.64.openmpi.default -L/Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/lib/libO/Darwin.gfortranclang.64.openmpi.default -L/usr/local/Cellar/gcc@12/12.4.0/bin/../lib/gcc/12/gcc/x86_64-apple-darwin21/12/../../../ -L./ -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/openmpi-4.1.6-vygxndf/lib -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/libevent-2.1.12-wcvodws/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -lm -lc++ -lgfortran -m64 -mcmodel=small -pthread /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/fms-2023.04-qlhudl5/lib/libfms_r4.a FV3/ccpp/libfv3ccpp.a FV3/ccpp/framework/src/libccpp_framework.a FV3/ccpp/physics/libccpp_physics.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/w3emc-2.10.0-h623r4g/lib/libw3emc_d.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/sp-2.5.0-hcgtob6/lib/libsp_d.a FV3/upp/sorc/ncep_post.fd/libupp.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/crtm-2.4.0.1-msaygjr/lib/libcrtm.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/netcdf-fortran-4.6.1-6ohynnt/lib/libnetcdff.dylib -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/netcdf-fortran-4.6.1-6ohynnt/lib -lnetcdff -lnetcdf -lnetcdf -lm /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/netcdf-c-4.9.2-csmw5ti/lib/libnetcdf.dylib -L/Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/netcdf-c-4.9.2-csmw5ti/lib -lnetcdf /usr/local/Cellar/gcc@12/12.4.0/lib/gcc/12/libgomp.dylib /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/g2-3.5.1-l5nigt3/lib/libg2_4.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/libpng-1.6.37-xhqhm5f/lib/libpng.dylib /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/zlib-1.2.13-kuxt6lg/lib/libz.a zxu/lib/libjasper.dylib /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/libjpeg-turbo-2.1.0-mxptypc/lib/libjpeg.dylib /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/w3emc-2.10.0-h623r4g/lib/libw3emc_4.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/bacio-2.4.1-ym4jkzz/lib/libbacio_4.a /Users/Natalie/spack-stack/spack-stack-1.6.0/envs/ufs-srw-env2/install/apple-clang/14.0.0/g2tmpl-1.13.0-r3xe3qe/lib/libg2tmpl.a

danrosen25 · 2024-10-23T22:43:54Z

danrosen25
Oct 23, 2024
Maintainer

@natalie-perlin
Can you run the NUOPC prototypes on your system without a failure? https://github.com/esmf-org/nuopc-app-prototypes
In order to run the ESMX prototypes you'll need to install PyYAML, which you can do using pip.

1 reply

natalie-perlin Oct 31, 2024
Author

@danrosen25 -
I've ran nuopc-app-prototypes tests using the build of the existing build of the esmf 8.6.0 with clang/clang++ 14.0.0, gfortran 12.4.0, openmpi/1.4.6. All ESMX tests failed, a test/build log attached.
Pyyaml is installed.

== TEST SUMMARY START ==
PASS: AsyncIOBlockingProto
PASS: AsyncIONonblockingProto
PASS: AtmOcnConOptsProto
PASS: AtmOcnConProto
PASS: AtmOcnCplListProto
PASS: AtmOcnCplSetProto
PASS: AtmOcnFDSynoProto
PASS: AtmOcnIceSimpleImplicitProto
PASS: AtmOcnImplicitProto
PASS: AtmOcnLndProto
PASS: AtmOcnLogNoneProto
PASS: AtmOcnMedIngestFromConfigProto
PASS: AtmOcnMedIngestFromInternalProto
PASS: AtmOcnMedPetListProto
PASS: AtmOcnMedPetListTimescalesProto
PASS: AtmOcnMedPetListTimescalesSplitFastProto
PASS: AtmOcnMedProto
PASS: AtmOcnMirrorFieldsProto
PASS: AtmOcnPetListProto
PASS: AtmOcnProto
PASS: AtmOcnRtmTwoTimescalesProto
PASS: AtmOcnScalarProto
PASS: AtmOcnSelectProto
PASS: AtmOcnSelectProto
PASS: AtmOcnSelectProto
PASS: AtmOcnSimpleImplicitProto
PASS: AtmOcnTransferGridProto
PASS: AtmOcnTransferLocStreamProto
PASS: AtmOcnTransferMeshProto
PASS: CustomFieldDictionaryProto
PASS: DriverInDriverDataDepProto
PASS: DriverInDriverProto
PASS: DynPhyProto
PASS: ExternalDriverAPIProto
PASS: ExternalDriverAPIWeakCplDAProto
PASS: GenericMediatorProto
PASS: HierarchyProto
PASS: NamespaceProto
PASS: NestingMultipleProto
PASS: NestingSingleProto
PASS: NestingTelescopeMultipleProto
PASS: SingleModelProto
PASS: SingleModelOpenMPProto
PASS: SingleModelOpenMPUnawareProto
FAIL: ESMX_StartHereProto
FAIL: ESMX_StartHereProto-Step1
FAIL: ESMX_StartHereProto-Step2
FAIL: ESMX_StartHereProto-Step3
FAIL: ESMX_StartHereProto-Step4
FAIL: ESMX_SingleModelInFortranProto
FAIL: ESMX_SingleModelInFortranProto-DL
FAIL: ESMX_SingleModelInCProto-DL
FAIL: ESMX_AtmOcnProto
FAIL: ESMX_AtmOcnProto-Alt
FAIL: ESMX_AtmOcnFortranAndCProto
FAIL: ESMX_ExternalDriverAPIProto
== TEST SUMMARY STOP ==

Python 3.11.3

import yaml
yaml.version
'6.0'

The first error in the log is as follows:

/Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/bin/binO/Darwin.gfortranclang.64.openmpi.default/ESMX_Builder -v
ERROR: ESMX_BUILD_FILE is missing: esmxBuild.yaml
Usage: /Users/Natalie/spack-stack/spack-stack-1.6.0/esmf-8.6.0/install/bin/binO/Darwin.gfortranclang.64.openmpi.default/ESMX_Builder [OPTIONS ...] [ESMX_BUILD_FILE]

ESMX_BUILD_FILE
  ESMX build configuration file
  (default: esmxBuild.yaml)

Where do I find or how do I build esmxBuild.yaml? Any other comments how proceed with the testing?

NB: Due to using Mac with x86_64, I've done a couple of tweaks in in testProtos.sh to accommodate different paths for homebrew libomp installation or a separate module:

Tweak 1
BREW=$(brew --prefix)
export LDFLAGS=-L${BREW}/opt/libomp/lib
export CXXFLAGS=-I${BREW}/opt/libomp/include
export CFLAGS=-I${BREW}/opt/libomp/include
alternative Tweak 2, after loading an additional llvm-openmp/16.0.0 module

   export LDFLAGS="-L${llvm_openmp_ROOT}/lib -lomp -Wl,-rpath,${llvm_openmp_ROOT}/lib "
   export CXXFLAGS=" -I${llvm_openmp_ROOT}/include "
   export CFLAGS=" -I${llvm_openmp_ROOT}/include "

log.testProtos.001.txt

danrosen25 · 2024-10-31T20:40:51Z

danrosen25
Oct 31, 2024
Maintainer

I'm seeing a different error in this log.

CMake Error at /Users/Natalie/nuopc-app-prototypes/ESMX_AtmOcnProto/install/cmake/Lumo.cmake:54 (set_target_properties):
  The link interface of target "Lumo" contains:

    ESMF::ESMF

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  Driver/CMakeLists.txt:401 (include)


-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.
ESMX_Builder Failed: (cmake)
make: *** [install/bin/esmx_app] Error 255

The develop branch of the nuopc-app-prototypes isn't guaranteed to work with older versions of ESMF. You may need to download the specific version that matches your ESMF release: https://github.com/esmf-org/nuopc-app-prototypes/releases/tag/v8.6.0

1 reply

natalie-perlin Oct 31, 2024
Author

@danrosen25 -
Downloaded a release/8.6.0 branch/version.

$ git remote -v
origin	https://github.com/esmf-org/nuopc-app-prototypes.git 
git branch
* release/8.6.0

All tests pass successfully.

== TEST SUMMARY START ==
PASS: AsyncIOBlockingProto
PASS: AsyncIONonblockingProto
PASS: AtmOcnConOptsProto
PASS: AtmOcnConProto
PASS: AtmOcnCplListProto
PASS: AtmOcnCplSetProto
PASS: AtmOcnFDSynoProto
PASS: AtmOcnIceSimpleImplicitProto
PASS: AtmOcnImplicitProto
PASS: AtmOcnLndProto
PASS: AtmOcnLogNoneProto
PASS: AtmOcnMedIngestFromConfigProto
PASS: AtmOcnMedIngestFromInternalProto
PASS: AtmOcnMedPetListProto
PASS: AtmOcnMedPetListTimescalesProto
PASS: AtmOcnMedPetListTimescalesSplitFastProto
PASS: AtmOcnMedProto
PASS: AtmOcnMirrorFieldsProto
PASS: AtmOcnPetListProto
PASS: AtmOcnProto
PASS: AtmOcnRtmTwoTimescalesProto
PASS: AtmOcnScalarProto
PASS: AtmOcnSelectProto
PASS: AtmOcnSelectProto
PASS: AtmOcnSelectProto
PASS: AtmOcnSimpleImplicitProto
PASS: AtmOcnTransferGridProto
PASS: AtmOcnTransferLocStreamProto
PASS: AtmOcnTransferMeshProto
PASS: CustomFieldDictionaryProto
PASS: DriverInDriverDataDepProto
PASS: DriverInDriverProto
PASS: DynPhyProto
PASS: ExternalDriverAPIProto
PASS: ExternalDriverAPIWeakCplDAProto
PASS: GenericMediatorProto
PASS: HierarchyProto
PASS: NamespaceProto
PASS: NestingMultipleProto
PASS: NestingSingleProto
PASS: NestingTelescopeMultipleProto
PASS: SingleModelProto
PASS: SingleModelOpenMPProto
PASS: SingleModelOpenMPUnawareProto
PASS: ESMX_AtmOcnProto
PASS: ESMX_AtmOcnProto-Alt
PASS: ESMX_ExternalDriverAPIProto
== TEST SUMMARY STOP ==

Log attached:
log.testProtos.002.txt

natalie-perlin · 2024-11-01T13:08:31Z

natalie-perlin
Nov 1, 2024
Author

@billsacks @danrosen25 @SamuelTrahanNOAA

What seemed to help to build ufs_model and to run it SUCCESSFULLY(!) was to set LINKER_LANGUAGE to CXX instead of Fortran in CMakeLists.txt, i.e.:
set_target_properties(ufs_model PROPERTIES LINKER_LANGUAGE CXX)

The only one concern is the need to set linker to CXX for the code that is nearly entirely in Fortran (and a little C), just because of a library (even a few libraries) in CXX... Please correct me if I'm wrong!

Thank you for your help!

1 reply

SamuelTrahanNOAA Nov 1, 2024

If you link C++ code, you need the C++ libraries. ESMF is C++. What else is C++, I do not know. UFS has many models in it: ocean, wave, aerosol, atmosphere, and so on. It's a good bet that there's other C++ code in there.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Earth System Modeling Framework

Runtime error on MacOSx with nlohmann::json, out_of_range exception: key 'NUOPC' not found #311

{{title}}

Replies: 6 comments 11 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Earth System Modeling Framework

Runtime error on MacOSx with nlohmann::json, out_of_range exception: key 'NUOPC' not found #311

natalie-perlin Oct 22, 2024

Requirements

Affiliation(s)

ESMF Version

Issue

Autotag

Replies: 6 comments · 11 replies

danrosen25 Oct 22, 2024 Maintainer

natalie-perlin Oct 23, 2024 Author

danrosen25 Oct 23, 2024 Maintainer

SamuelTrahanNOAA Oct 23, 2024

billsacks Oct 23, 2024 Maintainer

natalie-perlin Oct 31, 2024 Author

billsacks Oct 31, 2024 Maintainer

natalie-perlin Oct 31, 2024 Author

danrosen25 Oct 23, 2024 Maintainer

natalie-perlin Oct 31, 2024 Author

danrosen25 Oct 31, 2024 Maintainer

natalie-perlin Oct 31, 2024 Author

natalie-perlin Nov 1, 2024 Author

SamuelTrahanNOAA Nov 1, 2024

natalie-perlin
Oct 22, 2024

Replies: 6 comments 11 replies

danrosen25
Oct 22, 2024
Maintainer

natalie-perlin
Oct 23, 2024
Author

danrosen25
Oct 23, 2024
Maintainer

billsacks Oct 23, 2024
Maintainer

natalie-perlin Oct 31, 2024
Author

billsacks Oct 31, 2024
Maintainer

natalie-perlin Oct 31, 2024
Author

danrosen25
Oct 23, 2024
Maintainer

natalie-perlin Oct 31, 2024
Author

danrosen25
Oct 31, 2024
Maintainer

natalie-perlin Oct 31, 2024
Author

natalie-perlin
Nov 1, 2024
Author