CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)
-   -   [SOWFA] NREL SOWFA ABLTerrainSolver tutorial problem (https://www.cfd-online.com/Forums/openfoam-community-contributions/145758-nrel-sowfa-ablterrainsolver-tutorial-problem.html)

cico0815 December 5, 2014 08:22

NREL SOWFA ABLTerrainSolver tutorial problem
 
Hello everyone,

yesterday I downloaded the updated version of SOWFA from github. The solver
suite can be found here:

https://github.com/NREL/SOWFA

After several small tweaks everything compiles fine on my XUbuntu 14.04. I tried
the precursorABL/neutral tutorial case and after some updates (fixedFluxPressure
instead of buoyantPressure) I started the case. I used blockMesh, setFieldsABL
(which already failed because there was the following error)

Code:

Build  : 2.3.0-f5222ca19ce6
Exec  : setFieldsABL
Date  : Dec 05 2014
Time  : 14:08:06
Host  : "cfd"
PID    : 2650
Case  : /home/cfd/OpenFOAM/cfd-2.3.0/run/SOWFA/tutorials/precursorABL/neutral
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field U
Reading field T
Reading field p_rgh
Creating/Calculating face flux field, phi...
Reading gravitational acceleration...
Selecting incompressible transport model Newtonian
Creating the kinematic density field, rhok...

u* = 0.35863751503 m/s

<U_1>  = (6.92820323026 3.99999999999 0)  <U_s> = (6.92820323026  3.99999999999 0)  <dU/dn> = (-1.16193474595e-18  -3.25610680393e-18 0)


--> FOAM FATAL ERROR:
updateCoeffs(const scalarField& snGradp) MUST be called before updateCoeffs() or evaluate() to set the boundary gradient.

    From function fixedFluxPressureFvPatchScalarField::updateCoeffs()
    in file fields/fvPatchFields/derived/fixedFluxPressure/fixedFluxPressureFvPatchScalarField.C at line 151.

FOAM exiting

I anyways tried to let the ABLSolver run but an error alike the above occured. I
then commented out the line 325 in setFieldsABL.C (p_rgh.correctBoundaryConditions();) and the setFieldABL utility ran afterwards.
I also commented the line 92 in ABLSolver.C out (see before) and the solver ran
up to this point

Code:

/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.3.0                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 2.3.0-f5222ca19ce6
Exec  : ABLSolver
Date  : Dec 05 2014
Time  : 12:28:26
Host  : "cfd"
PID    : 10092
Case  : /home/cfd/OpenFOAM/cfd-2.3.0/run/SOWFA/tutorials/precursorABL/neutral
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading the gravitational acceleration, g...
Reading planetary rotation rate...
Reading the latitude...
Creating and reading potential temperature field, T...
Creating and reading modified pressure field, p_rgh...
Creating and reading velocity field, U...
Creating and calculating velocity flux field, phi...
Reading/calculating face flux field phi

Reading transport properties...
Selecting incompressible transport model Newtonian
Reading the atmospheric boundary layer properties...
    Specified wind at 80 m:
              Time 0,  wind from 240 degrees at 8 m/s
              Time 50000,  wind from 240 degrees at 8 m/s

    +x is east and +y is north
                  N
                  0
                  |

        W 270 --      --  90 E

                  |
                  180
                  S
Omega [0 0 -1 0 0 0 0] (0 5.40430167656e-05 4.86605508618e-05)
Creating turbulence model...
Selecting turbulence model type LESModel
Selecting LES turbulence model dynLagrangianCsBound
Selecting LES delta type smooth
Selecting LES delta type cubeRootVol
dynLagrangianCsBoundCoeffs
{
    filter          simple;
    ce              1.048;
    theta          1.5;
}

Creating the Coriolis force vector, fCoriolis...
Creating kinematic (Boussinesq) density field, rhok...
Creating the kinematic thermal conductivity field, kappat...
Reading and creating the wall shear stress field, Rwall...
Reading and creating the wall temperature flux field, qwall...
Creating and calculating the gravity potential field, gh and ghf...
Creating and calculating the static pressure field, p...
Setting up the pressure reference cell information...
Creating mean temperature field, Tmean...
Creating fluctuating temperature field, Tprime...
Creating mean velocity field, Umean...
Creating fluctuating velocity field, Uprime...
Creating mean SGS stress field, Rmean...
Creating mean SGS temperature flux field, qmean...
Creating mean SGS viscosity field, nuSGSmean...
Initializing with zero pressure gradient...

Courant Number mean: 0.373333333393 max: 0.373333333333

Total number of cell center height levels: 100
78400  90000000
...
78400  90000000
Local Flux Continuity Error:  Min 0  Max 3.39686165615e-14  Weighted Mean 8.87516162301e-17
Total Boundary Flux: 3.92910790963e-24

PIMPLE: Operating solver in PISO mode

Starting time loop

<U_1> = (8 0 0)  <U_s> = (8 0 0)  <dU/dn> = (0 0 0)
DILUPBiCG:  Solving for flm, Initial residual = 1, Final residual = 0.00180675762046, No Iterations 1
DILUPBiCG:  Solving for fmm, Initial residual = 1, Final residual = 0.00180675761966, No Iterations 1
TRef = 290
uStarMean = 0.817991099632  LMean = 9.99999999996e+29  phiMMean = 1
UParallelMeanMag = 8  UParallelPMeanMag = 8
RwMagMean  = 0.669109439077  RwMeanMag = 0.669109439077  sqrt(RwMagMean) =  0.817991099632  sqrt(RwMeanMag) = 0.817991099632  uStarMean =  0.817991099632
z1Mean = 4.99999999999
TRef = 290
TSurfaceMean = 300  TAdjacentMean = 300  deltaTMean = 0
#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::fixedHeatingRateFvPatchField::qwEvaluate(double&,  double&, double&, double&, double&, double, double,  double, double, double, double, double, double, double, double, double,  double, double, double, int) at ??:?
#4  Foam::fixedHeatingRateFvPatchField::evaluate(Foam::UPstream::commsTypes) at ??:?
#5  Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField,  Foam::volMesh>::GeometricBoundaryField::evaluate() at ??:?
#6 
 at ??:?
#7  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#8 
 at ??:?

Anyone out there who could help me resolve this issue? Is there a function that

is used to replace the p_rgh.correctBoundaryConditions()???

Any help is greatly appreciated!

Thanks a lot!

Best, Thomas

cico0815 December 5, 2014 15:47

Call to qwevaluate causes the error ... but ...
 
Hello!

I was able to delimit the second error mentioned above here

src/finiteVolume/fields/fvPatchFields/derived/surfaceTemperatureFluxModels/fixedHeatingRate/fixedHeatingRateFvPatchField.C

In line 309 of the above file there is a call to the "qwevaluate" function which seems to cause the error during the first
iteration (facei=0). As it produces an floatingpoint exception this might be a clue for someone more skilled than me to
help me solve the error?

Thanks a lot.

Best, Thomas

cico0815 December 11, 2014 11:59

NREL SOWFA ABLTerrainSolver tutorial problem
 
Hello everyone,

I am using the NREL SOWFA suite to setup some cases. The software can
be found on github

https://github.com/NREL/SOWFA/

I'm trying to create a ABLTerrainSolver case and it seems there are some
bugs in the implementation or am I doing something wrong? Somebody here
who could help me with this case?

[removed]

It uses moveDynamicMesh to attach to the terrain and calls setFieldsABL
afterwards. The ABLTerrainSolver crashes with this error message:

Code:

PIMPLE: Operating solver in PISO mode


Starting time loop

<U_1>  = (-1.25337e-05 15.0001 0)  <U_s> = (0.0136353 14.5618  0.680718)  <dU/dn> = (-0.000705281 0.0216922 -0.0335939)
DILUPBiCG:  Solving for flm, Initial residual = 1, Final residual = 0.0359155, No Iterations 1
bounding flm, min: -0.0230707 max: 0.0223845 average: -4.22079e-05
DILUPBiCG:  Solving for fmm, Initial residual = 1, Final residual = 0.0359094, No Iterations 1
bounding fmm, min: -0.00913156 max: 0.133026 average: 0.00141043
TRef = 300
uStarMean = 1.09808  LMean = 1e+30  phiMMean = 1
UParallelMeanMag = 14.5776  UParallelPMeanMag = 14.7777
RwMagMean = 1.20486  RwMeanMag = 1.20447  sqrt(RwMagMean) = 1.09766  sqrt(RwMeanMag) = 1.09748  uStarMean = 1.09808
Time = 21  Time Step = 21
Courant Number mean: 1.55351 max: 2.0861
deltaT = 0.358696
<U_1>  = (-1.25337e-05 15.0001 0)  <U_s> = (0.0136353 14.5618  0.680718)  <dU/dn> = (-0.000705281 0.0216922 -0.0335939)
DILUPBiCG:  Solving for Ux, Initial residual = 0.350015, Final residual = 1.96455e-16, No Iterations 6
DILUPBiCG:  Solving for Uy, Initial residual = 0.970456, Final residual = 1.77876e-16, No Iterations 6
DILUPBiCG:  Solving for Uz, Initial residual = 1, Final residual = 1.45511e-17, No Iterations 6
DILUPBiCG:  Solving for T, Initial residual = 1, Final residual = 5.24417e-16, No Iterations 6
GAMG:  Solving for p_rgh, Initial residual = 1, Final residual = 0.00935106, No Iterations 11
<U_1>  = (-0.0509501 15.9364 0.476419)  <U_s> = (-0.0439888 15.6557  0.746193)  <dU/dn> = (-0.000636055 0.0133576 -0.0127496)
DILUPBiCG:  Solving for T, Initial residual = 0.242254, Final residual = 2.41253e-17, No Iterations 6
GAMG:  Solving for p_rgh, Initial residual = 0.119069, Final residual = 0.00113359, No Iterations 8
<U_1>  = (-0.0329056 15.9365 0.484592)  <U_s> = (-0.0282349 15.7298  0.752945)  <dU/dn> = (-0.000600525 0.0116376 -0.0125505)
DILUPBiCG:  Solving for T, Initial residual = 0.237378, Final residual = 2.67629e-17, No Iterations 6
GAMG:  Solving for p_rgh, Initial residual = 0.0170006, Final residual = 8.93181e-09, No Iterations 35
<U_1>  = (-0.0303681 15.9439 0.485109)  <U_s> = (-0.0256299 15.7398  0.752529)  <dU/dn> = (-0.000603657 0.0115944 -0.0125146)
DILUPBiCG:  Solving for T, Initial residual = 0.234728, Final residual = 9.29193e-17, No Iterations 6
Local Flux Continuity Error:  Min 6.62286e-16  Max 1.27786  Weighted Mean 1.99251e-05
Total Boundary Flux: -5361.84
Total Boundary Area: 2.64029e+06
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  in "/lib/x86_64-linux-gnu/libc.so.6"
#3 
 at ??:?
#4  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#5 
 at ??:?

I would loooove to find out why this is happening! I am using the current github
release of SOWFA and OpenFOAM 2.3.0 on a 14.04 XUbuntu 64bit system
(to setup the case).
The case does only run up to this point due to the fact that I disabled the
"fixedHeatingRate" in the qwall file (0.orig folder) and set it to "zeroGradient".

There seems to be an error in the patch field library implementation too.

Anybody out there who is into the SOWFA solver suite?? Please help!

Best,

Thomas

Muhammad Omer Mughal December 23, 2014 04:16

Hi Thomas

I am facing the same issue .Have you resolved it yet.

cico0815 December 23, 2014 05:28

Re: SOWFA Terrain case ... still a mystery ...
 
Dear Muhammad,

not really but I am pretty sure, that the error that occured has something
to do with the cyclic boundaries that are used in all the other tutorial cases.
I think one needs to create cyclic boundaries again. This means that the
terrain has to be cyclic too (like a pattern you would adapt to some surface).

I am still trying to figure out a way to produce such a pattern from my
DTM data ... I am a little stuck there but that's something else...

I read in a PDF published by Matt Churchfield et. al. that they used
moveDynamicMesh to adapt to their surface. I think this also has
something to do with the resulting mesh as I think cyclic boundaries
need to have very good coincidence in the opposing cells ..

Did you have any ideas?

Best, Thomas

Muhammad Omer Mughal December 23, 2014 05:41

Hi Thomas

Thanks for the reply.
I had to change the boundary condition to be cyclic for north south and east and west patches. I have changed the boundary file in constant/polymesh and also in my block mesh dict. I had to change the matching tolerance from 0.001 to 0.4 as the mismatch between the patches was 11.56 %. When I did all these changes and used the mesh the solver runs upto the stage where it starts to do the first iteration and than it hangs there and there is no error shown but the solver doesnot perform the first iteration.
Then someone recommended to use ABLTerrainSolver instead .I therefore changed the boundary conditions similar to your case and I am stuck in the error that I mentioned in the previous post.
I have tried to run ABLTerrainSolver in the cyclic mode but it performs a few iterations and then stops and doesnot proceed forward.
moveDynamicMesh was used by Matt et al for the mesh to conform to the terrain.It doesnot create the cyclic patch as this is created by createPatchDict if you are certain to produce a cyclic patch separately.
Let me know if you hit a jackpot and get this problem solved.It has become a pain in the the neck

Muhammad Omer Mughal December 25, 2014 07:42

ABLTerrrainSOLVEr
 
Hi Thomas

I just discovered that the problem with this error is lying somewhere around here

const fvPatchScalarField& TPatch = T.boundaryField()[patch().index()];
scalarField TAdjacent = TPatch.patchInternalField();
scalar TAdjacentMean = gSum(TAdjacent * area) / areaTotal;

and as the error states

Local Flux Continuity Error: Min 2.41422e-15 Max 11.968 Weighted Mean 5.55559e-05
Total Boundary Flux: -4.27928e+07
Total Boundary Area: 1.29416e+09

That means the problem lies with the description of boundary condition on the faces .So I suggest we try to modify the boundary condition on the faces again and see if this works.
Any suggestions ?

cico0815 December 28, 2014 04:54

Clean Terrain Case ...
 
Dear Muhammad,

I tried to create a very simple case. Terrain (flat) with a bump in the middle.
It runs but I had to disable all the special boundary conditions to make it
work. I uploaded the case here

[removed]

And yes! I really think the error lies within the boundary conditions. There seem
to be a buried error somewhere .. I haven't been able to find it yet...

Best, Thomas

cico0815 December 29, 2014 03:52

Terrain "relaxation"??
 
Dear Muhammad,

I would like to ask you how you managed to "relax" the borders of your
terrain to make them match the other end? Did you alter the STL file?
How?

Any progress yet in using the boundary conditions or even make them work?

Thanks a lot!

Best,

Thomas

Muhammad Omer Mughal December 29, 2014 04:12

Hi Thomas

I just increased the match tolerance from 0.001 to 0.4.

I am still working on the boundary conditions.

Why have you used fastFoam as a solver in your controlDict.0 ?

do you have a skype ID ?

cico0815 December 29, 2014 04:49

Tolerance...
 
Dear Muhammad,

the solvers do not use the "application" entry in the controlDict
file. I use the ABLTerrainSolver. Do you still use the case from the
first post? That case has a lot of errors ... the second post is
corrected.

I'm sorry but I don't use skype...

Best, Thomas

P.S. I switched to OpenFOAM 2.2.2 ... that seems to be the
safer way to go...

Muhammad Omer Mughal December 31, 2014 03:57

Hi Thomas

I am still running in the same error using the boundary conditions that you have provided in your case .Do you think is it because I am using OpenFOAM 2.1.1

cico0815 January 9, 2015 15:29

[Solved] ABLTerrainSolver case ... tutorial included ...
 
This is an UN-official tutorial case I put together for
the ABLTerrainSolver (github version dated January 2015).

I used OpenFOAM 2.2.2 on a Ubuntu 14.04 64-bit computer.
The tutorial might be adapted to OpenFOAM 2.3.0 but the
"buoyantPressure" boundary condition doesn't exist in
2.3.0 anymore ... one could use "fixedFluxPressure" but
I won't do it ... ;-)

Just run the "Allrun.pre" and "Allrun.post" scripts and
follow the instructions.

Hope to be able to help someone out there! :-)

Best, Thomas

https://www.dropbox.com/s/4sw0z10p7k...rrain.tgz?dl=0

cico0815 January 12, 2015 05:37

Fine tuning this case ...
 
Dear Muhammad,

for some fine tuning for my real case I was wondering what the values in "initialConditions" for qwall (fixedHeatingRate) and Rwall (SchumannGroetzbach) really do ... I found out that even the Courant number is fine and within my desired range, the case crashes due to errors within the fixedHeatingRate, velocityABL and SchumannGroetzbach boundary conditions. They seem to have to be really finetuned ... any idea? Did you find the papers those conditions where based on?

What are those values?

Code:

// used by qwall und Rwall
kappa                0.41;    // vonKarman constant ??
betaM                15.0;
gammaM              4.9;
z0                    0.1;    // roughness length ??

// Schumann-Grotzbach (Reynolds-Stress)
Rwall                (0.0 0.0 -0.04 0.0 0.0 0.0);

// fixedHeatingRate
qwall                (0.0 0.0 0.001);
heatingRate            -6.9444444E-5;
T0                    265.0;
betaH                9.0;
gammaH                7.8;
alphaH                1.0;

Thanks a lot!

Best, Thomas

Muhammad Omer Mughal January 12, 2015 05:58

Hi Thomas

These values are actually adopted from "an inter comparison of LES of stable boundary layer " presented by Robert J.Beare from Uk Met Office as part of the global energy and water cycle experiment atmospheric boundary layer initiative.
Hope this helps.

how did you fix the cyclic boundary condition problem. I think since my geometry is more complex and large therefore it is becoming difficult to implement these conditions.Also I have used a different tool to generate the mesh.

Can you kindly give me your email address or any other social media address so that we can have a chat on this issue .I will be really grateful to you for that.

Muhammad Omer Mughal February 4, 2015 23:24

Hi Thomas

Problem solved

Thanks

jiaojiao November 24, 2015 05:42

Dear Muhammad,I meet the same problem in this thread, I am wondering that could you tell me how do you solver this problem? by finetuning? and do you commented out the line 325 in setFieldsABL.C (p_rgh.correctBoundaryConditions() and the line 92 in ABLSolver.C ?Thanks for any help!
Quote:

Originally Posted by Muhammad Omer Mughal (Post 530459)
Hi Thomas

Problem solved

Thanks


Muhammad Omer Mughal December 5, 2015 04:59

Hi jiaojiao

Sorry for late response

Primarily you have to concentrate on mesh development. If you are performing LES than be sure to use hexahedral cells in your mesh. Secondly your stl file should be meshed without orthogonality and skewness errors.

You dont have to alter the solver file. Once you are finished with polishing your mesh be sure to use the setABLFeilds command before you start using the ABL solver. Use ABLterrainSolver for complex geometry. I would recommend to use the terrainblockmesher to mesh the terrain if you are not using the cyclic boundary condition.
Let me know how if the things work out for you well and send me your case I would be happy to fix the boundary conditions for your case.

Regis_ February 1, 2016 18:16

I've been trying to set up a simple case using ABLTerrainSolver but so far I've been unsuccessful. I'm using OpenFOAM 2.4.0 and the latest release of SOWFA codes.

I get the same error reported by Thomas in the first post of this thread (updateCoeffs) during the execution of setFieldsABL. Is it correct to simply comment out such lines? Won't the result be affected negatively at all? How have you guys solved this issue?

Also, I checked everything you two talked about and it seems ok. The cyclic boundary conditions seems consistent and the blockMeshDict also seems alright. The generated boundary file in constant/polyMesh seems correct. I’ve increased the matching tolerance to see if that was the case with no success. I’m creating the mesh with blockMesh and then using snappyHexMesh to conform and snap to a bump geometry (as a test case, most likely similar to Thomas’).

I appreciate any help.

Falahaty March 5, 2021 19:40

3 Attachment(s)
Greetings!

I have to acknowledge that I am new to both SOWFA and LINUX.
I have downloaded SOWFA from https://github.com/pablo-benito/SOWFA-installation and installed on Ubuntu16.04.7 LTS to use for micro siting, but I am having two main problems.

Firstly, I am going to check the first example of SOWFA, example.ABL.flatTerrain.neutral. My current problem is that mpirun can not launch setFieldsABL initializer and ABLsolver.

I checked the .bashprofile to have right paths but it sounds ok. Could you please take a look on it.


Secondly, I could not install OpenFAST, even though upraded gfortran from 5.4.0 to 7.5.0. I am having problem with configuring Cmake:

HTML Code:

cmake -DCMAKE_INSTALL_PREFIX="/path/to/wherever/you/want/to/install/OpenFAST"

CMake Warning:

No source or binary directory provided.  Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.

-- The CXX compiler identification is unknown

-- The Fortran compiler identification is unknown
CMake Error at CMakeLists.txt:18 (project):
 The CMAKE_CXX_COMPILER:

 

 icpc

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


 CMake Error at CMakeLists.txt:18 (project):
  The CMAKE_Fortran_COMPILER:

  ifort

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
  path to the compiler, or to the compiler name if it is in the PATH.


 -- Configuring incomplete, errors occurred!
 See also "/home/hosein_falahaty/OpenFAST/CMakeFiles/CMakeOutput.log".
 See also

  /home/hosein_falahaty/OpenFAST/CMakeFiles/CMakeError.log

Could you please kindly help me in solving these two problems.

Thank you in advance


All times are GMT -4. The time now is 01:39.