Spitfire is a Python/C++ library for constructing tabulated chemistry models and solving differential equations.
License: Other
Spitfire is an open source Python/C++ scientific computing code for chemistry and reaction-diffusion problems related to combustion and porous material decomposition. Spitfire is primarily used at Sandia National Laboratories to build advanced nonpremixed flamelet libraries for large-scale accidental fire simulations and small-scale pool fires.
Documentation in the form of background, demonstrations, and installation instructions can be found on our RTD page.
Hi,
I'm actually trying to install LIM1TR: Lithium-Ion Modeling with 1-D Thermal Runaway model. The prerequisite for this is to install spitfire.
I'm following the spitfire documentation suggested for anaconda.
I have installed python 3.11.7.
I'm only a beginner user in python, so please pardon me if I get the terminologies wrong or if don't understand what you suggest :). I will try to explain the issue to the best of my abilities.
These were the steps I followed :
conda install -y compilers setuptools numpy scipy matplotlib Cython sphinx numpydoc gitpython
So when I try to install compilers, this is error message I get :
I believe the package is not install correctly. Can you help with this error?
`(spenv) C:\ProgramData\anaconda3>conda install -y compilers
Channels:
- conda-forge
- defaults
Platform: win-64
Collecting package metadata (repodata.json): done
Solving environment: done
## Package Plan ##
environment location: C:\Users\Parth Swaroop\.conda\envs\spenv
added / updated specs:
- compilers
The following NEW packages will be INSTALLED:
c-compiler conda-forge/win-64::c-compiler-1.7.0-hcfcfb64_1
clangdev conda-forge/win-64::clangdev-5.0.0-flang_3
compilers conda-forge/win-64::compilers-1.7.0-h57928b3_1
cxx-compiler conda-forge/win-64::cxx-compiler-1.7.0-h91493d7_1
flang conda-forge/win-64::flang-5.0.0-he025d50_20180525
flang_win-64 conda-forge/win-64::flang_win-64-5.0.0-h13ae965_20180526
fortran-compiler conda-forge/win-64::fortran-compiler-1.7.0-h9655429_1
libflang conda-forge/win-64::libflang-5.0.0-h6538335_20180525
llvm-meta conda-forge/noarch::llvm-meta-5.0.0-0
openmp conda-forge/win-64::openmp-5.0.0-vc14_1
vs2019_win-64 conda-forge/win-64::vs2019_win-64-19.29.30139-he1865b1_18
vswhere conda-forge/win-64::vswhere-3.1.4-h57928b3_0
The following packages will be UPDATED:
ca-certificates pkgs/main::ca-certificates-2023.12.12~ --> conda-forge::ca-certificates-2024.2.2-h56e8100_0
The following packages will be SUPERSEDED by a higher-priority channel:
certifi pkgs/main/win-64::certifi-2024.2.2-py~ --> conda-forge/noarch::certifi-2024.2.2-pyhd8ed1ab_0
Downloading and Extracting Packages:
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
C:\ProgramData\anaconda3>SET DISTUTILS_USE_SDK=1
C:\ProgramData\anaconda3>SET MSSdk=1
C:\ProgramData\anaconda3>SET "VS_VERSION=16.0"
C:\ProgramData\anaconda3>SET "VS_MAJOR=16"
C:\ProgramData\anaconda3>SET "VS_YEAR=2019"
C:\ProgramData\anaconda3>set "MSYS2_ARG_CONV_EXCL=/AI;/AL;/OUT;/out"
C:\ProgramData\anaconda3>set "MSYS2_ENV_CONV_EXCL=CL"
C:\ProgramData\anaconda3>set "PY_VCRUNTIME_REDIST=\bin\vcruntime140.dll"
C:\ProgramData\anaconda3>set "CXX=cl.exe"
C:\ProgramData\anaconda3>set "CC=cl.exe"
C:\ProgramData\anaconda3>set "VSINSTALLDIR="
C:\ProgramData\anaconda3>set "NEWER_VS_WITH_OLDER_VC=0"
C:\ProgramData\anaconda3>for /F "usebackq tokens=*" %i in (`vswhere.exe -nologo -products * -version [16.0,17.0) -property installationPath`) do (set "VSINSTALLDIR=%i\" )
C:\ProgramData\anaconda3>if not exist "" (for /F "usebackq tokens=*" %i in (`vswhere.exe -nologo -products * -requires Microsoft.VisualStudio.ComponentGroup.VC.Tools.142.x86.x64 -property installationPath`) do (
set "VSINSTALLDIR=%i\"
set "NEWER_VS_WITH_OLDER_VC=1"
) )
C:\ProgramData\anaconda3>if not exist "" (for /F "usebackq tokens=*" %i in (`vswhere.exe -nologo -products * -requires Microsoft.VisualStudio.Component.VC.v142.x86.x64 -property installationPath`) do (
set "VSINSTALLDIR=%i\"
set "NEWER_VS_WITH_OLDER_VC=1"
) )
C:\ProgramData\anaconda3>if not exist "" (set "VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\" )
C:\ProgramData\anaconda3>if not exist "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\" (set "VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\" )
C:\ProgramData\anaconda3>if not exist "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\" (set "VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\" )
C:\ProgramData\anaconda3>if not exist "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\" (set "VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\" )
C:\ProgramData\anaconda3>IF NOT "" == "" (
set "INCLUDE=;"
set "LIB=;;C:\Users\Parth Swaroop\.conda\envs\spenv\Library\lib"
set "CMAKE_PREFIX_PATH=;"
)
C:\ProgramData\anaconda3>call :GetWin10SdkDir
C:\ProgramData\anaconda3>call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 exit /B 1
C:\ProgramData\anaconda3>exit /B 0
C:\ProgramData\anaconda3>for /F %i in ('dir /ON /B "C:\Program Files (x86)\Windows Kits\10\\include\10.*"') DO (SET WindowsSDKVer=%~i )
C:\ProgramData\anaconda3>(SET WindowsSDKVer=10.0.22000.0 )
C:\ProgramData\anaconda3>if errorlevel 1 (echo "Didn't find any windows 10 SDK. I'm not sure if things will work, but let's try..." ) else (echo Windows SDK version found as: "10.0.22000.0" )
Windows SDK version found as: "10.0.22000.0"
C:\ProgramData\anaconda3>set "CMAKE_PLAT=x64"
C:\ProgramData\anaconda3>set "VCVARSBAT=64"
C:\ProgramData\anaconda3>set "CMAKE_ARGS=-DCMAKE_BUILD_TYPE=Release"
C:\ProgramData\anaconda3>IF "" == "1" (set "CMAKE_ARGS=-DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX= -DCMAKE_PROGRAM_PATH=\bin;\Scripts;\Library\bin;\bin;\Scripts;\Library\bin" )
C:\ProgramData\anaconda3>IF NOT "win-64" == "win-64" (
set "CONDA_BUILD_CROSS_COMPILATION=1"
set "CMAKE_ARGS=-DCMAKE_BUILD_TYPE=Release -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_SYSTEM_PROCESSOR=AMD64"
) else (set "CONDA_BUILD_CROSS_COMPILATION=0" )
C:\ProgramData\anaconda3>IF 2019 GEQ 2019 (
set "CMAKE_GEN=Visual Studio 16 2019"
set "USE_NEW_CMAKE_GEN_SYNTAX=1"
) ELSE (
IF "win-64" == "win-64" (set "CMAKE_GEN=Visual Studio 16 2019 Win64" ) else (set "CMAKE_GEN=Visual Studio 16 2019" )
set "USE_NEW_CMAKE_GEN_SYNTAX=0"
)
C:\ProgramData\anaconda3>echo "NEWER_VS_WITH_OLDER_VC=0"
"NEWER_VS_WITH_OLDER_VC=0"
C:\ProgramData\anaconda3>if "0" == "1" (set /p NEWER_VS= 0<"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\\VC\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt" )
C:\ProgramData\anaconda3>type "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\\VC\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt"
The system cannot find the path specified.
C:\ProgramData\anaconda3>dir "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\\VC\Redist\MSVC\"
The system cannot find the path specified.
C:\ProgramData\anaconda3>if "0" == "1" (
echo ""
if "~0,4" == "14.2" (set "CMAKE_GEN=Visual Studio 16 2019" ) else (set "CMAKE_GEN=Visual Studio 17 2022" )
set "USE_NEW_CMAKE_GEN_SYNTAX=1"
)
C:\ProgramData\anaconda3>IF "Visual Studio 16 2019" == "" SET "CMAKE_GENERATOR=Visual Studio 16 2019"
C:\ProgramData\anaconda3>IF "1" == "1" (
IF "x64" == "" SET "CMAKE_GENERATOR_PLATFORM=x64"
IF "v142" == "" SET "CMAKE_GENERATOR_TOOLSET=v142"
)
C:\ProgramData\anaconda3>pushd C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\
The system cannot find the path specified.
C:\ProgramData\anaconda3>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.29 10.0.22000.0
The system cannot find the path specified.
C:\ProgramData\anaconda3>if 1 NEQ 0 (if "" == "" (CALL "VC\Auxiliary\Build\vcvars64.bat" ) )
The system cannot find the path specified.
C:\ProgramData\anaconda3>popd
C:\ProgramData\anaconda3>call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE 1>nul 2>&1
C:\ProgramData\anaconda3>if errorlevel 1 exit /B 1
C:\ProgramData\anaconda3>exit /B 0
Add arc-length continuation to support S-curve calculations and progress variable tabulation for flamelets
Add automatic estimation (to chosen precision) of adiabatic flamelet extinction limits. This will likely be a bisection approach and/or a PI controller approach.
Implement automatic continuation with various homotopy maps, considering both global and local variants. These should support a tabulation API where only points of interest are provided by the user and spitfire automatically does continuation optimally behind the scenes, followed by interpolation onto points of interest and refinement
Improve calculation of the SLFM flamelet solution for the first nonzero dissipation rate. We currently use the equilibrium or Burke-Schumann solution as the initial guess, which leads to slow convergence and needs the GESAT pseudo-transient continuation method that doesn't scale particularly well for mechanisms with more than 150-200 species. This ultimately means that we spend 25-50% of the time building an adiabatic SLFM library in the first solve. It's possible that convex homotopies could improve performance or at least provide another alternative to GESAT that may outperform it on extremely large mechanisms.
Currently we build element molecular weights into Griffon statically. This breaks every thermochemistry test when we use Cantera 2.5 (2.3 and 2.4 are fine), because 2.5 has different element molecular weights than 2.3/2.4. To support both, we should load element data from Cantera.
It doesn't appear obvious how to extract element molecular weights in the Python interface, but a simple approach is to build a mechanism with only monatomic species and then extract species molecular weights. This can then be passed through a setter on the Griffon mechanism. This would also allow a user to overwrite the element molecular weights if desired.
This is not a Spitfire task, just a tracker for TabProps development. TabProps' python interface is sitting on a branch as we finish things. Once it's in master, we could consider submoduling TabProps to simplify things.
Currently the build_adiabatic_slfm_library method is used on its own as a standalone user-facing method, as well as internally by the nonadiabatic SLFM build_*_library methods. This is good reuse of code and if we were only ever interested in generating structured libraries it is fine. To enable code reuse for structured and unstructured library generation, we should rework this. Right now it builds a dictionary for the internal use and a Library for user-facing use. Is the dictionary the cleanest way to approach the unstructured case? It is based on the stoichiometric dissipation rate, which itself is meant for structuring and is not the most general thing we could do. A more general option would be to produce a totally flattened library with mixture fraction and the actual dissipation rate. Ideally we could then have a capability that takes such a library and some structuring rule (here, chi_st) to produce the structured (tensor product) 2D format.
Hi Mike,
I am having a few issues trying to build TabProps and Spitfire from source.
First, for TabProps, I ran make install and it failed:
tabprops/prepro/mixmdl/BetaMixMdl.h: No such file or directory
#include <tabprops/prepro/mixmdl/BetaMixMdl.h>
Second, for Spitfire, after creating my own fork, I tried python3 setup.py install and it failed:
Traceback (most recent call last):
File "/home/mameeha/research/spitfire/Spitfire/setup.py", line 75, in <module>
c.write_gitinfo()
File "/home/mameeha/research/spitfire/Spitfire/setup.py", line 50, in write_gitinfo
latest_tag = tags[-1]
~~~~^^^^
IndexError: list index out of range
which is definitely a result not having any previous commits on my fork.
Third, for Spitfire, using the normal code base, I tried python3 setup.py install and it failed with a bunch of errors. Here are a few:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from src/spitfire/griffon/griffon.cpp:832:0:
src/spitfire/griffon/include/combustion_kernels.h:151:17: error: ‘array’ is not a member of ‘std’
std::vector<std::array<double, NCP>> coefficients;
src/spitfire/griffon/include/combustion_kernels.h:275:12: error: ‘constexpr’ does not name a type
static constexpr int NCP = NCPn;
Any idea what could be causing these issues? Thanks!
Mike Meehan
We currently presume the fuel is a hydrocarbon when calculating stoichiometry (grid, dissipation rate for SLFM) and in solving for Burke-Schumann (idealized combustion) flamelets. Aluminum combustion models require this be relaxed. Perhaps with a user-specified fuel element and combustion products?
Things like mix_for_equivalence_ratio use Cantera and can only do hydrocarbon chemistry, even though we generalized our direct stoichiometry calculations to include Aluminum. We just need to not use Cantera everywhere for this.
Since we support non-hydrocarbon elsewhere I'm labeling this as a bug. The methods produce the wrong results (pure fuel) and don't indicate so.
The time integration code in Spitfire is entirely written in Python. This makes it slower than precompiled code for smaller-scale systems (e.g. hydrogen combustion in a reactor model). Moving the time integration framework to Griffon (C++) or Cython code makes it noticeably more awkward to work with and/or less general (for instance, reactor parameters as a function of time).
However, there are circumstances where less flexibility is needed and for which improved performance would be a feature. An example is ignition delay calculations for homogeneous reactor models. Speedups of 2-20x for ignition delay estimates or other well-defined, inflexible types of simulations would be a nice feature for kinetics studies.
Add the ability to generate typical FPV tables with a progress variable replacing the scalar dissipation rate. This also motivates the addition of double-delta PDFs for #11.
Our use of Cython to wrap the internal C++ engine (Griffon) is very heavy-handed and could probably be cleaner and more bug-proof with PyBind.
We currently evaluate flamelet right-hand sides and Jacobian matrices by iterating over mixture fraction points and calling into reactor-style thermo/kinetics handlers. Early prototyping showed significant speedup by rewriting these calls in a way that the compiler can vectorize. We should focus on flamelet performance, as 1D and 2D flamelet models are far more expensive than reactor models and are really becoming the primary production usage. Ideally we can avoid duplicating code across reactors and flamelets without hurting performance of reactors too much.
Kokkos would be nice for this, as the optimal data layout may change when large mechanisms are used (more species than grid points). One day this may also support threading/GPUs without major changes to Griffon. A surprising little issue here is that Kokkos may require cmake 3.10+, for which conda may not provide a simple installation.
We currently support enthalpy defect models (built with transient radiative extinction in mind) with a simple, high-level function. While enthalpy offset and quasisteady heat loss models are entirely possible with Spitfire (with quasisteady actually being a demo script currently), adding high-level support would be great.
Probably I didn't fully understand the code, but I can't find in the flamelet_rhs function the second derivative of the temperature and species mass fractions. Are they defined somewhere else? I'm trying to reconstruct the differential equations found in the documentation.
Thank's, have a nice day.
I used installation directions here:
https://spitfire.readthedocs.io/en/latest/?badge=latest
When I tried to do this:
pip install .
I got this:
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [38 lines of output]
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "<pip-setuptools-caller>", line 34, in <module>
File "D:\...\Spitfire\setup.py", line 79, in <module>
c.write_gitinfo()
File "D:\...\Spitfire\setup.py", line 47, in write_gitinfo
tags = sorted(repo.tags, key=lambda t: t.commit.committed_datetime)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\...\Spitfire\setup.py", line 47, in <lambda>
tags = sorted(repo.tags, key=lambda t: t.commit.committed_datetime)
^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\refs\tag.py", line 55, in commit
obj = self.object
^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\refs\tag.py", line 85, in object
return Reference._get_object(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\refs\symbolic.py", line 288, in _get_object
return Object.new_from_sha(self.repo, hex_to_bin(self.dereference_recursive(self.repo, self.path)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\objects\base.py", line 149, in new_from_sha
oinfo = repo.odb.info(sha1)
^^^^^^^^^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\db.py", line 41, in info
hexsha, typename, size = self._git.get_object_header(bin_to_hex(binsha))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\cmd.py", line 1678, in get_object_header
return self.__get_object_header(cmd, ref)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\cmd.py", line 1662, in __get_object_header
return self._parse_object_header(cmd.stdout.readline())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Apoge\anaconda3\envs\...\Lib\site-packages\git\cmd.py", line 1621, in _parse_object_header
raise ValueError(err_msg)
ValueError: SHA is empty, possible dubious ownership in the repository at D:\...\Spitfire.
If this is unintended run:
"git config --global --add safe.directory D:\...\Spitfire"
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
When I got to here:
python3 -m unittest discover -s tests
It gave me lots of errors:
======================================================================
ERROR: time_integration.test_vs_scipy_integrate (unittest.loader._FailedTest.time_integration.test_vs_scipy_integrate)
----------------------------------------------------------------------
ImportError: Failed to import test module: time_integration.test_vs_scipy_integrate
Traceback (most recent call last):
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.11_3.11.2544.0_x64__qbz5n2kfra8p0\Lib\unittest\loader.py", line 419, in _find_test_path
module = self._get_module_from_name(name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.11_3.11.2544.0_x64__qbz5n2kfra8p0\Lib\unittest\loader.py", line 362, in _get_module_from_name
__import__(name)
File "D:\...\Spitfire\tests\time_integration\test_vs_scipy_integrate.py", line 3, in <module>
from scipy import integrate as scipy_integrate
ModuleNotFoundError: No module named 'scipy'
----------------------------------------------------------------------
Ran 31 tests in 0.003s
FAILED (errors=31)
Scrolling back through previous steps, I found this:
C:\Windows\System32>type "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\\VC\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt"
The system cannot find the path specified.
C:\Windows\System32>dir "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\\VC\Redist\MSVC\"
The system cannot find the path specified.
Questions:
Note: Names were changed to protect the innocent.
Recently we have generalized our flamelet equations by adding the variable heat capacity and consistent enthalpy flux terms. This has been important in getting good results for both adiabatic and nonadiabatic flamelet libraries. There are more generalizations that should be supported in the future.
Support a use_molar_flux entry in the Flamelet constructor that uses mole fraction gradients to determine diffusive fluxes.
Support a use_Curtiss_Hirschfelder_approximation entry to the Flamelet constructor to compute all N mass fluxes and correct them for mass conservation according to Curtiss and Hirschfelder's procedure. The default will be the current behavior of forming N-1 fluxes and using mass conservation to directly set the N-th flux.
Note that these two choices (mass/mole, Curtiss_Hirschfelder/not) result in four diffusive flux models.
Support a consistent nonunity, constant Lewis number formulation. This involves some care over the four different diffusion models.
Support a nonconstant Lewis number formulation, with mixture-averaged transport properties. This is a big task requiring transport property evaluation in Griffon.
Currently we're pretty stuck on Peters or constant dissipation. While a user can specify their own dissipation rate, it is up to them to parameterize it. Seems like we should invert some of our design so that "Peters" is just another function for the dissipation rate, which Spitfire manages in general. Ideally someone could provide a function for the dissipation rate and let Spitfire scale it accordingly for a desired stoichiometric or maximum dissipation rate.
We could also consider supporting a general function, say chi(z, user_param1, user_param2, ...) for which we defer evaluation until the additional parameters are provided through a tabulation interface.
Currently the build_adiabatic_slfm_library method will actually solve the extinction problem before identifying that extinction has occurred. This is wasteful as the extinction solve can be difficult. We should make the compute_steady_state method smarter. A caveat here is that we could "predict" extinction simply due to a nonlinear solve being too aggressive. We would need to be careful here, perhaps rerunning the solve more conservatively to ensure that extinction is indeed expected.
Specifying the initial condition of a flamelet through the enthalpy instead of the temperature would be nice. Specifying the enthalpy defect also would be nice (using the linear enthalpy as a reference). This would simplify nonadiabatic, nonstrained library creation.
In general we could consider letting a user define a function that parameterizes a Cantera Solution/Quantity given the mixture fraction.
Currently we have scripts and notebooks in the spitfire_demo folder, the Sphinx documentation that includes background theory and some pointers towards scripts, and the Sphinx-ified API documentation.
I think a better approach is to leverage Sphinx for API and background theory documentation, and provide a guide in the readme with links to online html-converted notebooks in the spitfire_demo folder. This should be easier to maintain and more helpful to users in getting started. Much more hands-on.
At the moment odesolve can identify a step as unsuccessful and change the time step, force a linearization update, print a warning, raise an exception, etc. We should add the option of retrying the step that just failed (with the new linearization, etc.)
Let a user specify a list of times for odesolve that are matched precisely during time stepping. Spitfire makes sure to nail the exact final time specified, so a user can already do this themselves by restarting with several odesolve calls, but it would be nice to provide the feature for them and automatically handle output concatenation, etc.
The readthedocs builder has broken.
Cantera 2.5 (possibly 2.4, not 2.3) complains very verbosely about Troe reactions with a zero value of the T2 parameter. We should fix the mechanisms used in Spitfire's tests and demonstrations.
We need to clarify the use of state within the flamelet class. For certain things like steady solves we simply use Flamelet instances once and keep rebuilding new ones (build_adiabatic_slfm_library), while in other cases we build a Flamelet and "keep it around" for a while (nonadiabatic, nonstrained library builders). This is a subtle distinction but it's important. We've redesigned around FlameletSpec, which is a persistent container of data required to set up a flamelet calculation. Should we reduce the Flamelet class to functions that return FlameletResult instances that are similarly persistent? It's not ideal to have an ambiguous mix between single-use and persistent data structures, which I think Flamelet falls into right now.
This is relevant to arc length continuation. Do we treat that like transient flamelets where a Flamelet instance provides the entire trajectory, or because we are continuating over the dissipation rate in arc length, do we have to make new Flamelet instances (in which case it wouldn't make sense for Flamelet to have an arc length member function).
Library classI have to imagine this is possible, but I have no clue how to do it. I also lack real Windows resources to test it out... But we've seen several tickets recently so this may be worthwhile.
Currently it is frustrating to use Python multiprocessing because Cantera objects cannot be pickled directly. Making ChemicalMechanismSpec objects pickleable will dramatically simplify the use of processor pools to run ensembles of flamelets and reactors in parallel. We can follow the approach taken in the spitfire.chemistry.tabulation module that sidesteps the Cantera issue in generating nonadiabatic SLFM tables.
It would be good to let users add to the right-hand side (or residual) vector along with some contribution to the Jacobian matrix, ideally without requiring detailed knowledge of the internal indexing details. This should actually be pretty easy to support...
Currently PDF convolution can be parallelized over properties. This is a problem for many flamelet libraries with Arrhenius properties (likely...), as a load imbalanace leads to one property taking 5-10x longer than the rest of the table. A natural solution to this is to add parallelism - parallelize over both properties and the newly added convolution dimension (typically the scalar variance).
In your experience, is there a feasible path to extend Spitfire to handle non-ideal equations of state? Something like using a cubic eos to model behavior of supercritical flamelets for counter-flow diffusion configurations for example? Is such a thing on the radar for future Spitfire capabilities?
Adding the capability to build tables 'appended' with mixing variables as in presumed PDF models would enable direct application of data from Spitfire in solving turbulent combustion problems with RANS/LES. This is currently a major gap that could slow adoption of Spitfire in 'real' simulation codes. Recent work developed this capability using clipped Gaussian PDF code from the TabProps code at the University of Utah and SciPy integration, together with built-in multiprocessing, to accomplish efficient, accurate PDF convolutions. This work could be expanded, tested, and incorporated into Spitfire reasonably quickly. A nice feature of using Python to drive the convolution integrals would be user-defined PDFs.
slicing for Library instances, so that lib[..., ..., ...] returns a new library with sliced dimensions and properties
__str__ and __repr__ for Dimension and Library instances to facilitate comprehending a complex library from a black box method (in an interactive environment)
make library slicing return a view, similarly to numpy - this makes copy semantics the same (since we don't have 'magic' indexing for the library', not yet at least...)
remove the unstructured dimension capability, that can go back in when there is a clear driver
enable flamelet and reactor initialization from a library slice
Library for reactors and flamelets (with rethinking extensibility of the library more generally), or, when building a library from reactor or flamelet solvers, include in the extra_attributes dictionary some other things:
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.