IBM Fix on Non-uniform Initial Condition

Description

This is to deal with the issues for IBM with non-uniform initial conditions as mentioned by @anandrdbz in PR#398.

Fixes #401

Type of change

Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Scope

[x] This PR comprises a set of related changes with a common goal

How Has This Been Tested?

I use two regular patches that are not overlapping over each other with initial different velocities and put three IBs at the interface of these two patches. Thus, the velocity inside the IBs is not uniform initially. Velocity inside IBs should be corrected to be zero at the simulation stage. The animations below are the test case showing the expected changes in IBs for 2D and 3D cases.

Test Configuration:

[x] 2D case WENO5, 3rd Order Time Stepper. 'patch_icpp(1)%geometry' : 3, 'patch_icpp(1)%x_centroid' : x1/2, 'patch_icpp(1)%y_centroid' : x2/4, 'patch_icpp(1)%length_x' : x1, 'patch_icpp(1)%length_y' : x2/2, 'patch_icpp(1)%vel(1)' : 0.0E+00, 'patch_icpp(1)%vel(2)' : 0.0E+00, 'patch_icpp(1)%pres' : 1.0E+05, 'patch_icpp(1)%alpha_rho(1)' : (1.0 - 1e-12)rho1, 'patch_icpp(1)%alpha(1)' : 1.0 - 1e-12, 'patch_icpp(1)%alpha_rho(2)' : 1.0e-12rho2, 'patch_icpp(1)%alpha(2)' : 1.0e-12, 'patch_icpp(2)%geometry' : 3, 'patch_icpp(2)%alter_patch(1)' : 'T', 'patch_icpp(2)%x_centroid' : x1/2, 'patch_icpp(2)%y_centroid' : 3x2/4, 'patch_icpp(2)%length_x' : x1, 'patch_icpp(2)%length_y' : x2/2, 'patch_icpp(2)%vel(1)' : 1.0E+00, 'patch_icpp(2)%vel(2)' : 0.0E+00, 'patch_icpp(2)%pres' : 1.0E+05, 'patch_icpp(2)%alpha_rho(1)' : (1.0 - 1e-12)rho1, 'patch_icpp(2)%alpha(1)' : 1.0 - 1e-12, 'patch_icpp(2)%alpha_rho(2)' : 1.0e-12*rho2, 'patch_icpp(2)%alpha(2)' : 1.0e-12,

'patch_ib(1)%geometry' : 2, 'patch_ib(1)%x_centroid' : x1/4, 'patch_ib(1)%y_centroid' : x2/2, 'patch_ib(1)%radius' : x2/6, 'patch_ib(1)%slip' : 'F',

'patch_ib(2)%geometry' : 2, 'patch_ib(2)%x_centroid' : 3*x1/4, 'patch_ib(2)%y_centroid' : x2/2, 'patch_ib(2)%radius' : x2/8, 'patch_ib(2)%slip' : 'F',

'patch_ib(3)%geometry' : 2, 'patch_ib(3)%x_centroid' : x1/2, 'patch_ib(3)%y_centroid' : x2/4, 'patch_ib(3)%radius' : x2/10, 'patch_ib(3)%slip' : 'F',
[x] 3D case WENO5, 3rd Order Time Stepper. 'patch_icpp(1)%geometry' : 9, 'patch_icpp(1)%x_centroid' : 2.5, 'patch_icpp(1)%y_centroid' : 5.0, 'patch_icpp(1)%z_centroid' : 5.0, 'patch_icpp(1)%length_x' : 5, 'patch_icpp(1)%length_y' : 10, 'patch_icpp(1)%length_z' : 10, 'patch_icpp(1)%vel(1)' : -10, 'patch_icpp(1)%vel(2)' : 0.0E+00, 'patch_icpp(1)%vel(3)' : 0.0E+00, 'patch_icpp(1)%pres' : 10918.2549, 'patch_icpp(1)%alpha_rho(1)' : 1.22, 'patch_icpp(1)%alpha(1)' : 1.E+00, 'patch_icpp(2)%geometry' : 9, 'patch_icpp(2)%x_centroid' : 7.5, 'patch_icpp(2)%y_centroid' : 5.0, 'patch_icpp(2)%z_centroid' : 5.0, 'patch_icpp(2)%length_x' : 5, 'patch_icpp(2)%length_y' : 10, 'patch_icpp(2)%length_z' : 10, 'patch_icpp(2)%vel(1)' : 10, 'patch_icpp(2)%vel(2)' : 0.0E+00, 'patch_icpp(2)%vel(3)' : 0.0E+00, 'patch_icpp(2)%pres' : 10918.2549, 'patch_icpp(2)%alpha_rho(1)' : 1.22, 'patch_icpp(2)%alpha(1)' : 1.E+00,

'patch_ib(1)%geometry' : 8, 'patch_ib(1)%x_centroid' : 5, 'patch_ib(1)%y_centroid' : 5, 'patch_ib(1)%z_centroid' : 5, 'patch_ib(1)%radius' : 1, 'patch_ib(1)%slip' : 'F',

'patch_ib(2)%geometry' : 8, 'patch_ib(2)%x_centroid' : 5, 'patch_ib(2)%y_centroid' : 2.5, 'patch_ib(2)%z_centroid' : 5, 'patch_ib(2)%radius' : 1, 'patch_ib(2)%slip' : 'F',

'patch_ib(3)%geometry' : 8, 'patch_ib(3)%x_centroid' : 5, 'patch_ib(3)%y_centroid' : 7.5, 'patch_ib(3)%z_centroid' : 5.0, 'patch_ib(3)%radius' : 1, 'patch_ib(3)%slip' : 'F',
What computers and compilers did you use to test this: MacOS with GCC 13.1.6 and PACE Phoenix V100-16GB with NVHPC 22.11

Checklist

[x] I have added comments for the new code
[x] I ran ./mfc.sh format before committing my code
[x] New and existing tests pass locally with my changes, including with GPU capability enabled (both NVIDIA hardware with NVHPC compilers and AMD hardware with CRAY compilers) and disabled
[x] This PR does not introduce any repeated code (it follows the DRY principle)
[x] I cannot think of a way to condense this code and reduce any introduced additional line count

If your code changes any code source files (anything in `src/simulation`)

To make sure the code is performing as expected on GPU devices, I have:

[x] Checked that the code compiles using NVHPC compilers
[x] Checked that the code compiles using CRAY compilers
[x] Ran the code on either V100, A100, or H100 GPUs and ensured the new feature performed as expected (the GPU results match the CPU results)
[x] Ran my code using various numbers of different GPUs (1, 2, and 8, for example) in parallel and made sure that the results scale similarly to what happens if you run without the new code/feature

MFlowCode / MFC