Difference in function boundary condition solution to expected values

[AmbroiseJuston]

Check these boxes if you have followed the posting rules.

• Q&A General is the most appropriate section for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (screenshots as a last resort, triple back quotes around pasted text)

Question

Good afternoon,

I am working on a problem which required me changing a boundary condition to simulate different test conditions. Basically i am doing an IV plot of an electrical component.

We were trying to validate which way would better represent sweeping the IV plane (from 0v to 1v) and had some questions on why certain results diverged.

Option 1: we can manually solve for steady state (~10 units of time) and then use the final state as the IC of the next simulation, increasing the voltage by a certain amount (0.1 for example).
Option 2: we can used a piecewise function and create a discrete stair function with increments of 0.1 after x time (~10 units of time to let it each steady state at that condition.
Option 3: create another piecewise function but linearly increasing from 0 to 1 and then back down.

I can see how option 3 would be different that then other solutions however what i do not understand if how options 1 and 2 diverge because in my mind they are equivalent in the long run. The difference is if we do the step manually or as a discrete step function.

Is there a difference between how MOOSE would evaluate the results for options 1 and 2?

The step function being used is shown below:

   [./bc_function_step]
    type = PiecewiseLinear
    y = '0 0 0.001  0.001  0.01  0.01  0.1   0.1  0.2   0.2  0.3   0.3  0.4  0.4  0.5   0.5  0.6  0.6  0.7   0.7 0.8  0.8 0.9   0.9 1      1'
    x = '0 5 5.001  15    15.001  25  25.001  35 35.001 45  45.001 55  55.001 65 65.001 75  75.001 85 85.001 95 95.001 105 105.001 115 115.001 125'
    scale_factor = 1.0
  [../]

and the code that reads in the .e as the new IC for the simulation is defined here:

[UserObjects]
  [exo_soln]
    type = SolutionUserObject
    mesh = 'etpf-23_test_out_IC23.e'
    system_variables = 'c'
    timestep = LATEST
  []
[]

[GiudGiud]

Hello

Are you using pseudo timesteps in all these simulations? So timesteps but with no time derivative kernel so a steady state is reached on every time step?

Guillaume

[GiudGiud]

There are a few auxiliary variables

are they used now in the coupling? If so, how are the auxkernels set up? Are they executed often enough to keep the variables updated?

. Can these be retreived into the user object? If so i am not sure how.

Yes. Depending on the user object type there are different ways but for ElementUserObjects for example (a base class of many user objects), you can use the Coupleable interface

https://mooseframework.inl.gov/source/interfaces/Coupleable.html

[AmbroiseJuston]

I will go and double check how often they are being updated. From what i remember it should be often enough but i will make sure. We are using "SolutionUserObject" is there any difference in syntax between using apostrophes or just using spaces as shown below:

[UserObjects]
[exo_soln]
type = SolutionUserObject
mesh = 'etpf-23_test_out_IC23.e'
system_variables = 'var1 var2 var3 aux_var1 aux_var2 aux_var3'
timestep = LATEST
[]
[]

Versus

[UserObjects]
[exo_soln]
type = SolutionUserObject
mesh = 'etpf-23_test_out_IC23.e'
system_variables = var1 var2 var3 aux_var1 aux_var2 aux_var3
timestep = LATEST
[]
[]

[GiudGiud]

I would think it errors if you do :

param = var1 var2 var3

But if it's being accepted then no no difference

[AmbroiseJuston]

I have been playing around, and it seems like the error might be caused by some variables not being properly ported over (because of user error). I will play around with it for some more to see if there are any more major mistakes I am making.

you will probably hear from me again but in the mean time I apologise for my slow communication

[GiudGiud]

no worries. By error you mean the difference in behavior still right, not an error from the code.