Kernels at time interval and floating potential

[ASKapat]

Hi,

I have two questions:

1. I'm wanting to have a variable be calculated at some time step interval, is that possible to do?

2. I wanted to see if there was a floating potential BC that already exists, I couldn't find one

[csdechant]

Hi, about your questions:

1. You can use MOOSE's MultiApp System to calculate a separate variable with a different time step (this is how MOOSE uses sub-cycling). You can also "turn off and on" kernels throughout a simulation using PeriodicControllers. If you can provide more information on your problem, we can better point out what approach might be more beneficial.

2. There is currently no floating potential BC right now that ensures a zero net current (there is a DC-bias BC in the works that can be modified into a generic floating potential BC). Currently Zapdos can do DC, frequency-based, and ground potential BC. One side note is that for the electrostatic condition, one could do a zero displacement field BC by setting the gradient of the potential to zero at the walls (assuming $D = \varepsilon E = -\varepsilon \nabla V$).

[ASKapat]

Thanks for the reply. I have two different blocks, one of them with just the heat conduction, heat conduction time derivative kernels with a varying heat flux BC at one of the sides. I wanted to solve the temperature in this block less frequently than the solves of the other block

[csdechant]

Ok, it sounds like the temperature in that block acts on a different time scale than the other block. If that's the case, then using sub-cycles might be best here. MOOSE has a tutorial on the MultiApp system (link here: https://mooseframework.inl.gov/getting_started/examples_and_tutorials/tutorial02_multiapps/).

If you have already download Zapdos by following the instructions on the Zapdos website, the tutorial files should be located in ~/projects/zapdos/moose/tutorials/tutorial02_multiapps.

[ASKapat]

Thanks for the suggestion, there are two different time scales involved so that sounds perfect. Currently, I have a material that's calculating the heat flux in the master app and I'm trying to push that as a BC into the sub app where I want to run thermal conduction and then subsequently pull the temperature into the master. The transfer of temperature to the master app is straight forward but I'm not sure of the best way to implement the pushing of the heat flux material into the sub app where I can use it as a BC. Is it possible to transfer a material from the master app into the sub app as a variable or material (and subsequently use a coupled variable Neumann or material Neumann BC)?

[csdechant]

I don't believe you can transfer values as material properties with the MultiApp system (here is a link to more information about the transfer system: https://mooseframework.inl.gov/syntax/Transfers/index.html). To my knowledge, only variables, aux-variables, postprocessor values, and userobject values can be transferred between master and sub apps. One workaround is to define an aux-variable and use MaterialRealAux to define that aux-variable as the same value of the desired material property.

[ASKapat]

Thank you for the help with these questions, I did have a follow-up relevant to the second one. I wanted to find out how to have the variable (different from the variable for which the BC is for) inputs for a BC to be limited to their values at a different boundary, either by changing the syntax of the BC .C file (something in lieu of variable[_qp]) or by how the variable is given to the BC in the input file

[csdechant]

Just for clarification, is the different boundary touching the BC of interest? Lets say you have two squares touching, so that square A is on the left and square B is on the right. Are you talking about the interface where the right of square A and the left of square B are in contact? Or are you trying to couple two boundaries on opposite sides, like coupling the right and left side of square A?

For the former, you can use interface kernels (here is a like for more information: https://mooseframework.inl.gov/syntax/InterfaceKernels/).

For the latter, you might be able to use something like NearestNodeValueAux.C, which retrieves the values of the nodes closest to a desired boundary, as a starting point. For this approach, it might also be helpful to post in the MOOSE discussion section, since this might be more of a general MOOSE question, than a Zapdos question.

[ASKapat]

It would be the latter case, so I'll look into the NearestNodeValueAux.C and see what's on the Moose discussion, thanks

[ASKapat]

Hi, I wanted to get some clarity on this. I'm trying to make a floating potential BC just based on a set plasma potential and electron, ion densities, temperatures. The issue I'm running into is that I've been using the AuxKernel you suggested, but I can't use elemental variables for a Nodal BC like the floating potential BC. When I try to set the AuxVariables that I'm reading into the floating potential to family = LAGRANGE, I get a mesh error. Is there a simpler way to go about this?

[csdechant]

For clarification, by "floating potential BC", your are referring to a boundary condition where the net current is zero? In that case, you can try something like in NeumannCircuitVoltageMoles_KV.C, which converts the BC of:
$V_{plasma}+V_{cathode} = \left( e\Gamma_{i}-e\Gamma_{e} \right)$ AR
into a Neumann BC by rearrange the the equation, so that one is solving for the grad potential in the electron flux (i.e. $\nabla V = ...$), but in your case would start with $e\Gamma_{e} = e\Gamma_{i}$.

The other option is to try making a Penalty Dirichlet, with treats a Dirichlet BC as an IntegratedBC, instead of a NodalBC (more information here: https://mooseframework.inl.gov/source/bcs/ADPenaltyDirichletBC.html)

Also, if one of these options work for you and you can wait by a week, you can add an issue to Zapdos about a floating potential BC, outlining what exactly you would like in the BC and we can code it up with a MMS test by next Friday (the simplest option is to reformat the NeumannCircuitVoltageMoles_KV.C to a flux balance equation).

Just to note that in both cases I am assuming you have a DC case, otherwise you would need to integrate the current over a RF time scale and balance the current each RF period or once every several RF periods (which I am currently working on for the self-bias BC).

[ASKapat]

Thank you for the reply, yes I am referring to a net zero current at the wall. My worry about the approach similar to that of NeumannCircuitVoltageMoles_kV.C, in creating a NeumannBC by solving the current balance $e \Gamma_i = e \Gamma_e$ for $\underline{E}=-\nabla V$, is we haven't had success in getting converged solves, using a NeumannBC at the wall and a Dirichlet at the other "upstream" boundary. With the Penalty Dirichlet BC approach (which I'm generally not familiar with), what's the physical basis, if any, for the penalty value?

[csdechant]

For the penalty value, there is no physical basis. The value is purely for numerical reasons, in particular it depends on the mesh and the fact that one substituting a strongly implemented BC (nodal BC) for a weakly implemented BC (Integrated BC).

For the Neumann BC, what were convergence issues? Mainly, have you tried a mesh refinement study to see if the issue was mesh dependent?

[ASKapat]

I see, thanks!

There wasn't a detailed mesh refinement study per se, but we did try a couple different mesh sizes; regardless, we'll do some mesh refinement studies and circle back to that. I'll add an issue for a floating potential BC based on the NeumannCircuitVoltageMoles_kV.C BC.

[ASKapat]

I had a follow-up question that's confusing me a bit. Relevant to both using NearestNodeValueAux as well as NearestNodeTransfer, I don't quite understand how I should be using these. In the case of NearestNodeValueAux, per your response about using NearestNodeValueAux to retrieve variable values from one boundary to use as an AuxVariable input into a non-adjacent BC, I'm not understanding how to implement this exactly; I'm wanting the value of an elemental variable at the boundary to store in an AuxVariable but would this approach work using the NearestNodeValueAux AuxKernel given that it only uses the nearest node value to the boundary? In trying to do so, I've been getting "Please use getBoundaryIDs() when passing "ANY_BOUNDARY_ID"" when implementing a floating potential BC based on the PenaltyDirichlet approach you mentioned in one of your responses.

Related to this question is another suggestion you made about using the MultiApp system for two problems on different timescales. I've been using MultiAppNearestNodeTransfer but I get warnings saying that "Setting a target boundary is only valid for receiving variables of the LAGRANGE basis", which makes sense since I'm trying to transfer elemental variables; is there a way around this?

[csdechant]

For clarification I have a few questions:

• What variables are elemental? Elemental variables don't just exact on the boundary (Side Note: This is the same with material properties. This is why if a BC / Aux-kernels has material properties within it, you can't use NodalBC / Nodal Aux-variables).
• If this is for the floating potential BC, what is the formulations you are trying is use for the Dirichlet or PenaltyDirichlet BC?
• Are you able to upload your work to your GitHub branch? That will help with any further clarifications.

About NearestNodeValueAux: I thought you were trying to construct a BC that access the values at a different boundary. I recommend NearestNodeValueAux as an example of how to access different boundary information, since it has the paired_boundary parameter (to be fair, there might be a better example within MOOSE for this, but that was the first one I thought about). If you just want the value as an aux-variable, you can use SelfAux with the boundary parameter so that the aux-kernel only applies to that boundary.

About the MultiApp: this goes back to my first question. Elemental variables don't just exact on the boundary. You would have to call a domain for an elemental variables.

Lastly, it could be beneficial to talk over Zoom or Google Meets. My email should be on my GitHub profile, but if not, it is [email protected]