Python crashes with 1D solver in Cantera 3.1

[Daniel Thomas]

After upgrading to Cantera 3.1.0 on a primary Windows machine, python crashes when running the 1D flame solver.  Cantera seems to work fine otherwise, and I haven't this problem on my Mac, linux or other Windows systems.  I'm running out of ideas for debugging, so wanted to send this out to ask for ideas.  

The system is Windows 11 Education, Version 23H2, Conda 24.11.3, python 3.13.1.  I've tried reinstalling conda and installations with other versions of python.

Using trace, I get the following when running the diffusion_flame.py example code:

************ Solving on 6 point grid with energy equation enabled ************
 --- modulename: onedim, funcname: energy_enabled
onedim.py(203):          self.flame.energy_enabled = enable

..............................................................................

Attempt Newton solution of steady-state problem. --- modulename: interrupts, funcname: no_op
interrupts.py(11):      return 0.0
 --- modulename: interrupts, funcname: no_op
interrupts.py(11):      return 0.0

Any ideas on other things to check?

Thanks,

Daniel

[Ray Speth]

Hi Daniel,

I thought I had replied to this before, but it seems that somehow my reply got deleted. I’m confused by the output shown, in particular, what is causing the output like

--- modulename: onedim, funcname: energy_enabled onedim.py(203): self.flame.energy_enabled = enable

Is there any output after the end of what you showed, or is that the point at which the code crashes?

Can you provide the full list of installed packages and version, which can be obtained by running conda list?

Regards,
Ray

​

[Daniel Thomas]

Thanks for the note Ray.  Yes, there were more calls to interrupts.py that I left out.  I'll set a more complete trace output and the conda list when I'm back on this machine on Tuesday.  Thanks again,

Daniel

[Daniel Thomas]

Hi Ray - I've attached the output from `conda list` here.  I had reinstalled miniconda and noticed that I now get the same problem with Cantera 3.0, so I've installed the output for that environment too.  I've also attached the last 1k lines of the trace output from running the Cantera `diffusion_flame.py` example.  Thanks for your help with this,

Daniel

[Ray Speth]

Hi Daniel,

I'm still a little confused. Are you specifying some command line options that add this traceback information? Can you provide the complete output of running that example? What happens after the last line of log output -- are you getting dumped back to the command prompt, or is there an error dialog from Windows? All I see in there is a bunch of functions that are expected to be called as part of the solution process, and no indication of an error.

The one thing I can think of to try would be installing OpenBLAS rather than MKL to provide BLAS/LAPACK support.

Regards,

Ray

[Daniel Thomas]

Hi Ray,

Yes, I get dumped back to command prompt after the  Attempt Newton solution of steady-state problem. output.  (In Jupyter, the 'kernel died, restarting...' notice comes up at this point.)  There is no further output from the solve() method with loglevel=5, so I was trying to get some more debug info with the python trace module (running:  `python -m trace -t diffusion_flame.py`).  But like you say, I didn't see anything indicating a problem there.  

I'll try installing from source specifying OpenBLAS and see if that changes anything.

Thanks,

Daniel

--
You received this message because you are subscribed to a topic in the Google Groups "Cantera Users' Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cantera-users/M_g4RINP_FY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cantera-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cantera-users/ca021df5-51ad-4bf6-aa8c-75fbbbd3fd6bn%40googlegroups.com.

[Ray Speth]

Hi Daniel,

Ah, I see, that makes more sense. The Python trace output is unfortunately not that useful, as the actual solver is fully in C++ — all you see are the hooks for the Python callback where control is briefly returned to Python that allow you to interrupt the code with “Ctrl+C”. To get a traceback for where the C++ code is at the point of the crash, you can add

ct.print_stack_trace_on_segfault()

near the top of the script, after importing the Cantera module. This is a new function in Cantera 3.1, so won’t work with your Cantera 3.0 install. Hopefully this will point us in a more useful direction.

Regards,
Ray

​

[Daniel Thomas]

Hi Ray,

Thanks for the note -- I wasn't aware of the print stack option.  The output with that added is below.  

I'm still working on compiling from source to specify OpenBLAS.  I also tried a pip install, and that appears to be working fine.  Given the limitation to single thread with pip, it would still be nice to get conda working -- but at least pip is a backup.  

- Daniel

************ Solving on 6 point grid with energy equation enabled ************

..............................................................................

Attempt Newton solution of steady-state problem.

Segmentation fault. Stack trace:
 0# Cantera::CanteraError::getMethod in cantera_shared
 1# Cantera::setLogger in cantera_shared
 2# log2f in ucrtbase
 3# OPENSSL_Applink in python
 4# _C_specific_handler in VCRUNTIME140
 5# _chkstk in ntdll
 6# RtlFindCharInUnicodeString in ntdll
 7# KiUserExceptionDispatcher in ntdll
 8# mkl_blas_def_xdswap in mkl_def_2
 9# mkl_lapack_dgbtrf in mkl_intel_thread_2
10# dgbtrf in liblapack
11# Cantera::BandMatrix::factor in cantera_shared
12# Cantera::BandMatrix::solve in cantera_shared
13# Cantera::MultiNewton::step in cantera_shared
14# Cantera::MultiNewton::solve in cantera_shared
15# Cantera::OneDim::solve in cantera_shared
16# Cantera::Sim1D::solve in cantera_shared
17# PyInit__cantera in _cantera_cp313_win_amd64
18# PyInit__cantera in _cantera_cp313_win_amd64
19# PyBytes_Repeat in python313
20# PyObject_Vectorcall in python313
21# PyEval_EvalFrameDefault in python313
22# PyEval_EvalCode in python313
23# PyRun_FileExFlags in python313
24# PyRun_StringFlags in python313
25# PyRun_InteractiveOneFlags in python313
26# PyOS_double_to_string in python313
27# Py_GetBuildInfo in python313
28# Py_GetBuildInfo in python313
29# Py_RunMain in python313
30# OPENSSL_Applink in python
31# BaseThreadInitThunk in KERNEL32
32# RtlUserThreadStart in ntdll

To view this discussion visit https://groups.google.com/d/msgid/cantera-users/ebcfe099-1471-4eb2-8986-29be23fdb8a1n%40googlegroups.com.

[Ray Speth]

Hi Daniel,

Thanks, that traceback definitely suggests something fishy going on within MKL.

You don’t need to build Cantera from scratch to use OpenBLAS. You should be able to swap out the package providing BLAS/LAPACK within your Conda environment by running:
conda install 'libblas=*=*openblas' to switch to OpenBLAS, or conda install 'libblas=*=*mkl' to force it back to MKL.

The caveat about multithreaded BLAS/LAPACK is mostly irrelevant in the case of the 1D solver. My experience has been that the parallel algorithms for banded matrices in MKL aren’t that great and you might be better off running with a single thread (by setting the OMP_NUM_THREADS environment variable).

Regards,
Ray

​

[Daniel Thomas]

Hi Ray,

Switching the BLAS/LAPACK packages within the existing environment will make it easier -- I'll try that when I'm back on the machine on Monday.  And interesting to hear experience with multithreading and the 1D solver ...I have to try that out.

Thanks again,

Daniel

To view this discussion visit https://groups.google.com/d/msgid/cantera-users/0508e663-2977-4f62-ad72-481f12d1a188n%40googlegroups.com.

[Daniel Thomas]

The 1D solver works fine now after switching to OpenBLAS.  My students have machines with the same configuration and the same problem, so very nice to have a solution to this.  Thanks very much for your help, Ray.

Daniel