Closed ischoegl closed 12 months ago
Merging #1538 (db00fe1) into main (f89efe8) will decrease coverage by
0.03%
. The diff coverage is80.00%
.:exclamation: Current head db00fe1 differs from pull request most recent head 7bba1d2. Consider uploading reports for the commit 7bba1d2 to get more accurate results
@@ Coverage Diff @@
## main #1538 +/- ##
==========================================
- Coverage 70.50% 70.47% -0.03%
==========================================
Files 376 376
Lines 59075 59081 +6
Branches 21219 21222 +3
==========================================
- Hits 41649 41636 -13
- Misses 14348 14365 +17
- Partials 3078 3080 +2
Impacted Files | Coverage Δ | |
---|---|---|
include/cantera/base/fmt.h | 66.66% <ø> (ø) |
|
src/base/SolutionArray.cpp | 78.57% <76.19%> (-0.28%) |
:arrow_down: |
interfaces/cython/cantera/onedim.py | 82.63% <100.00%> (ø) |
|
src/base/AnyMap.cpp | 83.26% <100.00%> (ø) |
|
src/oneD/Boundary1D.cpp | 55.39% <100.00%> (ø) |
|
src/oneD/StFlow.cpp | 82.18% <100.00%> (ø) |
... and 4 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
For Cantera 3.0, I would prefer to maintain compatibility with fmt 6.1.2, which is the version available on Ubuntu 20.04 LTS. While using the submodule is reasonably convenient for users compiling on their own systems, it is highly undesirable when building Debian packages.
For Cantera 3.0, I would prefer to maintain compatibility with fmt 6.1.2, which is the version available on Ubuntu 20.04 LTS. While using the submodule is reasonably convenient for users compiling on their own systems, it is highly undesirable when building Debian packages.
Alright. I currently don't have a machine to test 6.1.2 (Apple silicon conda refuses to install fmt < 7.1), but I believe the PR by itself is worthwhile even if it does not resolve #1526 (it does fix two other unrelated issues). I set the minimum fmt version to 6.1.2, and removed code that assumed fmt 7.1 capabilities. I'd appreciate if we could merge this before tackling #1526?
PS: same on Windows 😠
Could not solve for environment specs
The following package could not be installed
└─ fmt 6.1.2** does not exist (perhaps a typo or a missing channel).
@speth ... thanks for your comments; everything should be taken care of.
With this one, I think we still need a
python-version
list if we want it to run all the combinations ofpython-version
andvs-toolset
. In the latest CI run, this only ran (VS 14.1, Python 3.11, fmt 7.1) and (VS 14.3, Python 3.11, fmt 7.1).
Fixed!
Changes proposed in this pull request
Frequent API changes in the {fmt} library have led to numerous workarounds in
fmt.h
. At the same time, the library is small (especially after version 7.0) and can be easily included from a git submodule. Note that the latest released {fmt} version is 10.0.default
setting.fmt.h
SolutionArray::save
CSV writing to {fmt}If applicable, fill in the issue number this pull request is fixing
Closes #1537, closes #1540
If applicable, provide an example illustrating new features this pull request is introducing
While this is was not an objective of the PR, the
SolutionArray
CSV writer speed was improved significantly. Formain
, the benchmark is:Using the proposed PR (switch to {fmt}), this reduces to
This could potentially be further improved by using version 7.1
fmt/os.h
file output (1.52 ms) and/or the compile-time format string compilationFMT_COMPILE
, but a major caveat is that the latter is not compatible withicc
(beyond only being available after 7.0). Note that YAML output is significantly slower (bottlenecks are elsewhere), so the possible optimization is not worthwhile:Checklist
scons build
&scons test
) and unit tests address code coverage