To MatLab, or not to MatLab

Provide feedback, request enhancements, and get help with wind-turbine computer-aided engineering tools.

Moderators: Bonnie.Jonkman, Jason.Jonkman

Marshall.Buhl
Posts: 437
Joined: Fri Oct 21, 2005 10:22 am
Organization: NREL/NWTC
Location: Boulder, CO
Location: Boulder, CO
Contact:

To MatLab, or not to MatLab

Postby Marshall.Buhl » Thu May 17, 2007 9:01 am

It seems that the kids coming out of engineering schools nowadays are pretty ignorant of Fortran, but fairly well versed in MatLab. We wrote most of our codes in Fortran with a few scripts in Perl. For programs that are CPU-bound and require raw speed (such as simulators), I think we'll stick with Fortran for now--it's the fastest language for such software.

For I/O-bound programs (such as postprocessors), it may make more sense to use MatLab--especially because it has such a complete set of analysis tools. I'm faced with making some significant changes to Crunch and was wondering if I should use MatLab instead.

What do you think?


Marshall
Mr. Marshall L. Buhl Jr.
NWTC-3811
National Renewable Energy Laboratory
Golden, CO 80401 USA
Marshall.Buhl@nrel.gov
Voice: +1 (303) 384-6914
Cell: +1 (303) 915-6623
Fax: +1 (303) 384-7079

Gunjit.Bir
Posts: 7
Joined: Thu Nov 10, 2005 4:18 pm
Location: Boulder, CO

Postby Gunjit.Bir » Thu May 17, 2007 10:03 am

I will strongly recommend MatLab. As you pointed out, it has a wide range of sophisticated analysis tools. Other advantages are:

1.Terse and intutive commands
2. Ideally suied for arrays
3. No need for explicitly allocating memory
4. Ease of understanding/ modifying scripts
5. Acess to built-in display (plotting) utilities

Disadvantage of course is slow speed compared to the speed offered by codes like Fortran. I am also not sure if it can efficiently handle very large arrays usually required for our post-processing needs.

If large memory handling is not a serious problem, I see no reason why we should not go for MatLab. Any feedback?
Gunjit Bir
NWTC-3811
National Renewable Energy Laboratory
1617 Cole Boulevard
Golden, CO 80401-3393
Voice: +1 (303) 384-6953
Fax: +1 (303) 384-6901
Email: gunjit_bir@nrel.gov
Web: http://wind.nrel.gov/

Pat.Moriarty
Posts: 40
Joined: Mon Nov 07, 2005 4:59 am
Location: NWTC/NREL

Matlab

Postby Pat.Moriarty » Thu May 17, 2007 11:08 am

In post-processing my data in Crunch, I've often come across memory issues so I'm not sure that writing it in Matlab will improve things.

Also, in order to get people to use our codes, having a DOS executable is preferable than requiring people to get a Matlab license (although there is that open source version). And, if we're running a bunch of simulations on our grid (i.e. Condor) we can be license limited.
Big whirls have little whirls, That feed on their velocity; And little whirls have lesser whirls, And so on to viscosity - Lewis Richardson.

duque

To MatLab, or not to MatLab

Postby duque » Thu May 17, 2007 11:09 am

Hey All,

Regarding the ignorance of compiled code, we academics have reacted to the different learning requirements of today's students. We found that students need quicker feedback. Also, from a teaching perspective, I'd much rather have the students work on understanding the physics and mathematics rather than how to compile a FORTRAN or heavens be a C code ;-) So, at NAU and at many other schools, undergraduates are taught how to program/script using MATLAB so that they can more quickly get to the physics, create plots and focus more on understanding the information. Leave compiled code fro Grad school...

Regarding using MATLAB with large matrices and such, I've found that it can be readily used to handle the large matrices, that's what its designed for afterall. We used it to rip through the UAE data for instance and create plots and animations. We even scripted it together with FIELDVIEW FVX scripts to create an instrument panel of CFD derived pressures and forces vs experiment and overlayed with CFD visualizations. So my expereince and student's experience is very positive. Eventually though, they will need to learn to program and compile using FORTRAN.

Also note that some people will have issues with having to buy MATLAB. The answer there is that most of the functionalies in MATLAB .m files can be executed using the gnu tool "octave" which also makes use of gnuplot for the ploting. octave comes with the cygwin distro so it can be easily used on windoze. Dunno about Mac's though... you can always compile from source ;-)

My 20 cents worth...

cheers,
e.

Marshall.Buhl
Posts: 437
Joined: Fri Oct 21, 2005 10:22 am
Organization: NREL/NWTC
Location: Boulder, CO
Location: Boulder, CO
Contact:

Re: Matlab

Postby Marshall.Buhl » Thu May 17, 2007 11:22 am

pmoriart wrote:Also, in order to get people to use our codes, having a DOS executable is preferable than requiring people to get a MatLab license

There is a compiler available for MatLab that allows you to distribute the code to non-MatLab owners.


Marshall
Mr. Marshall L. Buhl Jr.
NWTC-3811
National Renewable Energy Laboratory
Golden, CO 80401 USA
Marshall.Buhl@nrel.gov
Voice: +1 (303) 384-6914
Cell: +1 (303) 915-6623
Fax: +1 (303) 384-7079

Craig.Hansen
Posts: 2
Joined: Tue Nov 08, 2005 10:46 am

Matlab

Postby Craig.Hansen » Thu May 17, 2007 11:27 am

At Windward we have used Matlab scripts for several years to run and post-process simulations. It was relatively easy to write programs that would run and process large batches of simulations. I found these more productive and easier to write and maintain than other methods we had tried. We used Crunch for rainflow cycle counting and azimuth averaging, but Matlab for everything else.

The signal processing tools that are available in Matlab are very powerful and easy to use. Anyone involved in control system design is probably already using Matlab, so they are likely to appreciate a switch to Matlab for post-processing.

I recommend that you make the switch.
Craig Hansen
Windward Engineering LLC

Marshall.Buhl
Posts: 437
Joined: Fri Oct 21, 2005 10:22 am
Organization: NREL/NWTC
Location: Boulder, CO
Location: Boulder, CO
Contact:

MatLab

Postby Marshall.Buhl » Thu May 17, 2007 4:05 pm

Marwan Bikdash of North Carolina A&T State University was unfamiliar with our forum, so he e-mailed his response:

Marwan wrote:I totally support the move to MATLAB. Code written in FORTRAN should be compiled as mex files and interfaced to MATLAB. I used to write code in FORTRAN but this language is so painful to me now.

Frankly I think code written in FORTRAN or C or C++ has become practically inaccessible (useless?) today to the "general scientific public". Code development is much easier in MATLAB. Speeding and vectorization should be left to the officiando, and transparent to the user.
Mr. Marshall L. Buhl Jr.
NWTC-3811
National Renewable Energy Laboratory
Golden, CO 80401 USA
Marshall.Buhl@nrel.gov
Voice: +1 (303) 384-6914
Cell: +1 (303) 915-6623
Fax: +1 (303) 384-7079

Vicki.Zhao
Posts: 12
Joined: Thu Dec 08, 2005 3:25 pm
Location: Gorefiend

Postby Vicki.Zhao » Tue May 22, 2007 6:05 pm

I am a typical kid just came out of Engineering school ^_^ and I will definitely appreciate the idea of writting post-processing codes in Matlab.
It will take much less time for kids like me to understand what the codes are doing.... as I do not know Fortran at all >.< .
V. Zhao
The Valley of Honor
Orgrimmar
Durotar

Marshall.Buhl
Posts: 437
Joined: Fri Oct 21, 2005 10:22 am
Organization: NREL/NWTC
Location: Boulder, CO
Location: Boulder, CO
Contact:

Current MCrunch Features

Postby Marshall.Buhl » Tue Aug 07, 2007 10:35 am

Hi,

Currently, MCrunch (my MatLab-based postprocessor designed to replace Crunch, GPP, and GenStats) can do the following:
    Process files of various lengths
    Add scales and offsets to input data
    Add calculated channels
    Plot time series with user-defined layout of subplots
    Calculate statistics
    Generate summary statistics as Crunch did
    Tabulate extreme events
    Generate and plot probability density functions
    Do rainflow analysis, bin by range and/or mean, calculate DELs
Features on my to-do list:
    Load roses
    PSDs
    Limit input and processing to selected channels
    Low-pass, high-pass, and band-pass filtering
    Moving averages
    Peak and valley listing
    Statistical extrapolation
    Decimation
    Output modified input including calculated channels
    Tab-delimited option for output
    Interpolation
    Binning
    Crosstalk removal
    Merge processed data with boilerplate loads document

Please tell me how you would like to see the above implemented. Post your requests for other features. Rate features for importance.

I've never had to generate a loads document, so it's hard to guess what the industry needs. Your feedback will be greatly appreciated.


Marshall
Mr. Marshall L. Buhl Jr.
NWTC-3811
National Renewable Energy Laboratory
Golden, CO 80401 USA
Marshall.Buhl@nrel.gov
Voice: +1 (303) 384-6914
Cell: +1 (303) 915-6623
Fax: +1 (303) 384-7079

Andreas.Ferber
Posts: 25
Joined: Wed Nov 11, 2009 2:43 pm

Re: To MatLab, or not to MatLab

Postby Andreas.Ferber » Thu May 20, 2010 11:19 am

Hi all,

I am currently working on my masters here in Germany. I am using your codes here but I really have problems, understanding the Fortran files. I just once skimmed over them to find how a moment is defined and it really was hard to understand. It would be so much easier to do this all in Matlab for me and all students I know. Frankly I do not now one engeneering student who can compile in fortran. But everybody here uses and knows Matlab.

Oktave would really be a great alternative, too.

Andreas

Marshall.Buhl
Posts: 437
Joined: Fri Oct 21, 2005 10:22 am
Organization: NREL/NWTC
Location: Boulder, CO
Location: Boulder, CO
Contact:

Re: To MatLab, or not to MatLab

Postby Marshall.Buhl » Wed Jun 02, 2010 9:53 am

Thanks for the feedback.

MatLab is highly inefficient computationally. Processing takes probably an order of magnitude longer than it would for Fortran. Programs that are CPU bound will always need to use a compiled language. Fortran is the fastest language for scientific and engineering modeling. As long as MatLab is primarily an interpreted language, we'll continue doing our simulations in Fortran (or C++).
Mr. Marshall L. Buhl Jr.
NWTC-3811
National Renewable Energy Laboratory
Golden, CO 80401 USA
Marshall.Buhl@nrel.gov
Voice: +1 (303) 384-6914
Cell: +1 (303) 915-6623
Fax: +1 (303) 384-7079


Return to “Computer-Aided Engineering Software Tools”

Who is online

Users browsing this forum: No registered users and 1 guest