|
[Sponsors] |
[SOWFA] NREL SOWFA ABLTerrainSolver tutorial problem |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
December 5, 2014, 09:22 |
NREL SOWFA ABLTerrainSolver tutorial problem
|
#1 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 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 ??:? is used to replace the p_rgh.correctBoundaryConditions()??? Any help is greatly appreciated! Thanks a lot! Best, Thomas |
|
December 5, 2014, 16:47 |
Call to qwevaluate causes the error ... but ...
|
#2 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 |
|
December 11, 2014, 12:59 |
NREL SOWFA ABLTerrainSolver tutorial problem
|
#3 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 ??:? 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 Last edited by cico0815; January 9, 2015 at 16:30. |
|
December 23, 2014, 05:16 |
|
#4 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
Hi Thomas
I am facing the same issue .Have you resolved it yet. |
|
December 23, 2014, 06:28 |
Re: SOWFA Terrain case ... still a mystery ...
|
#5 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 |
|
December 23, 2014, 06:41 |
|
#6 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
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 |
|
December 25, 2014, 08:42 |
ABLTerrrainSOLVEr
|
#7 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
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 ? |
|
December 28, 2014, 05:54 |
Clean Terrain Case ...
|
#8 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 Last edited by cico0815; January 9, 2015 at 16:30. |
|
December 29, 2014, 04:52 |
Terrain "relaxation"??
|
#9 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 |
|
December 29, 2014, 05:12 |
|
#10 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
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 ? |
|
December 29, 2014, 05:49 |
Tolerance...
|
#11 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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... |
|
December 31, 2014, 04:57 |
|
#12 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
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 |
|
January 9, 2015, 16:29 |
[Solved] ABLTerrainSolver case ... tutorial included ...
|
#13 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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 |
|
January 12, 2015, 06:37 |
Fine tuning this case ...
|
#14 |
New Member
Thomas Schulz
Join Date: Jul 2014
Posts: 17
Rep Power: 12 |
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; Best, Thomas |
|
January 12, 2015, 06:58 |
|
#15 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
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. |
|
February 5, 2015, 00:24 |
|
#16 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
Hi Thomas
Problem solved Thanks |
|
November 24, 2015, 06:42 |
|
#17 |
Member
Fengjiao Bian
Join Date: Nov 2013
Location: beijing
Posts: 30
Rep Power: 13 |
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!
|
|
December 5, 2015, 05:59 |
|
#18 |
New Member
Muhammad Omer Mughal
Join Date: Jul 2010
Location: Singapore
Posts: 22
Rep Power: 16 |
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. |
|
February 1, 2016, 19:16 |
|
#19 |
New Member
Regis
Join Date: Jan 2012
Posts: 24
Rep Power: 14 |
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. |
|
March 5, 2021, 20:40 |
|
#20 |
New Member
Hosein Falahaty
Join Date: Jan 2021
Posts: 10
Rep Power: 5 |
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 Thank you in advance |
|
Tags |
solved |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
chtMultiRegionFoam: problem with the tutorial | samiam1000 | OpenFOAM | 21 | January 25, 2020 17:32 |
cavity tutorial problem in OF 3.0.x | mohsen.boojari | OpenFOAM Running, Solving & CFD | 5 | February 14, 2016 12:03 |
[SOWFA] NREL SOWFA pisoFoamTurbine tutorial problem | mohsen.boojari | OpenFOAM Community Contributions | 1 | February 9, 2016 09:43 |
multiRegionHeater tutorial visualization problem | Bufacchi | OpenFOAM Running, Solving & CFD | 3 | September 18, 2015 10:20 |
Vessel tutorial problem | hosseinhgf | CFX | 1 | March 17, 2013 12:39 |