TInF questions

[rps@uark.edu]

1.   When the window version is not working I downloaded the linux version of TInF tool. One of my student ran it and she said there are three options for turbulence model selection. When I ran the window version I have only two options. Why the disparity?
2.   For digital filter method option, there are parameters like grid factor, filter factor etc. It may be a good idea to discuss with a sample input what they are theoretically, what their effect and what their range is for application. At this time, I didn’t see any discussion in the user manual.

[fmk]

1. thanks for pointing that out. we have updated the binaries with a new release. they are the same now. https://simcenter.designsafe-ci.org/research-tools/tinf/. The applications come with new minimally sized installers. https://www.designsafe-ci.org/data/browser/public/designsafe.storage.community//SimCenter/Software/TurbulenceInflowTool

2. we have updated the documentation. it is now in an online format. https://nheri-simcenter.github.io/TinF-Documentation/index.html. It is probably still too theoretical a description. We are working to provide more examples and strive to have more discussion on the parameters and their effect in those.

[ZMansouri]

Dear Sir,

I was wondering if you could let me know the reason of below errors:
 
I tried to use exponential velocity profile at inlet but I got below error:
(1 0 0 0 1 0 0 0 1)
local x-axis: (1 0 0)
local y-axis: (0 1 0)
local z-axis: (0 0 1)
global position of the origin of the local coordinate sytem: (0 0 0)
coordinates tranform matrix: (1 0 0 0 1 0 0 0 1)
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::sqrt(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#4 Foam::sqrt(Foam::tmp<Foam::Field<double> > const&) at ??:?
#5 Foam::digitalFilterFvPatchVectorField::initialiseParameters() at ??:?
#6 Foam::digitalFilterFvPatchVectorField::updateCoeffs() at ??:?
#7 Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#8 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#9 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
Floating point exception (core dumped)

I tried also to run DFSEM but I got below error:
IOstream error at line 109.

Thank you in advance.

[pmackenz]

Would you be so kind and share

• exactly which version of OpenFoam you've been using?
• which version of linux you are using (the output of `uname -a` would be useful)

Thanks

[ZMansouri]

I use OpenFoam 7 and Ubuntu 20.04.1 LTS.

When I compile the code OpenFoam 6 located in the TurbulenceInflowTool folder, I will able to run the model with DFM and SEM inflow with uniform velocity at the inlet. However, I cannot run it with exponential velocity profile at the inlet and I got the mentioned error.

Whereas, when removed the platforms folder and again I compile the code OpenFoam 7 located in the TurbulenceInflowTool folder, I will not be able to run the model with DFM, SEM, and DFSEM inflow with uniform velocity at the inlet. I got the error related to IOstream.C at line 109.

I have uname.1.gz  and uname.2.gz and not uname -a.

uname.1.gz:

.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.3.
.TH UNAME "1" "September 2019" "GNU coreutils 8.30" "User Commands"
.SH NAME
uname \- print system information
.SH SYNOPSIS
.B uname
[\fI\,OPTION\/\fR]...
.SH DESCRIPTION
.\" Add any additional description here
.PP
Print certain system information.  With no OPTION, same as \fB\-s\fR.
.TP
\fB\-a\fR, \fB\-\-all\fR
print all information, in the following order,
except omit \fB\-p\fR and \fB\-i\fR if unknown:
.TP
\fB\-s\fR, \fB\-\-kernel\-name\fR
print the kernel name
.TP
\fB\-n\fR, \fB\-\-nodename\fR
print the network node hostname
.TP
\fB\-r\fR, \fB\-\-kernel\-release\fR
print the kernel release
.TP
\fB\-v\fR, \fB\-\-kernel\-version\fR
print the kernel version
.TP
\fB\-m\fR, \fB\-\-machine\fR
print the machine hardware name
.TP
\fB\-p\fR, \fB\-\-processor\fR
print the processor type (non\-portable)
.TP
\fB\-i\fR, \fB\-\-hardware\-platform\fR
print the hardware platform (non\-portable)
.TP
\fB\-o\fR, \fB\-\-operating\-system\fR
print the operating system
.TP
\fB\-\-help\fR
display this help and exit
.TP
\fB\-\-version\fR
output version information and exit
.SH AUTHOR
Written by David MacKenzie.
.SH "REPORTING BUGS"
GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
.br
Report uname translation bugs to <https://translationproject.org/team/>
.SH COPYRIGHT
Copyright \(co 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
.br
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
.SH "SEE ALSO"
arch(1), uname(2)
.PP
.br
Full documentation at: <https://www.gnu.org/software/coreutils/uname>
.br
or available locally via: info \(aq(coreutils) uname invocation\(aq



uname.2.gz

.\" Copyright (C) 2001 Andries Brouwer <aeb@cwi.nl>.
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\" %%%LICENSE_END
.\"
.\" 2007-07-05 mtk: Added details on underlying system call interfaces
.\"
.TH UNAME 2 2019-10-10 "Linux" "Linux Programmer's Manual"
.SH NAME
uname \- get name and information about current kernel
.SH SYNOPSIS
.B #include <sys/utsname.h>
.PP
.BI "int uname(struct utsname *" buf );
.SH DESCRIPTION
.BR uname ()
returns system information in the structure pointed to by
.IR buf .
The
.I utsname
struct is defined in
.IR <sys/utsname.h> :
.PP
.in +4n
.EX
struct utsname {
    char sysname[];    /* Operating system name (e.g., "Linux") */
    char nodename[];   /* Name within "some implementation-defined
                          network" */
    char release[];    /* Operating system release (e.g., "2.6.28") */
    char version[];    /* Operating system version */
    char machine[];    /* Hardware identifier */
#ifdef _GNU_SOURCE
    char domainname[]; /* NIS or YP domain name */
#endif
};
.EE
.in
.PP
The length of the arrays in a
.I struct utsname
is unspecified (see NOTES);
the fields are terminated by a null byte (\(aq\e0\(aq).
.SH RETURN VALUE
On success, zero is returned.
On error, \-1 is returned, and
.I errno
is set appropriately.
.SH ERRORS
.TP
.B EFAULT
.I buf
is not valid.
.SH CONFORMING TO
POSIX.1-2001, POSIX.1-2008, SVr4.
There is no
.BR uname ()
call in 4.3BSD.
.PP
The
.I domainname
member (the NIS or YP domain name) is a GNU extension.
.SH NOTES
This is a system call, and the operating system presumably knows
its name, release and version.
It also knows what hardware it runs on.
So, four of the fields of the struct are meaningful.
On the other hand, the field
.I nodename
is meaningless:
it gives the name of the present machine in some undefined
network, but typically machines are in more than one network
and have several names.
Moreover, the kernel has no way of knowing
about such things, so it has to be told what to answer here.
The same holds for the additional
.I domainname
field.
.PP
To this end, Linux uses the system calls
.BR sethostname (2)
and
.BR setdomainname (2).
Note that there is no standard that says that the hostname set by
.BR sethostname (2)
is the same string as the
.I nodename
field of the struct returned by
.BR uname ()
(indeed, some systems allow a 256-byte hostname and an 8-byte nodename),
but this is true on Linux.
The same holds for
.BR setdomainname (2)
and the
.I domainname
field.
.PP
The length of the fields in the struct varies.
Some operating systems
or libraries use a hardcoded 9 or 33 or 65 or 257.
Other systems use
.B SYS_NMLN
or
.B _SYS_NMLN
or
.B UTSLEN
or
.BR _UTSNAME_LENGTH .
Clearly, it is a bad
idea to use any of these constants; just use sizeof(...).
Often 257 is chosen in order to have room for an internet hostname.
.PP
Part of the utsname information is also accessible via
.IR /proc/sys/kernel/ { ostype ,
.IR hostname ,
.IR osrelease ,
.IR version ,
.IR domainname }.
.SS C library/kernel differences
.PP
Over time, increases in the size of the
.I utsname
structure have led to three successive versions of
.BR uname ():
.IR sys_olduname ()
(slot
.IR __NR_oldolduname ),
.IR sys_uname ()
(slot
.IR __NR_olduname ),
and
.IR sys_newuname ()
(slot
.IR __NR_uname) .
The first one
.\" That was back before Linux 1.0
used length 9 for all fields;
the second
.\" That was also back before Linux 1.0
used 65;
the third also uses 65 but adds the
.I domainname
field.
The glibc
.BR uname ()
wrapper function hides these details from applications,
invoking the most recent version of the system call provided by the kernel.
.SH SEE ALSO
.BR uname (1),
.BR getdomainname (2),
.BR gethostname (2),
.BR uts_namespaces (7)
.SH COLOPHON
This page is part of release 5.05 of the Linux
.I man-pages
project.
A description of the project,
information about reporting bugs,
and the latest version of this page,
can be found at
\%https://www.kernel.org/doc/man\-pages/.

Thank you in advance.

[pmackenz]

1) as for uname:

uname is a command, -a is an option to this command.  You need to type  the word uname followed by a space followed by -a.  The output is a string with all the necessary system details.  The gz files are manual pages to be viewed using

man uname

2) the real issue: OpenFoam. 

Your description is very helpful.  It looks like a version incompatibility that requires a fix in the code.   We are looking into this ASAP and keep you informed.  Most likely, we will release source for OpenFoam 6 and one for OpenFoam 7.

Thank you for your patience

[jwan1]

Dear Sir,

I was wondering if you could let me know the reason of below errors:
 
I tried to use exponential velocity profile at inlet but I got below error:
(1 0 0 0 1 0 0 0 1)
local x-axis: (1 0 0)
local y-axis: (0 1 0)
local z-axis: (0 0 1)
global position of the origin of the local coordinate sytem: (0 0 0)
coordinates tranform matrix: (1 0 0 0 1 0 0 0 1)
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::sqrt(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#4 Foam::sqrt(Foam::tmp<Foam::Field<double> > const&) at ??:?
#5 Foam::digitalFilterFvPatchVectorField::initialiseParameters() at ??:?
#6 Foam::digitalFilterFvPatchVectorField::updateCoeffs() at ??:?
#7 Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#8 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#9 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
Floating point exception (core dumped)

I tried also to run DFSEM but I got below error:
IOstream error at line 109.

Thank you in advance.

Hello

I'm here to help you sort out the error you encountered during the implementation of the turbulent inflow boundary condition. Would you please provide us with your OpenFOAM project files (or your input for the 'inflowProperties' file) so that we can look into it? Thank your.

Best regards

[ZMansouri]

Excuse me, when the turbulent spot method will be available to use? and I was wondering if you let me know approximately when the issue with DFSEM will be solved?

[ZMansouri]

Thank you for answer.
For DFSEM I tried different inputs, but the one of them is:
/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \    /   O peration     | Website:  https://openfoam.org
    \  /    A nd           | Version:  6
     \/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      inflowProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

        intersection       ( 0 0 0 );
        yOffset            0;
        zOffset            0;
// mean velocity
UDict
{
    referenceValue          7.66;
    profile                 uniform;
}

// turbulence intensity (symmTensorField)
IDict
{
    referenceValue         (0.03  0  0  0.03  0  0.03);
    profile                 uniform;
}

// turbulence length scale profile for u component
LuxDict
{
    referenceValue          1.808;
    profile                 uniform;
}

// turbulence length scale profile for v component
LvxDict
{
    referenceValue          1.808;
    profile                 uniform;
}

// turbulence length scale profile for w component
LwxDict
{
    referenceValue          1.808;
    profile                 uniform;
}

LuyToLuxRatio              0.2;
LuzToLuxRatio              0.3;
LvyToLvxRatio              0.2;
LvzToLvxRatio              0.3;
LwyToLwxRatio              0.2;
LwzToLwxRatio              0.3;


// ************************************************************************* //

I think it is better to have all project files, so I will upload project file in onedrive and will share its link to you.
Thank you in advance,

Dear Sir,

I was wondering if you could let me know the reason of below errors:
 
I tried to use exponential velocity profile at inlet but I got below error:
(1 0 0 0 1 0 0 0 1)
local x-axis: (1 0 0)
local y-axis: (0 1 0)
local z-axis: (0 0 1)
global position of the origin of the local coordinate sytem: (0 0 0)
coordinates tranform matrix: (1 0 0 0 1 0 0 0 1)
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::sqrt(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#4 Foam::sqrt(Foam::tmp<Foam::Field<double> > const&) at ??:?
#5 Foam::digitalFilterFvPatchVectorField::initialiseParameters() at ??:?
#6 Foam::digitalFilterFvPatchVectorField::updateCoeffs() at ??:?
#7 Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#8 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#9 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
Floating point exception (core dumped)

I tried also to run DFSEM but I got below error:
IOstream error at line 109.

Thank you in advance.

Hello

I'm here to help you sort out the error you encountered during the implementation of the turbulent inflow boundary condition. Would you please provide us with your OpenFOAM project files (or your input for the 'inflowProperties' file) so that we can look into it? Thank your.

Best regards

[ZMansouri]

Dear Sir,

I solved the problem and the error with exponential velocity profile by using smaller time steps. However the problem with DFSEM model is not solved yet, so I explained in the attach file in details about this issue.

Thank you in advance.

[jwan1]

Excuse me, when the turbulent spot method will be available to use? and I was wondering if you let me know approximately when the issue with DFSEM will be solved?

The turbulent spot method proposed by Hannes Kröger and Nikolai Kornev ("Generation of divergence free synthetic inflow turbulence with arbitrary anisotropy") is actually already available in the tool, see the boundary condition "turbulentATSMInlet".

[jwan1]

Dear Sir,

I solved the problem and the error with exponential velocity profile by using smaller time steps. However the problem with DFSEM model is not solved yet, so I explained in the attach file in details about this issue.

Thank you in advance.

Before answering your issues, please note that the latest version of the TInF tool and its source code will always be first updated at our repository on Github (https://github.com/NHERI-SimCenter/TurbulenceInflowTool/). The latest documentation will be updated at https://github.com/NHERI-SimCenter/SimCenterDocumentation/tree/master/TInF. Based on the screenshots you have provided in your attach file, it seems that you are using an out-dated version of the TInF tool. Please access the above link to get the latest one. We also provide some tutorials in the repository (https://github.com/NHERI-SimCenter/TurbulenceInflowTool/tree/master/tutorials). One major modification we have made in the latest code is that the parameters related to the turbulent intensity are now replaced by the parameters related Reynolds stresses. Another modification concerns how integral length scales should be specified. More details can be found in the latest documentation.

Regarding the issues mentioned in your attach file

1. If I use boundary condition folders for performing the command “wmake”, I will be able to
run models with SEM and DFM (i.e., digitalfilter and syntheticeddy), but not DFSEM.

Response: The boundary conditions "digitalfilter" and "syntheticeddy" are out of date, and they are now renamed as "turbulentDFMInlet" and "turbulentSEMInlet".  The latest source code contain four boundary conditions, i.e., turbulentDFMInlet, turbulentSEMInlet, turbulentDFSEMInlet and turbulentATSMInlet.

2. If I use turbulentInflow_OpenFOAM6 folder for performing the command “wmake”, the
platform folder was not produced. Its error will be stated.

Response: Since you are using OpenFOAM 7, please choose the source code corresponding to this version for compilation only. Choosing the wrong version will lead to unpredictable compilation errors.

3. If I use turbulentInflow_OpenFOAM7 folder for performing the command “wmake”, the
platform folder was produced. However, it has some issues in running models with DFSEM which be explained in follows.

Response: The issues (except for the last one) related to "DFSEM" mentioned in the attached file are as a consequence of an incorrect format of parameters input. Please read the instructions in the latest documentation for how to do it correctly. As for the last issue, it is difficult for us to tell what leads to the situation that the program stopped at a certain point based on the information provided in the screenshot. Can you provide the whole project case in addition? Please note that the mesh files can be deleted to reduce the size of the files. It noteworthy that we recommend the turbulent spot method (i.e., the "turbulentATSMInlet" boundary condition) over the divergence-free synthetic eddy method (i.e., the "turbulentDFSEMInlet" boundary condition). Please read the documentation for the difference between the input parameters required by different boundary conditions.

[ZMansouri]

Thank you for your response. My problem is not related to what you explained. I tried the new version, and still I have the same problem. You can find my project files on below link:

https://uark-my.sharepoint.com/:f:/g/personal/zmansour_uark_edu/Eq3JY18LRaJKh9RzNfmm4T4BE58hau9FY6a-pJU4pqdvjA?e=lglRUC

1. WBDFSEM-LV is related to the last version of TInF tools.
2. WBDFSEM is produced by the updated TInF tool.
3. WBDFSEM2 is the modified concerning the errors which I got by running WBDFSEM (i.e. produced files by the updated TInF tool). It stuck again in the first loop.
4. WBASTM produced files by TInF which I got following error.

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::vorton::vorton(Foam::word, int, Foam::Vector<double> const&, double, F                                   oam::Vector<double>, Foam::SymmTensor<double> const&, Foam::Random&) at ??:?
#4  Foam::turbulentATSMInletFvPatchVectorField::initialiseVortons() at ??:?
#5  Foam::turbulentATSMInletFvPatchVectorField::updateCoeffs() at ??:?
#6  Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::V                                   ector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet con                                   st&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#7  ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#8  ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10  ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
Floating point exception (core dumped)

Thank you in advance.

Dear Sir,

I solved the problem and the error with exponential velocity profile by using smaller time steps. However the problem with DFSEM model is not solved yet, so I explained in the attach file in details about this issue.

Thank you in advance.

Before answering your issues, please note that the latest version of the TInF tool and its source code will always be first updated at our repository on Github (https://github.com/NHERI-SimCenter/TurbulenceInflowTool/). The latest documentation will be updated at https://github.com/NHERI-SimCenter/SimCenterDocumentation/tree/master/TInF. Based on the screenshots you have provided in your attach file, it seems that you are using an out-dated version of the TInF tool. Please access the above link to get the latest one. We also provide some tutorials in the repository (https://github.com/NHERI-SimCenter/TurbulenceInflowTool/tree/master/tutorials). One major modification we have made in the latest code is that the parameters related to the turbulent intensity are now replaced by the parameters related Reynolds stresses. Another modification concerns how integral length scales should be specified. More details can be found in the latest documentation.

Regarding the issues mentioned in your attach file

1. If I use boundary condition folders for performing the command “wmake”, I will be able to
run models with SEM and DFM (i.e., digitalfilter and syntheticeddy), but not DFSEM.

Response: The boundary conditions "digitalfilter" and "syntheticeddy" are out of date, and they are now renamed as "turbulentDFMInlet" and "turbulentSEMInlet".  The latest source code contain four boundary conditions, i.e., turbulentDFMInlet, turbulentSEMInlet, turbulentDFSEMInlet and turbulentATSMInlet.

2. If I use turbulentInflow_OpenFOAM6 folder for performing the command “wmake”, the
platform folder was not produced. Its error will be stated.

Response: Since you are using OpenFOAM 7, please choose the source code corresponding to this version for compilation only. Choosing the wrong version will lead to unpredictable compilation errors.

3. If I use turbulentInflow_OpenFOAM7 folder for performing the command “wmake”, the
platform folder was produced. However, it has some issues in running models with DFSEM which be explained in follows.

Response: The issues (except for the last one) related to "DFSEM" mentioned in the attached file are as a consequence of an incorrect format of parameters input. Please read the instructions in the latest documentation for how to do it correctly. As for the last issue, it is difficult for us to tell what leads to the situation that the program stopped at a certain point based on the information provided in the screenshot. Can you provide the whole project case in addition? Please note that the mesh files can be deleted to reduce the size of the files. It noteworthy that we recommend the turbulent spot method (i.e., the "turbulentATSMInlet" boundary condition) over the divergence-free synthetic eddy method (i.e., the "turbulentDFSEMInlet" boundary condition). Please read the documentation for the difference between the input parameters required by different boundary conditions.

[ZMansouri]

The issue of DFSEM will be solved if the solver be pisoFoam and not pimpleFoam.

[ZMansouri]

The issue of ASTM type L also will be solved if the solver be pisoFoam and not pimpleFoam.

However, for the ASTM type R, I got bellow error:
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::vorton::vorton(Foam::word, int, Foam::Vector<double> const&, double, Foam::Vector<double>, Foam::SymmTensor<double> const&, Foam::Random&) at ??:?
#4  Foam::turbulentATSMInletFvPatchVectorField::initialiseVortons() at ??:?
#5  Foam::turbulentATSMInletFvPatchVectorField::updateCoeffs() at ??:?
#6  Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pisoFoam"
#7  ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pisoFoam"
#8  ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pisoFoam"
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10  ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pisoFoam"
Floating point exception (core dumped)