Code Monkey home page Code Monkey logo

conda-recipes's Introduction

cantera logo

doi codecov ci GitHub release

What is Cantera?

Cantera is an open-source collection of object-oriented software tools for problems involving chemical kinetics, thermodynamics, and transport processes. Among other things, it can be used to:

  • Evaluate thermodynamic and transport properties of mixtures
  • Compute chemical equilibrium
  • Evaluate species chemical production rates
  • Conduct kinetics simulations with large reaction mechanisms
  • Simulate one-dimensional flames
  • Conduct reaction path analysis
  • Create process simulations using networks of stirred reactors
  • Model non-ideal fluids

Cantera can be used from Python and Matlab, or in applications written in C++ and Fortran 90. A number of examples of Cantera's capabilities are available in the form of Jupyter notebooks. These examples can be tried interactively, in the cloud by using the following MyBinder link:

Installation

pip anaconda conda-forge

Installation instructions for the current release of Cantera are available from the main Cantera documentation site.

  • The Python module can also be installed using pip on Windows, macOS, and Linux.
  • Conda packages containing the Cantera Python and Matlab modules are also available for Windows, macOS, and Linux.
  • Additional installation packages are provided for Windows, macOS, Ubuntu, Fedora, RHEL, Gentoo, and FreeBSD.
  • For other platforms, or for users wishing to install a development version of Cantera, compilation instructions are also available.

Documentation

The documentation offers a number of starting points:

Documentation for the development version of Cantera is also available.

Code of Conduct

conduct

In order to have a more open and welcoming community, Cantera adheres to a code of conduct adapted from the Contributor Covenant code of conduct.

Please adhere to this code of conduct in any interactions you have in the Cantera community. It is strictly enforced on all official Cantera repositories, websites, users' group, and other resources. If you encounter someone violating these terms, please contact the code of conduct team (@speth, @bryanwweber, and @kyleniemeyer) and we will address it as soon as possible.

Development Site

The current development version is 3.1.0a2. The current stable version is 3.0.0. The latest Cantera source code, the issue tracker for bugs and enhancement requests, downloads of Cantera releases and binary installers , and the Cantera wiki can all be found on Github.

Users' Group

The Cantera Users' Group is a message board/mailing list for discussions amongst Cantera users.

Continuous Integration Status

ci

NumFOCUS

Cantera is a fiscally-sponsored project of NumFOCUS, a non-profit dedicated to supporting the open source scientific computing community. Please consider making a donation to support the development of Cantera through NumFOCUS.

Powered by NumFOCUS

conda-recipes's People

Contributors

bryanwweber avatar ischoegl avatar speth avatar

Stargazers

avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

Forkers

speth bryanwweber minhbau jonnypjohnston ischoegl

conda-recipes's Issues

conda-forge update

At this point, build scripts have diverged from conda-forge/cantera-feedstock. Once all recipes are stable here, the conda-forge recipes need to be updated accordingly.

I am posting here as I'm not sure who is following issues or bug report on conda-forge.

The generated conda package cannot run with glibc 2.12

Recently I used miniconda3 to install cantera on a RHEL 6.7 HPC. It report error about the glibc version. The conda package is compiled using trusty (travis-ci.org build env overview), which uses glibc 2.19 according to the [package list of trusty][(https://packages.ubuntu.com/trusty/allpackages). However, RHEL/CentOS 6 uses 2.12 and CentOS 7 uses 2.17.

Considering the backward compatibility issue of cantera in many HPC platform (glibc itself is designed to be backward compatible and portable), I suggest to use docker function in travis-ci to run the build and test in CentOS 6. There is a sample code here

I also considerred use ubuntu 12.04 in travis-ci, how ever, it uses glibc 2.15 and I cannot find downgrade guide of glibc.

Another idea I can imagine is to use static-linking (at least to all libraries pointed to /lib and /lib64 ) to generate the *.so file in cantera package. It should works better than shared link with size inflation (considering the size of glibc 2.12 rpm is about 13MB). Further, for exascale HPC application, static linking is necessary to accelerate loading of the program. And the RAM of modern HPC is horribly larger than cantera need.

Cantera conda package forces downgrade of recent numpy versions

Cantera version

2.4.0

Operating System

any

Python version

3.7

Behavior

Installing the latest stable version of Cantera using conda enforces numpy to be of version 1.15.*, essentially leading to a forced downgrade if a more recent version is installed. Since the latest dev-version only specifies numpy >=1.11.3 , is this actually necessary?

I am asking because I experienced some problems with other packages when downgrading numpy (which also shouldn't happen, but that's a different story).

Appveyor builds don't work using appveyor.yml

I had previously gotten Appveyor working by configuring it using their web interface. This interface provides the supposedly equivalent YML file, but trying to add an appveyor.yml file that combines what was done for the x86 and x64 builds doesn't seem to work. The previously-working (pre conda-build 2.0) configs were, for x64:

version: 1.0.{build}
environment:
  ANACONDA_KEY:
    secure: 3ZFhc2nXAfGp3E1OJ6jnXHmjWcEPwRJcpanlvQAJMigQQ7oi/Q4OOM07ip3Nv8lz
install:
- cmd: >-
    set PATH=C:\Miniconda;C:\Miniconda\Scripts;%PATH%

    conda install -y anaconda-client conda-build
build_script:
- cmd: conda build cantera --python=2.7 --python=3.4 --python=3.5 --numpy=1.11
deploy_script:
- cmd: anaconda -t %ANACONDA_KEY% upload --force -l dev C:\Miniconda\conda-bld\win-32\cantera*.tar.bz2

and for x86:

version: 1.0.{build}
environment:
  ANACONDA_KEY:
    secure: 3ZFhc2nXAfGp3E1OJ6jnXHmjWcEPwRJcpanlvQAJMigQQ7oi/Q4OOM07ip3Nv8lz
install:
- cmd: >-
    set PATH=C:\Miniconda-x64;C:\Miniconda-x64\Scripts;%PATH%

    conda install -y anaconda-client conda-build
build_script:
- cmd: >-
    set PATH=C:\Miniconda-x64;C:\Miniconda-x64\Scripts;%PATH%

    conda build cantera --python=2.7 --python=3.4 --python=3.5 --numpy=1.11
deploy_script:
- cmd: anaconda -t %ANACONDA_KEY% upload --force -l dev C:\Miniconda-x64\conda-bld\win-64\cantera*.tar.bz2

The build gets as far as creating the cantera-builder environment, but then fails with the error:

'scons' is not recognized as an internal or external command, operable program or batch file

For the last successful build (https://ci.appveyor.com/project/speth/conda-recipes/build/1.0.13), from the same point (after the message about how to activate/deactivate the new environment), it used to say:

Using Anaconda API: https://api.anaconda.org
scons: Reading SConscript files ...

Link conda packages to libhdf5

Cantera 3.0 adds "native" support for working with HDF5 files using libhdf5. Supporting this feature with the conda packages requires linking to a specific version of hdf5, and we need to decide how to handle this.

Some possibilities:

  • Link against the latest packaged version of libhdf5 and leave it at that
  • Provide packages linking to different versions of libhdf5, with the hdf5 version included in the version tag
  • Provide packages with and without libhdf5 dependencies, with the version tag specified so that installing with HDF5 is preferred

I think the last option is probably the best way to avoid creating dependency problems that prevent users from installing specific Cantera versions without downgrading other packages (for example, when users who also want to have h5py installed install a version of that that link to a newer version of HDF5 than is compatible with a given Cantera release).

`Conda Install` Development Cantera Version 3.0.0a2

Problem description

Steps to reproduce

I'm trying to install the Cantera development version 3.0.0a2 using conda. This is because I want to test the preconditioner functionality

I use the following command to create a new conda environment and install the latest dev Cantera version (note that I locally removed the stable Cantera version from my machine) :

conda create --name ct-dev --channel cantera/label/dev cantera ipython matplotlib jupyter

Using ipython I check the version of Cantera installed

import cantera as ct
print(ct.__version__)
# 2.6.0

But version 2.6.0 gets printed

Using conda list command I can see that version 3.0.0a2 is installed. But, doing pip list shows that there is also the 2.6.0 version installed even though I never installed it. It seems to get installed automatically when I install the dev version 3.0.0a2 using conda

Is there any way to fix this? Am I doing something wrong?

Thank you in advance for the help!

Behavior

System information

  • Cantera version: 3.0.0a2
  • OS: Centos7 Linux
  • Architecture: x86
  • Python Version: 3.9.12
  • Python/MATLAB/other software versions: Python

Attachments

Additional context

Installing Matlab interface via conda fails if MATLAB folder is not in standard location

From the comments inside post-link.sh and post-link.bat I realize that their current working is already a compromise.

However, I wanted to point out that at least on Windows, it is currently impossible to install the cantera-matlab package when the folder %USERPROFILE%\Documents\MATLAB does not exist. I would say this can be quite common, because many people tend to separate their User folders from their system partition. The only solution is to manually create the folder.

I haven't tested whether Linux is more forthcoming here.

In any case, I would suggest to update the script with a warning if the MATLAB folder could not be located, so the user than knows they have to provide the startup data manually.

libcantera-devel fails on Windows

While conda install -c cantera/label/dev libcantera-devel works nicely on a Linux system, it fails on Windows.

Steps taken on my system:

(base) conda create -n cantera-dev scons numpy cython ruamel_yaml libboost git ipython

and on conda-dev

conda install -c cantera/label/dev cantera
conda install -c cantera/label/dev libcantera-devel

I tried this both with and without Visual Studio (2019) environments set up. In either case, the critical error appears to be this:

C:\Users\ischoegl>pushd "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\"
The system cannot find the path specified.

Which indicates that the conda package contains remnants of a Visual 2017 Enterprise build stack. I am attaching the full logging information: libcantera-devel.log

PS: the expected location for an anaconda installation should likely be dictated by the python system path variable as returned by sysconfig.get_paths()['include']

Conda path replacement mangling Cantera data directories

The behavior used by conda to replace paths on the build system with paths corresponding to the installation location is causing some problems with the Cantera data directories. Specifically, from the Python interface:

>>> import cantera as ct
>>> ct.get_data_directories()
['.',
 '/home/speth/miniconda3/envs/ct26/lib/python3.10/site-packages/cantera/data',
 '/home/speth/miniconda3/envs/ct26/share/cantera/data\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
]
>>> ct.Solution('spam.yaml')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/python/cantera/base.pyx", line 71, in cantera._cantera._SolutionBase.__cinit__
  File "build/python/cantera/base.pyx", line 128, in cantera._cantera._SolutionBase._cinit
  File "build/python/cantera/base.pyx", line 215, in cantera._cantera._SolutionBase._init_yaml
cantera._cantera.CanteraError: 
*******************************************************************************
CanteraError thrown by Application::findInputFile:

Input file spam.yaml not found in directories 
'.', 
'/home/speth/miniconda3/envs/ct26/lib/python3.10/site-packages/cantera/data', 
'/home/speth/miniconda3/envs/ct26/share/cantera/data
>>>

The problem is that the last directory name is padded with null bytes. When this is inserted into the error message printed by findInputFile, the message apparently ends up being treated as a null-terminated string, and gets truncated there.

This problem also affects the conda-forge packages.

Version tested: cantera 2.6.0 py310h6cd0baa_0

Windows conda packages default to 2.5.1

Problem Description
Error while reading YAML files involving third-body reactions on Cantera v2.6.0 on mac OS.

Steps to reproduce

  1. Compile and run 'mech.yaml' (attached) on macOS Cantera v2.6.0. (Cantera using conda-forge channel in this case)
  2. See the error: 'undeclared duplicate reactions detected.'
  3. *The error goes away when I use Cantera v2.5.1.
  4. *To fix it one can add 'duplicate: true' in the reactions with error. Then the YAML file won't compile on Cantera version 2.5.1 and will give the error: 'No duplicate found for declared duplicate reaction number abc'.
  5. ** The error is not present on the Windows system with Cantera v2.6.0.

System information

  • Cantera version: v2.6.0
  • OS: [MacOS Monterey v12.5]
  • Python

Attachments
mech.yaml.zip

Update to handle introduction of Python extension support

The conda recipes need some updates to handle the addition of support for calling user-defined Python extensions from C++ (see Cantera/cantera#1382).

Currently, in the conda recipe, the shared library is built with the Python module disabled, but that is now also what determines whether support for Python-based extensions is compiled, since the requirements for Python extension support are the same as those for the Python module itself, and using the Python extension support requires the Python module to be present in any case. Further, libcantera now depends on a specific version of libpython, so we can't provide just one version of libcantera for all Python versions.

As discussed in Cantera/cantera#1382, it might make sense to just combine the libcantera package with the Python module, since the requirements for the two are now identical, and the first can only be fully used if the second is installed.

conda-build mangles libcantera-devel build system files

PR #35 packages headers and libraries for both C++ and Fortran 90 in libcantera-devel. However, some build system files are currently deliberately excluded, as conda-build is unable to properly patch them.

One file where this is apparent is lib/pgconfig/cantera.pc (installed in /opt/conda/envs/ct-env), which contains references to the GH build system (in this case /usr/share/miniconda3/conda-bld/cantera-recipe_1660271238971/_build_env), i.e.

$ cat cantera.pc 
prefix=/opt/conda/envs/ct-env
exec_prefix=${prefix}/bin
libdir=${prefix}/lib
includedir=${prefix}/include

Name: Cantera
Description: Cantera library
URL: http://www.cantera.org
Version: 3.0.0a2

Libs: -L${libdir} -L/usr/share/miniconda3/conda-bld/cantera-recipe_1660271238971/_build_env/lib -lcantera -lpthread
Cflags: -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /opt/conda/envs/ct-env/include -pthread -I${includedir} -I/usr/share/miniconda3/conda-bld/cantera-recipe_1660271238971/_build_env/include -I/opt/conda/envs/ct-env/include

In this case, the original cantera.pc.in template is:

prefix=@pc_prefix@
exec_prefix=${prefix}/bin
libdir=${prefix}/@libdirname@
includedir=${prefix}/include

Name: Cantera
Description: Cantera library
URL: http://www.cantera.org
Version: @cantera_version@

Libs: -L${libdir} @pc_libdirs@ @pc_libs@
Cflags: @pc_cflags@ -I${includedir} @pc_incdirs@

indicating that the replacements @pc_libdirs@ and @pc_incdirs@ fail.

While pkg-config still works, other build system files are currently not included in the package (e.g. Cantera.mak).

There are two potential solutions:

  1. Update template files upstream in Cantera/cantera in a way that all paths become patchable by conda-build
  2. Strategically patch/replace those files within Cantera/conda-recipes before running scons build and scons install
  3. Search/replace the mangled bits before packaging (e.g. using sed)

At least on *nix systems, (3) appears to be easiest?

Cantera-dev is outdated

While 2.5.1 is now officially released, - 🎉, - the dev conda variant appears to be still on 2.5.0.rc1

conda create -n cantera-test scons numpy cython ruamel_yaml libboost h5py ipython
conda install -c cantera/label/dev cantera
conda install -c cantera/label/dev libcantera-devel

and

In [1]: import cantera as ct

In [2]: ct.__version__
Out[2]: '2.5.0rc1'

Library importation bug in GCloud VM

I've been experiencing the following error when importing the library when using it in a gCloud VM:

Python 3.9.12 (main, Apr  5 2022, 06:56:58) 
Type 'copyright', 'credits' or 'license' for more information
IPython 8.3.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import cantera
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
Input In [1], in <cell line: 1>()
----> 1 import cantera

File ~/anaconda3/envs/ct-env/lib/python3.9/site-packages/cantera/__init__.py:4, in <module>
      1 # This file is part of Cantera. See License.txt in the top-level directory or
      2 # at https://cantera.org/license.txt for license and copyright information.
----> 4 from ._cantera import *
      5 from ._cantera import __version__, __sundials_version__, __git_commit__
      6 from .composite import *

ImportError: libmkl_rt.so.2: cannot open shared object file: No such file or directory

The enviroment has following setup:

# packages in environment at /home/reginaldo/anaconda3/envs/ct-env:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                        main  
_openmp_mutex             5.1                       1_gnu  
argon2-cffi               21.3.0             pyhd3eb1b0_0  
argon2-cffi-bindings      21.2.0           py39h7f8727e_0  
asttokens                 2.0.5              pyhd3eb1b0_0  
attrs                     21.4.0             pyhd3eb1b0_0  
backcall                  0.2.0              pyhd3eb1b0_0  
beautifulsoup4            4.11.1           py39h06a4308_0  
blas                      1.0                         mkl  
bleach                    4.1.0              pyhd3eb1b0_0  
brotli                    1.0.9                he6710b0_2  
ca-certificates           2022.4.26            h06a4308_0  
cantera                   2.6.0            py39h9a426be_0    cantera
certifi                   2022.5.18.1      py39h06a4308_0  
cffi                      1.15.0           py39hd667e15_1  
cycler                    0.11.0             pyhd3eb1b0_0  
dbus                      1.13.18              hb2f20db_0  
debugpy                   1.5.1            py39h295c915_0  
decorator                 5.1.1              pyhd3eb1b0_0  
defusedxml                0.7.1              pyhd3eb1b0_0  
entrypoints               0.4              py39h06a4308_0  
executing                 0.8.3              pyhd3eb1b0_0  
expat                     2.4.4                h295c915_0  
fontconfig                2.13.1               h6c09931_0  
fonttools                 4.25.0             pyhd3eb1b0_0  
freetype                  2.11.0               h70c0345_0  
giflib                    5.2.1                h7b6447c_0  
glib                      2.69.1               h4ff587b_1  
gst-plugins-base          1.14.0               h8213a91_2  
gstreamer                 1.14.0               h28cd5cc_2  
h5py                      3.6.0            py39ha0f2276_0  
hdf5                      1.10.6               hb1b8bf9_0  
icu                       58.2                 he6710b0_3  
intel-openmp              2021.4.0          h06a4308_3561  
ipykernel                 6.9.1            py39h06a4308_0  
ipython                   8.3.0            py39h06a4308_0  
ipython_genutils          0.2.0              pyhd3eb1b0_1  
ipywidgets                7.6.5              pyhd3eb1b0_1  
jedi                      0.18.1           py39h06a4308_1  
jinja2                    3.0.3              pyhd3eb1b0_0  
jpeg                      9e                   h7f8727e_0  
jsonschema                4.4.0            py39h06a4308_0  
jupyter                   1.0.0            py39h06a4308_7  
jupyter_client            7.2.2            py39h06a4308_0  
jupyter_console           6.4.3              pyhd3eb1b0_0  
jupyter_core              4.10.0           py39h06a4308_0  
jupyterlab_pygments       0.1.2                      py_0  
jupyterlab_widgets        1.0.0              pyhd3eb1b0_1  
kiwisolver                1.4.2            py39h295c915_0  
lcms2                     2.12                 h3be6417_0  
ld_impl_linux-64          2.38                 h1181459_1  
libcantera                2.6.0                h3fd9d12_0    cantera
libffi                    3.3                  he6710b0_2  
libgcc-ng                 11.2.0               h1234567_0  
libgfortran-ng            7.5.0               ha8ba4b0_17  
libgfortran4              7.5.0               ha8ba4b0_17  
libgomp                   11.2.0               h1234567_0  
libpng                    1.6.37               hbc83047_0  
libsodium                 1.0.18               h7b6447c_0  
libstdcxx-ng              11.2.0               h1234567_0  
libtiff                   4.2.0                h2818925_1  
libuuid                   1.0.3                h7f8727e_2  
libwebp                   1.2.2                h55f646e_0  
libwebp-base              1.2.2                h7f8727e_0  
libxcb                    1.15                 h7f8727e_0  
libxml2                   2.9.14               h74e7548_0  
lz4-c                     1.9.3                h295c915_1  
markupsafe                2.0.1            py39h27cfd23_0  
matplotlib                3.5.1            py39h06a4308_1  
matplotlib-base           3.5.1            py39ha18d171_1  
matplotlib-inline         0.1.2              pyhd3eb1b0_2  
mistune                   0.8.4           py39h27cfd23_1000  
mkl                       2021.4.0           h06a4308_640  
mkl-service               2.4.0            py39h7f8727e_0  
mkl_fft                   1.3.1            py39hd3c417c_0  
mkl_random                1.2.2            py39h51133e4_0  
munkres                   1.1.4                      py_0  
nbclient                  0.5.13           py39h06a4308_0  
nbconvert                 6.4.4            py39h06a4308_0  
nbformat                  5.3.0            py39h06a4308_0  
ncurses                   6.3                  h7f8727e_2  
nest-asyncio              1.5.5            py39h06a4308_0  
notebook                  6.4.11           py39h06a4308_0  
numpy                     1.22.3           py39he7a7128_0  
numpy-base                1.22.3           py39hf524024_0  
openssl                   1.1.1o               h7f8727e_0  
packaging                 21.3               pyhd3eb1b0_0  
pandocfilters             1.5.0              pyhd3eb1b0_0  
parso                     0.8.3              pyhd3eb1b0_0  
pcre                      8.45                 h295c915_0  
pexpect                   4.8.0              pyhd3eb1b0_3  
pickleshare               0.7.5           pyhd3eb1b0_1003  
pillow                    9.0.1            py39h22f2fdc_0  
pip                       21.2.4           py39h06a4308_0  
prometheus_client         0.13.1             pyhd3eb1b0_0  
prompt-toolkit            3.0.20             pyhd3eb1b0_0  
prompt_toolkit            3.0.20               hd3eb1b0_0  
ptyprocess                0.7.0              pyhd3eb1b0_2  
pure_eval                 0.2.2              pyhd3eb1b0_0  
pycparser                 2.21               pyhd3eb1b0_0  
pygments                  2.11.2             pyhd3eb1b0_0  
pyparsing                 3.0.4              pyhd3eb1b0_0  
pyqt                      5.9.2            py39h2531618_6  
pyrsistent                0.18.0           py39heee7806_0  
python                    3.9.12               h12debd9_0  
python-dateutil           2.8.2              pyhd3eb1b0_0  
python-fastjsonschema     2.15.1             pyhd3eb1b0_0  
pyzmq                     22.3.0           py39h295c915_2  
qt                        5.9.7                h5867ecd_1  
qtconsole                 5.3.0              pyhd3eb1b0_0  
qtpy                      2.0.1              pyhd3eb1b0_0  
readline                  8.1.2                h7f8727e_1  
ruamel.yaml               0.16.12          py39h27cfd23_1  
ruamel.yaml.clib          0.2.6            py39h7f8727e_0  
send2trash                1.8.0              pyhd3eb1b0_1  
setuptools                61.2.0           py39h06a4308_0  
sip                       4.19.13          py39h295c915_0  
six                       1.16.0             pyhd3eb1b0_1  
soupsieve                 2.3.1              pyhd3eb1b0_0  
sqlite                    3.38.3               hc218d9a_0  
stack_data                0.2.0              pyhd3eb1b0_0  
terminado                 0.13.1           py39h06a4308_0  
testpath                  0.5.0              pyhd3eb1b0_0  
tk                        8.6.11               h1ccaba5_1  
tornado                   6.1              py39h27cfd23_0  
traitlets                 5.1.1              pyhd3eb1b0_0  
typing-extensions         4.1.1                hd3eb1b0_0  
typing_extensions         4.1.1              pyh06a4308_0  
tzdata                    2022a                hda174b7_0  
wcwidth                   0.2.5              pyhd3eb1b0_0  
webencodings              0.5.1            py39h06a4308_1  
wheel                     0.37.1             pyhd3eb1b0_0  
widgetsnbextension        3.5.2            py39h06a4308_0  
xz                        5.2.5                h7f8727e_1  
zeromq                    4.3.4                h2531618_0  
zlib                      1.2.12               h7f8727e_2  
zstd                      1.5.2                ha4553b6_0

The OS is 20.04.1-Ubuntu.

I appreciate any help.

Intel MKL

Supersedes #29

Some Cantera versions on the cantera channel are compiled with Intel MKL support, which requires correct versions. Due to recurring issues (example: #29), MKL is currently no longer used for compiled packages.

Originally posted by @speth in #29 (comment)

Recent builds of Numpy seem to have separate builds for different MKL versions. Partial output of mamba search --info -c defaults numpy=1.23.5 shows:

numpy 1.23.5 py310h5f9d8c6_1
----------------------------
file name   : numpy-1.23.5-py310h5f9d8c6_1.conda
name        : numpy
version     : 1.23.5
build       : py310h5f9d8c6_1
build number: 1
size        : 10 KB
license     : BSD-3-Clause
subdir      : linux-64
url         : https://repo.anaconda.com/pkgs/main/linux-64/numpy-1.23.5-py310h5f9d8c6_1.conda
md5         : 875377e83010e75870affa1797444ce7
timestamp   : 2023-05-01 15:03:28 UTC
dependencies: 
  - blas 1.0 mkl
  - libgcc-ng >=11.2.0
  - libstdcxx-ng >=11.2.0
  - mkl >=2023.1.0,<2024.0a0
  - mkl-service >=2.3.0,<3.0a0
  - mkl_fft
  - mkl_random
  - numpy-base 1.23.5 py310hb5e798b_1
  - python >=3.10,<3.11.0a0

numpy 1.23.5 py310hd5efca6_0
----------------------------
file name   : numpy-1.23.5-py310hd5efca6_0.conda
name        : numpy
version     : 1.23.5
build       : py310hd5efca6_0
build number: 0
size        : 10 KB
license     : BSD-3-Clause
subdir      : linux-64
url         : https://repo.anaconda.com/pkgs/main/linux-64/numpy-1.23.5-py310hd5efca6_0.conda
md5         : 14704ba32c38d4d8d78e5812f274a795
timestamp   : 2022-12-29 19:03:16 UTC
dependencies: 
  - blas 1.0 mkl
  - libgcc-ng >=11.2.0
  - libstdcxx-ng >=11.2.0
  - mkl >=2021.4.0,<2022.0a0
  - mkl-service >=2.3.0,<3.0a0
  - mkl_fft
  - mkl_random
  - numpy-base 1.23.5 py310h8e6c178_0
  - python >=3.10,<3.11.0a0

So, one build that specifically requires MKL 2021 and one that specifically requires MKL 2023, in addition to a build for OpenBLAS (and a conspicuous absence of a build for MKL 2022, which was the source of some of the original trouble reported here). I think for us, all the extra builds really aren't worth it, and we should just stick to using OpenBLAS for the packages on the cantera channel.

Add script to auto-generate build matrix

@speth Does the code here: 54581e5 make sense to include? The intended use is that a maintainer runs generate-ci-builds.py locally and commits the changes to .travis.yml and appveyor.yml. Ideally, only the build matrix will change after this first commit where things get a little bit reformatted. The only dependency is ruamel.yaml>=0.15.0, but it only has to be installed locally by a maintainer when they want to update things, users don't have to do anything.

My only concern is the reformatting of .travis.yml and appveyor.yml. That should only happen this one time though. Thoughts?

PS This isn't a PR because it generates a pretty large number of builds that I didn't want to kick off again 😄 Seems like the builds are working fine: https://travis-ci.org/Cantera/conda-recipes/builds/242566802 and https://ci.appveyor.com/project/Cantera/conda-recipes/build/1.0.57 I also have a similar changeset for the master branch that I didn't push yet because, again, a bunch of builds

Feature request: include C++ headers in conda

Cantera version

2.4.0 installed via conda (e.g. anaconda3-5.2.0)

  • Expected Behavior: C++ header files should be distributed in the standard include/cantera/... folders
  • Actual Behavior: While a compilation from source does install header files, the conda installation does not.
  • Steps to reproduce: Install cantera using conda.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.