f90_demo crashes on macOS (Apple Silicon)

[ischoegl]

Problem description

The macOS F90 sample crashes on macOS (arm)

Steps to reproduce

Build cantera from source:

% scons build
% scons install
% cd path/to/samples/f90
% make

Edit: or simply run scons test-f90-demo

Behavior

Running the demo crashes:

% ./demo

 ********   Fortran 90 Test Program   ********
 Initial state properties:


Temperature:       1200.0     K
Pressure:         0.10132E+06 Pa
Density:          0.28921     kg/m3
Molar Enthalpy:   0.23514E+08 J/kmol
Molar Entropy:    0.20594E+06 J/kmol-K
Molar cp:          27056.     J/kmol-K


libc++abi: terminating with uncaught exception of type Cantera::CanteraError:
*******************************************************************************
CanteraError thrown by ThermoPhase::equilibrate:
Invalid solver specified: ''
*******************************************************************************


Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x101c576f7
#1  0x101c5671b
#2  0x1c49434a3
#3  0x1c492bedf
#4  0x1c486633f
#5  0x1c48e6b07
#6  0x1c48d6937
#7  0x1c47cc32f
#8  0x1c48e5ea3
#9  0x1c48e8c1b
#10  0x1c48e8bc7
zsh: abort      ./demo

System information

• Cantera version: 3.0.0a2
• OS: macOS (on M2)
• Python/MATLAB/other software versions: installation in conda environment, including gfortran

% cat cantera.conf
blas_lapack_libs = 'openblas'

Further:

(base) % conda activate cantera-dev
(cantera-dev) % g++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
(cantera-dev) % gfortran --version
GNU Fortran (Homebrew GCC 12.2.0) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(cantera-dev) % python --version
Python 3.10.5

Additional context

The same error occurs for SCons and make routes (after applying fix in #1378). The example works on Linux and Intel macOS.

On a separate note, F90 CMake throws an error when linking on Intel macOS (which is not an issue on Apple Silicon).

[speth]

I dug into this a bit, adding the following debugging outputs to ctthermo_equilibrate (in cantera_thermo.f90):

      write(*,*) "ctthermo_equilibrate:"
      write(*,*) "    XY = '", XY, "' len = ", len(XY)
      write(*,*) "    trim(XY) = '", trim(XY), "', len = ", len(trim(XY))
      write(*,*) "    solver_ = '", solver_, "' len = ", len(solver_)
      write(*,*) "    trim(solver_) = '", trim(solver_), "', len = ", len(trim(solver_))

and th_equil_ in fct.cpp:

            writelog("th_equil_:\n");
            writelog("    XY = '{}' len = {}\n", f2string(XY,lenxy), lenxy);
            writelog("    solver = '{}' len = {}\n", f2string(solver,lensolver), lensolver);
            writelogendl();

Running the demo.f90 program produces the following output for me on macOS (using both clang and gfortran from conda-forge):

 ctthermo_equilibrate:
     XY = 'HP' len =            2
     trim(XY) = 'HP', len =            2
     solver_ = 'auto                                              ' len =           50
     trim(solver_) = 'auto', len =            4
th_equil_:
    XY = 'HP' len = 2
    solver = '' len = 0

followed by the same "libc++abi: terminating with uncaught exception of type Cantera::CanteraError" error reported above.

But on Linux (Ubuntu 20.04), the output is:

 ctthermo_equilibrate:
     XY = 'HP' len =            2
     trim(XY) = 'HP', len =            2
     solver_ = 'auto                                              ' len =           50
     trim(solver_) = 'auto', len =            4
th_equil_:
    XY = 'HP' len = 2
    solver = 'auto' len = 4

The problem seems to be that the hidden length argument corresponding to the second string argument isn't being correctly set. If I change the declaration of th_equil so that the type of the string length arguments is int64_t instead of int, then I get the right value for lensolver. However, I don't understand why the same problem isn't occurring for other functions that call (multiple) string arguments, such as th_newfromfile.

I also don't know how to identify what integer type should be used for this argument for a specific compiler/platform (and this is the first time that I've seen our default assumption of int be incorrect). To avoid this kind of problem, I think we should be using the Fortran 2003 iso_c_binding feature, which should provide a way to call Cantera's clib functions with null terminated strings and not require any platform-specific code. Such a change would probably best be handled as part of a larger-scale modernization of the Fortran interface, and done in conjunction with Cantera/enhancements#39.

[ischoegl]

Running

scons test-f90-demo

or just

scons test

is the 'simplest' way to stumble across this issue.