Wind simulation for Askervein Hill
Hi there! I am a new Foamer who just stated with OpenFoam recently. I am trying to simulate with the k-epsilon model the flow over the Askervein hill. I started looking at the turbinesiting tutorial and then tried to use it as a base for wind study. I have encountered some problems when trying to run the solver SimpleFoam after having imported the Askervein.stl map and having meshed it with SnappyHeshMesh. I get this message error
montserrat@benji-Satellite-A215:~/OpenFOAM/montserrat-1.7.1/run/Test_Wind_cases/Askervein_Stl$ espero #0 Foam::error::printStack(Foam::Ostream&)q in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 in "/lib/libm.so.6"
#4 log in "/lib/libm.so.6"
#5 Foam::incompressible::atmBoundaryLayerInletVelocit yFvPatchVectorField::updateCoeffs() in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6 Foam::incompressible::atmBoundaryLayerInletVelocit yFvPatchVectorField::atmBoundaryLayerInletVelocity FvPatchVectorField(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#7 Foam::fvPatchField<Foam::Vector<double> >::adddictionaryConstructorToTable<Foam::incompres sible::atmBoundaryLayerInletVelocityFvPatchVectorF ield>::New(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#8 Foam::fvPatchField<Foam::Vector<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#9 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::GeometricB oundaryField(Foam::fvBoundaryMesh const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#10 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readField(Foam::dictionary const&) in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#11 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readField(Foam::Istream&) in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#12 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#14 __libc_start_main in "/lib/libc.so.6"
Apparently it cannot even start the simulation. I see that the problem could be related to the inlet velocity profile. Some questions arise when thinking in how they define the inletvelocityprofile function:
-Why is z_ground a input parameter as it could vary in the spanwise direction?
Is it because it is thought that the inlet should be at the same height?
I use the boundary conditions that come by default, so I basically just tune the inlet velocity and the turbulent kinematic energy k. Has anyone used this tutorial to do some wind simulations over small hills?
If somebody could give me a hint in what the problem could be and give me some advise on how to pursue in this case, I would really appreciate it.
Thank you in advance,
I m doing a similar study. until now, i didnīt start yet the simulation. i just read a master theses about something similar.
i donīt know if you read this these. it will give you some good guide lines.
search on internet "Modelling of wind flow over complex terrain
using OpenFoam"-by Xabier Pedruelo Tapia.
I will start a case this week. we can share information if you are interest. it is not so easy to be on your one on OF. I know from experience.
Hey! It's nice to find somebody working on the same project! To tell you a little bit about me: I have started a master thesis for wind simulation over complex terrain using OpenFoam, and this is my 5th week. I am quite desperate because there is no information anywhere and time passes without getting any results. As you say, I have allready read the master thesis of Xavi and it is an okey starting point. But, as you can see he doesn't manage to simulate the Askervein hill with SnappyHexMesh.
For now I have set up the case, but I have problems with the inlet velocity profile and cannot manage to overcome it. It could be perfect if we could share information!! do you have dropbox? (www.dropbox.com) it could be a good idea to share a folder with the test cases. If you give me your approval I will create it. my email is: firstname.lastname@example.org
By the way I see that you are living in MAdrid. I'm from Barcelona but doing my thesis in Denmark.
I have done wind simulation with simpleWindFoam over the Bolund terrain. I have not yet verified my results but I think it works fine. Are you sure that you have the latest version of 1.7? I know thet there was a bug in the beginning with the inlet profile. Make sure to use "git pull" to always get the lates version. And you have to adjust the zGround in the ABLCondition file to your area.
From your error message it also looks like you are trying to run simpleFoam. You need to run simpleWindFoam.
best regards Siri
Hi Siri! It's nice to hear that you came out with some results.
- Concerning the version I am running it is the 1.7.1 on Ubuntu, just installed a month ago (more or less), so I suppose the bug issue has already been resolved right??
- On the other hand, and related to SimpleWindFoam solver, I thought this solver is only used for wind turbine load calculation, when modeling wind turbines on a hill (correct me if I am wrong). If not what is the difference between SimpleWindFoam and SimpleFoam?
- To start with, I am trying to run SimpleWindFoam for the tutorial case, and I can't:
> first of all I get a little bit confused since the solver is located in the parent folder SimpleWindFoam/SimpleWindFoam/SimpleWindFoam.C and not in opt/applications/solvers/incompressible
> I have tried to run it after doing on the command window> blockMesh, then SnappyHexMesh and after that SimpleWindFoam. Result> he cannot find the solver. I have realised as well that on the ControlDict the solver used is SimpleFoam! So I get doble confused.
> I have tried doing ./Allrun and 'foamRunTutorials' but it does not work either.
I would really appreciate if you could give me a hint on what I should do to run SimpleWindFoam and what is actually does.
Thanks in advance,
well Siri, to answer to your question, nope i didnīt succeed to run the simpleWindFoam case. just dosen't work. i receive the following error:
"Selecting model type actuationDiskSource
- selecting cells using cellSet actuationDisk1
--> FOAM FATAL IO ERROR
cannot open file
If i understand is something connected with CellSet and that file makeZone. i donīt know what to change to include the makeZone file in the computations, so from here it's appear the error.
one question, What kind of compiler do you use do see the C++ file? iīm using eclipse, like the majority who utilize OF. this is a tutorial, :
to use the simpleWindFoam model, first you have to build it with wmake. enter in the Make directory, open "files" and change (if is not change already) the following line:
this will specify were to create the simpleWindFoam solver, in our case $WM_PROJECT_USER_DIR; more precise in your "user"-1.7.1/applications directories.
to create the solver you can do it using eclipse and in this case you need to read the link above or just type wmake in the simpleWindFoam directory.
the simpleWindFoam solver will be create. after that if you want to use in the turbineSiding case, change the controlDict file from system directory; replace simpleFoam with simpleWindFoam. save the file and try to run it to see if the simulation starts.
my email address is email@example.com.
Yes I do not know why the solver was not located in the "normal" folder. I struggeld with that in the beginning to. As I understand it simpleWindFoam has the ability to use some atmosperic inlet condition. The turbinsiting tutorial has an "Include"-folder in the constant/0-folder and here you must spesify your settings. I have just used the turbinSiting as a startingpoint and I have removed the turbines in snappHM-file. You need to change the controlDict file and make a call to simpleWindFoam insted of simpleFoam.
Hope this help!
i change the snappyHM file. also i delete the sourcesProperties. after deleting this file and starting the simulations i receive an error, which tells me that it can not be found the sourcesProperties files. i try to run the simulation without doing the snappyHM. and the same error.
i'm totally confuse how this things works.
Hey Guys! Thanks a lot for your help! I can now compile SimpleWindFoam following your instructions.
Nevertheless, there are some issues that I would like to discuss about>
I had the same problem as Ovidiu when running manually step by step the turbine sitting tutorial. first blockMesh, then snappyHexMesh and finally simpleWindFoam. But then I looked at the ./Allrun file:
runApplication snappyHexMesh -overwrite
runApplication setSet -batch makeZones
runApplication setsToZones -noFlipMap
So in order to run simpleWindFoam, one needs to run the application setSet and setsToZones, which I think defines the area where the turbines are placed.
So my question is> Do we really need to run these applications everytime since we are not putting any turbines at the site? and are you guys sure that this is the correct solver we need to use and not simpleFoam. (Look at definition of solver for SimpleWindFoam:
Steady-state solver for incompressible, turbulent flow with external
source in the momentum equation to approximate, e.g. wind turbines.
Siri, could you clarify this misunderstanding? I don't get why we can't use simpleFoam.
You can also run the turbine sitting case with SimpleFoam and it works too!
In order to make my case running I have to start the Allrun script (the same as Ben posted). I can not make simpleWindFoam work without the setSet and the setToZone application. This has something to do with mesh manipulation, but I do not understand what the applications are doing!
If you look at the source code the simpleWindFoam and simpleFoam looks very similar. The only difference is that the simpleWindFoam have an additional line stating; include IObasicSourceList.H. I think this is related to the fact that you can add/change sourse file to the momentum equation. In the constant-folder there is a sourceProperties file and this defines the sorces that simpleWindFoam can handel. But I do not have a clear understanding of this ..
Perhaps simpleWind foam alco can handle the ABLcondition on the inlet (I guess so - but then you need to look at the turbineSiting tutorial and copy the boundary condition set up ) and if you are not interested in turbines I guess you could go with simpleFoam.
For my work I need the ability to add external source in the momentum equation so I will continu with simpleWindFoam and try to understand it...
I'm glad I finally met someone that are working with wind and OF. Are you both doing your master thises? My e-amil is; firstname.lastname@example.org
i did a small analysis of two solvers, simpleWindFoam (SWF) and simpleFoam (SF), and i found the following:
-SWF has one more library then SF, in options file you can see the mesh library;
-the UEqn.H it is different at lines 11 and 12 in SWF then SF;
-creatFields.H has one line more in SWF, which includes the external mesh of the turbines;
-also, the code SWF.C at line 36 includes one more header; this header is connected with the sourcesProperties file from turbineSiting/constant case.
in SF the only difference that appears is in pEqn.H at line 21 and 22.
As a conclusion, SWF is the same like SF, but it's include the external turbines mesh.
I don't know Siri if you read Xavi paper. it is a good guide line about the study of wind over complex terrain in OF, but unfortunately is not complete. it dosen't have all the codes in appendix. it has only some code like, the roughness, which is important. and, if i well understood he used a windFoam, which is different from simpleFoam. his study was made only for neutral atmosphere (density constant) and only for flat plane and bump, without and with roughness (two values). the results were compared with Fluent. for the Askervein Hill he used only the snappyHexMesh, doing a small analysis over the mesh. he didn't do the analysis on terrain, like velocity profile or other coefficients. it would be good to know if it is a big difference between his windFoam and the standard simpleFoam. my opinion, i don't think the difference is big, because dosen't count the density. another conclusion from his paper, the 2nd order scheme are more accurate the 1st order (in Fluent the difference is not obvious); doing a parallel with Fluent results in some cases are better(OF results).
now, depending on the parameters of the problem, if you have stable or unstable atmosphere, your density will not be constant anymore, so you have to include it on the equations. also, if is a big domain, you need to put the Coriolis and gravitational forces to obtain the results close to the real world.
this are my conclusion until now.
i have some questions about snappyHM.
i didn't understood it well how it works this pre-processing tool. do you have a good tutorial on this?
your terrain it is directly on *.stl extension or it has a different extension like *.xyz? you used global mapper to convert the file?
depending on your problems, i propose you to write the solver including the others parameters, like: density, Coriolis and gravitational forces, energy equations.
All the best,
Hey Ovidiu! To convert xyz to stl format, I used Pointwise which was given to me, from the research center facilities..I don't know what other ways there are to convert to stl format.
This discussion might help you:
and concerning SnappyHexMesh tutorials there is actually not a lot more than the userguide.
Check this website:
How are you guys doing with the project? I have still not fixed my problem with the velocity inlet profile problem.
See if you get good results in the Askervein hill. I am in parallel using a Mesh provided by the research center..see if I get results using this mesh as well.
Did not understand quite..are your problem related to inlet velocity or mesh or both?
If you want I can have a quick look at your snappyHM file and compair it to mine (my mesh works fine for the Bolund case)...perhaps I can take a quick look at for case files as well (but then you need to make a drop box).
thanks for the snappyHM tutorial, Ben. i already read that website, but still is not so clear for me.
anyway, ... what kind of solver did you used for your cases, simpleFoam, or did you made another one?
i found meshlab which suppose to convert in stl, but is not doing the conversion so i have to install globel mapper at the end, :(
im using AcrossRiver.stl terrain from SnakeRiverCanyon case like a stl surface for a tutorial case.
my question is:
how can i know what are the "nFaces" and "startFace" numbers to write it in constant/polyMesh/boundary files?
Ben, Siri, did you use roughness for you cases?
Hey guys! Sorry for my late reply. I have been away for several days but I am back to work again. I will create a dropbox folder right now for the three of us so we can share our files and with the purpose to learn together.
Ovidiu: you do not need to specify the startFaces or nFaces in the boundary folder. That is done automatically when you run blockMesh or when you run your code without it if you are using another mesh. On the other hand, I am using simpleFoam for now, and will try to make it work first. Once that is done, we will see if we can add extra coding (Coriolis effect for instance and others).
Sire: I will upload my snappyHexMesh, the Askervein terrain Stl file (it is not that big), blockMesh file + boundary conditions, right now on dropbox. If you have time, take a look at it! Thanks a lot!
You will see that I have issues with the inlet velocity profile when you run the code. I suppose that on your Bolund case, you set zground to 0 right? Here, it is a little bit different, since as you will see, the height above ground in the inlet patch is not constant.
How can we determine the exact height in that patch if we are cutting the map with blockMesh? do you guys have an idea on how to do it?
Regards! and keep in touch!
I'm looking at your files now. It looks that you have too fine mesh created with blockmesh. Where you able to rund snappyHeckMesh at all? SnappyHM will create a finer mesh for you. I would also expand the bounding box so that it cut the stl-surface where the height is zero and reduce the cells defines in blockMesh to 30 30 30 insted of 150 140 30.
how are things for your case? did you manage to start the simulations? i look at your case and i run snapyHM. i saw something strange, why does appear the "ground" after you run the snapyHM. this part should be replace by the "terrain.stl" file. Siri was write when she suggest you to reduce the number of cell in the box:
Did you manage to put a roughness for you case Siri? and if you did, what where the steps.
I tried to run Bens case (I expand the domain box and reduced the number of cells) but I am not able to create the mesh. Checkmesh gives me the following message. Have some of you an idea of what is wrong? Where you able to run sHM Ben??
Ovidiu; I have not yet started in implementing changing rougness. The only roughness I use is the Z0 setting for the inlet profile. I need to be able to handle rougness but have not find out how yet...
Result from checkMesh:
Overall domain bounding box (70165 819240 -0.91939004831) (80767 828840 1000)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (4.27267880053e-19 -1.46679611887e-18 -1.13105316657e-18) OK.
Max cell openness = 2.32917475953e-16 OK.
Max aspect ratio = 28.2564446563 OK.
Minumum face area = 281.553788064. Maximum face area = 113088. Face area magnitudes OK.
Min volume = 14732.8817292. Max volume = 3807296.00377. Total volume = 99474676602.2. Cell volumes OK.
Mesh non-orthogonality Max: 79.4290028756 average: 25.586894006
*Number of severely non-orthogonal faces: 18000.
Non-orthogonality check OK.
<<Writing 18000 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
***Max skewness = 5.2424079162, 198 highly skew faces detected which may impair the quality of the results
<<Writing 198 skew faces to set skewFaces
I check your case and i modified the dimensions of your box in the z direction with -20 (or you can move the *.stl file position with 20 in the upper direction (but i don't know how to do this)). i run the snappyHM and worked very good. also, the checkMesh seem ok. another element , but i don't think is so important, i change the numbers of layers, from 4 to 7.
why did i went down with -20 on the z direction, because when you are running the snappyHM, your "terrain.stl" will replace the ground; the terrain.stl becomes your acting zone, not ground from the box. (see again the turbineSitting case; you will see that after running the sHM you will not have ground anymore, you will remain only with the *.stl file)
i put the case on dropbox.
I didn't start the simulations.
|All times are GMT -4. The time now is 13:03.|