turbulentDFMInlet crashed using inhomogenous turbulence input - stan_lw, February 04, 2021

[JustinBonus]

I am trying to run a test case with turbulentDFMInlet using tabulated boundary data for U, R, L. Since the inhomogenousTurbulence case in the tutorial uses tabulated boundary data, I started with that case. This tutorial case uses turbulentATSMInlet, and I encounter no issue with that. However, when I modified it to run with turbulentDFMInlet, it crashed after the first time step. Below are the three changes I made to the original tutorial case file:

1. In directory /constant/boundaryData/inlet, I renamed the file “L” to “L_ATSM”, then renamed “L_copy” to “L”
2. In directory /0/U, I changed the inlet boundary condition from turbulentATSMInlet to turbulentDFMInlet
3. Change endTime from 20 to 2 in controlDict file (this is not crucial, just to reduce the total run time while troubleshooting)

The case file is too large to be uploaded here. I will send it over email. The zipped case file also contains the run.log file and the error message when it crashed. Thank you!

• stan_lw, February 04, 2021

[JustinBonus]

stan,

I am not sure if I have the correct set of your files, but the ones I've got from Frank appear to have one missing file: constant/inflowProperties (not saying that this is the only issue. Might be in our code, too)

I suggest changing 0/U to include:

inlet
{
    type               turbulentDFMInlet;
    filterType         gaussian;
    filterFactor       4;
    gridFactor         1;
    perodicInY         false;
    perodicInZ         true;
    cleanRestart       false;
    calculateU         true;
    calculateL         true;
    calculateR         true;
    value    $internalField;
}

and add the attached file to constant/. That file was generated using the SimCenter TInF tool. The CFD Expert in WE-UQ uses the same engine and should generate the same input file.

Please let me know if that got you any further. I am available to zoom Friday afternoon or most days next week.

~Peter

• pmackenz, February 05, 2021

[JustinBonus]

Thank you for your suggestion. From Section 2.3 in the documentation (https://nheri-simcenter.github.io/TinF-Documentation/theory/turbulent_inflow.html#specification-of-the-statistics-of-the-target-turbulence), there are three methods to specify the statistics: Direct specification, Specification via interpolation, and Specification via prescribed functions. If I understood correctly, the “inflowProperties” file is only needed for the “Specification via prescribed functions method”. I am trying to use “Specification via interpolation” method which reads the tabulated data in constant/boundaryData/inlet. So I think the “inflowProperties” file is actually not needed?

Anyway I have try running with your suggestion. I added the downloaded file constant/inflowProperties, and modified 0/U inlet boundary as suggested. However, it still crashed at the first time step.

• stan_lw, February 05, 2021

[JustinBonus]

Would you mind connecting with me via zoom or share a recording showing all your settings so I can reproduce the issue? This looks like a bug in the OpenFOAM module and will require some debugging on our end. Having precisely your settings makes tracking and testing easier.

Thanks

• pmackenz, February 05, 2021

[JustinBonus]

Sure we can discuss over Zoom, I will send you the updated case file with inflowProperties if you want to try whether you can reproduce the bug.

• stan_lw, February 06, 2021

[JustinBonus]

Did you get a chance to discuss with Peter, over Zoom? Would you like me to help you setup a meeting?

Thanks
Ajay

• ajaybh, February 07, 2021

[JustinBonus]

Hi Ajay,
Yes I have emailed Peter and he is looking into it, thanks

• stan_lw, February 09, 2021

[JustinBonus]

The issue appears to be that directional parameters in InflowProperties must be provided or the code runs into numeric exceptions (1/0 or 0/0).

Workaround:
Use the InflowProperties file provided in a post above

TODO:

• The OpenFOAM library needs to set sensible default values

• The OpenFOAM library needs to provide human readable error messages instead of just crashing (all modules)

• pmackenz, February 17, 2021

[JustinBonus]

To update on this issue, Jay suggests turning off “calculateU, calculateL and calculateR” by setting them to false. I tried that, but this does not work. In fact, the original tutorial case (which crashed) does not have these lines so by default they are false. If we turned them on (i.e, set them to true), then the simulation works because instead of looking for the tables in /constant/boundaryData/inlet, the simulation looks for /constant/inflowProperties file and skip reading the tables. I run a few tests to provide a clearer description of the issue:

1. Set calculateU, calculateL and calculateR to false -> crashed
2. Set calculateU, calculateL and calculateR to true -> cannot start because there is no inflowProperties file
3. Set calculateU, calculateL and calculateR to true and add the file /constant/inflowProperties -> can run
4. Set calculateU, calculateL and calculateR to false and add the file /constant/inflowProperties -> crashed

From above tests, the simulation works if it reads the file /constant/inflowProperties to obtain U, R, and L (“Specification via prescribed functions” method in the Documentation), but crashed if it reads the tables in /constant/boundaryData/inlet (“Specification via interpolation” method in the Documentation). So the issue lies with the tabulated data in the tables. Jay mentioned that the sigma tensor needs to be positive definite, I will play around with the values in the R table to check whether this is the root cause.

• stan_lw, March 11, 2021

[JustinBonus]

To update, I did another test with an R table having all positive-definite R matrix. In fact, the original R table in the tutorial already have all rows being positive definite, excepts the four rows at the top and bottom of the domains, which have zeros for all values. I changed the values of R11, R22 and R33 to 1e-9 (a very small number but sufficient to make the R matrix positive definite) and rerun, but the simulation still crashed without starting.

• stan_lw, March 14, 2021

[JustinBonus]

I am writing to you as a follow-up on our discussion during today's programmer meeting. Peter & myself ran Jay's and your examples locally on my Ubuntu VM today morning. Below is a detailed description of all the steps we followed, just in case.

For this, we used OpenFOAM7. I downloaded the TinF from SimCenter Github (https://github.com/NHERI-SimCenter/TurbulenceInflowTool). I used the "wmake" command using the files in the folder openFOAM_code / openFOAM7 / turbulentInflow to compile the libraries.

We compared with Jay's examples provided in the folder tutorials / inhomogeneousTurbulence / DFM / channel395. For the solver here, he has used pimpleFoam. We used both pimpleFoam and pisoFoam and both seem to work and restart. We see that you have renamed the solver as TinFFoam but I hope the linking is correctly done.

Another thing that we noticed was that some items (like Ufinal / kfinal etc.) were missing from the system / fvSolutions dictionary. These were in the original Jay's files but were removed. I am guessing that this was probably unintentional. If we run the files, we get an error message from OpenFOAM that these are missing. So once we added them back, the case started running. We used the procedure outlined by Jay (given below in the attached email) to test the restart operation.

We ran four cases where each had a time increment of 0.2:
(a) Case01: Start time was 0s and end time was 1s (10 steps)
(b) Case12: Start time was 1s and end time was 2s. Here, Case01 was re-started from 1s. So 10 steps.

(c) Case02a: Start time was 0s and end time was 2s.
(d) Case02b: Start time was 0s and end time was 2s

Since there is a random generator being employed, there is a small difference between the results of Case12 and Case02a. In order to confirm this, we ran the case again (Case02b). I have emailed the link for you to download all four cases.

We think that the restart function itself is working correctly. Could you please check again?

• ajaybh, May 14, 2021