postprocessor ordering

[jessecarterMOOSE]

Not sure if this is an "issue" or not, but I recently came across a case my postprocessor results were dependent on the order they were listed in the input file. I have several that were used together in a ParsedFunction, which gets output with a Postprocessor, and then that result made it into another ParsedFunction, whose output was also produced with a Postprocessor. If I had that second Postprocessor listed above the first in the input file, the results came out lagged by a timestep even if I told the processors to execute more often (ie. linear). Not a big deal (easy to fix), but I just thought I'd inquire if this was something expected.

I was able to reproduce with this minimal input file:

[Mesh]
  type = GeneratedMesh
  dim = 2
  xmin = 0
  xmax = 1
  ymin = 0
  ymax = 1
  nx = 2
  ny = 2
[]

[AuxVariables]
  [./v]
  [../]
[]

[Variables]
  [./u]
  [../]
[]

[Functions]
  [./constant_func]
    type = ConstantFunction
    value = 2.798
  [../]
  [./test]
    type = ParsedFunction
    vars = 'value1 value2'
    vals = 'value1 value2'
    value = 'value1+value2'
  [../]
  [./test2]
    type = ParsedFunction
    vars = 'test'
    vals = 'test'
    value = 'test'
  [../]
[]


[ICs]
  [./u_ic]
    type = ConstantIC
    variable = u
    value = 2
  [../]
[]

[AuxKernels]
  [./one]
    type = ConstantAux
    variable = v
    value = 1
    execute_on = 'initial timestep_end'
  [../]
[]

[Kernels]
  [./diff]
    type = Diffusion
    variable = u
  [../]
[]

[BCs]
  [./left]
    type = DirichletBC
    variable = u
    boundary = left
    value = 0
  [../]
  [./right]
    type = DirichletBC
    variable = u
    boundary = right
    value = 1
  [../]
[]

[Postprocessors]
  [./value1]
    type = FunctionValuePostprocessor
    function = constant_func
    execute_on = 'initial timestep_end'
  [../]
  [./value2]
    type = FunctionValuePostprocessor
    function = 2*t
    execute_on = 'initial timestep_end'
  [../]

  # these next two postprocessors should output the same result
  # but will not if 'test2' is listed before 'test'
  [./test2]
    type = FunctionValuePostprocessor
    function = 'test2'
    execute_on = 'initial timestep_end'
  [../]
  [./test]
    type = FunctionValuePostprocessor
    function = 'test'
    execute_on = 'initial timestep_end'
  [../]
[]

[Executioner]
  type = Transient
  num_steps = 5
[]

[Outputs]
  csv = true
[]

[Problem]
  solve = false
[]

[dschwen]

Dependency resolution of postprocessors is not carried through indirect dependencies that result from the use of postprocessors in parsed functions with said function values then being used in another postprocessor.

postprocessor1 -> function -> postprocessor2

The dependency resolution only recognizes

postprocessor1 -> postprocessor2

[dschwen]

A quick workaround would be to allow users to explicitly specify indirect dependencies. The better solution, a complete overhaul of the dependency system, is being researched as a funded project as far as I know.

[dschwen]

Like so: fa926be

[jessecarterMOOSE]

Great! The input file I posted above might make a good test for this.

[dschwen]

PR at #16358 (I used a simpler test based on the current time)

[jessecarterMOOSE]

Is there not some kind of parsed postprocessor @dschwen ? I'm only using Functions to combine postprocessor results. If I could get rid of the Functions then maybe I could get dependency resolution.

[jessecarterMOOSE]

ping @dschwen

[dschwen]

How are you combining them? Difference, sum, average... ?

[jessecarterMOOSE]

All of the above.

[dschwen]

I don't think the code duplication resulting from a parsed postprocessor is acceptable. I'm working on a quick fix now.

[aeslaughter]

You may consider creating a custom object to compute what you need, perhaps the new Reporter system is worth a look.
https://mooseframework.inl.gov/syntax/Reporters/index.html