Initialize the 3D pressure field from a scalar value

[taeoukkim]

Current situation

Resolves #546.

This PR is a clean replacement for the previously closed pressure-initialization PR. It has been rebuilt on top of the latest main after the 3D–1D coupling changes were merged through PR #563.

Release Notes

• Add support for initializing the entire 3D pressure field from a single scalar value specified in solver.xml.
• Preserve the existing option to initialize pressure from a full 3D result file.
• Initialize the first-step under-relaxation history for 3D–1D and 3D–0D coupling using the pressure and flow values computed from the initialized 3D state.

The scalar pressure can be specified using:

<Initial_pressure_scalar>80000.0</Initial_pressure_scalar>

If both a nodewise pressure field and a scalar pressure are provided, the nodewise pressure field takes precedence.

Documentation

Initial_pressure_scalar is specified in the general simulation parameters in solver.xml.

Selecting an appropriate initial pressure can reduce initial pressure oscillations in standalone 3D simulations and coupled 3D–1D or 3D–0D simulations.

Testing

• Successfully built on macOS using AppleClang 17.
• Tested a parallel simulation using 8 MPI processes.
• Verified that the 3D pressure field is initialized with the specified scalar value.
• Verified initialization of the coupled 3D–1D pressure history using the initialized 3D state.

Code of Conduct & Contributing Guidelines

• I agree to follow the Code of Conduct and Contributing Guidelines.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[taeoukkim]

This PR is a clean replacement for the previously closed pressure-initialization PR.

[ktbolt]

@taeoukkim The svMultiPhysics/tests/cases/struct/LV_NeoHookean_passive_sv0D_cap test is failing because CoupledBoundaryCondition::compute_flowrates is being called before CoupledBoundaryCondition::initialize_cap is called so the arrays in cap_global_mesh_state_ have not been allocated.

[michelebucelli]

Sorry for not reviewing this yet! I'll do my best to look at the code in detail as soon as possible. In the meantime, I have a couple general (and perhaps naive) comments.

1. What is the implication of initializing the pressure to a given value, and to what model or set of models does it apply?

   My understanding is that in Navier-Stokes the pressure does not have any initial conditions because the equations do not have any pressure time derivative in them. Whatever the initial value assigned to the pressure, it should immediately (at the first time step) be overwritten by whatever pressure is implied by the boundary conditions, which will have no "memory" of the initial condition.

   Therefore, as far as I understand, for standalone Navier-Stokes, the initial pressure can at best have a "cosmetic" effect, in the sense that it can make sure that the output of the initial condition is somewhat in line with the outputs of the following frames (as opposed e.g. to being zero everywhere), but it should not have any effect on the solution. (Even if this is only cosmetic it is a useful thing to include, I just want to make sure I understand the maths).

   I think that the picture is similar in the case of FSI, for similar reasons: the pressure at first timestep will only depend on the boundary conditions and the initial displacement of the solid, but should have no memory of the initial value assigned to it.

   What I am not so sure about is how this looks in the context of 3D-1D or 3D-0D coupling. I still feel that something like what I wrote above should apply (even if the 1D or 0D model has a time derivative of pressure, or something related to it, that would apply to the 1D or 0D domain only, not to the 3D domain), but I am less familiar with the model and I'd be interested in understanding this better. Does this relate to the coupling algorithm?

   To summarize, I'd be curious to understand more about the initial pressure oscillations that you talk about in the PR description, and where they come from.

2. On a more practical note: your PR description says that it is possible to specify both the nodal and constant pressure, and the former takes precedence. I would recommend disallowing this, and instead throwing an exception if they are both specified. This would prevent the user from specifying conflicting information in the XML file, which might be a sign that they're making some error that they'd rather find out about immediately.