Inquiry on species transport in MOOSE Navier Stokes

[sanjuucsd2022-sketch]

Check these boxes if you have followed the posting rules.

• Q&A Navier Stokes is the most appropriate category 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 (avoid screenshots if possible, triple back quotes before/after pasted text, etc)

Question

I am Sanjay and I am using MOOSE for my project. However, I am stuck on the species transport equation(scalar transport).
For the advection kernel there seems to be only the INSScalarFieldAdvection kernel object.( I am appending species after solving for energy, navier stokes and continuity). The kernel doesn't allow me to multiply by density(which is a function of temp in my case) i.e I want to solve for Del .(rhovelmass_fraction) and not Del . (vel*mass_fraction)- which the kernel only supports. Please let me know how to proceed.
Thank you

Additional information

No response

[GiudGiud]

Hello

We currently do scalar advection using mostly the INSFV and WCNSLinearFV finite volume implementations. For those we have added the option for a density multiplier
If you need to change something with the regular INS finite element implementation, you will need to modify the kernels yourself on your local version of the code.

[GiudGiud]

did you remember to build petsc?
what does the diagnostics script in moose/scripts return?

[GiudGiud]

#28151
is the branch with k omega SST. You'll need to rebase it, it's a signifcant task to get it working again

[sanjuucsd2022-sketch]

did you remember to build petsc? what does the diagnostics script in moose/scripts return?

./scripts/diagnostics.sh
##############################################################################################
Influential Environment Variables

CC=mpicc
CONDA_CHANNEL=https://conda.software.inl.gov/public
CONDA_EXE=/home/senai2/miniconda/anaconda/bin/conda
CONDA_PYTHON_EXE=/home/senai2/miniconda/anaconda/bin/python
CONDA_SHLVL=0
CURL_CA_BUNDLE=
CXX=mpicxx
F77=mpif77
F90=mpif90
FC=mpif90
LD_LIBRARY_PATH=/usr/local/cuda/lib64:
MOOSE_JOBS=6
PATH=/mnt/d_disk/lokesh/.vscode-server/data/User/globalStorage/github.copilot-chat/debugCommand:/mnt/d_disk/lokesh/.vscode-server/data/User/globalStorage/github.copilot-chat/copilotCli:/mnt/d_disk/lokesh/.vscode-server/cli/servers/Stable-0958016b2af9f09bb4257e0df4a95e2f90590f9f/server/bin/remote-cli:/usr/local/cuda/bin:/home/senai2/miniconda/anaconda/condabin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/mnt/d_disk/lokesh/.vscode-server/extensions/ms-python.debugpy-2026.6.0-linux-x64/bundled/scripts/noConfigScripts
REQUESTS_CA_BUNDLE=
SSL_CERT_FILE=
##############################################################################################
Compiler(s) (CC CXX FC F77 F90):

which $CC; /usr/bin/mpicc
$CC --version; gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
$CC -show; gcc -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi

which $CXX; /usr/bin/mpicxx
$CXX --version; g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
$CXX -show; g++ -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_cxx -lmpi

which $FC; /usr/bin/mpif90
$FC --version; GNU Fortran (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
$FC -show; gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread -I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi

which $F77; /usr/bin/mpif77
$F77 --version; GNU Fortran (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
$F77 -show; gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread -I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi

which $F90; /usr/bin/mpif90
$F90 --version; GNU Fortran (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
$F90 -show; gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread -I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi

OK
##############################################################################################
Python Sanity Checks

/usr/bin/env python3 --version; (reporting as: Python 3.8.10) matches
which python3 python;

/usr/bin/python3 --version; == Python 3.8.10
Python 2.7.18
FAIL: Python 2.7.18
/usr/bin/python --version (reporting as )) != Python 3.8.10

This will likely result in the TestHarness failing. Or WASP/HIT parsing errors.
##############################################################################################
Python Modules (TestHarness, run-ability)

OK

checks FAILED

[GiudGiud]

so:

• you'll need to use a newer python
• you'll need to install petsc in the same session or set PETSC_DIR if you change session between installing petrsc and libmesh

[sanjuucsd2022-sketch]

Understood

[sanjuucsd2022-sketch]

/usr/bin/mpiexec --oversubscribe -n 1 /tmp/petsc-pr8jlnnn/config.packages.MPI/conftest
Runaway process exceeded time limit of 120

ERROR while running executable:
Could not execute "['/usr/bin/mpiexec --oversubscribe -n 1 /tmp/petsc-pr8jlnnn/config.packages.MPI/conftest']":
Runaway process exceeded time limit of 120

UNABLE to CONFIGURE with GIVEN OPTIONS

Timeout: Unable to run MPI program with
/usr/bin/mpiexec --oversubscribe -n 1. This happens when I build PETSc.

I changed the linking by modifying the bashrc to point to the correct python executable(ie python 3.10.18). Still the diagnostics script gives error. However while building PETSc I don't get that error, but the one given above, what do you think is happening?

[GiudGiud]

hello

Looks like the last version of the input file was INSFV with a Steady executioner not the SIMPLENonlinearAssembly.
Can you please paste the current version of your input file?

Hi, it seems like my mu_t and other postprocessors are completely frozen every iteration,

you need to execute the auxkernel computing mu_t on NONLINEAR, and same for the postprocessors. You already have output as expected.

In SIMPLESolveNonLinearAssembly.C you can see

  // Loop until converged or hit the maximum allowed iteration number
  while (iteration_counter < _num_iterations && !converged)
  {
    iteration_counter++;
    // Resdiual index
    size_t residual_index = 0;

    // Execute all objects tagged as nonlinear
    // This will execute everything in the problem at nonlinear, including the aux kernels.
    // This way we compute the aux kernels before the momentum equations are solved.
    _problem.execute(EXEC_NONLINEAR);

this last line does the execution of all objects on NONLINEAR and will update mu_t

[sanjuucsd2022-sketch]

Looks like the last version of the input file was INSFV with a Steady executioner not the SIMPLENonlinearAssembly.
Can you please paste the current version of your input file?

Just the executioner right? Here it is:

[Executioner]
  type = SIMPLENonlinearAssembly
  rhie_chow_user_object = 'rc'
  momentum_systems = 'u_system v_system w_system'
  pressure_system = 'pressure_system'
  turbulence_systems = 'TKE_system TKED_system'
  pressure_gradient_tag ='pressure_grad_tag'
  momentum_equation_relaxation = 0.3
  pressure_variable_relaxation = 0.2
  turbulence_equation_relaxation = '0.3 0.3'
  num_iterations = 500
  pressure_absolute_tolerance = 1e-6
  momentum_absolute_tolerance = 1e-6
  turbulence_absolute_tolerance = '1e-5 1e-5'
  momentum_petsc_options_iname = '-pc_type -pc_hypre_type'
  momentum_petsc_options_value = 'hypre boomeramg'
  pressure_petsc_options_iname = '-pc_type -pc_hypre_type -ksp_converged_reason'
  pressure_petsc_options_value = 'hypre boomeramg true'
  momentum_l_abs_tol = 1e-8
  pressure_l_abs_tol = 1e-8
  turbulence_l_abs_tol = 1e-6
  momentum_l_max_its = 100
  pressure_l_max_its = 200
  turbulence_l_max_its = 100
  momentum_l_tol = 0.0
[]

// Execute all objects tagged as nonlinear
// This will execute everything in the problem at nonlinear, including the aux kernels.
// This way we compute the aux kernels before the momentum equations are solved.
_problem.execute(EXEC_NONLINEAR);

I understand that. Unfortunately, my postprocessors are still frozen at their initial-condition values. I made the source change you suggested by adding outputStep(EXEC_NONLINEAR) right after execute_on(EXEC_NONLINEAR), but the values remain unchanged.

I also wondered whether EXEC_NONLINEAR might not be the appropriate execution flag in this case. To test that, I changed the flag to TIMESTEP_END (and updated the source accordingly). With that change, the postprocessor values do vary, but they remain constant within each SIMPLE iteration.

Am I missing something about when the postprocessors are actually evaluated or updated during the SIMPLE iteration?

On both cases, my input exec_on flag for each auxkernel and postprocessor exactly matches what's in the source code

[sanjuucsd2022-sketch]

Also one more question, which among them below are absolute residual norms? Is it the outlier variable residual norm? Because until now I was assuming the first set below are absolute norms, please let me know. And this additional outlier variable residual norms started appearing after changing the flag from NONLINEAR to TIMESTEP_END

 Momentum equation: Component 1 0.0831501
 Momentum equation: Component 2 0.0823413
 Momentum equation: Component 3 0.0666122
 Pressure equation: 0.000625223
Turbulence Iteration
TKE_system 0.0642298
TKED_system 0.0420848


Outlier Variable Residual Norms:
  vel_x: 9.960593e-01
  vel_y: 1.117077e+00
  vel_z: 5.662503e+02
  p: 1.118013e-06
  TKE: 2.062766e+00
  TKED: 3.663752e+00

[GiudGiud]

Outlier Variable Residual Norms:

comes from the Debug option to debug the residual
It's output from

      Real var_norm = sys.calculate_norm(nl.RHS(), i, DISCRETE_L2);

in residual.C. This is not really the residual for the SIMPLE algorithm where we are solving a linear system and the RHS does not need to be 0.

I'll create an issue for this

[GiudGiud]

Hi, it seems like my mu_t and other postprocessors are completely frozen every iteration, I tried modifying the SIMPLE executioner source as you mentioned and it still doesn't change, could you please assist here:

ok I can reproduce this locally. I'll find out what's going on