Add time transformation

[dschwen]

Closes #29639

[moosebuild]

Job Precheck, step Clang format on a097131 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/docs/PRs/29640/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 7d4ab78f22eae799c7d28a9f675a33e886d7831e

[moosebuild]

Job OpenMPI on 061e9c5 : invalidated by @dschwen

Unrelated failure?

[moosebuild]

Job Documentation, step Docs: sync website on 1cc4a29 wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage, step Generate coverage on 1cc4a29 wanted to post the following:

Framework coverage

	1e1768	#29640 1cc4a2
	Total	Total	+/-	New
Rate	85.25%	85.25%	-0.00%	66.67%
Hits	108011	108015	+4	18
Misses	18681	18682	+1	9

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

Warnings

• framework new line coverage rate 66.67% is less than the suggested 90.0%

This comment will be updated on new commits.

Phase field test shows there's a solution initialization issue. Should add a call to initial setup on the new transformation function

[GiudGiud]

function* not solution

[dschwen]

function* not solution

No the time in the solution in the Solution user object

[GiudGiud]

the function that gives you the transformation, probably needs a initialSetup call on it before it gets used in that phase field test

[dschwen]

I'll clarify the doc string. I'm surprised at the initialization issue. No initialization was performed before the pr, and the change should not affect behavior with the default function (identity). :-/

[GiudGiud]

before the PR, you did not create a parsed function like this in a parameter? I m not sure there were any parsed functions involved in that object, which executes rather early

[dschwen]

Fingers crossed that the early function initialization doesn't break other stuff...

[dschwen]

If this doesn't pass I'm rolling back the changes I made to SolUO (moving initialization from initialSetup to the constructor). The root problem is the function requiring access to the userobject to get the name of the variable in the solution file. This currently prevents moving Function initialSetup before UO initialSetup. IMO we should just get rid of that small convenience where the user doesn't have to specify a variable name anywhere, as long as the solution only contains a single variable. That scenario seems like an edge case, and having the variable stated explicitly in the input seems more expressive.