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 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:
/*---------------------------------------------------------------------------*\ is used to replace the p_rgh.correctBoundaryConditions()??? Any help is greatly appreciated! Thanks a lot! Best, Thomas |
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 |
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 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 |
Hi Thomas
I am facing the same issue .Have you resolved it yet. |
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 |
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 |
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 ? |
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 |
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 |
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 ? |
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... |
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 |
[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 |
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 Best, Thomas |
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. |
Hi Thomas
Problem solved Thanks |
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:
|
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. |
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. |
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" Thank you in advance |
All times are GMT -4. The time now is 01:39. |