The selection of alpha in penalty method
Moderators: silvia, selimgunay, Moderators
The selection of alpha in penalty method
I found the result is kind of sensitive to the alpha value in penalty method. Any suggestions? Thanks a lot.
this is what i put in the manual, which I got from the cook book:
"Guideline for choice of alpha: If computer words carry approximately p decimal digits, experience has shown that alpha should not exceed 10^(p/2)" (cook)
Silvia Mazzoni, PhD
Structural Consultant
Degenkolb Engineers
235 Montgomery Street, Suite 500
San Francisco, CA. 94104
Structural Consultant
Degenkolb Engineers
235 Montgomery Street, Suite 500
San Francisco, CA. 94104
machine epsilon
Hello There,
even less than sqrt(1/macheps) is probably more advisable,
For x86 based machines (intel, amd...) all three floating precissions (float, double and long double) get promoted to long double, which has machine epsilon (machine precission) of about 1.08420217248550443401e-19 while they should actually be (from float.h as specified in standard include files):
#define FLT_EPSILON 1.19209290e-07F
#define DBL_EPSILON 2.2204460492503131e-16
#define LDBL_EPSILON 1.08420217248550443401e-19L
(see more in IEEE standard 754 on floating point numbers)
You can test some of those if you look into math_tst.cpp in SRC/nDarray in OpenSees source repository...
A book by Dennis and Schnabel:
@book{ Schnabel83,
author = { Dennis, Jr., J. E. and
Schnabel, Robert B. },
year = { 1983 },
title = { Numerical Methods for Unconstrained Optimization
and Nonlinear Equations },
publisher = { Prentice Hall , Engelwood Cliffs, New Jersey 07632. },
note = { },
napomena = { local CS01 ; QA 402.5.D44 1983 ISBN 0--13-627216-9 },
}
has some good suggestions what to do so that the system is still solvable with decent accuracy.
Simply put it:
Sqrt[1.08420217248550443401e-19] =
3.2927225399135962334e-10 or actually 1 over that
3.0370004999760496924e9
is too large for penalty spring so you might want to trim couple orders from that, so you can for example use machine precission to the power of 1/3 so that you get a penalty spring stiffness of about 10^6 to 10^7...
Make a simple example and play with it...
Boris
even less than sqrt(1/macheps) is probably more advisable,
For x86 based machines (intel, amd...) all three floating precissions (float, double and long double) get promoted to long double, which has machine epsilon (machine precission) of about 1.08420217248550443401e-19 while they should actually be (from float.h as specified in standard include files):
#define FLT_EPSILON 1.19209290e-07F
#define DBL_EPSILON 2.2204460492503131e-16
#define LDBL_EPSILON 1.08420217248550443401e-19L
(see more in IEEE standard 754 on floating point numbers)
You can test some of those if you look into math_tst.cpp in SRC/nDarray in OpenSees source repository...
A book by Dennis and Schnabel:
@book{ Schnabel83,
author = { Dennis, Jr., J. E. and
Schnabel, Robert B. },
year = { 1983 },
title = { Numerical Methods for Unconstrained Optimization
and Nonlinear Equations },
publisher = { Prentice Hall , Engelwood Cliffs, New Jersey 07632. },
note = { },
napomena = { local CS01 ; QA 402.5.D44 1983 ISBN 0--13-627216-9 },
}
has some good suggestions what to do so that the system is still solvable with decent accuracy.
Simply put it:
Sqrt[1.08420217248550443401e-19] =
3.2927225399135962334e-10 or actually 1 over that
3.0370004999760496924e9
is too large for penalty spring so you might want to trim couple orders from that, so you can for example use machine precission to the power of 1/3 so that you get a penalty spring stiffness of about 10^6 to 10^7...
Make a simple example and play with it...
Boris