[Regis_]

Dear Hosein,

Before I attempt to answer some of your questions, I should note that there is a more recent version of SOWFA that works with OpenFOAM 6 and that is currently maintained. It's available on NREL's github page, under the name of "SOWFA-6", dev branch. Even though it is the dev branch, the code is fully working with working example files.

Now, to your issues. The error you are getting in both ABLSolver and setFieldsABL is because the system cannot find the executable. If you look at the .bash_profile that you are sourcing, you did not change the paths to adapt to your system. Look at the very first line-- I doubt your SOWFA installation is present in that path. This function needs to be edited by you so that it is consistent with your system. Also, make sure you indeed call the function you are setting with the .bash_profile to load everything you set there.

As far as the OpenFAST error, the issue is likely the same since you haven't even modified the install prefix.

Hope this helps.
-Regis

[Falahaty]

Thanks a lot for your prompt response.

Based on your kind comment, I have downloaded SOWFA-6 from "https://github.com/NREL/SOWFA-6/tree/dev".

I have installed OpenFOAM-6 from "https://openfoamwiki.net/index.php/Installation/Linux/OpenFOAM-6/Ubuntu#Ubuntu_16.04" too.

the versions of gcc, gfortran and g++ in my ubuntu16.04.7LTS are 5.5.0 20171010.

The structure of my folders are as follow:

OpenFOAM-6 directory:"/home/hosein_falahaty/OpenFOAM/OpenFOAM-6"
ThirdParty-6 directory:"/home/hosein_falahaty/OpenFOAM/ThirdParty-6"
SOWFA-6 directory:"/home/hosein_falahaty/OpenFOAM/hosein_falahaty-6/SOWFA-6".
OpenFAST directory:"/home/hosein_falahaty/OpenFAST".
(I have to mention that the OpenFAST is not installed successfully. But since I don't need coupling between aerodynamics and structural response at this stage I'd like to ignore it (please correct me if I'm wrong). I'm just going to do micro-siting).

I have attached the bashrc of OpenFAOM and bash_profile of SOWFA.

Unfortunately, still I have not been successful in installing SOWFA (the error log file is attached). Please kindly help me in this regard.

Best regards,

Hosein

[Falahaty]

I could run SOWFA and more or less is working. But still I have couples of problems. Sorry if they are not professional.

Is it OK if I comment out the part related to environmental variable $PBS_O_WORKDIR in runscript.solve1? Where is it defined? Since it is not recognized by the system, it is causing a shift of directory to home/$user and then "cp system/controlDict.$runNumber system/controlDict" is not conducted.

How could I apply a real geometry to SOWFA? what type of database is available?
Thank you.

[Regis_]

I'm glad you were able to move forward. I see your `setFieldsABL` log file has nothing to do with the actual utility you are trying to run. The system is still not able to find it. Are you successful if you try to run `setFieldsABL` outside of a script?

And if you are not using an HPC system with PBS/Torque scheduler, then yes, you should comment out the PBS-related lines of the script. Make sure you are using one of the latest tutorial files available-- `runscript.solve1` isn't one of them.

You can use an STL and make your mesh conform to it. Check the terrain case tutorial files. No "real geometry" database is distributed with SOWFA.

[Falahaty]

Thank you for your reply. Actually, I suppose the problem was from sourcing the bash_profile. Still I have no idea what is the exact source of this problem, but I figured out that the environmental variables in the bash_profile are not being recognized. Then I executed the bash_profile directly in the terminal and then ran Allwmake. In the runscript.solve1, since the PATH and LD_LIBRARY_PATH environmental variables were not known, then the pathes to setFieldsABL and ABLSolver were not found . Now I am defining those env. variables in the same terminal right before executing runscript.solve1. If you have any idea about how to fix the problem of sourcing in a logical way, I will appreciate if you can kindly let me know.

I tried to use SOWFA-6 dev version, but at this stage not successful. I will surely push forward with it.If there is any newer version of SOWFA available, I will appreciate if you could introduce the direct link to me.

If I have the high resolution data-base of geometry for a real case, is there any way to conform it to SOWFA? For meshing, does it make sense to load the topography file into SALOME-CFD, make mesh and conform it to the OpenFOAM?

Thank you

[Regis_]

If you are able to correctly assign some environment variables (like PATH, LD_LIBRARY_PATH, SOWFA_APPBIN, etc) in your current terminal window, then just use the same commands on you .bashrc/.bash_profile. Note that in the bash_profile file you attached in post #22, all those variables are defined within a function, which means you have to call that function for those commands to be executed.

The dev branch of SOWFA-6 is actively being updated. That's where you'll find the latest changes. I strongly suggest you switch from SOWFA-2.4 to SOWFA-6.

For using a geometry of a real case, again, take a look in the terrain case of the tutorial files.

[Falahaty]

Dear Regis_

Thanks a lot for your nice comments.

I have set the bash_profile (environmentScripts) for SOWFA-6 and have run the Allwmake successfully. I just commented out the parts related to OpenFAST in Allwmake at this stage.

But when I am going to run the test case, I'm having couples problems.

Like first in tut.ABLflatTerrain.run, in preprocessing stage (1_preprocess), there are some commands which are specific for HPC systems and since I am not using HPC currently, I am not sure whether they'll cause trouble or not.

Second (and most important), in general I have problem with setting the precursorDir in 1_preprocess.

Especially about the second point, I will appreciate, if you can guide me.

Thank you.

Best Regards,

Falahaty

[Regis_]

Hi Hosein,

1. Yes, you can/should comment out or delete the lines related to the scheduler (SLURM lines in the case you are referring to)

2. Well, you have to have a precursor to run a complex terrain case-- at least the way we have it setup right now. If you don't understand why a precursor is needed, you have to take a step back in understanding the whole workflow in running a wind plant simulation. The first step usually consists of generating the turbulence that will be used in a wind plant case (or complex terrain). You see, when you have a terrain or turbines (or both), it doesn't make sense for you to have a periodic/cyclic type of boundaries conditions. At the same time, you want to keep your domain as small as you can in order to keep computational costs down. So, think about it-- what boundary conditions are you going to use? What type of inflow are you going to feed into a simulation where you have some wind turbines? Does it make sense for you to feed in a a uniform flow speed at the boundaries? The answer is no.

In that case, we first run what is usually referred to as a "precursor". The goal here is to develop/resolve the background turbulence for you to feed into another case where your interest is in. In the precursor stage, you have a cyclic domain and you usually run it for many thousand seconds until the flowfield is developed and the planar-averaged turbulence statistics converged. You will notice that SOWFA conveniently outputs planar averages for a flat-terrain case. For example, for a canonical neutral (no potential temperature variation below the inversion, and thus no significant buoyant effects), it is common to run a 3x3x1 km domain with 10 m uniform grid resolution for about 20,000s. After that, we run for another, say, 2,000s saving boundary data. The stage saving boundary data is extremely important because this is the data you will use as boundary condition to your terrain (or turbines, or both) simulation.

So there you have it-- you ran your precursor and you can use that data in the terrain simulation. You should try to read the entire script and understand what it is doing before just attempting to run it in its entirety.

Finally, you should read this paper. It's one of the original papers by the main SOWFA developer and it explains many conceptual steps of the simulation process. https://www.tandfonline.com/doi/abs/...48.2012.668191

Hope that helps.

[Falahaty]

Dear Regis_,

Thanks a lot for your nice explanations and the reference you introduced to me. They were very helpful to me. I have studied the paper and I think now I am almost familiar with the concept of precursor.

Since I am not using HPC, so I changed the scripts to simple desktop and I could run the tut.ABLflatTerrain.precursor.

But when I am going to run tut.ABLflatTerrain.run based on the precursors made in tut.ABLflatTerrain.precursor., I am having problems.

First renumbering of mesh is not done well. Second (and perhaps as a consequece), there are errors in executing the solver as attached.

I will extremely appreciate, if you can guide me in this regard, if you have any idea about how can I sort out this problem?

Thank you in advance.

Best regards,

Hosein

[Regis_]

A few things:

- renumberMesh is a standard OpenFOAM application, not a SOWFA-specific one. Use the search button on this forum to search of general issues you run into. The log shows a clear error that is easily google-able. In any case, that error is related to your boundaries having patch/cyclic information mismatch.

- Checking the vanilla solver log quickly it seems to me that a "WARNING"-type of file has been created by the first script. What is it related to? You can't try to brute force and run the whole script at once. You have to understand where it is failing so you can fix it yourself.

- As per the naming of the warning file I can see you are not using the latest scripts. I suggest you get the latest ones. As I mentioned earlier, SOWFA-6 repo is active and you should keep an eye there.

[Falahaty]

Dear Regis,

Thank you for your comments. Is it OK if I change movedynmesh to snappyhexamesh? I think it might solve my problem.

[Falahaty]

Dear Regis,


Thanks a lot for your kind comments and I am sorry that sometime I do not distinguish well between the OpenFOAM-related issues vs. SOWFA-related ones.



I have run the tut.ABLflatTerrain.precursor and I am going to use the results as precursor to a complex terrain with the same blockMesh domain in tut.ABLterrain.


I can run the 1_preprocess in tut.ABLterrain, but when I am going to run 2_solve, I'm facing an error regarding the momentumSource called by #include "givenSourceU" in constant/ABLProperties (I have attached the error log.file; log.2.superDeliciousVanilla).



Apparently the format of momentumSource term defined in post-processing folder of tut.ABLflatTerrain.precursor is not consistent with what is supposed to be called by #include "givenSourceU" in ABLProperties of tut.ABLterrain.



I tried to reference sourceHistory_to_drivingForce file and SourceTemperatureHistory file in postprocessing folder of tut.ABLflatTerrain.precursor in 1-preprocess of tut.ABLterrain, but the format seemed not to be compatible.



Furthermore, I tried to use the same method as you had described in "https://github.com/NREL/SOWFA/issues/26" to make the momentumSource manually, but still not successful.


Sorry but do you mind if I ask about any idea of your on how to sort out this issue and generate a momentumSource in tut.ABLflatTerrain.precursor readable to tut.ABLterrain?






Another point is that though moveDynamicMesh in 1_preprocess of tut.ABLterrain is being apparently executed well without error, when I check the mesh network in paraview I can not see the alteration in blockMesh domain due to crossing of the terrain. Sorry shouldn't I include reconstructPar in either 1_preprocess or 2_solve, before running, cause I can not see it in neither of the scripts of tut.ABLterrain?


Thanks a lot.


Best regards,


Hosein

[Regis_]

Hi Hosein,

1- Yes, you can replace moveDynamicMesh with snappyHexMesh, or really any other mesh-generation code you want to use. As long as the mesh is valid and the statistics are good, you are fine (check with checkMesh).

2- Regarding the sources, you are right. There is a step in between that is not very well documented. There is a script to get your sources terms from precursorCase/postProcessing/sourceHistory and put in a nice format that can be given to constant/ABLProperties.*sources. The script can be found here: https://github.com/NREL/windtools/bl...rce_history.py

Note that you may need to pull the whole repo so you have the functions that such python script is using. This repo also includes a few nice readers to get postProcessing data in pandas dataframe format, which can be really useful.

3- checkMesh will give you the bounding box and that will make it easy for you to check if your mesh conformed to the STL. moveDynamicMesh marches in time and will save intermediate steps along the way (if you so specify in controlDict). However, if you notice in the scripts there is a loop that gets that last time-step and puts it back as being your startTime (as defined in the scripts). If you run checkmesh in parallel, it should read that mesh and you should be fine. If you do blockMesh in serial it will read the mesh you have inside casedir/constant/polyMesh, which is the one generated serially by your initial call do blockMesh, and NOT the conformed post-moveDynamicMesh mesh. Does that make sense?

-Regis

[Falahaty]

Hi Regis,

I appreciate a lot for your nice comments.

I can run tut.ABLterrain with moveDynamicMesh. Also, the hierarchy of commands checkMesh and moveDynamicMesh all make sense and I run everything in parallel (but not on a HPC).

For example for checkMesh I do:

mpirun -np $cores checkMesh -latestTime -parallel > log.1.checkMesh.final 2>&1

But still I can not see the terrain in visual representation of the domain in paraview. (it seems unlikely, but I am afraid that there is some problem induced by not using HPC).

When I run snappyHexMesh, the terrain is shown visually, but I'll have problem with initilialiaing the solution.

Sorry but I have some further questions.

- When we use precuser analysis in advance of main wind plant simulation, if the wind plant itself is done on a complex terrain, then the precursor is supposed to be done on a complex terrain, right?

- Is it possible to use precursor as a meso-scale analysis and then couple the meso-scale CFD analysis with a micro-scale wind plant simulation? Then is there anyway to circumvent the problem of inequity of sizes of cells in the domain when initializaing the simulation?

Thanks a lot.

Best regards.

[Regis_]

Are you marching in time and saving intermediate time steps during the execution of moveDynamicMesh? If yes, you should be able to see the terrain moving. Look at the log of moveDyanmicMesh-- is your overall volume changing? Remember that you should have a dictionary for moveDynamicMesh inside constant/, and if you don't, it will just not work as you expect it to.

As far as the precursor goes, you have to think about what it means to run with cyclic/period boundary conditions. You are doing an infinite domain because you want the turbulence to develop out of the friction with the bottom wall (your stress boundary condition for atmospheric flows, usually Schumman). That takes a long extent, both in space and time, so that a periodic BC is the most suitable option. Now, if you have a terrain that repeats itself over and over, that is not a realistic scenario anymore, is it? The apparent simple idea of having developed flow over terrain is not as simple as you'd think at first, as you can see. Some methods exist in which you perturb the potential temperature right at the edge of your domain and that triggers the turbulence needed and you don't need precursors. Or, you can use the two-step approach of using a precursor.

The idea of running a precursor for a finite-domain terrain-containing simulation is that you will feed in that data as boundary conditions. To avoid numerical issues, your boundary would match the precursor boundary condition and your terrain would smoothly turn into the actual terrain you want. So you essentially have a "fringe" region around the boundaries where you go from flat terrain (matching precursor boundary dimensions) to a region with different elevations within your domain.

You touched on a very active research area, which is coupling between mesoscale and microscale. The "problem of inequity of cells" that you mention is sometimes referred to as "gray zone" or "terra incognita". In simple terms, it is where your grid spacing is inappropriate for mesoscale models to work properly and also too large for full microscale CFD to get anything meaningful. Search for terra incognita and you will find several articles about it. As far as the coupling goes, there are a few different ways to do it and you will quickly find some of those during your literature survey on this topic. One way is to use mesoscale data to drive the precursor, and then use that precursor on a terrain. The source terms that you set in ABLProperties can be used to that. A common mesoscale solver is the Weather Research and Forecasting (WRF) model.

[Agavi]

Hi Regis,

I'm running the exact same solvers, but for a 1x1x1 km domain with a 10m cell size and adjustable time step and hoping to get some ABL representation. Although the mean values seem to be correct in the precursor simulation (mean profile respects the log law) and the probed time series seem to have stabilized around a mean value, my residuals look weird. I'm attaching a screenshot of my residual plot. Do you know how the residuals are meant to drop in the SOWFA software and generally, how they should look like in LES (ie how many orders of magntitude they should drop etc).

Thank you!

residuals.png

[Regis_]

There are several settings that you can check. Some of them are your time step and maximum CFL number, number of PISO loops (inner and outer), tolerance and relative tolerance for each variable inside system/fvSolutions. Your residuals should drop further than that after you make sure these settings are appropriate.
Good luck!