-
-
Notifications
You must be signed in to change notification settings - Fork 398
Energy equation for reactors using PlasmaPhase #2068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2068 +/- ##
==========================================
- Coverage 76.75% 76.66% -0.09%
==========================================
Files 457 457
Lines 53744 53825 +81
Branches 9122 9135 +13
==========================================
+ Hits 41250 41266 +16
- Misses 9386 9454 +68
+ Partials 3108 3105 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
BangShiuh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mquiram Thanks for working on this. I left some comments for the changes in class PlasmaPhase.
| } | ||
| return m_eedfSolver->getElectronMobility(); | ||
| } else { | ||
| throw NotImplementedError("PlasmaPhase::electronMobility", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Electron mobility can be supported without Boltzmann-two-term if we provide the cross-section data and the EEDF. The equation is different according to the bolsig document. I am fine with the current implementation. But I would make another PR to improve this so that the plasma reactor can be more flexible. In addition, IonGasTransport.::getMobilities can use the electron mobility. We can cache the electron mobility value in PlasmaPhase so we don't need to call getElectronMobility() when it stays the same value.
| // sigma = e * n_e * mu_e [S/m]; q_J = sigma * E^2 [W/m^3] | ||
| const double mu_e = electronMobility(); // m^2 / (V·s) | ||
| if (!(mu_e > 0.0) || !std::isfinite(mu_e)) { | ||
| return 0.0; | ||
| } | ||
| const double ne = concentration(m_electronSpeciesIndex) * Avogadro; // m^-3 | ||
| if (!(ne > 0.0) || !std::isfinite(ne)) { | ||
| return 0.0; | ||
| } | ||
| const double E = electricField(); // V/m | ||
| if (!std::isfinite(E) || E == 0.0) { | ||
| return 0.0; | ||
| } | ||
| const double sigma = ElectronCharge * ne * mu_e; // S/m | ||
| return sigma * E * E; // W/m^3 | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think checking std::isfinite for each term is needed. The error should be caught when calling the function. We can check if any term is or smaller than zero and return zero..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. This, along with lines 577-579 is a sort of debugging artifact, and I agree that it's now unnecessary looking back at it.
| if (!std::isfinite(q_elastic)) { | ||
| return 0.0; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this? Can we issue an error instead?
…ng single temperature
… tests g_eq_sum_gk_Xk
Changes proposed in this pull request
Checklist
scons build&scons test) and unit tests address code coverage