-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Never hits the double couple #27
Comments
the iso parameter parameter has to be interpolated, so it may be close to an expected value but with small differences, in this case 0.000004. there may be a couple of ways to fix this if it turns out to be a problem, but seems like uncertainty estimation needs to be tested first.
does this refer to the code in the inversion or code in uncertainty estimation? |
In the inversion code. Even if it does not create any problems in the uncertainty estimation there is no reason we should have this. |
Sounds like you already have a solution, and sounds like it should not be big. What is your suggestion?
We are both working on this project. We both have permissions to make change on the code. Perhaps share your suggestions and we can work together to make the change. |
If input is a double couple type i.e. -R0/0 and -I1/1/x/y/z, where x,y,z On Fri, Mar 4, 2016 at 4:37 PM, R [email protected] wrote:
Vipul Silwal |
Yes this is the way that CAP worked in the past. But for point solutions there is no reason to go into the inversion block. These can be simply calculated in the main section, I don't think it's a major change or that it would break much. Go for it, or we can discuss next meeting. |
A random grid will never hit ISO=0 and CLVD=0 exactly. So this issue is if abs(v) < TOL, v = 0 Set TOL to 1e-4 or so. Perhaps I am missing some intricacies of the implementation. If not, just Thanks, On Wed, Mar 2, 2016 at 11:27 AM, Vipul Silwal [email protected]
|
CAP never hits the double couple (ISO=0 and CLVD=0)
The closest we get is ISO 0.000004. It should be okay for inversions but I am not entirely sure how it will effect in the uncertainty estimation. It should not be a big change to fix this.
Thanks,
The text was updated successfully, but these errors were encountered: