How to update model by the program "xmodel_update"

[wangkaim8]

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc_external_mesh.bin proc_drhorho.bin proc**dvsvs.bin proc**_dvpvp.bin proc__ibool.bin proc__possion_new.bin crop__rho_new.bin proc__vp_new.bin proc__vs_new.bin proc__vb_new.bin proc__x.bin proc__y.bin proc_z.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

[rmodrak]

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

[rmodrak]

To respond specifically to the question about xmodel_update--

From issue #396, it seems xmodel_update might still be broken. There are some other github issues that mention xmodel_update that give a sense for the underlying problem. Basically, I think src/tomography originally contained a "quick and dirty" way of doing things that has not been fully cleaned up.

In general, an alternative to xmodel_update is to use xgenerate_databases in combination with the Parfile setting MODEL=gll. Once you have your model as a set of proc??????[vp,vs,rho].bin files, you can use MODEL=gll to have SPECFEM work with the model in that form. There is no need to interpolate back to the tomography_model.xyz format. Some other approach might be needed, though, if you are using a CUBIT model or doing something else specialized.

On Thu, Mar 17, 2016 at 11:30 AM, R Modrak rmodrak@gmail.com wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model " tomography_model.xyz". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

[komatits]

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

[rmodrak]

Hi Dimitri,

Thanks also for the update! Incidentally, through the devel branch I've been trying to follow Vadim's work on penalty variation methods, which we agree are important. This is something we've looked at as well, though only in the 2D context. Just last year, there was a paper by one of Lianjie Huang's collaborators on Tikhonov and total variation regularization that Etienne and I were looking at. From Etienne, I realized Lianjie's group is similar perhaps to the Marseille group--yours and Lianjie's are the only two I know who do both large-scale seismology and small-scale acoustics.

Anyway, getting back to the github issue. With Etienne earlier, I was arguing it is not practical to include a real inversion test case within EXAMPLES--the way of doing things in that directory is not flexible enough to deal with all the complexity of an inversion.

By coincidence, however, David Luet introduced us this morning to a tool called Jenkins that seems like it might provide a workable framework for an inversion example. From what I could tell, Jenkins is like buildbot, only more powerful. Jenkins seems to require a lot of upfront work, customizing for a particular environment, so from the beginning the user has some idea what they're getting into. Anyway, thought I'd mention it here since it seems relevant.

Best, Ryan

On Thu, Mar 17, 2016 at 6:40 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub < https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198111763

[wangkaim8]

Hi Ryan,

Thanks for the help!

I used the 2-D example in SeisFlows months ago, it works well. However, they haven't provided a 3-D example for specfem3d nor specfem3d_globe at that time. That is why I have to write scripts of iterative inverison with specfem3d by myself.

As reminded by you, they have already launched 3-D examples for Cartesian and Global version. Cheers ! However, the 3-D examples are only available for local user with account on tiger, which I am not. I have taken your suggest to use MODEL=gll for updating models, it works well. Thanks!

In the meantime, do you have some materials about how to use src/tomography codes and I will appreciate if you can provide me some. By the way, could it possible for non-local user like me to get the two 3-D examples for Cartesian and Global version from Seisflows?

Best regards, Kai Email: kai.wang@mq.edu.au

[rmodrak]

Hi Kai,

If you are only doing a single acoustic inversion the MODEL=gll approach might work well for you. SeisFlows might be overkill.

If you are doing an elastic inversion or multiple acoustic inversions, SeisFlows might work better -- in the elastic inversin case because careful numerical safeguards become important, and in the multiple acoustic inversions case because SeisFlows provides a much more automated workflow.

I've copied the 3D Cartesian example we use on our local cluster to http://tigress-web.princeton.edu/~rmodrak/3dAcoustic/checkers. You might be able to get it to work by downloading SPECFEM3D commit b5559822 and compiling and substituting your own (machine dependent) binaries. Minor changes to the system interface might be needed. Do you have at least 16 cores on the node you'll be submitting from? You could probably run with as few as four cores, but you'd have to modify some things.

Also, I've copied the 3D global example we use to http://tigress-web.princeton.edu/~rmodrak/Examples3dGlobe/mideast. This one is a lot more expensive than the 3D Cartesian examples, and it's been longer since I tested it, so you may be better off starting with the 3D Cartesian example.

Compared with the 2D checkerboard inversion, the 3D test cases are quite expensive, so they are not designed to run as long. If you make it to the line search, then be assured everything is working properly, even if you get a line search error.

Feel free to open up an issue on the SeisFlows github page. It might be more appropriate to discuss there than on the SPECFEM formum, and other developers from our group might be able to help as well. I am trying to defend in a month or two, so I might not be available at times, but I will try.

Best, Ryan

[rmodrak]

My apologies for commandeering this thread. Kai, I am opening a new issue. Please follow the link for any further discussion not directly related to SPECFEM3D.

[komatits]

Hi Ryan,

Thanks for your feedback! I agree that the current directory structure of the code is not suitable for examples of inverse problems any more because none of the subdirectories related to inversion routines is actively maintained. However that is relatively easy to fix, Emanuele is soon going to commit his current way to Git and from there Vadim will clean all of that and will come up with a single set of routines, simple, easy to use and with at least a couple of examples.

In the past when we had three copies of Geocubit in different directories and even different servers, none of them up-to-date, we had to do the same kind of cleaning to come back to a single version and move all the rest to the "unused" directory and things quickly came back to normal. We need to do the same for inversion.

We should be done around the end of June.

As you say we should (and we will) support both adjoint tomo and FWI, since different users use different ways and different cost functions.

We also need to support at least one fully automatic way, because in some fields (e.g. medical, oil industry) they often do not do careful data selection but rather perform automatic inversion of the whole dataset (at least in some cases).

Thanks, Dimitri.

On 18/03/2016 02:30, rmodrak wrote:

Hi Dimitri,

Thanks also for the update! Incidentally, through the devel branch I've been trying to follow Vadim's work on penalty variation methods, which we agree are important. This is something we've looked at as well, though only in the 2D context. Just last year, there was a paper by one of Lianjie Huang's collaborators on Tikhonov and total variation regularization that Etienne and I were looking at. From Etienne, I realized Lianjie's group is similar perhaps to the Marseille group--yours and Lianjie's are the only two I know who do both large-scale seismology and small-scale acoustics.

Anyway, getting back to the github issue. With Etienne earlier, I was arguing it is not practical to include a real inversion test case within EXAMPLES--the way of doing things in that directory is not flexible enough to deal with all the complexity of an inversion.

By coincidence, however, David Luet introduced us this morning to a tool called Jenkins that seems like it might provide a workable framework for an inversion example. From what I could tell, Jenkins is like buildbot, only more powerful. Jenkins seems to require a lot of upfront work, customizing for a particular environment, so from the beginning the user has some idea what they're getting into. Anyway, thought I'd mention it here since it seems relevant.

Best, Ryan

On Thu, Mar 17, 2016 at 6:40 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub <

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198111763

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198153482

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

[rmodrak]

Hi Dimitri,

Thanks for the update.

In a way, it seems like a question of what is the most efficient way forward. If a lot of effort would be required to realize the above changes, then I worry it might not be worth it. Inversion is such a complicated thing-- all successful implementations I am aware are at the package level, not the subpackage level. While it might be possible to get something working, I worry that in the end it may not be very easily automated or flexible.

On the other hand, if new changes are almost ready to go, then it couldn't hurt to commit them. Just the restructuring you mentioned itself would be a big improvement.

Thanks again, Ryan

On Sat, Mar 19, 2016 at 8:07 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi Ryan,

Thanks for your feedback! I agree that the current directory structure of the code is not suitable for examples of inverse problems any more because none of the subdirectories related to inversion routines is actively maintained. However that is relatively easy to fix, Emanuele is soon going to commit his current way to Git and from there Vadim will clean all of that and will come up with a single set of routines, simple, easy to use and with at least a couple of examples.

In the past when we had three copies of Geocubit in different directories and even different servers, none of them up-to-date, we had to do the same kind of cleaning to come back to a single version and move all the rest to the "unused" directory and things quickly came back to normal. We need to do the same for inversion.

We should be done around the end of June.

As you say we should (and we will) support both adjoint tomo and FWI, since different users use different ways and different cost functions.

We also need to support at least one fully automatic way, because in some fields (e.g. medical, oil industry) they often do not do careful data selection but rather perform automatic inversion of the whole dataset (at least in some cases).

Thanks, Dimitri.

On 18/03/2016 02:30, rmodrak wrote:

Hi Dimitri,

Thanks also for the update! Incidentally, through the devel branch I've been trying to follow Vadim's work on penalty variation methods, which we agree are important. This is something we've looked at as well, though only in the 2D context. Just last year, there was a paper by one of Lianjie Huang's collaborators on Tikhonov and total variation regularization that Etienne and I were looking at. From Etienne, I realized Lianjie's group is similar perhaps to the Marseille group--yours and Lianjie's are the only two I know who do both large-scale seismology and small-scale acoustics.

Anyway, getting back to the github issue. With Etienne earlier, I was arguing it is not practical to include a real inversion test case within EXAMPLES--the way of doing things in that directory is not flexible enough to deal with all the complexity of an inversion.

By coincidence, however, David Luet introduced us this morning to a tool called Jenkins that seems like it might provide a workable framework for an inversion example. From what I could tell, Jenkins is like buildbot, only more powerful. Jenkins seems to require a lot of upfront work, customizing for a particular environment, so from the beginning the user has some idea what they're getting into. Anyway, thought I'd mention it here since it seems relevant.

Best, Ryan

On Thu, Mar 17, 2016 at 6:40 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here <http://seisflows.readthedocs.org/en/latest/instructions_remote.html , which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub <

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

< https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198111763

— You are receiving this because you commented. Reply to this email directly or view it on GitHub < https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198153482

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198812091

[rmodrak]

P.S. Sorry if all my posts on this topic come across as repetitive. In implementing inversion myself, I made a lot of mistakes early on that I hope others could avoid. I appreciate all the work being done to improve SPECFEM.

On Sun, Mar 20, 2016 at 12:26 AM, Ryan Modrak rmodrak@princeton.edu wrote:

Hi Dimitri,

Thanks for the update.

In a way, it seems like a question of what is the most efficient way forward. If a lot of effort would be required to realize the above changes, then I worry it might not be worth it. Inversion is such a complicated thing-- all successful implementations I am aware are at the package level, not the subpackage level. While it might be possible to get something working, I worry that in the end it may not be very easily automated or flexible.

On the other hand, if new changes are almost ready to go, then it couldn't hurt to commit them. Just the restructuring you mentioned itself would be a big improvement.

Thanks again, Ryan

On Sat, Mar 19, 2016 at 8:07 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi Ryan,

Thanks for your feedback! I agree that the current directory structure of the code is not suitable for examples of inverse problems any more because none of the subdirectories related to inversion routines is actively maintained. However that is relatively easy to fix, Emanuele is soon going to commit his current way to Git and from there Vadim will clean all of that and will come up with a single set of routines, simple, easy to use and with at least a couple of examples.

In the past when we had three copies of Geocubit in different directories and even different servers, none of them up-to-date, we had to do the same kind of cleaning to come back to a single version and move all the rest to the "unused" directory and things quickly came back to normal. We need to do the same for inversion.

We should be done around the end of June.

As you say we should (and we will) support both adjoint tomo and FWI, since different users use different ways and different cost functions.

We also need to support at least one fully automatic way, because in some fields (e.g. medical, oil industry) they often do not do careful data selection but rather perform automatic inversion of the whole dataset (at least in some cases).

Thanks, Dimitri.

On 18/03/2016 02:30, rmodrak wrote:

Hi Dimitri,

Thanks also for the update! Incidentally, through the devel branch I've been trying to follow Vadim's work on penalty variation methods, which we agree are important. This is something we've looked at as well, though only in the 2D context. Just last year, there was a paper by one of Lianjie Huang's collaborators on Tikhonov and total variation regularization that Etienne and I were looking at. From Etienne, I realized Lianjie's group is similar perhaps to the Marseille group--yours and Lianjie's are the only two I know who do both large-scale seismology and small-scale acoustics.

Anyway, getting back to the github issue. With Etienne earlier, I was arguing it is not practical to include a real inversion test case within EXAMPLES--the way of doing things in that directory is not flexible enough to deal with all the complexity of an inversion.

By coincidence, however, David Luet introduced us this morning to a tool called Jenkins that seems like it might provide a workable framework for an inversion example. From what I could tell, Jenkins is like buildbot, only more powerful. Jenkins seems to require a lot of upfront work, customizing for a particular environment, so from the beginning the user has some idea what they're getting into. Anyway, thought I'd mention it here since it seems relevant.

Best, Ryan

On Thu, Mar 17, 2016 at 6:40 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here < http://seisflows.readthedocs.org/en/latest/instructions_remote.html>, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang <notifications@github.com

wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub <

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

< https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198111763

— You are receiving this because you commented. Reply to this email directly or view it on GitHub < https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198153482

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198812091

[komatits]

Hi Ryan, Hi all,

PS: Vadim tells me that Clara Castellanos from Univ of Nice, France, (now at Schlumberger) has implemented Lianjie's Total Variation technique, and Vadim worked with Clara for two years and thus knows how to implement it as well. He will therefore add it to the package in May and June when he does all the cleaning and merging for the unified inversion package.

Best wishes, Dimitri.

On 20/03/2016 01:07, Dimitri Komatitsch wrote:

Hi Ryan,

Thanks for your feedback! I agree that the current directory structure of the code is not suitable for examples of inverse problems any more because none of the subdirectories related to inversion routines is actively maintained. However that is relatively easy to fix, Emanuele is soon going to commit his current way to Git and from there Vadim will clean all of that and will come up with a single set of routines, simple, easy to use and with at least a couple of examples.

In the past when we had three copies of Geocubit in different directories and even different servers, none of them up-to-date, we had to do the same kind of cleaning to come back to a single version and move all the rest to the "unused" directory and things quickly came back to normal. We need to do the same for inversion.

We should be done around the end of June.

As you say we should (and we will) support both adjoint tomo and FWI, since different users use different ways and different cost functions.

We also need to support at least one fully automatic way, because in some fields (e.g. medical, oil industry) they often do not do careful data selection but rather perform automatic inversion of the whole dataset (at least in some cases).

Thanks, Dimitri.

On 18/03/2016 02:30, rmodrak wrote:

Hi Dimitri,

Thanks also for the update! Incidentally, through the devel branch I've been trying to follow Vadim's work on penalty variation methods, which we agree are important. This is something we've looked at as well, though only in the 2D context. Just last year, there was a paper by one of Lianjie Huang's collaborators on Tikhonov and total variation regularization that Etienne and I were looking at. From Etienne, I realized Lianjie's group is similar perhaps to the Marseille group--yours and Lianjie's are the only two I know who do both large-scale seismology and small-scale acoustics.

Anyway, getting back to the github issue. With Etienne earlier, I was arguing it is not practical to include a real inversion test case within EXAMPLES--the way of doing things in that directory is not flexible enough to deal with all the complexity of an inversion.

By coincidence, however, David Luet introduced us this morning to a tool called Jenkins that seems like it might provide a workable framework for an inversion example. From what I could tell, Jenkins is like buildbot, only more powerful. Jenkins seems to require a lot of upfront work, customizing for a particular environment, so from the beginning the user has some idea what they're getting into. Anyway, thought I'd mention it here since it seems relevant.

Best, Ryan

On Thu, Mar 17, 2016 at 6:40 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here

http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang notifications@github.com wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub <

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198111763

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198153482

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

[rmodrak]

Hi Dimitri,

Very interesting, it seemed split Bregman total variation could be relevant to Etienne, since his models had some extremely pronounced layer discontinuities. It would also be interesting see how well the method works for geophysical inversion, beyond the type of synthetic problems Huang et al. considered. Thanks for the update,

Ryan

On Mon, Mar 21, 2016 at 12:10 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi Ryan, Hi all,

PS: Vadim tells me that Clara Castellanos from Univ of Nice, France, (now at Schlumberger) has implemented Lianjie's Total Variation technique, and Vadim worked with Clara for two years and thus knows how to implement it as well. He will therefore add it to the package in May and June when he does all the cleaning and merging for the unified inversion package.

Best wishes, Dimitri.

On 20/03/2016 01:07, Dimitri Komatitsch wrote:

Hi Ryan,

Thanks for your feedback! I agree that the current directory structure of the code is not suitable for examples of inverse problems any more because none of the subdirectories related to inversion routines is actively maintained. However that is relatively easy to fix, Emanuele is soon going to commit his current way to Git and from there Vadim will clean all of that and will come up with a single set of routines, simple, easy to use and with at least a couple of examples.

In the past when we had three copies of Geocubit in different directories and even different servers, none of them up-to-date, we had to do the same kind of cleaning to come back to a single version and move all the rest to the "unused" directory and things quickly came back to normal. We need to do the same for inversion.

We should be done around the end of June.

As you say we should (and we will) support both adjoint tomo and FWI, since different users use different ways and different cost functions.

We also need to support at least one fully automatic way, because in some fields (e.g. medical, oil industry) they often do not do careful data selection but rather perform automatic inversion of the whole dataset (at least in some cases).

Thanks, Dimitri.

On 18/03/2016 02:30, rmodrak wrote:

Hi Dimitri,

Thanks also for the update! Incidentally, through the devel branch I've been trying to follow Vadim's work on penalty variation methods, which we agree are important. This is something we've looked at as well, though only in the 2D context. Just last year, there was a paper by one of Lianjie Huang's collaborators on Tikhonov and total variation regularization that Etienne and I were looking at. From Etienne, I realized Lianjie's group is similar perhaps to the Marseille group--yours and Lianjie's are the only two I know who do both large-scale seismology and small-scale acoustics.

Anyway, getting back to the github issue. With Etienne earlier, I was arguing it is not practical to include a real inversion test case within EXAMPLES--the way of doing things in that directory is not flexible enough to deal with all the complexity of an inversion.

By coincidence, however, David Luet introduced us this morning to a tool called Jenkins that seems like it might provide a workable framework for an inversion example. From what I could tell, Jenkins is like buildbot, only more powerful. Jenkins seems to require a lot of upfront work, customizing for a particular environment, so from the beginning the user has some idea what they're getting into. Anyway, thought I'd mention it here since it seems relevant.

Best, Ryan

On Thu, Mar 17, 2016 at 6:40 PM, Dimitri Komatitsch < notifications@github.com> wrote:

Hi all,

Thanks!

It is true that there are currently many ways in the SPECFEM package, none of them working (or at least not documented and with no working example provided) and none of them actively maintained (and in EXAMPLES there is no inversion example, only kernel calculations); this is problematic and should be fixed.

With Vadim this spring we are going to move all the old and unmaintained ways to the "utils/unused_routines" directory and maintain a single, clean one with at least one working example of inversion, not only kernels. This is becoming crucial (we also noticed that in the last few months here).

We should be done before the summer. We'll send an email to the mailing list when we are done.

Thanks! Dimitri.

On 17/03/2016 16:30, rmodrak wrote:

Hi Kai,

Welcome. Excellent question, I believe many users have had similar issues.

In truth, there are many ways to carry out an iterative inversion using SPECFEM.

Within the SPECFEM repository itself, the src/tomography routines, which it sounds like you are using, are not the only option. There is also the src/inverse_problem way of doing things, as well as the utils/ADJOINT_TOMOGRAPHY_TOOLS way of doing things. I'm not sure whether any of these approaches are working at the moment--in the past, they were sometimes broken.

Outside of the SPECFEM respository itself, there are yet other options. One package I am involved with, called SeisFlows, provides an inversion workflow that can be used with the 2D, 3D,and 3D_GLOBE versions of SPECFEM. The documentation for SeisFlows is available here http://seisflows.readthedocs.org/en/latest/manual/manual.html, source code here https://github.com/PrincetonUniversity/seisflows. There is a ready-to-go 2D example available here

http://seisflows.readthedocs.org/en/latest/instructions_remote.html, which can run on any desktop, laptop or cluster.

Unfortunately, there is a meeting I have to go to now, so I will leave it at that. In the meantime, please let me know if you have any questions. I am happy to provide information about either the src/tomography or SeisFlows way of doing things.

Best regards, Ryan

On Thu, Mar 17, 2016 at 7:53 AM, Kai Wang <notifications@github.com

wrote:

Hi all,

I am a new user of specfem3d. Recently, I try to do iterative inversion by the adjoint method. I used a user defined 3D velocity model "tomography_model.xyz" and then run forward and adjoint simulation. The resulting event kernels are sumed, preconditioned and smoothed to obtain the misfit gradient. Then, I used the program 'xmodel_update' to update model. I run the program successfully with the following outputs in OUTPUT_MODEL: proc _externalmesh.bin proc drhorho.bin proc dvsvs.bin proc dvpvp.bin proc ibool.bin proc _possionnew.bin crop _rhonew.bin proc _vpnew.bin proc _vsnew.bin proc _vbnew.bin proc x.bin proc y.bin procz.bin

I know that proc***vp/vs/rho_new.bin are the new model files, however they are not so easy to convert to the initial model "tomography_model.xyz ". I notice this program also produce new external_mesh.bin, which can be directly used to do the next forward simulation. However, when I copy these new *external_mesh.bin to specfem3d/OUTPUT_FILES/DATABASES_MPI and run xspecfem3D, it occurs: " forrtl: severe (67): input statement requires too much data......"

Should I convert proc****vp/vs/rho_new.bin to tomography_model.xyz or there are other way to update the model ? Thanks in advance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub <

https://github.com/geodynamics/specfem3d/issues/732#issuecomment-197933373

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

< https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198111763

— You are receiving this because you commented. Reply to this email directly or view it on GitHub < https://github.com/geodynamics/specfem3d/issues/732#issuecomment-198153482

Dimitri Komatitsch CNRS Research Director (DR CNRS), Laboratory of Mechanics and Acoustics, UPR 7051, Marseille, France http://komatitsch.free.fr

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/geodynamics/specfem3d/issues/732#issuecomment-199360018

[komatits]

Thanks! See https://github.com/geodynamics/specfem3d/issues/23 . Let me close this one because Vadim @vmont will implement https://github.com/geodynamics/specfem3d/issues/23 before the summer and then we will be all set. Thanks, Dimitri.