Open nish-ant opened 1 year ago
For point 2, I found the script to perform the conversion in the windtools
repository: sowfa_convert_source_history.py. I am testing it currently.
There are no significant changes from SOWFA 2.4 to 6 regarding the inclusion of turbines. The .turbine
version of the solver here is equivalent to the turbine-specific solver from version 2.4. Unfortunately we do not have a proper guidelines written for a wind farm simulation. There are some relatively old example cases within the repository with turbine models that you might find useful.
That's right, you run that script and it will use the precursor to create the source files that you will then give to the turbine simulation. The details of the source and linking boundary information for a turbine simulation is analogous to the tutorial case you pointed to.
Note that I will push in the coming weeks a simple example containing turbine.
I am seeing a warning message during the boundary data generation step of precursor simulation:
--> FOAM Warning :
From function bool Foam::rmDir(const Foam::fileName&)
in file POSIX.C at line 1051
cannot open directory "/scratch/nkumar001/OpenFOAM/nkumar001-6/SOWFA6/exampleCases/tut.ABLflatTerrain.precursor/postProcessing/boundaryData/25000"
This seems to appear from the surface writer script: https://github.com/NREL/SOWFA-6/blob/ad09c1511724681fe29a965b0111fdec62a8a636/src/fileFormats/sampledSurfaceWriters/boundaryData/boundaryDataSurfaceWriter.C#L143 If I understood it correctly, the error can be resolved by changing the line to:
rmDir(baseDir/timeName);
This is because the time directories are stored in directories associated with individual boundary patches:
$ ls ./tut.ABLflatTerrain.precursor/postProcessing/boundaryData/
. .. east north south west
As a result of this warning, I don't see any planar averaging data saved during the course of the simulation. If needed I can run some tests and open a new ticket.
You're right about the warning. However, the warning does not prevent the boundary data from being saved. I've been ignoring the warning because I know it tries to delete directories that do not exist. Give it a shot without replacing that line with your suggestion and see if it works---it should.
As you mentioned planar averaging, I believe you might be mixing up boundary data with planar average data. Boundary data saves U
, T
, and k
from the periodic precursor simulation:
https://github.com/NREL/SOWFA-6/blob/ad09c1511724681fe29a965b0111fdec62a8a636/exampleCases/tut.ABLflatTerrain.precursor/system/sampling/boundaryData#L10-L15
You obviously need the enabled
flag to be true
for proper saving to occur.
Planar averaging, on the other hand, is handled by
https://github.com/NREL/SOWFA-6/blob/ad09c1511724681fe29a965b0111fdec62a8a636/exampleCases/tut.ABLflatTerrain.precursor/setUp.neutral#L66-L67
and the planarAveraging
function object that exist inside system/sampling
.
Let me know if you manage to properly save the boundary data.
Hello @rthedin. Sorry for the late response. I am able to obtain the boundary data with the original boundaryDataSurfaceWriter
.
Going back to the turbine simulation, I have not been able to execute one successfully. Firstly, the solver superDeliciousVanilla.turbine
was not built as it was commented out in Allwmake
:
https://github.com/NREL/SOWFA-6/blob/ad09c1511724681fe29a965b0111fdec62a8a636/Allwmake#L74
Then I came across this reply: https://github.com/NREL/SOWFA-6/issues/49#issuecomment-1334458316
Henceforth, I switched to the latest
branch of mchurchf/SOWFA-6
which is ahead of the dev
branch of NREL/SOWFA-6
.
From exploring this repository, I see that the plan is to indeed unify the ABL and ADM/ALM solvers within superDeliciousVanilla
as the line #include "horizontalAxisWindTurbinesALMOpenFAST.H"
has been moved inside applications/solvers/superDeliciousVanilla/superDeliciousVanilla.C
.
Here I must point put that I was unable to build OpenFAST successfully but as I was not interested in structural dynamics, I ignored this error, as also mentioned in https://github.com/NREL/SOWFA-6/issues/11#issuecomment-792896421.
As noted in https://github.com/NREL/SOWFA-6/issues/47#issuecomment-1220051389, this was not an issue for running the ABL solver.
But since the turbine solver has been moved in mchurchf/SOWFA-6
, I am not even able to build superDeliciousVanilla
as now it requires OpenFAST and it throws following error:
In file included from horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.C:36:0:
horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.H:69:22: fatal error: OpenFAST.H: No such file or directory
#include "OpenFAST.H"
^
compilation terminated.
I also tried to use the standard turbine models:
$ wmake src/turbineModels/turbineModelsStandard
but getting an error:
/bin/ld: cannot find -lincompressibleTurbulenceModel
collect2: error: ld returned 1 exit status
I hope this is not very confusing.
I would like to know if there is a way to build either superDeliciousVanilla.turbine
or the unified superDeliciousVanilla
solver without requiring OpenFAST. Perhaps it is just as simple as commenting out some lines and referring to the standard turbine models instead.
UPDATE: I managed to install OpenFAST [1]. I can test that it has been installed correctly by checking the following output:
$ openfast -v
**************************************************************************************************
OpenFAST
Copyright (C) 2022 National Renewable Energy Laboratory
Copyright (C) 2022 Envision Energy USA LTD
This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
See the "LICENSE" file distributed with this software for details.
**************************************************************************************************
OpenFAST-v3.0.0
Compile Info:
- Compiler: GCC version 7.3.0
- Architecture: 64 bit
- Precision: double
- OpenMP: No
- Date: Dec 16 2022
- Time: 16:48:50
Execution Info:
- Date: 12/19/2022
- Time: 10:39:09+0100
OpenFAST terminated normally.
In the next step, before building SOWFA-6, I assign the OPENFAST_DIR
environment variable as follows:
$ export OPENFAST_DIR=/gpfs/home/nkumar001/tools/spack/opt/spack/linux-centos7-skylake_avx512/gcc-7.3.0/openfast-3.0.0-nlhyy3yjisdkoudmuzctea5e7czgsvbi
$ ls $OPENFAST_DIR
. .. bin include lib .spack
Next, running ./Allwmake
fails at the step wmake src/turbineModels/turbineModelsOpenFAST
with the following error:
In file included from horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.C:36:0:
horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.H:69:10: fatal error: OpenFAST.H: No such file or directory
#include "OpenFAST.H"
^~~~~~~~~~~~
compilation terminated.
make: *** [Make/linux64GccDPInt32-spack/horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.o] Error 1
I'm attaching the full log file for reference: Allwmake.log
In the GitHub repository, I notice that OpenFAST.H
is located in ~/glue-codes/openfast-cpp/src
. But I'm not able to find it in the OpenFAST install path. Is there some way to make it discoverable to the SOWFA compiler?
[1] Just for information, OpenFAST has been installed as a package in a spack
environment. The same environment contains other packages like OpenFOAM-6, Open MPI, etc. This is one of the ways to ensure homogeneity of dependencies.
Sorry for late response.
You seem to be doing it correctly. I'm not very familiar with spack, so I'm not sure if that is the source of your problems. Make sure OpenFAST is visible within the environment you are calling Allwmake
from. Check the options
file inside SOWFA-6/src/turbineModels/turbineModelsOpenFAST/Make
and make sure the openfast stuff is there and libs and directory exists.
If that still doesn't work, I would suggest trying to get both OpenFAST and SOWFA compiled using cmake and skip the spack step. Get OpenFAST at least version 3.1. If that works, then you would be able to debug your spack installation. Hope that helps.
Hello @rthedin. As you mentioned, I built OpenFAST v3.3.0 from source. I verified the installation and there were no errors. Next I declared the following environments variables:
export OPENFAST_DIR=~/tools/OpenFAST/install
... and ensured that the paths referred in /src/turbineModels/turbineModelsOpenFAST/Make/options
exist.
Then, I pulled the latest
branch from mchurchf/SOWFA-6
and executed Allwmake
.
This time it is able to discover OpenFAST.H
as I don't see the error I mentioned in the previous comment.
But now I am seeing a different error:
horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.C: In member function ‘void Foam::turbineModels::horizontalAxisWindTurbinesALMOpenFAST::sendInput()’:
horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.C:482:31: error: ‘__gnu_cxx::__alloc_traits<std::allocator<fast::globTurbineDataType> >::value_type {aka struct fast::globTurbineDataType}’ has no member named ‘forcePtsBladeDistributionType’
fi.globTurbineData[iTurb].forcePtsBladeDistributionType = bladePointDistType[iTurb];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... and the build exits with following message:
/usr/bin/ld: cannot find -lSOWFATurbineModelsOpenFAST
collect2: error: ld returned 1 exit status
make: *** [/gpfs/home/nkumar001/OpenFOAM/nkumar001-6/SOWFA6/platforms/linux64GccDPInt32-spack/bin/superDeliciousVanilla] Error 1
The full log can be viewed here: log.Allwmake
There are several warnings for unused symbols but I think they can be ignored. I'm not sure what is causing this error but it will help if you can suggest any fix.
Ah- I apologize. Modifications to openfast have not been merged to the main repository. You should cherry-pick the following commits, which added the forcePtsBladeDistributionType
option:
https://github.com/mchurchf/openfast/commit/a0d4f7e76d936f36f2eeb782af63dc60ad4c4f1f
https://github.com/mchurchf/openfast/commit/ea33943d2476c619f8564b5bd169e6f2d2e83516
https://github.com/mchurchf/openfast/commit/4ed7952afce1720d1ccd00e2d19db8f4a8b2847e
https://github.com/mchurchf/openfast/commit/9c7ee2e066363f9d1dea7904b857823afd664b5e
Hi @rthedin. I retried with https://github.com/mchurchf/openfast/commit/a0d4f7e76d936f36f2eeb782af63dc60ad4c4f1f but still getting an error while building SOWFA6.
I will like to point out that I'm currently following the advice in https://github.com/OpenFAST/openfast/issues/60#issuecomment-338397668 and using the build script so that the OpenFAST routines can be accessed by SOWFA via the C++ interface. The make and install stages finish without error, as can be seen from the log files log.make
and log.make.install
.
The SOWFA6 installation fails with several undefined reference
messages, see log.Allwmake
. This error is different from the previous build. It will help if you can take a look and suggest a fix.
Okay, a few things worth double-checking:
OPENFAST_DIR
? You mentioned two distinct locations in your prior few messages. Check that.module load
? You seem to be missing a few packages.make
and piping the output to a file, make sure to also pipe the standard error. Use 2>&1
instead.Thanks @rthedin for the inputs.
- Make sure you are using the same compilers for OpenFAST, SOWFA, and ROSCO (if you are planning on using it). Ideally, do all the compilation within the same environment
So far, I've been performing the compilation of OpenFAST and SOWFA in the same environment. I'll make it a point to confirm it next time.
- What is your
OPENFAST_DIR
? You mentioned two distinct locations in your prior few messages. Check that.
Previously OPENFAST_DIR
was pointing to the spack installation but I later built it as a stand-alone installation from source. Now the variable OPENFAST_DIR
points to this new installation.
- Why it can't find this file? I would check paths and spack details. You did SOWFA via
spack
and OpenFAST viacmake
, so maybe there is some path inconsistencies going on there
Slight correction: I built SOWFA using Allwmake
and not spack
. But yes, it is strange that it couldn't find the file, even though the path is valid. I will check.
- Do you have the proper packages loaded, maybe through
module load
? You seem to be missing a few packages.
I didn't notice this before but it is another strange message because I load the modules and confirm the paths for the dependencies before building SOWFA. I will confirm this too.
- When running
make
and piping the output to a file, make sure to also pipe the standard error. Use2>&1
instead.
I've been using the suffix to pipe the standard error as well. But I will confirm.
So it seems that I need to check whether the dependencies can be discovered during the build or not. I will get back once I've some update.
- There are no significant changes from SOWFA 2.4 to 6 regarding the inclusion of turbines. The
.turbine
version of the solver here is equivalent to the turbine-specific solver from version 2.4. Unfortunately we do not have a proper guidelines written for a wind farm simulation. There are some relatively old example cases within the repository with turbine models that you might find useful.- That's right, you run that script and it will use the precursor to create the source files that you will then give to the turbine simulation. The details of the source and linking boundary information for a turbine simulation is analogous to the tutorial case you pointed to.
Note that I will push in the coming weeks a simple example containing turbine.
Hello, I have encountered some problems with the case running "tut.ABLflatTerrain.precursor", I checked my own compilation installation, it seems to be no problem.
Create time Removing 0 existing processor directories Decomposing mesh region0 Create mesh Calculating distribution of cells Selecting decompositionMethod scotch preservePatches : adding constraints to keep owner of faces in patches 4 ( north south east west ) on same processor. This only makes sense for cyclics.
Finished decomposition in 0.4 s Calculating original mesh data Distributing cells to processors Distributing faces to processors Distributing points to processors Constructing processor meshes
Processor 0 Number of cells = 160218 Number of faces shared with processor 1 = 6972 Number of processor patches = 1 Number of processor faces = 6972 Number of boundary faces = 19562
Processor 1 Number of cells = 159782 Number of faces shared with processor 0 = 6972 Number of processor patches = 1 Number of processor faces = 6972 Number of boundary faces = 13238
Number of processor faces = 6972 Max number of cells = 160218 (0.13625% above average 160000) Max number of processor patches = 1 (0% above average 1) Max number of faces between processors = 6972 (0% above average 6972) Wrote decomposition to "/home/didix/SOWFA-6/exampleCases/TEST_ABL/constant/cellDecomposition" for use in manual decomposition. Wrote decomposition as volScalarField to cellDist for use in postprocessing. Time = 0 Processor 0: field transfer Processor 1: field transfer End
In addition, is there any link related to "a simple example containing turbine"? If you can share it, thank you very much.
I unfortunately do not have a complete example with turbines. You will have to start from an inflow-outflow case and start adding the turbines from there. Note that the syntax has not changed, so it shouldn't be too complicated to get it working.
Regarding the error above, the boundary data has not been saved. That can be a consequence of an unsuccessful execution of the solver. Your decomposePar
log appears to be correct. Did the solver run? Did the boundary data in postProcessing/boundaryData/<patch>
get created? Are you even saving the boundary information from the precursor? Those should help you debug your issue.
@Didi-X As pointed out, you should check the logs of the executions before the precursor boundary data is starting to be saved, specifically log.2.setFieldsABL
and log.2.superDeliciousVanilla.startAt0
. That might point to errors that might be stopping the first boundary data from being saved.
NOTE: I am referencing the script 2_solve
from the tut.ABLflatTerrain.precursor
case that you mentioned.
Also I have created a repository with the wind turbine case in case you want to refer (might need several modifications): https://github.com/nish-ant/SOWFA.NREL5MWRef.ALMAdvanced.flatTerrain.neutral
@rthedin Thank you very much for your reply, my boundary data postProcessing/boundaryData / < patch > did not create success, I have done some query log files, found that is a question of Slurm. I'll try again after the change.
@nish-ant Thank you very much for your sharing, I have seen this sharing case, and I will try to run it as soon as I solve the problem.
@rthedin @nish-ant I want to confirm that the original sowfa2.4 pisoFoamTurbine. ALM, pisoFoamTurbine. ALMAdvancedOpenFAST whether to implant superDeliciousVanilla as well. If it is already implanted, which Settings should I change for the existing example, because it will show when I am not currently using the precursor data
[0] --> FOAM FATAL IO ERROR: [0] file "constant/boundaryData/west/points" does not exist
Apparently it thinks I'm running a simulation with precursor data. In addition, I was able to perform simulations with precursor data.
If you can, please let me know which file Settings need to be changed, I would appreciate it
superDeliciousVanilla
is the solver name for SOWFA-6. pisoFoamTurbine
, ABLSolver
, and so on are the solver names for SOWFA-2.4. The equations being solved are the same. This is the SOWFA-6 repository so my answer above applies to SOWFA-6. The boundary treatment of SOWFA-2.4 (based on OpenFOAM 2.4) is different and it requires additional processing. It is recommended that you use SOWFA-6 (based on OpenFOAM 6). If for some reason you'd rather using 2.4, some of the scripts to process boundary data are available on the SOWFA 2.4 repository, here.
Regarding the specific error, it says the points
file does not exist. The BCs are given in the 0
directory. That is where you probably have set to use boundary data hence why it is looking for it.
Yes, I am currently using SOWFA-6, and I would like to say that when I run a uniform wind simulation with SOWFA-6 (similar to pisoFoamTurbine.ALM
for SOWFA-240), solver is set to superDeliciousVanilla
, it says the following:
[0] --> FOAM FATAL IO ERROR: [0] Cannot open include file "/constant/../constant/sources" while reading dictionary "/constant/ABLProperties"
I think the error is that the solver superDeliciousVanilla
thinks I'm running an ALM simulation with a precursor, so it follows the simulation process with a precursor, but obviously I want to run a simulation without a precursor.
In SOWFA-240 version, I can simulate with or without precursors by using different solvers: pisoFoamTurbine.ALM and windPlantSolver.ALM
.
But there is only one superDeliciousVanilla in SOWFA-6, I don't know what setup I should use to implement a without precursor simulation.
As I mentioned, your BCs defined in the 0
directory is where you are telling your solver to look for boundary data. There is no implicit assumption whatsoever that you want to run an ALM. It is just reading inputs as you set them.
You can use superDeliciousVanilla
to simulate an inflow-outflow case without giving boundary data without the need to implement anything. Again, it is just a matter of setting up the correct boundary conditions. You need to specify the boundary conditions you are interested in inside the 0
(or 0.original
depending on where you're starting from), for each variable.
Regarding the error, it is saying right there what the issue is. It seems like you are requesting a file called sources
somewhere within the constant/ABLProperties
files and that file is not found. What are you setting there? What are you intending to set there? You have to set your source treatment accordingly to what you want to simulate.
Thank you very much for your answer, next I will try to adjust the Settings to achieve the simulation. As for the error, I think it is caused by inappropriate Settings, and after changing the boundary conditions, it may disappear.
@rthedin Currently, for the coupling case, the GenPwr
I calculated at 5MWBaseline
at rated wind speed is less than 3MW
(changing the mesh size
and Epsilon
doesn't change the results much), and it seems I've seen the same problem elsewhere. Have you encountered such a situation, or what problems such a situation might be caused by, and has the current branch used benchmark case testing? I am looking forward to your answers and guidance.
In addition, I would like to confirm whether the mesh size
and Epsilon size
do not lead to large gaps in GenPwr
. Although I know that these variables can make the results a little bit different.
Your grid resolution and your epsilon parameter play key roles in the accuracy of the actuator line model. I recommend you check some references by Martinez-Tossas et al for guidelines and how to properly set them. At some point, you may need to compromise in terms of grid resolution and epsilon.
Yes, I've been looking at the references in detail and adjusting the examples.
I'm sorry to come back to this question, but I really want to clarify this question.
As I mentioned, your BCs defined in the
0
directory is where you are telling your solver to look for boundary data. There is no implicit assumption whatsoever that you want to run an ALM. It is just reading inputs as you set them.You can use
superDeliciousVanilla
to simulate an inflow-outflow case without giving boundary data without the need to implement anything. Again, it is just a matter of setting up the correct boundary conditions. You need to specify the boundary conditions you are interested in inside the0
(or0.original
depending on where you're starting from), for each variable.I think it should be like this, I changed some boundary conditions, I wanted to do
pisofoam
like in2.4.0
, butsuperDeliciousVanilla
thought I wanted to runwindplantsolver
, so to accessABLProperties
, I needed precursor data, etc. This was obviously different from the simulation I wanted to implement myself, which led to a lot of errors.Regarding the error, it is saying right there what the issue is. It seems like you are requesting a file called
sources
somewhere within theconstant/ABLProperties
files and that file is not found. What are you setting there? What are you intending to set there? You have to set your source treatment accordingly to what you want to simulate.
I don't think even wind simulation requires the use of ABLproperties
, like pisofoam
in 2.4.0
The following are some 0
files I set and the 0
files of pisofoamFAST8
(I have set and used them, I can't), I want to know how I should change them.
pisoFoam
is a standard OpenFOAM solver. superDeliciousVanilla
is a SOWFA solver. The SOWFA solver is custom-designed for wind energy applications and its flexibility allows the user to give more inputs. The inputs within ABLProperties
are part of what has been implemented in SOWFA and thus it will obviously not be part of pisoFoam
. If you're using a certain solver, you need to give the inputs that the solver requires, which in the case of SOWFA, includes the ABLProperties
file. windPlantSolver
is a different solver, part of the original SOWFA (based on OpenFOAM 2.4.x) and is no longer part of SOWFA-6 (this repository, based on OpenFOAM 6). Same with pisoFoamFAST8
-- that is a solver that no longer applies to SOWFA-6. There is no implicit assumption that superDeliciousVanilla
"wants" to use windPlantSolver
. Also note that you do not need precursor data to run superDeliciousVanilla
-- in fact, you run it to generate your precursor.
Hope that helps.
Hi there, Apologies for the disturbance. It seems I've encountered a problem similar to @nish-ant 's. Following the discussions above, I compiled OpenFAST-6 and mchurchf/openfast@a0d4f7e. However, I encountered the following issue:
In file included from /foam/openfast/install/include/OpenFAST.H:20:0,
from horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.H:69,
from horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.C:36:
/foam/openfast/install/include/SC.h:14:10: fatal error: hdf5.h: No such file or directory
#include "hdf5.h"
^~~~~~~~
compilation terminated.
/foam/OpenFOAM-6/wmake/rules/General/transform:25: recipe for target 'Make/linux64GccDPInt32Opt/horizontalAxisWindTurbinesALMOpenFAST/horizontalAxisWindTurbinesALMOpenFAST.o' failed
I'm quite certain that I previously set up the relevant environment variables, following the example in SOWFA-6/environmentScripts/OF-6-env-gcc-central
. Then, I followed the instructions mentioned in https://github.com/pablo-benito/SOWFA-installation:
vim /foam/SOWFA-6/src/turbineModels/turbineModelsOpenFAST/Make/options
# Inside the EXE_INC variable
-I$(LIB_SRC)/transportModels \
$(PFLAGS) \
$(PINC) \
-I$(OPENFAST_DIR)/include \ # <-- Add this backslash
-I$(HDF5_DIR)/include # >-- and add this line
# Inside the LIB_LIBS variable
-lsctypeslib \
-lservodynlib \
-lsubdynlib \ # <-- Add this backslash
-L$(HDF5_DIR)/lib \ # and add the next three lines
-lhdf5 \
-lhdf5_hl
Then I recompiled using:
cd ${SOWFA_DIR} && ./Allwclean && ./Allwmake
This time, no fatal errors were reported (no red text), but I still encountered the error:
/usr/bin/ld: cannot find -lSOWFATurbineModelsOpenFAST
collect2: error: ld returned 1 exit status
/foam/OpenFOAM-6/wmake/makefiles/general:140: recipe for target '/foam/SOWFA-6/platforms/linux64GccDPInt32Opt/bin/superDeliciousVanilla' failed
make: *** [/foam/SOWFA-6/platforms/linux64GccDPInt32Opt/bin/superDeliciousVanilla] Error 1
I have no idea how to proceed with debugging. I'm building within a Docker container. Here are all the commands I executed from scratch and the errors log output: build.log output.log
Thanks in advance for any assistance!
Sorry, I didn't notice the error before in output.log:133 :
wmake src/turbineModels/turbineModelsOpenFAST
Make/linux64GccDPInt32Opt/options:65: *** missing separator. Stop.
Make/linux64GccDPInt32Opt/options:65: *** missing separator. Stop.
wmake error: file 'Make/linux64GccDPInt32Opt/sourceFiles' could not be created in /foam/SOWFA-6/src/turbineModels/turbineModelsOpenFAST
wmake src/meshTools
I believe I should upload this file, It shouldn't have any suffix, but to comply with the file uploading rules on GitHub, I added ".txt": options.txt
=================
I tried again from scratch and I Successfully build it. I guess I messed up with something before, maybe I forgot a backslash in the "options" file. Thank you for instructions in this issue!
Hello,
I am migrating from SOWFA-2.4.0 to SOWFA-6 and trying to understand how the wind turbine simulation is set up using the tutorial. So far I have been able to run the precursor simulation and generate the
boundaryData
.I then looked into the directory
tut.ABLflatTerrain.run
to initiate a wind turbine simulation. I have some questions regarding this:The instructions mention that the tutorial does not include turbine files. Coming from SOWFA-2.4.0, I have a general idea of how the wind plant information is provided as input. But I believe that there are significant changes in SOWFA-6, especially in terms of the solver
superDeliciousVanilla.turbine
Can you please provide the guidlines to perform a turbine simulation ?I also cannot find the source information in
$precursorDir/constant/
which is required for the run: https://github.com/NREL/SOWFA-6/blob/ad09c1511724681fe29a965b0111fdec62a8a636/exampleCases/tut.ABLflatTerrain.run/1_preprocess#L113Apart from this, if there is another tutorial case I should refer for learning about the wind turbine simualtion in SOWFA-6, please let me know. Thanks.