Floating potential BC

Hi, per a discussion post, I wanted to see if it would be possible to have a floating potential Neumann BC, based on an ion, electron flux balance $\Gamma_e = \sum \Gamma_{i} $, with the $\nabla V$ solved for similarly to the NeumannCircuitVoltageMoles_kV BC.

Docker Image builds should be automated

Based on the success of #153, we should have some sort of action to generate and upload the docker image on each push to master as well. Docker themselves seems to have made one that might be worth looking into: https://github.com/marketplace/actions/build-and-push-docker-images

My question right now is - how much can we use the current script we have to generate and upload the image? Or do we need to start from scratch? Making an issue to note thoughts and explorations...

Turn off Legacy Dirichlet BC

See idaholab/moose#15448. Setting use_legacy_dirichlet_bc=false in ZapdosApp.C will cause some test failures (https://civet.inl.gov/job/545141/) that need to be fixed.

Fix deprecation errors

CIVET is failing Zapdos when testing for deprecated code. Opening a general issue to fix several noted in the most recent results (https://civet.inl.gov/job/296466/):

perf_graph needs to replace print_perf_log
registerObjects needs to be replaced with registerAll

Nothing dire here, but should be fixed eventually. I'll take a crack at it when I get a chance.

Secondary Electron Emission Issues

Reason

Secondary electron emission coefficients can be both species and material dependent. Right now we set a single value for the entire domain, which is fine for the moment but doesn't quite work for more complicated domains.

Design

Maybe the simplest path is to just have secondary electron emission coefficient(s) be an input parameter for the secondary electron BCs. It could be a single value or a vector of values so each ion can have its own SE coefficient on a boundary if the user wants.

If we want to keep it as a material property, it's also easy to include a GenericMaterialProperty that is restricted to a boundary so we have boundary-dependent SE coefficients. It's also not hard to include an additional material property in the HeavySpecies class so each species has its own coefficient. However, I don't know the best way to have both at the same time if we go the Material route. Either way, it should be taken out of GasElectronMoments and treated separately.

The secondary electron energy may also be remodeled at the same time to either be a user-input value (again, boundary-dependent) or specified based on the work function of that material.

Impact

This will allow boundaries to have more realistic secondary electron emission coefficients! Different species and surfaces will have different electron emission coefficients.

No way to view the syntax of available inputs that are exclusive to Zapdos on the website

At the moment there is no way to view the syntax of objects that are available in Zapdos without all of the objects that are available in MOOSE as well. This can be very overwhelming and a large portion of users will likely not need knowledge of all of the objects available in MOOSE.

Design Proposal

Add a tab to the Zapdos website which only shows the Syntax in Zapdos and allow viewers to see all of the objects available in MOOSE if required.

Changes required for file path cleanup in crane

lcpp-org/crane#125 introduces a default file_location parameter of the cwd. file_location = '' is no longer valid, because an empty path will resolve to the file root / in idaholab/moose#26945.

We'll need to correct for these in input. Namely, file_location = '' is no longer necessary as the default is the cwd.

Website improvements

This is a general issue/task list regarding the Zapdos website, now that we have something live and are iterating on it up to GEC (and beyond). Feel free to edit this and add tasks. Please reference this issue as you make PRs.

Updating and Adding Syntax Checks for "Problems" Input Files

As previously discussed from a recent PR (#68) and forum post (https://groups.google.com/g/zapdos-users/c/drMKqU1xQqI/m/3YveOuhnAgAJ), the "Problems" directory need to be update with the latest syntax and have a Syntax Checks for these files.

Fixup headers script needs to be updated to Python 3

Opening an issue as a reminder that scripts/fixup_headers.py is still only compatible with Python 2, while the rest of MOOSE has well moved on. Need to update this at some point, as the script will not function with the most up-to-date MOOSE environment.

Update README

We've done a significant shuffling of input files recently, and as a result our README directions are pretty out-of-date. This user (while having other issues) would run into problems trying to follow the README.

Need pressure dependent mobilities and diffusivities

Capability currently does not exist in Gas.C

Consistent naming conventions across all inputs

Motivation

Currently the same input parameter across a majority of the Zapdos objects is scattered and not immediately obvious. I would like to propose the following standard for input parameter naming conventions.

Description	input
Electron density in log-molar form	`electrons`
Mean electron energy multiplied by electron density in log form	`electron_energy`
Multiple Ion Densities in log-molar form	`ions`
Ion Specific Potentials	`ion_potentials`
Species dependent secondary electron emission coefficient	`emission_coeffs`

If there are other common inputs missing from this list please let me know or propose a standard for those as well. Or if others would like to propose potential modifications to these standards I am open to feedback as well!

This issue goes into helping resolve some parts of #49 and #73 as well and improve the user experience by reducing the amount of input for certain cases by enabling the users to define these variables once with the GlobalParams block.

Solution

Deprecate all existing inconsistent input parameters from objects currently available in Zapdos with a removal date for those options set to be 01/01/2025

@lindsayad @csdechant @cticenhour What are your thoughts on adopting this naming convention standard?

Deprecation errors

Scheduled deprecated testing is back (nightly): https://civet.inl.gov/job/1023673/

It's worth trying to fix these when possible.

Ping @cticenhour

Add FieldEmissionBC

Need field emission physics at boundaries for modeling some of the experimental plasmas at Notre Dame.

Multiple Ionic Species in BCs

If Zapdos is meant to be a general plasma simulation tool moving forward, we're going to need to allow multiple ionic species to be included in the model. Right now most relevant boundary conditions are hard-coded to allow a single ion species (example: ip = 'Arp') and a single set of material properties associated with that one ion. This should be changed to allow the user to input a vector of ions. These are the boundary conditions that should be modified:

And of course this will need to allow for multiple secondary electron emission coefficients. SecondaryElectronEmissionBC can probably be left alone since it can be applied to each ion individually, but the formulation of many of these (like HagelaarEnergyBC) require a sum over all of the ion fluxes unless they are rewritten and a separate BC is included.

Add MooseDocs to Zapdos

For future documentation development activities, Zapdos should be upgraded to the new MooseDocs system. This enables consistent online documentation, and the possibility of a website presence (in conjunction with a future GitHub Pages shannon-lab repo), if we so chose.

Tagging @csdechant since we spoke about this earlier this week. A PR adding the infrastructure and initial content stubs is forthcoming.

Website build action is failing

Example: https://github.com/shannon-lab/zapdos/actions/runs/8295430635

This seems to consistently occur during the copy phase of the page build (the last stage pre-deployment).

GitHub pages have size limits, and with the Doxygen content being a significant portion of the site build, we might need to consider removing it. This might not be a bad thing. Zapdos developers will still have access to the MOOSE Doxygen - AKA all of the core APIs. The Zapdos-specific ones we create should be easier to determine via source.

Add to test coverage

Looks like there are several directories inside of tests that don't actually get tested:

Schottky_emission
field_emission (related to #3?)
reflections

Adding this issue as a reminder to fix these at some point.

UPDATE 5-31-19 : Also, the 2d syntax checks residing in the problems directory probably need to be moved into tests.....not really adding to test coverage, but related to test improvements generally. (Done in #34)

Power Regulation Infrastructure

Proposed Label - Enhancement

Motivation

It is often the case that experiments will hold power deposition into the plasma constant. Currently the power deposition in an RF system primarily affected by the amplitude of the applied voltage boundary condition. In order to facilitate better comparisons with experiments there is a need to be able to regulate the power deposition in the plasma. In order to do this the average periodic power deposition in the plasma should be used. We should also give the ability to average the power deposition over multiple periods and start updating the voltage amplitude after the firs n, user defined, periods and only update the voltage BC amplitude after m ,user defined, periods so the system has some time to relax.

Design

Several Postprocessors that feed into each other can give more general functionality for other potential use cases as well enable this specific use case.

A time integrated post processor which allows for the integration of another post processor while also multiplying that post processor value by a constant value. This is important for multiplication by the domain scaling as well as the assumed cross sectional area for 1D simulation and the assumed length/width/depth for a 2D simulation
A periodic time integrator which inherits from the above post processor and resets this integral at the start of each period
A multi period average. Which will allows us to average the value of a periodic integral over multiple periods
A voltage amplitude regulator which allows us to modify the amplitude of a voltage BC starting after a user specific number of periods have occurred, and wait n periods between updating the value of the voltage boundary condition amplitude.
Created a linear combination aux kernel to add multiple variables that have the '+' character in their name. Currently we can calculate the total power deposition in each species in the plasma with the PowerDep. The total power could be calculated with the ParsedAux, AuxKernel if their name does not contain the + or - character. But I would like to automate power regulation later with an action and have that action create Auxkernels in a naming convention that is consistent with user defined names and we may have names like Ar+_PowerDep which cannot be properly parsed by ParsedAux

Inconsistent capitalization of input params

Issue

Some objects require inputs where the first letter is capital and others do not. This should be consistent or a convection for capitalization vs non-capitalization should be established for input parameters.

Ex. test/tests/DrifDiffusionAction/RF_Plasma_actions.i

[DriftDiffusionAction]
  [Plasma]
    electrons = em
    charged_particle = Ar+
    Neutrals = Ar*
    mean_energy = mean_en
    potential = potential
    Is_potential_unique = true
    using_offset = false
    position_units = ${dom0Scale}
    Additional_Outputs = 'ElectronTemperature Current EField'
  []
[]

Objects with issues

Proposed Solution

Add deprecation warnings to all of the parameters that have this inconsistency and remove the inconsistent versions of input params after some time.

Updating User Interface

I think we're getting to the point where we can start making this code a little more like COMSOL -- we can create Actions that users can intuitively grasp without requiring them to search for all these different input parameters that seem so random. Right now I'm thinking of adding a few different Actions, essentially mirroring COMSOL's different "interfaces" in the plasma module:

ElectronTransport
- Input: transport coefficients file(s), initial conditions
- Adds electron transport materials, mass, charge, etc...
- Adds electron drift-diffusion kernels
HeavySpeciesTransport
- Input: name, mass, charge, IC, transport coefficient(s)
- Adds relevant Materials, ICs, kernels, etc.
- Eventually add more complex formulations, like computing transport coefficients from Chapman-Enskog theory automatically, use mixture-averaged diffusion coefficients, and include temperature dependence
Interfaces
- Input: type (dielectric or water), relevant species names, Henry coefficients (for water)
- Dielectric -- either explicitly add surface charge material and interface kernels, or assume a small dielectric layer and apply EconomouDielectricBC
- Water - add species solvation interface kernels and boundary conditions

Obviously this is all tentative and up for discussion. This is just my initial thoughts on the kind of user interface we could include. While doing this we should also add thorough documentation of everything in Zapdos and use MooseDocs to make the website as comprehensive as possible.

Interfaces
ElectronTransport
HeavySpeciesTransport
Website documentation
Parameter consistency ("electrons" vs "em", "ions" vs "charged_species" vs "ip")

CIVET: 'Mirror scheduled' failure

Testing 90ecae6

Mirror scheduled : Failed

View the results here.

Some tests will diff if the initial residual evaluation is skipped

See this PR idaholab/moose#26222 for how to reproduce this issue.

Note that no action will be required unless you opt to use the new behavior.

Remove legacy parameter construction

Legacy parameter construction is deprecated. Switch to new input parameter construction.

Standardize Headers

I was reminded today that there are quite a few MOOSE headers that have snuck into the source code over the years that shouldn't be there. Thought I should make an issue as a reminder to remove those.

Alternatively, we could make our own standard header as a replacement. Thoughts? @lindsayad @csdechant

Update moose and crane submodules after API change

See lcpp-org/crane#57 and idaholab/moose#15331

Make sure heavy tests pass

And then make sure CIVET tests them...?

README needs to be updated

Due to commit 19d58b4 adding MOOSE as a submodule, the installation instructions need to be updated to reflect the new step of building and testing MOOSE as a submodule (if the user wants to use MOOSE as a submodule, that is).

At least one user has already run into issues because of this: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/zapdos-users/hd5qThPwYuI

Retrieve _u_old in AuxKernels

Reason

We're switching away to providing _u_old and _u_older in AuxKernels so that we can only construct older solution states when they are needed.

Design

First, update _u_old and _u_older in AuxKernels to use internal APIs. After MOOSE is updated, switch to the new API uOld() and uOlder().

Impact

Enables the storage of only the AuxVariable solution states that are requested.

Submodule updates should be automated

We may be able to use GitHub Dependabot to automate submodule updates. Regardless, we should probably setup weekly or bi-weekly checks for available submodule updates and then have them staged in a PR for developer review and approval. Perhaps even automatically merge based on test status?

Making an issue to cover this work.

Several Classes are missing the class descriptions

Several classes in the Shannon-lab zapdos repo contain no class description in their definition of validParams

shannon-lab / zapdos Goto Github PK

zapdos's People

Contributors

Stargazers

Watchers

Forkers

zapdos's Issues

Reason

Design

Impact

Design Proposal

Motivation

Solution

Proposed Label - Enhancement

Motivation

Design

Issue

Objects with issues

Proposed Solution

Reason

Design

Impact

Objects with issues

Recommend Projects

Recommend Topics

Recommend Org