CMake for MAP++, TurbSim & FAST

Wind & Water Computer-Aided Engineering Software Tools
1

hello everyone! :slight_smile:
i assembled CMake build files for MAP++, TurbSim & FAST.
I did this, to be able to conveniently compile them under linux, as the makefiles required at least manual editing for 32/64 bit build choosing, but were also in some cases outdated and in the end not as user friendly as with cmake.

In case someone does not know CMake:
it is a meta build system, meaning, it is a file (or a set of files) describing the project (name, source files, required libraries, …), which then allows to generate the actual build system, which could be a Makefile, a visual studio project file or many other alternatives.
The benefits of using cmake are, to have a single, dense “database” for the projects meta info, which can then be used on any platform, architecture, compiler, build system or IDE. it is also usually more clean and shorter then the things it generates.

I would like to submit patches, preferably to git repositories of the latest development branch. i found the git repo for MAP++, but could not find any SCMs for TurbSim and FAST. do they exist? are they public? and if not, why not, and could they be initiated?

The MAP++ CMake patch(es) can be found and tested here (on the cmakeIntro branch):
bitbucket.org/hoijui/map-plus-plus

PS: this is my first post here. i am mainly a software developer for a group of researchers that wants to run these tools on a linux cluster, and currently uses wine to run the windows builds for that.

2

i was asked to backport my cmake patches to an older version of FAST, but i do not even know where to get the sources for that one…

is there an SCM (git?) of FAST, available to the public?

3

As I mentioned in another post, we plan to move our SVN repositories to gitHub later this year. Meanwhile… which version of FAST are you looking for?

4

thank you …
it is FAST (v8.10.00a-bjj, 31-Mar-2015).
i have the sources now (they had them somewhere on the cluster), but i get these compile errors now:

	[  1%] Building Fortran object CMakeFiles/FAST.dir/Source/FAST_Library.f90.o
	/home/user/Projects/Wind/repos/FAST_asOnCluster/Source/FAST_Library.f90:209.9:

		 ErrMsg_c = TRANSFER( C_NULL_CHAR, ErrMsg_c )
		 1
	Error: Different shape for array assignment at (1) on dimension 1 (1025 and 1)
	/home/user/Projects/Wind/repos/FAST_asOnCluster/Source/FAST_Library.f90:212.9:

		 ErrMsg_c  = TRANSFER( "Simulation completed."//C_NULL_CHAR, ErrMsg_c )
		 1
	Error: Different shape for array assignment at (1) on dimension 1 (1025 and 22)
	/home/user/Projects/Wind/repos/FAST_asOnCluster/Source/FAST_Library.f90:217.6:

	      ErrMsg_c  = TRANSFER( "FAST_Update:size of OutputAry is invalid or FAST h
	      1
	Error: Different shape for array assignment at (1) on dimension 1 (1025 and 71)
	/home/user/Projects/Wind/repos/FAST_asOnCluster/Source/FAST_Library.f90:221.6:

	      ErrMsg_c  = TRANSFER( "FAST_Update:size of InputAry is invalid."//C_NULL_
	      1
	Error: Different shape for array assignment at (1) on dimension 1 (1025 and 41)

regarding SVN → git(hub) move…
i did this for two projects in the past (a small and a big one), and i can recommend a lot to create a (bash)-script for the whole process (downloading the SVN repo, converting it, filtering out binary files as they should not be in a git repo, possibly splitting up the repo into sub-repos, …). so instead of doing things manually, you automate the whole process, really everything. this makes the whole thing much less tedious and stress-free, and you will be able to test easily before doing the actually move, also with different people and versions of the repo, plus you have a documentation for how to do it for other projects and so on.
in case you did not start yet and want help, i could help there aswell. i would just need the SVN repo, and i could produce a script which you can check out and adjust in the end.

5

i had to change :

TRANSFER( C_NULL_CHAR, ErrMsg_c )

to

TRANSFER( C_NULL_CHAR, ErrMsg_c, 1025 )

it compiles now!
will post patches (as git repos) soon.

6

Thanks for the offer of help. If you want to send me an example script, I can take a look at it. I’ve actually converted several repos already with the svn2git tool, which seems to work fairly well. I don’t think I’ll be able to get you access to our SVN repos–last time it took SIX months to get someone to allow a new external user. Some of the repos have branches that shouldn’t be converted for privacy/licensing reasons, so I think it will mostly take a little time to make sure everything–including the history of deleted branches–is okay. Due to the nature of our funding, I need to get FAST linearization complete before tackling this project; and then I probably still need to convince task leadership that converting the history is beneficial.

The problem with the arguments to the TRANSFER() routine in FAST_Library.f90 was fixed (using a slightly different method) in v8.12. I just noticed the same issue in the DISCON*.f90 files for the controller, and I’ll make sure those get fixed as well.

7

cool… thanks bonnie!
… aaand bummer! :smiley:
well, i am sure these limitations are even more annoying to you then to us…
but that does mean that in the end, if you get it into git, and cleaned up, that git repo can be public, right?

i now have an other problem:
when running my self-compiled native FAST:

FAST CertTest/SimpleTestV8/SimpleTest.fst

 **************************************************************************************************
 FAST (v8.10.00a-bjj, 31-Mar-2015)

 Copyright (C) 2015 National Renewable Energy Laboratory

 This program comes with ABSOLUTELY NO WARRANTY. See the "license.txt" file distributed with this
 software for details.
 **************************************************************************************************

  Running FAST (v8.10.00a-bjj, 31-Mar-2015), compiled as a 64-bit application using single
  precision
  linked with NWTC Subroutine Library (v2.05.02a-bjj, 25-Feb-2015)

  Heading of the FAST input file:
     TITLE

  Running ElastoDyn (v1.02.00a-bjj, 31-Mar-2015).

 FAST_InitializeAll:FAST_Init:FAST_ReadPrimaryFile:OutFmt produces a column width of 14 instead of
 10 characters.
 FAST_InitializeAll:ED_Init:ED_ReadInput:ReadBladeInputs:ReadBladeMeshFile:The input file,
 "CertTest/SimpleTestV8/..\5MW_Baseline\NRELOffshrBsline5MW_Onshore_AeroDyn.dat", was not found.

 FAST encountered an error during module initialization.
  Simulation error level: FATAL ERROR

  Aborting FAST.

while the win64 executable runs fine with the same input through wine on the same machine.
will try to figure it out myself…

8

Yes, the gitHub repos will be public when we get them there.

The first thing I’d take a look at is the direction of your file separators for the “AeroFile” listed in your primary FAST input file. I try to always specify them so they work on Linux because Windows doesn’t care which direction they are specified, but Linux does. Then it’s easy to use the same input files on different systems.

9

ahhh good! :slight_smile:

… and you were right about the win/linux path separators! :slight_smile:
it now gets a bit further. do you have an idea what could cause this?

the “14 instead of 10” thing is just a warning, that happens under wine too. the problem is the:

FAST_InitializeAll:SrvD_Init:BladedInterface_Init: LoadDynamicLib: Not implemented for GNU Fortran for Linux
… i will also look for a solution for that.

whole output:

[code]$ FAST CertTest/SimpleTestV8/SimpleTest.fst

FAST (v8.10.00a-bjj, 31-Mar-2015)

Copyright (C) 2015 National Renewable Energy Laboratory

This program comes with ABSOLUTELY NO WARRANTY. See the “license.txt” file distributed with this
software for details.

Running FAST (v8.10.00a-bjj, 31-Mar-2015), compiled as a 64-bit application using single
precision
linked with NWTC Subroutine Library (v2.05.02a-bjj, 25-Feb-2015)

Heading of the FAST input file:
TITLE

Running ElastoDyn (v1.02.00a-bjj, 31-Mar-2015).

Running ServoDyn (v1.02.00a-bjj, 31-Mar-2015).

Running ServoDyn Interface for Bladed Controllers (using GNU Fortran for Linux, 1-May-2013).

FAST_InitializeAll:FAST_Init:FAST_ReadPrimaryFile:OutFmt produces a column width of 14 instead of
10 characters.
FAST_InitializeAll:ED_Init:ED_ValidateInput:OutFmt produces a column width of 14 instead of 10
characters.
FAST_InitializeAll:SrvD_Init:BladedInterface_Init: LoadDynamicLib: Not implemented for GNU
Fortran for Linux

FAST encountered an error during module initialization.
Simulation error level: FATAL ERROR

Aborting FAST.
[/code]

10

That error comes because you have not compiled with the “-DUSE_DLL_INTERFACE” preprocessor flag, but you are trying to call a BLADED dynamic library for control algorithms.

When you compile FAST on Linux/Mac OS, you’ll need to compile with -DUSE_DLL_INTERFACE and link with the dl (dynamic load) library -ldl. Then, you’ll have to make sure you’ve actually compiled dynamic libraries (.so files) for the controller you are trying to use. For the FAST CertTest cases, you want to use (or at least take a look at) makefile_DISCON_DLL, which is in the compiling directory The source files for the DISCON libraries are in the CertTest/5MW_Baseline/ServoData/Source directory. You’ll need to specify the name of the library file in the ServoDyn input file (the input is called DLL_FileName).

The warning about the 14 vs. 10 characters is a concern only if you are using some of the NREL post-processing tools that are hard-coded to 10-character column widths. Some of the older codes (like Crunch) read files in an interesting way…

11

ahhh thank you bonnie!
would it be ok to change the error message then, from “not implemented” to “not compiled with -DUSE_DLL_INTERFACE”, in this case?

i will include USE_DLL_INTERFACE as a cmake variable aswell. ar ethere any other such defines that a user (who is compiling FAST) might want to set?

12

Sure, we can change that message. It was originally put there because the first person to test my Linux implementation complained that it didn’t compile, and so I just removed my code with the preprocessor directives.

The other possible definitions should be listed in the makefile distributed with FAST. If you’re using BeamDyn, DOUBLE_PRECISION (along with -fdefault-real-8) is one you would want to use. There are some more for debugging that aren’t listed in the makefile, but I’m not sure how many people would want them…