Announcing MExtremes

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,

I have created a new MatLab function called MExtremes. It generates extreme-event tables similar to those from Crunch and MCrunch, but it is far more efficient. This is all it does, so we don’t need to store all files in memory concurrently. Instead of having to do one Crunch or MCrunch run for each load case and then combine the resultant tables using CombEEv, you can process all load cases in a single MExtremes run.

It generates tables in plain-text files and also formatted Excel files. One advantage of MExtremes over MCrunch is that it colors the diagonal cells. I’ll probably add that feature to MCrunch if I ever find time.

The program is currently just an alpha release (v1.00.00c-mlb) because only I have used it. If you use it and it seems to work, please tell me and I will promote it to beta. If you find problems or have suggestions, please let me know about it.

I have not created a manual for MExtremes. The sample input files in the CertTest folder are fairly self explanatory, but you may find that the MCrunch manual may clarify some things for you.

You can call MExtremes from the MatLab prompt, or use the compiled version if you do not have a MatLab license. You will need to install the correct MatLab Component Runtime Installer to use the compiled version. There is a link to it on the MExtremes web page:

[url]National Wind Technology Center's Information Portal | Wind Research | NREL

Enjoy!

2

Hi Marshall,

Thank you for this one. You couldn’t have timed it better :slight_smile: This really saved me a lot of time. I had resorted to decimating the outputs and requesting fewer outputs to keep file sizes small and just last week I had written an excel macro to read in the extreme event file and change the color of the diagonal cells. But this makes life so much easier. I did go in and edit the source code a little to make it look in a different directory for the FAST output files, only for housekeeping purposes. I did also compare the outputs from a couple of my crunch runs to the output of MExtremes. The worst deviation I got for the 16 or so channels that I was looking at was in the order of 10e-5, which I assume must be due to some rounding error between codes / platforms. So far so good. Just thought I’d give you some feedback based on first looks. Like I mentioned earlier, I was just dealing with extreme events and the timing was just perfect to test it out. However due to limited functionality I will have to go back to Crunch or Mcrunch. I hope some other member of this forum will spend some time with it to see if they are any bugs and I really hope you can incorporate this into Mcrunch. Thanks once again.

Regards,

Subin.

3

Thanks for the great feedback. I’m planning to do a similar thing for fatigue-life calculations, but programming time is scarce.

If you have recommendations on how to improve MExtremes, please be specific.

4

Marshall,

The only recommendation I have, after having played with the code for only a couple of days, is to have a little more flexibility regarding the location of the input files. Right now I have modified the code so that it looks for the FAST output files in the same location as that of the .mext file. I modified the ReadEESettings file and the WriteExtEvts files. In case you are interested, I am attaching the modified code below.

ReadEESettings modification at line 402:

%========================================================================== %S.S (12/15/2010) - Trial to automatically set file path for input files to % the location where the settings (.mext) file is located %========================================================================== mextFilePath = GetRoot( SettingsFile ); tempPath = 0; tempPath = strfind(mextFilePath,'\'); if isempty(tempPath) h=errordlg('Please enter full path name for .mext file'); uiwait(h); return end mextFilePath = mextFilePath(1:tempPath(end)); %========================================================================== for File=1:NumFiles ReadFileList{File,1} = [mextFilePath cell2mat( ReadVal( ParamFile{1}{PLine+File}, 'string' , 1, '', '' ) )]; % Location of files to be read FileList{File,1} = cell2mat( ReadVal( ParamFile{1}{PLine+File}, 'string' , 1, '', '' ) ); % File names that will be reported in the Excel Workbook. end % for File

WriteExtEvts modification at line 123

XLSfile = [ GetRoot( SettingsRoot ), '_EEvts.', XLStype ]; FullXLSfile = XLSfile; %[ pwd, filesep, XLSfile ]; Modified by S.S on 12/14/2010

These modifications are very rudimentary, not very elegant and do not have enough error handling built into them for public use but it works for the setup I have. I am posting them because I think it would be easier for you to understand what I am talking about by looking at the code modifications.

And I did also change the number formatting for the values reported in the excel sheet.

As I mentioned earlier these are mostly cosmetic and houskeeping changes. If I find any bugs which affect the actual output, I’ll let you know.

Subin.

5

Subin,

I’m not sure I understand what your issue is with the input files. When I run MExtremes, I make the folder containing the settings file and the time series the current folder, and it just works. You can also include an absolute or relative path to in the file names in the settings file.

As for the number format, are you saying that the RealFmt parameter in the settings file is being ignored?

Marshall

6

Marshall,

I think there must be some issue with my path settings then. I will check that and get back with you.

It seemed to me that the RealFmt parameter changed the formatting only of the text file output and not the excel file. It looked like the excel file number format was hardcoded into WrExtEvts.m at line 295

RngObj.cells.EntireColumn.NumberFormat = '0.00E+00';

Subin.

7

Marshall,

I have to apologize about my comment on the input files. There was an issue with my Matlab search path which was preventing me from running the code from the the folder where the settings and input files were. Now it all works. I feel stupid for not thinking about that.
Although with my rewrite, now I can execute the program from anywhere as long as I supply the entire path to the settings file, whereas earlier it would crash when it got to writing the excel file because to get it to run from a different folder, I had to supply the absolute path to my input files in the settings file. When it was trying to write the excel file, it would append this absolute path to the end of the path of the current directory thus creating a non-existent location causing the program to crash. In short it now allows me to not have to keep changing my current directory. I guess it was a learning experience. Thanks for taking the time to respond.

Regards,

Subin.

8

You are correct. I had hardcoded it in the test program I wrote and forgot to fix it when I incorporated the code in MExtremes. I’ve fixed that now. The newly available v1.00.00d-mlb will use the same precision in the Excel files that is used for the text files.

I also formatted the data columns to use AutoFit, but all columns have the same width as the widest needed to be. I’d like to do that for the first column (channel names), but because of the long string in the title line, it’s not very easy. If it turns out to be a problem for the user community, I’ll revisit the issue.

Enjoy!

Marshall

9

Actually, Subin showed me an easy way to do it, so I fixed the code and uploaded MExtremes v1.00.00e-mlb.

10

I’d like to get a feeling for how many people would be interested in adding a peak finder to MExtremes. In case you don’t know, a peak finder finds peaks (and valleys) and fits a quadratic to the the peak and two points surrounding it. It then replaces the peak value with the maximum of the quadratic. The time value is left unchanged.

The assumption is that the output is sampled at regular time steps and the the real peaks are often missed. Finding the maximum of the parabola supposedly gives you a better approximation of the actual peak. You can read more about it starting on Page 7 in Schluter’s and Sutherland’s “User’s Guide for LIFE2’s Rainflow Counting Algorithm”: [url]Web Login Service - Error.

This is often useful in tabulating extreme events and rainflow cycle counting. It is available in Crunch, but not MCrunch.

11

Well, Jason thought the peak finder was an important feature to add to MExtremes, so I updated the program to include it. You can now download v1.00.00f-mlb from the alpha-tester’s page (wind.nrel.gov/designcodes/postpr … mes/alpha/).

12

Hello all,

First of all, thank you for publishing this software. I have been using MExtremes to generate the EE table for my certification calculations and it is very useful, especially because it can read files with different output lengths, so the table can be generated in just one step. However, I think I found a bug within the program as it does not seem to be applying the scale factors for the variables introduced in the input file. I did a test working with different scales in one case and using a factor of 1 for all the variables in another case and the result table I obtained in both situations is exactly the same.

Regards,

Ohiana Goikoetxea

13

Dear Ohiana,

Greg Hayman took over development of MExtremes a some months ago and he has released newer versions since then. It is up to alpha version “h” and the program was used for a major effort. I think it is working (mostly) correctly now. It will also apply partial safety factors, which is really nice.

Please try the new version.

Marshall

14

Hello Marshall,

I am trying to run MExtremes using MATLAB version 7.7 (7.7.0.471 R2008b, to be precise), but I am getting these ‘unexpected bracket’ error.

MExtremes_err.PNG
MExtremes_err.PNG1394×819 288 KB

I thought ‘~’ was causing it and I replaced it with ‘ext’; so this error was gone. But then a similar error popped up for “ParseEESettingsFile.m” function.

Do you know source of this error or have you seen it before?

Appreciate your help in advance.

Best Regards,
Neelabh

15

The tilde operator was introduced with MATLAB Version 7.9 (R2009b).

mathworks.com/help/matlab/m … tputs.html

You will need to place dummy variables where ever you see ~ in a function output list for this code to work with your version of matlab. There may be additional version-related issues which you will encounter.

Best regards,

Greg

16

Thanks Greg for your response. Replacing ~ with a dummy variable did help (I was on the right path, but then there were multiple replacements to be done; so I was not sure).

Now, MExtremes seem to run fine.

Cheers,
Neelabh

17

Hello Greg,

I have another question regarding “Input Files” tab in MExtremes.

Is there a way to specify all the input files (i.e. output files from FAST) in one go here. The thing is, I want to do an ultimate analysis with few hundred load cases and its a bit cumbersome to generate this big list.

Can MExtremes read something like “*.out” when all the input files are present in one folder? Or is there any other way to shorten the effort required to generate the input files list?

Any help here, would be appreciated.

Thanks a lot,
Neelabh

18

Dear Neelabh,

Greg may have other suggestions, but it would be easy to enter “dir” in a Windows Command Prompt (or the like) to show the full contents of a directory, which can then be copied and pasted into the MExtremes input file.

Best regards,

19

Hello again guys,

Thanks for answering previous queries. Those did help.
Currently I am using using MExtremes for post-processing loads based in IEC 61400-1 ed3. I have a very specific query here:

I have run ETM (DLC1.3) with 11 wind speeds, 6 seeds and 3 yaw misalignment. So total of 198 cases. I give a yaw MIS by giving different values of Nacelle yaw. The wind speed signal I use for binning is “uwind”. Since I should use bin option ‘1’ in MExtremes for DLC 1.3, I have two possibilities :

  1. Keep all 198 files under one DLC umbrella
  2. Split into 3 DLC sets for each yaw MIS value

The second option would make more sense as then, we could see the effect of yaw MIS on loads (otherwise they will get averaged out, by choosing option 1)). The 2) option, gives higher loads than 1) option, which also seems logical.

Now coming to the question: I compared the option 2) above with GH Bladed post-processing (via same approach and same 198 files) but I get 4-6 % higher loads with MExtremes. So I am now wondering, what could be the differences. Could you tell how MExtremes bins the input files? I understand it will use “uwind”(in my case) over the simulation length to calculate the mean wind speed. Is that correct? I use Wsmin=2,Wsmax=38 and Wsmaxbinsize=2. Is it then possible (for eg.) that mean wind of 11.9 m/s and 12.1 m/s are binned differently when infact they are both for 12 m/s? In GH Bladed we explicitly assign the bins, hence there are exact 6 files per wind bin with a total of 33 bins.

Binning is just one thing I can think of right now. I would appreciate if you could throw a bit more insight on these “averaged max.” calculation. When I read MEXtremes and Bladed manual they seem to follow similar approach.

Thanks a lot in advance,
Neelabh

20

Dear Neelabh,

Yes, MExtremes will bin the data based on the specified mean wind speed channel and if you have bins for 10-12 m/s and 12-14 m/s than a simulation with a mean of 11.9 m/s will show up in the former and 12.1 m/s will show up in the latter. To get around such a rounding problem, I would normally run my load-case simulations at wind speeds near the center of the bin e.g. 11 m/s and 13 m/s for the two bins above (alternative, you could change your bins so that a bin is 11-13 m/s).

By the way: I’m assuming you are using post-processing GH Bladed results in both MExtremes and GH Bladed post-processing i.e. the differences are the result of the post-processor, and not e.g. FAST versus GH Bladed?

Best regards,