ornl/additivefoam

Heat and mass transfer software for simulation of additive manufacturing, based on OpenFOAM

additivefoam's Issues

Undesired behavior of heat source normalization at mesh boundaries

The heat source normalization scales the total input power based in the integrated volume. This is a reasonable approach when the laser is completely contained in the physical domain, however, not when we start to scan outside of the mesh.

Since we have analytical forms of the normalization factors, when should probably calculate this based on the volume of the heat source in the physical domain. The rescaling to this normalized volume should fall out naturally.

Add description of spack install to README

Change WM_PROJECT_INST_DIR to WM_PROJECT_USER_DIR

In docs and source

Brief notes from building and running things on an HPC cluster

So, I took a shot at running/building AdditiveFoam on one of the HPC systems at LLNL that's a TOSS4 (RHEL8-based) system.

Thanks to @colemanjs help I was able to get everything built and able to get the tests up and running.

I just wanted to note a few quick things that could be helpful for other users.

While OpenFoam claims you need quite a few things such as paraview, I did not find that necessary to get things running. You only need their TPLs located at this directory: https://github.com/OpenFOAM/ThirdParty-10

For OpenFoam, you'll want to modify their OpenFoam/etc/bashrc file. @colemanjs provided me the following info that was helpful to get up and running with MPICH/MVAPICH and GCC code.

Around the WM_MPLIB line you can modify things to:

export MPI_ARCH_FLAGS="-DMPICH_SKIP_MPICXX"
export MPI_ARCH_INC="-I$MPI_ROOT/include"
export MPI_ARCH_LIBS="-L$MPI_ROOT/lib -lmpich -lrt"
export WM_MPLIB=SYSTEMMPI

and then set the following line in that same file:

export FOAM_SIGFPE=unset

Next, running OpenFOAM ./Allwmake just build things in serial. You'll definitely want to remember to add that -j flag in there for parallel builds.

For AdditiveFoam, if you're running the examples/tutorials depending on how your HPC system is set-up you might have to modify the OpenFoam/bin/tools/RunFunctions file where it uses mpirun and sub it out for your systems appropriate job queue run commands such as srun on a SLURM job queue system or jsrun on a LSF job queue system.

Tmax default incorrectly set in marangoniFvPatchVectorField

The default for Tmax is 0 instead of inf, so if it is not provided by the user, no fluid flow occurs. This is the opposite of the desired behavior.

Incorrect Normalization Implementation in modifiedSuperGaussian

const dimensionedScalar V0
(
"V0",
dimVolume,
s.x()*s.y()*s.z()piFoam::tgamma(1.0 + 2.0/k_)*Foam::tgamma(1.0 + 2.0/m_)*Foam::tgamma(1.0 + 2.0/k_)
/ Foam::tgamma(1.0 + 3.0/m_)
);

should be:
const dimensionedScalar V0
(
"V0",
dimVolume,
s.x()*s.y()*s.z()piFoam::tgamma(1.0 + 2.0/k_)*Foam::tgamma(1.0 + 1.0/m_)*Foam::tgamma(1.0 + 2.0/m_)
/ Foam::tgamma(1.0 + 3.0/m_)
);

Incorrect boundary value in marangoni boundary condition

The snGrad() function in the marangoni boundary conditions is correct, and therefore, equating the viscous stress to the tangential temperature gradient at the boundary condition is correct in the solver. However, the evaluation of the velocity field on the surface should be done using a slip condition instead of what is currently implemented. Here is a COMSOL test case to verify implementation:
https://www.comsol.com/blogs/modeling-marangoni-convection-with-comsol-multiphysics/

A test case for this boundary condition should be added in the pull request fixing this issue. Please use:
marangoni.zip

Time step limiting based in beam velocity

Solution controls can allow the beam to "jump" in a time step past its radius. The beam integration time step should be limited to $\Delta t = 2 \sigma / u$