Merging Casey's Thesis Work #265

csdechant · 2024-11-22T18:04:12Z

This PR directly addresses and should close Issue #257. This PR is based on @cticenhour thesis-rebase branch, excluding $H_{\phi}$ objects. The main focus of this PR includes:

The includes of a new material object, FieldSolverMaterial, which allows uses to supply the electric field terms in the drift-diffusion equation as a electrostatic potential variable or a vector electric field variable.
A material object to calculate the plasma dielectric coefficient.

This PR also includes updates based on @csdechant ZapdosAD-plus (which was rebased early on into the thesis-rebase branch), the excluding FV objects. That work includes:

Kernel objects for the electron energy flux using a thermal conductivity and an effected electric field calculation for ions.
Boundary conditions objects using an effected electric field calculation for ions and a dielectric time integral boundary condition.
Tests based on the method of manufactured solutions (MMS).
Minor bug fixes to the Newton-Shooting method acceleration objects.

Note that the electromagnetic test is temporary and will be replaced when the electromagnetic module is enabled via MOOSE submodule update.

… params.

Gold files are based on devel branch

…y flux

…trostatic conditions.

csdechant · 2024-11-22T18:07:58Z

@cticenhour this PR has a lot of commit to begin with. I am in favor of squashing all the commit into one, but since this PR is based on your old branch, I wanted to get your opinion first.

csdechant · 2024-11-22T18:21:13Z

@cticenhour I am fixing the Precheck errors and one of them is a "banned keywords" error. The PlasmaDielectricConstant material object uses std::cout. I am suggest that I just comment out the section of code and leave a NOTE: comment stating that users can uncomment this section of code for debugging purposes. What are your thoughts?

moosebuild · 2024-11-22T23:38:25Z

Job Precheck, step Clang format on 7014a11 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/zapdos/docs/PRs/265/clang_format/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 402e17523a5ef51b0dac40c3c8175cd976b6ce48

moosebuild · 2024-11-22T23:48:25Z

Job Documentation, step Sync to remote on c17657f wanted to post the following:

View the site here

This comment will be updated on new commits.

csdechant · 2024-11-26T16:13:22Z

@cticenhour @gsgall This PR is ready for review. The same as for the other active PR, #263, @gsgall is planned to be the primary reviewer (since this PR involved Casey's and my work). There are two issues I want to point out:

Depending on which PR is merged first (this one or Updating Doc String: Address Issue #258 #263), the other PR will most likely need to be rebased due to replacing _grad_potential with _electric_field.
There is a test fail due to a Exodiff for tutorial/tutorial05-PlasmaWaterInterface. In particular, the difference is with the Current_OHm and EFieldx1 auxvariables with a relative difference of 3.46855e-05 and 1.67417e-05, respectively. This error only occurs with CIVET and I have not been able to replicated with my Mac (Intel processor). I am in favor of increasing the ceiling threshold for these variables, but I wanted you guys input first.

- input parameters were made consistent with issue shannon-lab#223 - secondary electron emmision coefficients were made material and species dependent - secondary electron energy was moved to a BC input parameters - several test inputs were updated in order to facilitate this as well

- made all member variables that can be const, const for the BCs - also moved any variable declaration in a member function to be a member variable - all of the secondary electron emmision coefficients were also made material properties

…jects Due to the git history involving a mixture of edits between the HPhiCylindricalPlasma and PlasmaDielectricConstant kernel objects and the PlasmaDielectricConstant material object, there is no clear breaking point the only includes the PlasmaDielectricConstant material object without substantial re-work. For this reason, the kernel objects will be removed from this branch and worked in the based branch until further notice.

…mentation

…er documentation

Removing the FaradayCurrentBC object since it belongs to the HPhiCylindricalPlasma set of objects. These objects will be work on in a seperate branch.

AddPeriodicControllers and Shooting Method Kernels were updated in previous commits (868f397 and 2c20476, respectively) which resulted in changes in the tests that involve these objects. This commit addresses those test changes.

…t, and make mms test heavy

gsgall · 2024-11-27T22:32:07Z

@csdechant Is the testing strategy of this PR similar to the larger physics based testing used for the majority Zapdos testing? Or is it more math based, focusing on the simplest tests possible for each kernel, i.e having a single kernel in an input whenever possible.

@gsgall All new test are math based (MMS to be exact) and in my option, all new tests in Zapdos should be against some type of known solution (either analytical or MMS) and any new test based on validation should be on a case-by-case basis. For the new MMS test, they are designed to test problems of increase coupling (i.e. one for diffusion-only, next with advection-diffusion with a function potential, next with advection-diffusion with variable potential, etc.).

The reason for the large gold files is that these MMS tests use solutions designed for an RF discharge, so the test are for one RF cycle. The current tests looks at every time step, so the gold files are big (in honesty, I could probably increase the step size too, as the original step size was chosen to be significantly small enough not to interfere with spatial convergence studies).

@csdechant Is there a reason we cannot just a steady state mms test for each Kernel individually? Testing with increasing coupling over an entire RF cycle seems like it is overkill for testing each Kernel and a bit redundant. I don't really see a need to have these tests be a transient simulation if the Kernel is not a time derivative. If we guarantee that each kernel works as expected on its own we should be able to guarantee the expected behaviour of our system, since MOOSE takes care of using multiple kernels in one system. I would like to advocate for a simpler testing approach. A single steady state test MMS test for each kernel where each test uses only as many objects as strictly necessary for testing a specific kernel, ideally a single kernel per input, if possible. I would also like to see our testing convention be something closer to the MOOSE convection of separating the tests by what type of object we are testing (Kernel, AuxKernel, ..., etc.).

The other concern, along with the size of gold files, I have with these tests is the amount of time it takes to run the test suite. Checking out the CI, testing, https://civet.inl.gov/job/2565410/, it shows that this test suite takes a little over 7 minutes to run. It also shows an average test time of 16 seconds, even when running the tests in parallel. I really think we should be aiming to decrease this to somewhere around a few seconds for each test, unless there is a specific reason we need these extended tests.

closes shannon-lab#257

…due to edits in shooting acceleration method

…ter to better match the tolerances in mean_en

csdechant · 2024-11-27T23:58:17Z

@csdechant Is there a reason we cannot just a steady state mms test for each Kernel individually? Testing with increasing coupling over an entire RF cycle seems like it is overkill for testing each Kernel and a bit redundant. I don't really see a need to have these tests be a transient simulation if the Kernel is not a time derivative. If we guarantee that each kernel works as expected on its own we should be able to guarantee the expected behaviour of our system, since MOOSE takes care of using multiple kernels in one system.

These MMS test were to verify Zapdos for the uses of RF discharges, so the manufactured solution should represent a simple, yet similar, solution of a RF discharge. The reason for that is one should not assume that since two separate parts of codes work as intended, that the coupled version will work and shouldn't be tested. This is similar to the idea between unit vs integration testing. While MOOSE combines the residuals and handles the Jacobians of multiple kernels, that does not ensure that the coupled model will behave as expected (just an example, what if a developer coded a variable or material as non-AD when it should be AD? The non-couple test will show no error, as there is no coupling of variables, and MOOSE doesn't know it should be AD, MOOSE will just provide an incorrect Jacobian).

I would like to advocate for a simpler testing approach. A single steady state test MMS test for each kernel where each test uses only as many objects as strictly necessary for testing a specific kernel, ideally a single kernel per input, if possible. I would also like to see our testing convention be something closer to the MOOSE convection of separating the tests by what type of object we are testing (Kernel, AuxKernel, ..., etc.).

I agree and disagree with this to a point (maybe it is just wording). My view is similar, as Zapdos should have more simple cases (similar to the MOOSE framework), but also my rigid coupled cases (similar to other MOOSE modules, such as the Navier Stokes module). My vision for the Zapdos testbed is as such:

Have a type of "unit test" system that test just one kernel at a time (This is not a "true" unit test, as these are not testing single functions). These would be strictly non-heavy tests.
Have a type of integration test system that test the coupling of multiple kernels and actions to verify the intended models of Zapdos. This would be a mixture of non-heavy and heavy tests, depending on run time. These should be coarse version of more rigid verification tests.
Have a system of verification tests. These are full convergence study test that compare the CSV files output and plot convergence slopes. These are marked as heavy, by default, and will generate verification/convergences plots for the Zapdos website (similar to TMAP8).
Finally, have a system of validation tests. Similar to the verifications test, these test will be marked as heavy, by default, and if need will be marked as hpc-heavy. These tests too will generate plots for the Zapdos website (similar to TMAP8 validation tests).

The other concern, along with the size of gold files, I have with these tests is the amount of time it takes to run the test suite. Checking out the CI, testing, https://civet.inl.gov/job/2565410/, it shows that this test suite takes a little over 7 minutes to run. It also shows an average test time of 16 seconds, even when running the tests in parallel. I really think we should be aiming to decrease this to somewhere around a few seconds for each test, unless there is a specific reason we need these extended tests.

I just push a commit to reduce the gold files and run time. Also, the new MMS test are marked as heavy, so they will only run if a user inputs ./run_tests -jn --heavy. It seems CIVET for Zapdos runs all the test together instead as a separate Test Heavy, like for MOOSE and MOOSE module PRs. @cticenhour Is there a setting to separate regular vs heavy test, so it doesn't seem like develops are submitting longer test without heavy = True?

@gsgall Please let me know if you have any question or different options as what I have stated above. @cticenhour We talked about this a little offline about revamping the Zapdos testbed, in regards to Issue #261. Please let my know if you have any comments or concerns about the about vision for the Zapdos testbed.

gsgall

In general most of my comments are small changes.

There are a few things that I need to be address but this PR may not be the right place for them. But, here is a summary of those changes:

There are a lot of files in this PR which do not adhere to const correctness.
Some files have MooseVariables as class member variables but only use those during construction. Unless there is a good reason those should not be member variables but temporary constructor variables for the class.
A lot of header files are missing proper documentation for all variables, functions and function parameters.
Some of the files which add new functionality do not fully support multi-ion systems. Nor do they use materials for secondary emission coefficients like the rest of the current Zapdos implementation.

gsgall · 2024-12-22T15:10:45Z

doc/content/source/auxkernels/Current.md

 Where $N_{j}$ is the molar density of the specie in logarithmic form, $N_{A}$ is Avogadro's number, $l_{c}$ is the scaling factor of the mesh.

 For the case of the where artificial diffusion is introduced to the charge specie flux, an additional term is included in the current density, such that:



Suggested change

Where $N_{j}$ is the molar density of the specie in logarithmic form, $N_{A}$ is Avogadro's number, $l_{c}$ is the scaling factor of the mesh.

For the case of the where artificial diffusion is introduced to the charge specie flux, an additional term is included in the current density, such that:

Where $N_{j}$ is the molar density of the species in logarithmic form, $N_{A}$ is Avogadro's number, $l_{c}$ is the scaling factor of the mesh.

For the case of the where artificial diffusion is introduced to the charge species flux, an additional term is included in the current density, such that:

gsgall · 2024-12-22T15:12:06Z

doc/content/source/auxkernels/DriftDiffusionFluxAux.md

@@ -5,16 +5,16 @@
 ## Overview

 `DriftDiffusionFluxAux` returns the simplified drift-diffusion flux of a species. `DriftDiffusionFluxAux`
-assumes a mobility and diffusion coefficient of unity, the electrostatic approximation for the electric field, and a non-scaled version of the specie's density.
+assumes a mobility and diffusion coefficient of unity and a non-scaled version of the specie's density.


Suggested change

assumes a mobility and diffusion coefficient of unity and a non-scaled version of the specie's density.

assumes a mobility and diffusion coefficient of unity and a non-scaled version of the species density.

gsgall · 2024-12-22T15:13:10Z

doc/content/source/auxkernels/EFieldAdvAux.md

@@ -4,20 +4,19 @@

 ## Overview

-`EFieldAdvAux` returns electric field driven advective flux of defined species in logarithmic form. `EFieldAdvAux`
-assumes the electrostatic approximation for the electric field.
+`EFieldAdvAux` returns electric field driven advective flux of defined species in logarithmic form.


Suggested change

`EFieldAdvAux` returns electric field driven advective flux of defined species in logarithmic form.

`EFieldAdvAux` returns electric field driven advective flux of a defined species in logarithmic form.

gsgall · 2024-12-22T15:14:12Z

doc/content/source/auxkernels/EFieldAdvAux.md

 `EFieldAdvAux` is defined as

 \begin{equation}
-\Gamma_{\text{Advection}}  = N_{A} \text{sign}_{j} \mu_{j} \frac{\text{-} \nabla (V)}{l_{c}} \exp(N_{j})
+\Gamma_{\text{Advection}}  = N_{A} \text{sign}_{j} \mu_{j} \frac{\vec{E}}{l_{c}} \exp(N_{j})
 \end{equation}

 Where $N_{j}$ is the molar density of the specie in logarithmic form, $N_{A}$ is Avogadro's


Suggested change

Where $N_{j}$ is the molar density of the specie in logarithmic form, $N_{A}$ is Avogadro's

Where $N_{j}$ is the molar density of the species in logarithmic form, $N_{A}$ is Avogadro's

gsgall · 2024-12-22T15:15:04Z

doc/content/source/auxkernels/PowerDep.md

@@ -5,26 +5,25 @@
 ## Overview

 `PowerDep` returns the amount of power deposited into a user specified specie by


Suggested change

`PowerDep` returns the amount of power deposited into a user specified specie by

`PowerDep` returns the amount of power deposited into a user specified species by

gsgall · 2024-12-22T16:56:59Z

src/actions/AddDriftDiffusionAction.C

-    mooseError("There are electrons or charged_particles that are missing their potential! Please "
-               "check your input.");
+  if (!field_present && (em_present || (number_ions > 0)))
+    mooseError(


This could probably be more informative if we used a paramError instead of a mooseError

gsgall · 2024-12-22T16:57:38Z

src/actions/AddDriftDiffusionAction.C

    mooseError("There are secondary_charged_particles that are missing their corresponding "
-               "effective potential (eff_potentials)! Please check your input.");
+               "effective fields (eff_fields)! Please check your input.");


Similar suggestion here, using paramError rather than a mooseError.

gsgall · 2024-12-22T17:01:27Z

src/actions/AddPeriodicControllers.C

      }

      // If control cycles are back to back, then disable_start and disable_end times would be the
      // same, To avoid this, if cycles are back to back, then the disable_end starts at +
      // 0.0001*period
-      if (_cycles_per_controls == 1.0)
+      if (_cycles_between_controls == 1.0)


We really shouldn't be doing this sort of float equality comparison. we should be using the absolute fuzzy equals functionality for this sort of comparison.

gsgall · 2024-12-22T17:12:38Z

src/materials/FieldSolverMaterial.C

+    mooseError("Solver mode is electrostatic, but electric field was provided. Please either "
+               "change the mode or provide a potential variable.");
+  }
+  else if (_mode == ELECTROMAGNETIC && parameters.isParamSetByUser("potential") &&
+           !parameters.isParamSetByUser("electric_field"))
+  {
+    mooseError("Solver mode is electromagnetic, but potential was provided. Please either change "
+               "the mode or provide an electric field variable.");
+  }
+  else if (parameters.isParamSetByUser("electric_field") &&
+           parameters.isParamSetByUser("potential"))
+  {
+    mooseError("Both electric field and potential variables have been provided. Please provide "
+               "only one, consistent with the solver mode parameter.");
+  }
+  else if (!parameters.isParamSetByUser("electric_field") &&
+           !parameters.isParamSetByUser("potential"))
+  {
+    mooseError("Neither potential nor electric field variables are defined. Please provide a "
+               "variable for field determination.");
+  }


These should be using paramError instead of mooseErrors.

gsgall · 2024-12-22T17:14:33Z

src/materials/Water.C

+  _EField[_qp] = _electric_field[_qp](0); // TODO: does this need to be 0 component now? consider
+                                          // fixing this up....1D will request the 0 by default


are these going to be addressed in this PR or a later one?

cticenhour and others added 22 commits November 7, 2024 14:50

Add FieldSolverMaterial and tests

06d3a9d

Note that the electromagnetic test is temporary and will be replaced when the electromagnetic module is enabled via MOOSE submodule update.

Convert kernels to solver material

a0d53e2

Convert materials to solver material, and remove extraneous potential…

f2339ab

… params.

Convert bcs to solver material

75c2c33

Convert auxkernels to solver material

7450f3e

Convert postprocessors to solver material

ec48303

Convert dgkernels to solver material

7189f2e

Convert interfacekernels to solver material

2322d19

Fixup tests that do not use DriftDiffusionAction

29a03fc

Enable electromagnetics module

efb898f

Re-gold ES field test

b4b86d8

Fixup more non-DriftDiffusionAction inputs after rebase

0233c10

Convert DriftDiffusionAction and associated inputs

cd57bcf

Fixup tutorial inputs with new syntax

398a56f

Convert tutorial tests to exodiff

ca8b63f

Gold files are based on devel branch

Clean-up unused parameters

5944fc0

Fixup compiler warning

79b16cb

Fixed minor error for 'AddPeriodicControllers'.

868f397

Adding option for a 'thermal conductivity' version for the mean energ…

2185c5c

…y flux

Adding option the calculate and use an effective Efield assuming elec…

1973fab

…trostatic conditions.

Updating Acceleration By Shooting Method

2c20476

Adding Dielectric BC based on the integral form

de1bcbc

csdechant requested review from cticenhour and gsgall November 22, 2024 18:05

csdechant force-pushed the Casey-Thesis-No-HPhi-Objects branch from 7fa241a to a8a7474 Compare November 22, 2024 23:03

MengnanLi91 and others added 19 commits November 27, 2024 15:11

Add default value for vector type input parameters shannon-lab#207

5f70f0e

Commenting out MMS test for re-work

a3b1fb7

Updating default values for vector inputs

fb5965f

Updating default values for vector inputs

83d04c9

Re-working shooting method accelerator

02e1d0a

Initial clean up after rebase

a510288

Removing 'GEC_2D' case study files'

0e86dae

Fixing MMS tests for FieldSolverMaterial update

c921a0a

Remove NeumannCircuitVoltageNew.h due to rebase error and update docu…

d5b3a72

…mentation

Updating documentation for new objects and fixing minor errors in old…

6c3bbf1

…er documentation

Removing FaradayCurrentBC

efea8f1

Removing the FaradayCurrentBC object since it belongs to the HPhiCylindricalPlasma set of objects. These objects will be work on in a seperate branch.

Updating documentation on DielectricBCWithEffEfield

398f831

Updating test for Shooting Method

cafb630

AddPeriodicControllers and Shooting Method Kernels were updated in previous commits (868f397 and 2c20476, respectively) which resulted in changes in the tests that involve these objects. This commit addresses those test changes.

Removing old file for Shooting Method test

2a4dbce

Adding missing rate coefficients for updated tests

21a0f77

Adding test for DielectricBCWithEffEfield and PlasmaDielectricConstan…

2526667

…t, and make mms test heavy

csdechant added 7 commits November 27, 2024 15:37

Updating docstring for new objects and cleaning up mms test input files

f87fdbf

closes shannon-lab#257

Removing trailing whitespace

0e08a36

Removing trailing whitespace again

91dfae1

Applying Clang format

bd36de8

Increasing testing time for MMS tests and fixing documentation error …

f43997e

…due to edits in shooting acceleration method

Changing the tolerances of current_OHm and Efield in DC_argon-With-Wa…

b24b0dd

…ter to better match the tolerances in mean_en

Including electromagnetics module in the unit makefile

c17657f

csdechant force-pushed the Casey-Thesis-No-HPhi-Objects branch from c37b2a6 to c17657f Compare November 27, 2024 22:57

gsgall requested changes Dec 22, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merging Casey's Thesis Work #265

Merging Casey's Thesis Work #265

csdechant commented Nov 22, 2024

csdechant commented Nov 22, 2024

csdechant commented Nov 22, 2024

moosebuild commented Nov 22, 2024

moosebuild commented Nov 22, 2024 •

edited

Loading

csdechant commented Nov 26, 2024

gsgall commented Nov 27, 2024

csdechant commented Nov 27, 2024

gsgall left a comment

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

gsgall Dec 22, 2024

		Where $N_{j}$ is the molar density of the specie in logarithmic form, $N_{A}$ is Avogadro's number, $l_{c}$ is the scaling factor of the mesh.

		For the case of the where artificial diffusion is introduced to the charge specie flux, an additional term is included in the current density, such that:

	assumes a mobility and diffusion coefficient of unity and a non-scaled version of the specie's density.
	assumes a mobility and diffusion coefficient of unity and a non-scaled version of the species density.

	`EFieldAdvAux` returns electric field driven advective flux of defined species in logarithmic form.
	`EFieldAdvAux` returns electric field driven advective flux of a defined species in logarithmic form.

		@@ -5,26 +5,25 @@
		## Overview

		`PowerDep` returns the amount of power deposited into a user specified specie by

		_EField[_qp] = _electric_field[_qp](0); // TODO: does this need to be 0 component now? consider
		// fixing this up....1D will request the 0 by default

Merging Casey's Thesis Work #265

Are you sure you want to change the base?

Merging Casey's Thesis Work #265

Conversation

csdechant commented Nov 22, 2024

csdechant commented Nov 22, 2024

csdechant commented Nov 22, 2024

moosebuild commented Nov 22, 2024

moosebuild commented Nov 22, 2024 • edited Loading

csdechant commented Nov 26, 2024

gsgall commented Nov 27, 2024

csdechant commented Nov 27, 2024

gsgall left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moosebuild commented Nov 22, 2024 •

edited

Loading