ERROR ... ----------​----------​----------​-------- cwt ---> Invalid Value for Scales !

what is the reason for this error?

[KSSV]

What code have you tried so that you got this error? Show us the context of this error.

[zl]

Wavelet transforms are performed using code provided in the literature, but this error is always reported.Some say it's because of too much data

[zl]

ERROR ...

--------------------------------------

cwt ---> Invalid Value for Scales !

**************************************

cwt (line 74)

Invalid Value for Scales !

fn_analyze_record>fn_extract_one_wavelet (line 155)

cwt_coefs = cwt(signal,scales, wname);

fn_analyze_record (line 27)

[coefs, pulse_scale, rows, Tp] = fn_extract_one_wavelet(signal, dt);

main_analyze_ground_motion (line 26)

pulse_data = fn_analyze_record(signal, record_dt);

[Walter Roberson]

https://www.seismosoc.org/Publications/BSSA_html/bssa_104-4/2013276-esupp/index.html is that the source of the code?

[zl]

yes

[Walter Roberson]

@zl

The line numbers of your error message do not match the code in that link. For example it says that at line 27 of fn_analyzer_record there is a call to fn_extract_one_wavelet, but in the actual code, line 27 is a comment.

[zl]

I looked at the code again, but couldn't find the problem

[zl]

@Walter Roberson

[Walter Roberson]

I have difficulty assisting with code that I cannot see.

There are three possibilities at the moment:

• you might be using fairly different code that was inspired by the code that I linked to, but is not the same
• you might be using an earlier version of the code I linked to, and maybe the problem has already been fixed
• you might have edited a copy of the code that I linked to, in which case it is difficult for me to predict what you changed.

Have you considered moving aside the code you are using, and trying the code that I linked to?

[zl]

Thank you for your patient reply, this is the code I used, you can check it

[zl]

@Walter Roberson

Answer 1

[Walter Roberson]

Compare the example_ground_motion.acc file with the ex1.acc and ex2.acc files. The example_ground_motion.acc file starts with

PEER NGA Rotated Accelerogram (v1.1)

H1 for rotation: SAN FERNANDO 02/09/71 14:00, PACOIMA DAM, 254 (CDMG STATION 279)

H2 for rotation: SAN FERNANDO 02/09/71 14:00, PACOIMA DAM, 164 (CDMG STATION 279)

rotation angle - clockwise 31.0

FN component, azimuth = 195.0

Acceleration in g

4164 0.01000 NPTS, DT

and then there are 5 columns of data (but the last row in the file does not have all 5 entries.)

The ex1.acc and ex2.acc files just start directly in to data, after a one-line header, such as

0.01 22600

-0.016

-0.055

-0.070

The code you are using, main_analyze_ground_motion.m expects that multi-line header, and does some fixed-format reading of the file in places, in order to extract dt (the timestep). When with the data in the file not being in the expected form, sometimes at the point it does the reading of dt, the next available data in the file just happens to be a valid floating point number less than 1. That is the case for ex1.acc : even though the data is not in the expected format, it just happens to read in 0.0153 for the time step, and that value does not happen to lead to a code crash.

But for ex2.acc, after doing the fixed-format reading, the file just happens to be positioned after the decimal point of a number, and it ends up reading 0.517 without the leading 0.5 so it is parsing 17 and reads that as 17. That happens to crash the program as the code needs a value less than about 0.178 in order for a vector needed by cwt to happen to start with a value greater than 0.

The solution is to only use .acc files that have the expected file header... or to use some other code to read the .acc files.

[zl]

This problem has been solved. Thank you very much for your patient reply and answer. Thank you very much indeed@Walter Roberson