Guidelines for turbine simulation

[nish-ant]

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:

1. 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 ?

2. 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#L113

Apart 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.

[nish-ant]

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.

[rthedin]

1. 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.

2. 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.

[nish-ant]

1. Thanks for confirming this. I will try to set up a turbine simulation in a similar way as for SOWFA-2.4.0.
2. The source file generation works using the python script.

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.

[rthedin]

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.

[nish-ant]

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.

[nish-ant]

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.

[rthedin]

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.

[nish-ant]

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.

[rthedin]

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

[nish-ant]

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.

[rthedin]

Okay, a few things worth double-checking:

1. 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
2. What is your OPENFAST_DIR? You mentioned two distinct locations in your prior few messages. Check that.
3. Why it can't find this file? I would check paths and spack details. You did SOWFA via spack and OpenFAST via cmake, so maybe there is some path inconsistencies going on there
4. Do you have the proper packages loaded, maybe through module load? You seem to be missing a few packages.
5. When running make and piping the output to a file, make sure to also pipe the standard error. Use 2>&1 instead.

[nish-ant]

Thanks @rthedin for the inputs.

1. 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.

2. 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_DIRpoints to this new installation.

3. Why it can't find this file? I would check paths and spack details. You did SOWFA via spack and OpenFAST via cmake, 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.

4. 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.

5. When running make and piping the output to a file, make sure to also pipe the standard error. Use 2>&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.

[Didi-X]

1. 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.
2. 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.

1. 1_preprocess runs normally, 2_solve runs: Case not reconstructed and first time of boundaryData not fixed. Check if endTime dir exists. ls: cannot access 'postProcessing/boundaryData/north': No such file or directory ls: cannot access 'postProcessing/boundaryData/south': No such file or directory ls: cannot access 'postProcessing/boundaryData/east': No such file or directory ls: cannot access 'postProcessing/boundaryData/west': No such file or directory
2. I checked my log. 2. decomposePar. There seems to be no problem.The log. 2. decomposePar file displays as follows:

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.

[rthedin]

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.

[nish-ant]

@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

[Didi-X]

@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.

[Didi-X]

@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.

[Didi-X]

@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

[rthedin]

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.

[Didi-X]

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.

[rthedin]

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.

[Didi-X]

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.

[Didi-X]

@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.

[rthedin]

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.

[Didi-X]

Yes, I've been looking at the references in detail and adjusting the examples.

[Didi-X]

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 the 0 (or 0.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 in 2.4.0, but superDeliciousVanilla thought I wanted to run windplantsolver, 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 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.

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.

0.zip

FASTV8_0.zip

[rthedin]

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.

[Kumoi-S]

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!

[Kumoi-S]

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!