lcpp-org / crane Goto Github PK

Any MOOSE headers that have been unintentionally left in the source code over the past year should be replaced with CRANE-specific headers.

Flagging this is an issue since I noticed it while working on fixing up CRANE documentation. There are many objects in CRANE that contain some version of the following header:

/****************************************************************/
/*               DO NOT MODIFY THIS HEADER                      */
/* MOOSE - Multiphysics Object Oriented Simulation Environment  */
/*                                                              */
/*           (c) 2010 Battelle Energy Alliance, LLC             */
/*                   ALL RIGHTS RESERVED                        */
/*                                                              */
/*          Prepared by Battelle Energy Alliance, LLC           */
/*            Under Contract No. DE-AC07-05ID14517              */
/*            With the U. S. Department of Energy               */
/*                                                              */
/*            See COPYRIGHT for full restrictions               */
/****************************************************************/

This is the MOOSE copyright header, and should not be used in CRANE. This issue can be closed when all of these headers have been removed from the code.

Two users have found that their input files (Zapdos-Crane) runs for hours when using a solve_type = newton, but for only ~30 minutes using solve_type = pjfnk (preconditioned jacobian-free Newton-Krylov). The only culprit for this behavior is an incorrect Jacobian calculation. Since Zapdos Jacobian calculations are fully automated, the error must be in Crane's reaction network.

Townsend-type electron impact reactions have already been converted to automatic differentiation, but the bug here is happening with rate-type electron impact reactions. This is a good opportunity to fully automate the rest of the jacobian calculations in Crane as well.

Task
Add automatic differentiation for the following reaction types:

• Rate-type reactions with tabulated rate coefficients
• Parsed function rate coefficients
• Constant rate coefficients

Impact
Improved convergence and reduced simulation time for users using Crane in 1D-3D. (This will have no effect on Crane in 0D since different variable and kernel types are utilized.)

In problems/lorentz_attractor.i, the input file fails to run with the following error:

*** ERROR ***
aux_rate0: Trying to get a non-existent variable ‘args'

This appears to be linked with the evaluation of the rate constants dependent on the variables ‘sigma’, ‘R’, and ‘p’ that are provided under ‘equation_constants’ and given values in ‘equation_values’. This is very confusing because this is the exact same structure used for some input files containing ‘Tgas’, “J’, and ‘pi’, among others.

Notes:

• No error is given when these constants and values are given but not utilized in the rate coefficient expressions.
• Copy-and-pasting the syntax and usage of ‘Tgas’ and etc from other input files does not work either.

INL's continuous integration (CI) system CIVET allows for testing of external MOOSE applications like CRANE, both within their own repository (PRs, branch merges, etc.) and as part of regular MOOSE PR testing - see this page for a recent set of results on the MOOSE next branch. CRANE could benefit from this workflow, given as up until now CRANE components have been tested only locally and as part of their usage in Zapdos.

Another change I would make would be the creation of a devel branch. After a PR merge, everything would be re-tested and then merged into master only when everything is passing. The branch testing would be where you might have extended testing in the future.....at first it might have the same test configurations - we call them "recipes" - as your PRs. This workflow protects your master branch from possible failure points that might occur when multiple people are working on the code. Having a devel branch is optional, but all of the INL MOOSE apps and several external apps use this structure.

To get this rolling, we would need to perform a few things:

• Add a MOOSE submodule to CRANE (I have a branch ready to submit for this shortly).
• Add CRANE to the list of tested external applications (I would perform this internally).
• Add a MOOSE webhook that allows GitHub to communicate with CIVET when a new event (like a PR or branch merge) occurs.
• Add a set of regular CRANE test configurations for PRs and branches. Again, I would do this internally and be your point of contact if you wanted to make changes. At first, I think we should base this on those found in Zapdos.

Happy to answer any questions you might have on this!

Tagging @smpeyres @dcurreli

Hi,

I am working on modeling a steady-state argon plasma.
Below is a section of the input file.

[ChemicalReactions]
[ScalarNetwork]
species = 'Ar4s Ar4p Arp Ar2p'
aux_species = 'Ar e'
equation_constants = 'Tgas'
equation_values = '300'
equation_variables = 'Te'
interpolation_type = 'linear'

reactions = 'e + Ar -> e + e + Arp         : {2.34e-14*Te^(0.59)*exp(-17.44/Te)}
                    e + e + Arp -> e + Ar         : 1e-40
                    Ar2p + Ar -> Arp + Ar + Ar    : {(6.06e-6/Tgas)*exp(-15130.0/Tgas)}'

[]
[]

At t = 0, output prints Te = 3 and Tgas = 300 but reaction_constant0 = 0, reaction_constant1 = 1e-40 and reaction_constant2 = 0.
Is there a way for crane to accept Te and Tgas into the reaction rates?
Within executioner, I am using type = Steady and solve_type = 'Newton'

This is something that I had just forgotten about, but it's necessary. Right now only one action is allowed at a time, which is insufficient if we have two or more regions which each have their own set of species and reaction pathways. (A plasma-liquid system, for example.)

Probably requires something like this in CraneApp.C:

s.registerActionSyntax("AddZapdosReactions", "ChemicalReactions/*");

Shouldn't be difficult, but if possible I don't want this to overwrite the currently available syntax.

Hi,
Archlinux 64-bit user here.
I downloaded moose and crane into projects using git with conda for the necessary files.

I am unable to run the tests successfully after making the program. What is the typical cause for EX0DIFF failing?
I have uploaded the output from my terminal when running:
./run_tests -j 12

Thanks for your help.

Myles
errors.txt

Many rate coefficients are given in functional forms, often in terms of electron and/or gas temperature. Occasionally other species are also included. Automatic differentiation does not work with parsed materials at the moment, so these need to be added manually.

Parsed rate coefficients are already using the DerivativeParsedMaterial class so the groundwork is in place. The actual derivative calculations need to be added and a new class of Kernels should be included to handle the parsed function jacobian contributions.

Dear developers of crane,

I am KenShu Ho. I got 10 errors while I tried to compile crane. It looks like the errors were generated during compiling meshgenerators. The log of compilation is attached. I installed my moose framework last Saturday. Could you please help me solve these problems?

Thank you very much for your help!
install20230508-1.log

Recently, with help of @csdechant, I've learned that CRANE is capable of steady solves, rather than just transient problems. This should've been a bit more obvious to me given that the ODETimeKernels are always written outside of the reaction action block, but nowhere on either the Zapdos or CRANE repository is there an example of using a CRANE reaction block in a Steady problem. The closest thing that exists is the Zapdos diffusion tutorial, which uses a reaction kernel from CRANE.

@csdechant has also shared with me a version of the input file that uses the CRANE reaction block instead, and I also wrote a version of the two-reaction argon problem with a steady solve that can be found on my fork. The steady-state results are identical to the transient solve and is significantly faster. Developing various examples of using the Steady solve and placing proper constraints on variables and constructing common models for circuits, particle balance, power balance, etc used in various plasma chemistry models will be of great benefit to many users of CRANE working on essentially steady-state problems.

Three main proposals, which could be written as tests:

• Steady-state TwoReactionArgon -> need to write as test
• Steady-state ArgonMicrodischarge -> write tutorial for transient one first
• Simple uniform discharge model including particle balance and power balance from Lieberman & Lichtenberg

In file included from /home/lindad/projects/zapdos/crane/build/unity_src/actions_Unity.C:2:
/home/lindad/projects/zapdos/crane/src/actions/AddGeneralReactions.C: In member function ‘virtual void AddGeneralReactions::act()’:
/home/lindad/projects/zapdos/crane/src/actions/AddGeneralReactions.C:365:93: warning: ‘non_electron_index’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  365 |                 std::find(_species.begin(), _species.end(), _reactants[i][non_electron_index]) !=
      |                                                                                             ^
In file included from /home/lindad/projects/zapdos/crane/build/unity_src/actions_Unity.C:4:
/home/lindad/projects/zapdos/crane/src/actions/AddScalarReactions.C: In member function ‘virtual void AddScalarReactions::act()’:
/home/lindad/projects/zapdos/crane/src/actions/AddScalarReactions.C:424:93: warning: ‘non_electron_index’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  424 |                 std::find(_species.begin(), _species.end(), _reactants[i][non_electron_index]) !=
      |                                                                                             ^
In file included from /home/lindad/projects/zapdos/crane/build/unity_src/actions_Unity.C:6:
/home/lindad/projects/zapdos/crane/src/actions/AddZapdosReactions.C: In member function ‘virtual void AddZapdosReactions::addEEDFEnergy(const unsigned int&, const string&)’:
/home/lindad/projects/zapdos/crane/src/actions/AddZapdosReactions.C:506:97: warning: ‘non_electron_index’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  506 |   params.set<std::vector<VariableName>>("target") = {_reactants[reaction_num][non_electron_index]};
      |                                                                                                 ^

I looked in the source for AddGeneralReactions and from the uninformed eye it definitely looks like non_electron_index could be uninitialized

Currently the reaction parser works, but it's sloppy. It is done entirely with C++ string parsing by identifying specific tokens and splitting each reaction one by one for loops. Each product and reactant for every reaction is recorded by looking for an exact string match, and the stoichiometric coefficient is implemented by tallying the number of times the exact match appears on each side of the equation. Accordingly, each kernel is named for the number of reactants it includes: FirstOrderReactant, SecondOrderReactant, FirstOrderProduct, SecondOrderProduct, etc... Besides being pretty misleading, this comes with a host of obvious problems:

1. Stoichiometric coefficients are included by writing out the number of reactants/products; e.g. e + Ar -> 2e + Ar+ must be written as "e + Ar -> e + e + Ar+". It is cumbersome to have to write out every reactant and product; imagine having a fake "reaction" (an empirical formula meant to simulate photoionization, for example) made up of dozens of products and reactants - writing such a formula out would be both obnoxious and prone to errors.

2. In a related matter, the above assumes order and stoichiometry are the same. This is not always the case, though it is usually true for typical plasma systems. No fractional orders are allowed.

3. There is really no need to have so many kernels...one product and reactant kernel with a loop in the constructor to count the number of reactants and multiply them together should be sufficient.

SOLUTIONS:

• A better parser that allows a reaction with "2e" to be read as "e + e".
• Modified kernels to include stoichiometric coefficient as an exponent in std::pow.
• (OPTIONAL) Better string parsing algorithm in general (possibly with Perl?).

Replacing kernels should be done with care. std::pow might incur a performance penalty.

User @csdechant requested the option to use a linear interpolation instead of a spline for tabulated rate coefficients.

Task
Add a Material to perform a linear interpolation of rate coefficients, and modify the Action system with a new input parameter "interpolation_type" with options 'spline' and 'linear'.

Impact
Splines can run into monotonicity-preserving issues, especially when forced to extrapolate beyond the input data set. Linear might be safer in some circumstances. This will allow users to choose whether to use splines or linear interpolations.

For input of 3 Td, interpolation is used to get rate coefficient from the reported data. Below are the nearby points.

E/N--------- k
2.848036------5.344192e-31
3.274549 ------7.650413e-28

ISSUE:
It is expected that, k should be between e-31 and e-28 for 3 Td. However, when “spline" interpolation was used, the chosen k value for 3 Td was1.18e-24 (spline.i file in in "Interpolation.zip").

ALTERNATE TRIED:
When interpolation was changed to “linear,” the chosen k value was 9.36e-29 (linear.i in "Interpolation.zip").

Interpolation.zip

In another case, with simple Two reaction for N2, for 30 Td, the "spline" picked k as 0, whereas the linear worked fine (N2-Interpolation.zip for reference)

N2-Interpolation.zip

I am getting the below error when I try to run the "argon_test.i" file.

../../crane-opt: symbol lookup error: /home/ananth/projects/moose/framework/libmoose-opt.so.0: undefined symbol: ZN7libMesh14MacroFunctions12report_errorEPKciS2_S2

This test is simply way too long for a test. Should be a replaced by a shorter version that runs in a fraction of the time or several mini-tests. A better place for this would be as a tutorial.

I installed crane, and all tests passed that i verified that its intalled successfully. After that, I tried to run example1 from the problems folder. and I am getting the following error.

*** ERROR ***
/home/ananth/projects/crane/problems/example1.i:41: unused parameter 'ChemicalReactions/ScalarNetwork/reaction_coefficient_format'

Stack frames: 10
0: libMesh::print_trace(std::ostream&)
1: moose::internal::mooseErrorRaw(std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >)
2: void mooseError<std::__cxx11::basic_string<char, std::char_traits, std::allocator >&>(std::__cxx11::basic_string<char, std::char_traits, std::allocator >&)
3: Parser::errorCheck(libMesh::Parallel::Communicator const&, bool, bool)
4: MooseApp::errorCheck()
5: MooseApp::executeExecutioner()
6: MooseApp::run()
7: main
8: __libc_start_main
9: ../crane-opt(+0x23ef) [0x558530fc83ef]
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
[unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
:
system msg for write_line failure : Bad file descriptor

Dear Crane developer.

Hello! I'm Samuel Park
I have a problem when I compile the crane
The problem is

###################################################################################
/home/samuel/CCA-E/crane/src/userobjects/BoltzmannSolverScalar.C:127:16: error: invalid conversion from 'const VariableValue*' {aka 'const MooseArray'} to '__gnu_cxx::__alloc_traits<std::allocator<MooseArray>, MooseArray>::value_type' {aka 'MooseArray'} [-fpermissive]
127 | _args[i] = &coupledScalarValue("mole_fractions", i);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| const VariableValue* {aka const MooseArray*}
make: *** [/home/samuel/CCA-E/crane/../../projects/moose/framework/build.mk:122: /home/samuel/CCA-E/crane/build/unity_src/userobjects_Unity.x86_64-conda-linux-gnu.opt.lo] Error 1
#############################################################################################

Yesterday I redownload the MOOSE Framework, I didn't change anything in my MOOSE Framework. (I just followed the script)
I think this problem is the first problem, so I can not find the solution in the moose-users group
How can I solve this problem???

Thank you for you guys help!

Three reactions are solved as a simple test case. Two reactions use “EEDF” to obtain rate coefficients from the external data file, and the third one has a constant rate coefficient.

ISSUE:
If the the reaction that uses “EEDF” is given as last, there is error in running the input file. But, if the reactions that use the EEDF are given first followed by the reaction that use constant rate coefficient as last, the input file runs OK. I am sharing both the input file for reference, and sharing below the reaction info used in both the input files.

1. Reaction order when issue was faced (FOLDER: EEDF-ISSUE_PROBLEM):

'e + Ar -> e + e + Ar+ : EEDF (ionization)
e + Ar -> e + Ar* : EEDF (excitation)
e + Ar+ + Ar -> Ar + Ar : 1e-25'

2. Reaction order when the issue was resolved (FOLDER: EEDF-ISSUE_FIXED):

reactions = 'e + Ar -> e + e + Ar+ : EEDF (ionization)
e + Ar+ + Ar -> Ar + Ar : 1e-25
e + Ar -> e + Ar* : EEDF (excitation)'

3. Also, for the input which contains just one reaction that calls for EEDF, worked just fine (shown below the reaction from input file, uploaded FOLDER: EEDF-ISSUE_FIXED2):

reactions = 'e + Ar -> e + e + Ar+ : EEDF (ionization)'

Input files for above three cases are in the uploaded zip "ISSUES" for your review. The error message is uploaded as text file.

ISSUES.zip

ERROR .txt

Within an N2O2 0D plasma case, the n2(a'1) species appears in multiple reactions but when input into scalar kernels and variables in such format there is an error to do with the parentheses and apostrophe not being valid characters. When these characters are removed though an error occurs where it says the n2(a'1) is missing. How would this be fixed? This is my first time actually using Github to report an issue so I apologize for this being unformatted and uneducated.

Legacy input parameter construction (validParams<T>) is being deprecated. Remove it and use the new input parameter construction (static InputParams validParams() on the object).

idaholab/moose#15331 will add parsed function with support for forward mode automatic differentiation. This requires a few small API changes. I'll provide a PR for this that can be merged after the MOOSE PR is in.

With a growing CRANE user base, especially of experimentalists who want to model their plasma experiment's chemistry, it's becoming clear that CRANE's documentation needs to be expanded to help onboard new users with minimal 1-on-1 assistance.

I have identified several notable tasks that could significantly enhance CRANE's documentation, especially for new users.

1. Set up and basic edits to ReadTheDocs.

• Set up ReadTheDocs website (Completed by @dcurreli, commit fc77a79)
• Put link in repo (Completed by @smpeyres)
• Flesh out "running" (Completed by @smpeyres, commit c2f0ccd)
• Flesh out "tutorials" page (see below)

2. Flesh out the tutorials on the ReadTheDocs to fully explain the setup and philosophy behind the three ZDPlasKin example used for testing, similar to ZDPlasKin's "Examples" tab on their webpage. In the future, more examples and tutorials can be added to explore different discharge types and chemical processes.

• Example 1 Two-Reaction Argon (Completed by @smpeyres, commit 61b0910)
• Example 2 Argon Microdischarge
• Example 3 Nitrogen Plasma with External E-Field and Electron Density (optional)

3. (Maybe no longer be necessary with ReadTheDocs) Improve and expand the user guide. Currently has some functionality, but this is the perfect place to put what can't fit in the wiki. The non-ZDPlasKin based examples such as the Lorentz attractor and the hydrogen CRM featured in the ArXiv preprint can be included. General practical guidelines for plasma chemistry modeling should be included as well (start simple, keep units consistent, maintain quasineutrality, useful formulas, etc). Additionally, .tex file should be kept in repository along with the .pdf for easier updates down the line.

• User guide: Obtain .tex file to current user guide pdf, if possible. If not, be prepared to re-write it.
• User guide: Include various examples (ZDPlasKin, Lorentz, CRM) with extended theory/explanation.
• User guide: Practical guidelines for plasma chemistry modeling.