Plasma phase

[BangShiuh]

Changes proposed in this pull request

• Add PlasmaPhase for plasma thermodynamic properties.
• Fulfill part of Plasma phase enhancements#127

If applicable, fill in the issue number this pull request is fixing

Closes #

If applicable, provide an example illustrating new features this pull request is introducing

Checklist

• The pull request includes a clear description of this code change
• Commit messages have short titles and reference relevant issues
• Build passes (scons build & scons test) and unit tests address code coverage
• Style & formatting of contributed code follows contributing guidelines
• The pull request is ready for review

[codecov]

Codecov Report

Merging #1190 (eaab899) into main (b4616ef) will increase coverage by 0.02%.
The diff coverage is 71.76%.

@@            Coverage Diff             @@
##             main    #1190      +/-   ##
==========================================
+ Coverage   65.47%   65.50%   +0.02%     
==========================================
  Files         327      329       +2     
  Lines       46350    46664     +314     
  Branches    19688    19853     +165     
==========================================
+ Hits        30349    30566     +217     
- Misses      13476    13538      +62     
- Partials     2525     2560      +35     

Impacted Files	Coverage Δ
src/thermo/Phase.cpp	81.48% <ø> (+0.35%)	⬆️
include/cantera/thermo/Phase.h	83.67% <60.00%> (-0.95%)	⬇️
src/numerics/funcs.cpp	71.92% <65.21%> (-28.08%)	⬇️
src/transport/IonGasTransport.cpp	75.20% <66.66%> (-0.53%)	⬇️
include/cantera/thermo/PlasmaPhase.h	71.42% <71.42%> (ø)
src/thermo/PlasmaPhase.cpp	73.29% <73.29%> (ø)
include/cantera/thermo/IdealGasPhase.h	94.73% <100.00%> (ø)
src/thermo/IdealGasPhase.cpp	77.70% <100.00%> (ø)
src/thermo/ThermoFactory.cpp	71.27% <100.00%> (-0.12%)	⬇️
src/kinetics/KineticsFactory.cpp	90.56% <0.00%> (-1.36%)	⬇️
... and 6 more

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[bryanwweber]

Thanks @BangShiuh Just a couple of small questions here

[BangShiuh]

This PR is mostly done. One thing that I am not sure about is valuecache implementation. I hope I did it correctly. Another thing that might be a little confusing is the implementation of setElectronTemperature and setElectronEnergyDistrb. What I would like is that you can choose to use electron temperature to calculate electron energy distribution or you can use electron energy distribution to calculate electron temperature. Maybe there is a better to implement the mutually dependent relationship.

[ischoegl]

Hi @BangShiuh ... for starters, I have a very high-level comment: based on how things are implemented, Plasma really is just a specialization of Phase, correct? Insofar, I think it would make sense to group the new classes with other specializations (and treat PlasmaPhase the same as any other ThermoPhase), rather than to create an entirely new parallel structure?

[BangShiuh]

Hi @BangShiuh ... for starters, I have a very high-level comment: based on how things are implemented, Plasma really is just a specialization of Phase, correct? Insofar, I think it would make sense to group the new classes with other specializations (and treat PlasmaPhase the same as any other ThermoPhase), rather than to create an entirely new parallel structure?

Yes, I think we had some discussion in #700 and decided to put plasma in a separate folder so that thermo is not getting more crowded. But if you think that is not a problem, I can definitely move it back.

[ischoegl]

I think we had some discussion in #700 and decided to put plasma in a separate folder so that thermo is not getting more crowded. But if you think that is not a problem, I can definitely move it back.

I think these should be kept in the same folder, as having headers for a derived class in a separate folder is somewhat confusing.

[ischoegl]

One other thing I recalled from #1099 is this: #1099 (comment)

Could you include a mechanism here that makes Te track T for a regular IdealGasPhase?

[BangShiuh]

@ischoegl I have made Te = T for IdealGasPhase. I made the setElectronTemperature throw NotImplementedError. For now, m_electronTemp is private of Phase. Do you think I should change it to protected so that I can use it directly or I should keep it private and use Phase::setElectronTemperature?

[ischoegl]

I made the setElectronTemperature throw NotImplementedError. For now, m_electronTemp is private of Phase. Do you think I should change it to protected so that I can use it directly or I should keep it private and use Phase::setElectronTemperature?

I believe this approach makes sense (for anything not outside of PlasmaPhase). For PlasmaPhase, things will get more interesting ... at the same time I am wondering whether there even should be a setter for Te as it is part of the thermodynamic state and thus not necessarily an independent variable?

[BangShiuh]

@ischoegl Ultimately Te depends on T, E (electric field), and P. E provide energy for electron. Electrons lose energy to gas molecules which depends on gas density (pressure), gas temperature (weakly), and the collision cross-sections. So in the future, something like gas.TPE can be a way to set plasma state. Let me know if there is anything else that I can do in this PR.

[ischoegl]

@BangShiuh … at the moment, this PR is still in draft status?

[ischoegl]

Hi @BangShiuh ... thank you for responding to the first round of review comments. The current round is mostly about formatting (there are some choices that are different from those commonly found in Cantera source code).

Beyond, I still am not sure about the introduction of the Plasma class in Python; from my viewpoint, it is not sufficiently distinct from other bulk phases. It probably needs to be integrated into Solution one way or another before this is ready to be merged.

[ischoegl]

@BangShiuh ... thanks for making the Plasma Python API consistent with other thermo phases!

The solution was to cast the child class to the parent class after initiation and cast back to the child class when using its member functions. It is a little tedious. Maybe we can figure out better ways to do this.

This is pretty much what is done elsewhere across the board (even the underlying C++) ... see ReactionRate, various Reactor implementations, etc. . So I think there's nothing wrong with using the same approach here.

[ischoegl]

@BangShiuh ... Although I still have a couple of minor comments, this looks mostly good to me.

[speth]

Thanks, @BangShiuh. This looks good to me. I did a little bit of cleanup of the history and commit messages and pushed that to your branch.