Fix issues with 1D flame solver#1705
Conversation
The empty string / Python None object correspond to the 'none' transport model, never to the 'default' transport model defined by the YAML file. Resolves Cantera#1680
Resolves side-issue noted in Cantera#1680
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1705 +/- ##
==========================================
+ Coverage 75.69% 75.72% +0.02%
==========================================
Files 443 443
Lines 60971 60981 +10
Branches 9552 9557 +5
==========================================
+ Hits 46154 46178 +24
+ Misses 11786 11777 -9
+ Partials 3031 3026 -5 ☔ View full report in Codecov by Sentry. |
"-q" flag suppresses output of what package versions are being installed, unlike the same flag for conda.
122b4d4 to
2176966
Compare
|
I'm going to leave the Windows .NET CI failure alone for the sake of this PR. I tried testing locally and can't replicate it. |
|
@AH9316 Are you using a compiled version of the main branch version of Cantera? These changes haven't been released yet through the standard channels yet. |
|
Thank you for your quick response, I am using the normal user version now
and trying to create a script to find the extinction stretch rate for
counterflowtwinflame. I saw there is the example for diffusion flame,
however I am not sure we can use the same way to get it.
My personal thoughts is either to keep the domian size Z as fixed and to
increase the exit velocity, then in the Tmax Vs K plot, I can see the
maximum stretch rate for flame. But this is not accurate since the
calculated maximum stretch rate is basically dependent on the incremental
step of velocity and when we couldn’t find a solution for the counterflow
flame. I am thinking if we can restart the flame just before one step of
the extinction and change the initial temperature profile to skip the
singularity point, that may give us another solution that can help us to
identify the exact extinction stretch rate buy fit all Tmax vs K points.
I am not sure if it makes sense, or if the Cantera already has a function
to find it for counterflowtwinflame.
Chris Neal ***@***.***>于2024年9月20日 周五10:05写道:
… @AH9316 <https://github.com/AH9316> Are you using a compiled version of
the main branch version of Cantera? These changes haven't been released yet
through the standard channels yet.
—
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AL24F2MX227T7R6UEOQF7YDZXRIVLAVCNFSM6AAAAABI53WBCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGE2TGOBXHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
If you are using the Python interface, the counterflow example that finds the extinction point should work fine if you are simply interested in the strain rate at extinction. Your method of using a constant domain and increasing the mdot at the boundaries should also work, and in cases where your incremented mdot fails to solve, you can simply reduce the mdot increment and call the solve() method again in a loop. If you want to obtain the flame all the way down the unstable branch, then in the next coming release of Cantera there is a two-point control continuation method that was added to the counterflow solver. |
|
Thanks, Chris, that sounds good!
Chris Neal ***@***.***>于2024年9月20日 周五11:09写道:
… If you are using the Python interface, the counterflow example that finds
the extinction point should work fine if you are simply interested in the
strain rate at extinction. Your method of using a constant domain and
increasing the mdot at the boundaries should also work, and in cases where
your incremented mdot fails to solve, you can simply reduce the mdot
increment and call the solve() method again in a loop. If you want to
obtain the flame all the way down the unstable branch, then in the next
coming release of Cantera there is a two-point control continuation method
that was added to the counterflow solver.
—
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AL24F2IF2AZ36Y27ZVW2ZWLZXRQGLAVCNFSM6AAAAABI53WBCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGI3DMOBZG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Changes proposed in this pull request
This PR fixes a number of issues with the 1D flame solver.
nonetransport model. The stringdefaultneeds to be specified to activate the YAML-specified transport model. Resolves SelectingNoneastransport_modelfor a 1D flame gives no error but selects default #1680TestCounterflowPremixedFlameNonIdeal::test_solve_case1was previously taking upwards of 30 seconds to run on GitHub Actions.Checklist
scons build&scons test) and unit tests address code coverage