Alain's questions/comments

[rmodrak]

Hi Alain, Thanks for pointing out this bug. Will commit a fix soon.

[AlainPlattner]

Hi Ryan,

I was not sure if this was the right way of pointing it out. Shall I post things like this in the future? Or just send you an email when it's not solved within a Month? Or solve it myself and send a pull request?

For now I just checked out an earlier commit where it isn't a problem.

I am a little bit stuck but there may be an easy fix: When I try to run the inversion with real data, then the target function f does not go down by much compared to its starting value (but it does go down to about 70%). But because of this, the program decides that line search was unsuccesful. Is there an easy way to make it contiune anyway and do the next inversion step even if the target function does not diminish much?

If there is no "easy way", then I would just add another option for line search mode and just have it count the number of steps and set isdone=1 when the max number of tries is reached.

Thanks for writing this amazing piece of software! I love using it and the code is extremely beautifullt written.

Cheers, Alain

rmodrak notifications@github.com writes:

Hi Alain, Thanks for pointing out this bug. Will commit a fix soon.

---

Reply to this email directly or view it on GitHub: https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186042801

[rmodrak]

Hi Alain,

Thanks so much for the feedback.

For bug reports or feature requests, I think github issues are a good way--it could be helpful to other users to know that a bug exists and is being worked on.

I am happy to work on bugs, or if you like feel free to commit fixes yourself.

By default the program tries the LBFGS direction first, and if that fails, then then steepest descent direction. If that also fails, the inversion is stalled at a local minimum of the objective function. Unfortunately, this behavior is quite common, I think, in dealing with real data. Adjusting line search or other numerical parameters in this situation might buy an additional model update or two, but in my experience this not a reliable solution. Much better I think is to adjust the multiscale or regularization settings, e.g. bandpass corner frequencies.

Are you doing an acoustic or elastic inversion? If the latter, I could make some additional suggestions as well.

Best, Ryan

On Fri, Feb 19, 2016 at 12:08 AM, AlainPlattner notifications@github.com wrote:

Hi Ryan,

I was not sure if this was the right way of pointing it out. Shall I post things like this in the future? Or just send you an email when it's not solved within a Month? Or solve it myself and send a pull request?

For now I just checked out an earlier commit where it isn't a problem.

I am a little bit stuck but there may be an easy fix: When I try to run the inversion with real data, then the target function f does not go down by much compared to its starting value (but it does go down to about 70%). But because of this, the program decides that line search was unsuccesful. Is there an easy way to make it contiune anyway and do the next inversion step even if the target function does not diminish much?

If there is no "easy way", then I would just add another option for line search mode and just have it count the number of steps and set isdone=1 when the max number of tries is reached.

Thanks for writing this amazing piece of software! I love using it and the code is extremely beautifullt written.

Cheers, Alain

rmodrak notifications@github.com writes:

Hi Alain, Thanks for pointing out this bug. Will commit a fix soon.

---

Reply to this email directly or view it on GitHub:

https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186042801

— Reply to this email directly or view it on GitHub https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186052929 .

[rmodrak]

P.S. Could you copy/paste your output.optim file here just to double check there is not a problem with the default numerical parameters?

On Fri, Feb 19, 2016 at 12:31 AM, Ryan Modrak rmodrak@princeton.edu wrote:

Hi Alain,

Thanks so much for the feedback.

For bug reports or feature requests, I think github issues are a good way--it could be helpful to other users to know that a bug exists and is being worked on.

I am happy to work on bugs, or if you like feel free to commit fixes yourself.

By default the program tries the LBFGS direction first, and if that fails, then then steepest descent direction. If that also fails, the inversion is stalled at a local minimum of the objective function. Unfortunately, this behavior is quite common, I think, in dealing with real data. Adjusting line search or other numerical parameters in this situation might buy an additional model update or two, but in my experience this not a reliable solution. Much better I think is to adjust the multiscale or regularization settings, e.g. bandpass corner frequencies.

Are you doing an acoustic or elastic inversion? If the latter, I could make some additional suggestions as well.

Best, Ryan

On Fri, Feb 19, 2016 at 12:08 AM, AlainPlattner notifications@github.com wrote:

Hi Ryan,

I was not sure if this was the right way of pointing it out. Shall I post things like this in the future? Or just send you an email when it's not solved within a Month? Or solve it myself and send a pull request?

For now I just checked out an earlier commit where it isn't a problem.

I am a little bit stuck but there may be an easy fix: When I try to run the inversion with real data, then the target function f does not go down by much compared to its starting value (but it does go down to about 70%). But because of this, the program decides that line search was unsuccesful. Is there an easy way to make it contiune anyway and do the next inversion step even if the target function does not diminish much?

If there is no "easy way", then I would just add another option for line search mode and just have it count the number of steps and set isdone=1 when the max number of tries is reached.

Thanks for writing this amazing piece of software! I love using it and the code is extremely beautifullt written.

Cheers, Alain

rmodrak notifications@github.com writes:

Hi Alain, Thanks for pointing out this bug. Will commit a fix soon.

---

Reply to this email directly or view it on GitHub:

https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186042801

— Reply to this email directly or view it on GitHub https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186052929 .

[rmodrak]

Hi Alain, I've added you as a collaborator to seisflows. If you find the email updates too verbose, feel free to "unwatch" the repository.

On Fri, Feb 19, 2016 at 12:34 AM, Ryan Modrak rmodrak@princeton.edu wrote:

P.S. Could you copy/paste your output.optim file here just to double check there is not a problem with the default numerical parameters?

On Fri, Feb 19, 2016 at 12:31 AM, Ryan Modrak rmodrak@princeton.edu wrote:

Hi Alain,

Thanks so much for the feedback.

For bug reports or feature requests, I think github issues are a good way--it could be helpful to other users to know that a bug exists and is being worked on.

I am happy to work on bugs, or if you like feel free to commit fixes yourself.

By default the program tries the LBFGS direction first, and if that fails, then then steepest descent direction. If that also fails, the inversion is stalled at a local minimum of the objective function. Unfortunately, this behavior is quite common, I think, in dealing with real data. Adjusting line search or other numerical parameters in this situation might buy an additional model update or two, but in my experience this not a reliable solution. Much better I think is to adjust the multiscale or regularization settings, e.g. bandpass corner frequencies.

Are you doing an acoustic or elastic inversion? If the latter, I could make some additional suggestions as well.

Best, Ryan

On Fri, Feb 19, 2016 at 12:08 AM, AlainPlattner <notifications@github.com

wrote:

Hi Ryan,

I was not sure if this was the right way of pointing it out. Shall I post things like this in the future? Or just send you an email when it's not solved within a Month? Or solve it myself and send a pull request?

For now I just checked out an earlier commit where it isn't a problem.

I am a little bit stuck but there may be an easy fix: When I try to run the inversion with real data, then the target function f does not go down by much compared to its starting value (but it does go down to about 70%). But because of this, the program decides that line search was unsuccesful. Is there an easy way to make it contiune anyway and do the next inversion step even if the target function does not diminish much?

If there is no "easy way", then I would just add another option for line search mode and just have it count the number of steps and set isdone=1 when the max number of tries is reached.

Thanks for writing this amazing piece of software! I love using it and the code is extremely beautifullt written.

Cheers, Alain

rmodrak notifications@github.com writes:

Hi Alain, Thanks for pointing out this bug. Will commit a fix soon.

---

Reply to this email directly or view it on GitHub:

https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186042801

— Reply to this email directly or view it on GitHub https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186052929 .

[rmodrak]

The original issue has been fixed now I think. If it's alright, let me convert this issue to a question/comments thread in case it might be helpful for other users.

[AlainPlattner]

Thanks Ryan for adding me, and for resolving the issue so quickly. That's fantastic!

I am attaching an output.optim file from one run where I set the max step number to very high and also didn't limit the step length, just to see where it goes. When I do limit the number of steps then it would just stop after that number and state that the line search failed. I have to say that the data I am trying to invert is of very poor quality, so maybe my attempts are moot anyway and the software is right by telling me that it doesn't work. I pretty much just took a hammer and a bunch of geophones out to our backyard and hammered some data out of soil and alluvium..

output.optim.txt

[AlainPlattner]

To your question whether elastic or acoustic: I am using elastic, source_type=2. Because my soil is like a sponge I needed to set Qmu and Qkappa to 1.5. I tweaked specfem2d a little such that it also writes and reads the variables Qmu_attenuationext and QKappa_attenuationext into and from a binary file.

I will try out the adaptive spectral filtering. I think that's a very good idea considering the extremely poor quality of my data.

Thank you so much for your help!

[rmodrak]

Hi Alain,

In your output.optim file, your misfit levels off after abot the 7th trial step length. This is not at all what I would expect if your inversion had stalled at local minimum.

One idea-- perhaps the step length alpha has become so large that the perturbed model m + alpha dm is unstable or unphysical in some way, causing the forward evaluation to fail. This might explain why the misfit value is not being updated after the 7th line search iteration. Does this make sense? Ideally, it would be good to detect if the forward simulations fail and stop immediately, but this may not happen because the SPECFEM packages do not always return the proper exit status codes.

In any case, it might be worth visually checking the observations, synthetics, gradient, and updated models to make sure there are no obvious problems.

Ryan

[AlainPlattner]

Thanks Ryan,

That's a good idea. I will limit alpha to the value where it stopped updating the model and see what happens. I'm currently playing around with the updated seisflows with obspy and am also gonna try filtering.

Alain

rmodrak notifications@github.com writes:

Hi Alain,

In your output.optim file, your misfit levels off after abot the 7th trial step length. This is not at all what I would expect if your inversion had stalled at local minimum.

One idea-- perhaps the step length alpha has become so large that the perturbed model m + alpha dm is unstable or unphysical in some way, causing the forward evaluation to fail. This might explain why the misfit value is not being updated after the 7th line search iteration. Does this make sense? Ideally, it would be good to detect if the forward simulations fail and stop immediately, but this may not happen because the SPECFEM packages do not always return the proper exit status codes.

In any case, it might be worth visually checking the observations, synthetics, gradient, and updated models to make sure there are no obvious problems.

Ryan

---

Reply to this email directly or view it on GitHub: https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-186368225

[rmodrak]

Hey Alain, Have you had any luck? Here is one small change that I think would fix your problem. In optimize.base, replace each occurence of

        elif PAR.LINESEARCH == 'Bracket' or \
            self.iter == 1 or self.restarted:

with

        elif PAR.LINESEARCH == 'Bracket':

[AlainPlattner]

Hi Ryan,

Awesome, thanks. I'll give this a try right away.

I did manage to get an inversion running with a very narrow bandpass but no useful results so far. But it's not because of the software. My data is just really low quality.

Alain

rmodrak notifications@github.com writes:

Hey Alain, Have you had any luck? Here is one small change that I think would fix your problem. In optimize.base, replace

        elif PAR.LINESEARCH == 'Bracket' or \
            self.iter == 1 or self.restarted:

with

        elif PAR.LINESEARCH == 'Bracket':

---

Reply to this email directly or view it on GitHub: https://github.com/PrincetonUniversity/seisflows/issues/17#issuecomment-192541912

[rmodrak]

Hi Alain, I know how busy you are with teaching, so no rush!

[rmodrak]

Rather than a narrow passband, perhaps just a lowpass? I've read that works well for most exploration, regional and global problems. It all depends though on the design of the source and receivers.

The signal processing features in seisflows are kind of rudimentary--not something I focused on a lot on or tested a lot. Local modifications may be needed.