BModes beam discretisation (for a tower)

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,

I have a few questions about the input and usage of BModes (used for a tower):

First question:
what is the relationship between the two following inputs?

el_loc(i) - found in the main input file

sec_loc - found in the section properties file

Both are adimensional, running from 0 (bottom) to 1 (top). What is the “right” usage of them? In the supplied input sample, they are similar but not identical:

el_loc:

0.  0.08  0.16  0.24  0.32  0.40  0.48  0.56  0.64  0.72  0.80  0.90   1.0

sec_loc:

0 0.1111 0.2222 .... 0.888 1 (equal steps, 0.1111)

The tower I am modelling is slightly conical, I have identified about 15 significative sections, including flanges, irregularly distributed along Z. Should I try to follow with el_loc the same distribution? By the way, is it correct to try to simulate the flanges with short, thick segments of tower? I used to do this with standard FEM codes (e.g. ANSYS) in order to correctly account for the concentrated mass and the locally increased stiffness.

Second question:
the tower ends at a given height Ztop above the ground. The center of mass of the nacelle+rotor is at Zcg, higher than Ztop. In the figure 6 pag. 18 of the user manual, it seems that the tower must end at Zcg. Is this correct? if yes, I plan to insert a dummy tower segment, very stiff and very light, to “reach” the right Zcg. Is this a good idea?

Third question:
I have tried to recompile the code, in order to use a different number of segments than 12. I am using a freeware Fortran compiler called G95 ([url]http://g95.sourceforge.net/[/url]). I get a compilation error when the first USE statement is found (line 365: USE Struc). The compiler is looking for a file called “Struc.mod”. Maybe I am doing something wrong…

as usual, thanks a lot for your advice
Best regards
Claudio

2

Sec_loc (section locations) help you to specify sections at which beam properties are available. A user would typically obtain these properties from drawings or from measurements.

El_loc (location of elements) helps you divide the beam into elements of your choice. El-Loc allows you to specify beam element boundaries, which can be different from locations at which you specify blade properties via the properties file. BModes interploates blades properties (specified in the properties file) and assigns these to the Gaussain points in each element.

As for the discretization of your tower into beam elements, your strategy is ideal – this is the way it should be. Ensure that the el_loc boundaries coincide with points at which tower properties jump. You may further subdivide longer elements into smaller elements (by introducing more el_loc points) until modal results converge.

You are right. Currently, BModes does not have provision for vertical offset of the tower-top c.m. from the tower top. Your plan to insert a dummy tower segment, very stiff and very light, to “reach” the right Zcg, is indeed the way to go. Here at NWTC, we have used this very approach in the past.

Sometime in the future, I plan to introduce a rigid massless element, which would allow a user to specify the vertical offset and avoid introducing an extraneous stiff element.

I talked to my friend Marshall Buhl and he recommnds compiling the modules file (modules.f90) first and then compile the other files. If this does not work, please let us know.

Thanks for sharing your concerns. Keep us updated.

Regards,
Gunjit

3

Gunjit,
thanks a lot for your answers. Concerning the compilation, I have still a few problems. I have uploaded (temporarily) a snapshot of the error message that I get when I try to compile “modules.f90”.

terom.it/upload/Compile_BMODES.jpg

Anyway, already a few days ago I had to produce a result, and accepted the 12 elements. I am for the moment satisfied with this discretisation, and I will not try again, in the immediate future.

Nevertheless, I do believe that for the “casual” user :slight_smile: like myself (well, not really so casual, but let’s say not having a commercial fortran compiler available), the necessity to recompile the code to change the discretisation is a little problem.

If in the future, as written in the user’s guide, you succeed in making this an input, even with a limited range (say between 10 and 30), it will be easier for everybody.

As usual, thanks a lot and keep up the good work!
Claudio

4

Claudio,

Compilers don’t work that way. You either have to compile all routines together with a single compilation, or you have to use the -c option to compile them separately.

The compiler’s complaint is an indication of that. It’s saying it couldn’t find a main program. That’s because you were compiling a file of modules or subroutines. You can either specify all the files in a single g95 statement or merge them all into a single file, which will allow for better optimization and faster code.

Regardless of which of the three techinques you choose, you will have to compile the routines in the correct order. I don’t happen to know what order that is. If you get an error saying a routine cannot find a needed module, then you need to find out which file contains that module and compile it before the invoking routine.

Here are the three techinques to use:

  1. Compile separately with separate commands:

g95 -c -O -o file1.obj file1.f90
g95 -c -O -o file2.obj file2.f90
g95 -c -O -o file3.obj file3.f90
g95 -o Bmodes.exe file1.obj file2.obj file3.obj

I don’t know the g95 compiler so I am unsure of the exact syntax, but it will be something like that above. The -O is to optimize. The last g95 statement is to link all the object files together into a single executable.

  1. Compile separately with a single command:

g95 -O -o BModes.exe file1.f90 file2.f90 file3.f90

This compiles and links all the files in a single statement. Using this or the previous technique does not allow for inter-file optimizations.

  1. Merge all source files into a single file and compile that:

copy file1.f90+file2.f90+file3.f90 BModesAll.f90
g95 -O -o BModes.exe BModesAll.f90

This method will produce the fastest code.

Marshall

5

Marshall,
thanks a lot for the time you took to teach me! I hope this will be useful also for other users of the program. Many years ago I did work with fortran, but that was on mainframes, in the 80s, and now, how should I say… :slight_smile: things have changed!
As soon as I will have time again, I will try the way you suggest.
Best regards from Italy
Ciao
Claudio

6

I am trying to compile BModes using ifort. I think this compiler is the DOS command prompt version of the Intel Visual FORTRAN compiler. NREL has used this compiler.

Do you have a DOS batch file for BModes like the one supplied for FAST? Many thanks.

I appreciate that the order of the source code .F90 files is important. It’s necessary to compile all the modules, subroutines and functions which are referenced in a routine before the routine itself. It would be possible to list all the CALL and USE statements in the collection of .F90 files and then to work out the order in which .F90 files ought to be compiled. Quite a lengthy task though if you haven’t written the program yourself.

Kind Regards,

Mark Spring (Lloyd’s Register)

7

Mark,

I do not know the compilation order for BModes and don’t have a batch file. However, if you append all the files together, I think you will eliminate that problem and may actually make the code run faster.

One serious issue is that BModes uses a proprietary eigensolver which we do not have the rights to and cannot distribute. I have no idea where our copy is.

Is it really necessary to recompile BModes?

Marshall