[cig-commits] [commit] devel: added list_for_Zhinan_for_SPECFEM2D_PMLs.txt (items that need to be done for PMLs; we will remove that file when we are done) (18dca12)
cig_noreply at geodynamics.org
cig_noreply at geodynamics.org
Mon Dec 15 17:24:19 PST 2014
Repository : https://github.com/geodynamics/specfem2d
On branch : devel
Link : https://github.com/geodynamics/specfem2d/compare/b9ebe7067d5477624920c59e5a3eae08d3a427d1...18dca124af92e193e4eb317a34c16b3bca77dcb6
>---------------------------------------------------------------
commit 18dca124af92e193e4eb317a34c16b3bca77dcb6
Author: Dimitri Komatitsch <komatitsch at lma.cnrs-mrs.fr>
Date: Tue Dec 16 02:19:53 2014 +0100
added list_for_Zhinan_for_SPECFEM2D_PMLs.txt (items that need to be done for PMLs; we will remove that file when we are done)
>---------------------------------------------------------------
18dca124af92e193e4eb317a34c16b3bca77dcb6
list_for_Zhinan_for_SPECFEM2D_PMLs.txt | 644 +++++++++++++++++++++++++++++++++
1 file changed, 644 insertions(+)
diff --git a/list_for_Zhinan_for_SPECFEM2D_PMLs.txt b/list_for_Zhinan_for_SPECFEM2D_PMLs.txt
new file mode 100644
index 0000000..2db6d54
--- /dev/null
+++ b/list_for_Zhinan_for_SPECFEM2D_PMLs.txt
@@ -0,0 +1,644 @@
+
+For SPECFEM2D PMLs:
+-------------------
+
+1/ current SPECFEM2D PMLs do not support the fluid-solid boundary not inside CPML_X_ONLY, see https://github.com/geodynamics/specfem2d/issues/81
+
+Date: Sat, 31 May 2014 23:50:43 +0200
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: è°¢å¿—å— <xiezhinan1984, Paul Cristini
+
+Dear Zhinan,
+
+There was also this one.
+If it is not too time consuming, it would be great to do it as well,
+this way all the minor issues detected in the last few months will
+finally be permanently fixed (this one (below) is the last one that I
+had noted; there a no other ones I think).
+
+Thanks a lot,
+Dimitri.
+
+Subject: Re: PML do not support the fluid-solid boundary not inside
+CPML_X_ONLY
+Date: Fri, 28 Feb 2014 18:51:18 +0100
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: è°¢å¿—å— <xiezhinan1984
+
+Dear Zhinan,
+
+It would be really great if you could do it if possible when you have
+time, because in the attached Par_file I had to rotate the model by 90
+degrees in order for the code to work (the model is supposed to be
+horizontal instead of vertical).
+
+Thanks again,
+Best wishes,
+
+Dimitri.
+
+On 26/02/2014 03:36, è°¢å¿—å— wrote:
+> Dear Dimitri,
+>
+> We can to change to support CPML_Z_ONLY as well.
+> If you want, I can do the job.
+> Please tell the deadline that you think the code should be ready.
+>
+> Thank you so much, Sir.
+> Best regards,
+> Zhinan
+>
+>
+> 2014-02-26 9:46 GMT+08:00 Dimitri Komatitsch:
+>
+> Dear Zhinan,
+>
+> When I try to put a fluid-solid boundary inside the PML in the
+> vertical direction, the code currently displays this:
+>
+> PML do not support the fluid-solid boundary not inside CPML_X_ONLY.
+>
+> How easy would it be to implement it in CPML_Z_ONLY as well?
+>
+> (we could exclude the corners, i.e. change it to:
+>
+> PML do not support the fluid-solid boundary inside CPML corners.
+>
+> Could you tell me if you think this is easy to implement, or
+> difficult to implement?
+>
+> Thank you very much,
+> Best regards,
+>
+> Dimitri.
+
+-------------------------------------------------------------------------------------------------------
+-------------------------------------------------------------------------------------------------------
+
+2/ example "LuoYang_fluid_solid_kernel" of the 2D code seems to blow up when Stacey conditions are used:
+
+Date: Thu, 04 Sep 2014 13:38:22 +0200
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: xiezhinan
+CC: Yingzi Ying, Paul Cristini
+
+Dear Zhinan,
+
+Great, thanks a lot for checking! This will be very useful. Please keep
+us informed if you manage to fix the problem.
+
+Thank you,
+Best regards,
+
+Dimitri.
+
+On 04/09/2014 04:45, xiezhinan wrote:
+> Dear Dimitri and Ying,
+>
+> An initial tests show the problem is that:
+>
+> Even for forward simulation with a purely fluid model, when turning the
+> bottom and top Stacey BC on, the simulation quickly blow up.
+> But for tests with right and left Stacey BC only, the simulation is fine.
+>
+> While for forward simulation with a purely solid model,everything is fine.
+>
+> Thus, I will first focus on solving the following problem:
+> Fixing Stacey BC for a purely fluid model with Stacey BC imposed on its
+> four out-edge boundaries.
+>
+> Thank you so much.
+>
+> Best regards,
+> Zhinan
+>
+>
+> At 2014-09-04 05:56:50, "Dimitri Komatitsch" wrote:
+>>
+>>Dear Zhinan,
+>>
+>>Yingzi Ying (cc'ed) noticed that the example
+>>"LuoYang_fluid_solid_kernel" of the 2D code seems to blow up when Stacey
+>>conditions are used. Do you have an idea of what could be wrong?
+>>(I remember you used that example last year when you were here for
+>>several tests, thus maybe you know how to check it?).
+>>
+>>Thank you very much,
+>>Best wishes,
+>>
+>>Dimitri.
+>>
+>>
+>>> On 09/03/2014 10:56 AM, Yingzi Ying wrote:
+>>>> Hi Dimitri,
+>>>>
+>>>> Thanks for replying.
+>>>>
+>>>> I also have a fluid-solid coupled Stacey boundary condition, i.e., in
+>>>> the example "LuoYang_fluid_solid_kernel" I set
+>>>>
+>>>> STACEY_ABSORBING_CONDITIONS = .true.
+>>>> and
+>>>> absorbbottom = .true.
+>>>> absorbright = .true.
+>>>> absorbtop = .false.
+>>>> absorbleft = .true.
+>>>> and do
+>>>> ./run_this_example.sh (forward simulation)
+>>>>
+>>>> I got an error:
+>>>>
+>>>> ./run_this_example.sh: line 59: 9260 Floating point exception(core
+>>>> dumped) ./xspecfem2D
+>>>>
+>>>> (Every thing goes well if I set STACEY_ABSORBING_CONDITIONS = .false)
+>>>>
+>>>>
+>>>> I don't have such problem in using 7.0.2 tar ball(mostly this version,
+>>>> as I can not remember well and can not find it online again).
+>>>>
+>>>> Can you help me to have a look what is the problem. I am targeting to do
+>>>> calculate some kernels of fluid-solid coupled media.
+>>>>
+>>>> Best,
+>>>> Yingzi
+
+-------------------------------------------------------------------------------------------------------
+-------------------------------------------------------------------------------------------------------
+
+3/ PML_init.f90 and optimization of PML parameters:
+
+Date: Sat, 31 May 2014 23:48:18 +0200
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: è°¢å¿—å— <xiezhinan1984, Paul Cristini
+
+Dear Zhinan,
+
+Here is the other modification that we discussed for pml_init.
+it would be great to do them both before sending me the modified file.
+
+thanks
+Dimitri.
+
+Subject: Re: Optimization of PML parameters
+Date: Tue, 27 May 2014 01:34:47 +0200
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: cristini, è°¢å¿—å— <xiezhinan1984
+
+Dear Zhinan,
+
+Following Paul's email below, in the next few days could you please
+email me your final PML_init.f90 file? this way I will commit it to Git,
+because the current version on the Git server is not the right one, and
+by email you sent us several of them, thus could you please send us a
+single one, and I will commit it?
+
+(if you need to add some logical constants for instance to say whether
+the model is elongated or not and thus different CPML constants should
+be used or not, then please add these constants to setup/constants.h.in
+and email me that file as well, and I will commit it too).
+
+In summary, modifications made outside of Git are almost useless because
+they are quickly lost or forgotten, thus I need to commit the final
+version to Git in the next few days.
+
+Thank you,
+Best regards,
+
+Dimitri.
+
+On 26/05/2014 21:33, cristini wrote:
+> Dear Zhinan,
+>
+> Thank you for you analysis of the PML parameters when dealing with
+> grazing angles.
+> I enclosed an image of a simple configuration : homogeneous fluid in a
+> square domain but with the source not situated at the center of the
+> domain so that reflection angles greater than 45 degrees can occur.
+> Justly, it seems that a spurious reflection is starting at an angle of
+> 45 degrees. Is it something that you consider as normal with the
+> parameter values present in PML_init ? With the parameter values you
+> suggested in the new version of PML_init do you have an idea of the kind
+> of angle value at which this spurious reflection occurs ?
+> It would be nice if you could commit the new pml_init file with perhaps
+> a new constants.h file including the variables you added.
+> I know that commitments with the Git system is something cumbersome. You
+> can send Dimitri the files so that he will do the commit.
+>
+> Thank you so much
+>
+> Best regards
+> Paul
+
+Date: Sat, 31 May 2014 23:43:48 +0200
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: è°¢å¿—å— <xiezhinan1984
+CC: cristini
+
+Dear Zhinan,
+
+OK, great, thank you very much. Yes, I think your suggestion below for a
+simple modification is perfect.
+
+Then, please send me the final modified file (or files) by email and I
+will commit them to the official version of the code.
+
+There were other small modifications that we discussed for PML_init.f90,
+I will send them back to you in a few minutes, this way you can make
+them as well (in the same file) before sending me the final file.
+
+Thanks,
+Dimitri.
+
+On 30/05/2014 15:51, è°¢å¿—å— wrote:
+> Dear Dimitri,
+>
+> Thank you so much.
+>
+> Is a simple value equal to ratio of width and height of model
+> proper for a simple index of whether the model is elongated?
+>
+> Then we decide use different CPML constants or not.
+>
+> I will make the modification and send to you.
+>
+> Thanks again,
+> Best regards,
+> Zhinan
+>
+>
+> 2014-05-27 7:34 GMT+08:00 Dimitri Komatitsch:
+>
+> Dear Zhinan,
+>
+> Following Paul's email below, in the next few days could you please
+> email me your final PML_init.f90 file? this way I will commit it to
+> Git, because the current version on the Git server is not the right
+> one, and by email you sent us several of them, thus could you please
+> send us a single one, and I will commit it?
+>
+> (if you need to add some logical constants for instance to say
+> whether the model is elongated or not and thus different CPML
+> constants should be used or not, then please add these constants to
+> setup/constants.h.in <http://constants.h.in> and email me that file
+> as well, and I will commit it too).
+>
+> In summary, modifications made outside of Git are almost useless
+> because they are quickly lost or forgotten, thus I need to commit
+> the final version to Git in the next few days.
+>
+> Thank you,
+> Best regards,
+>
+> Dimitri.
+>
+> On 26/05/2014 21:33, cristini wrote:
+>
+> Dear Zhinan,
+>
+> Thank you for you analysis of the PML parameters when dealing with
+> grazing angles.
+> I enclosed an image of a simple configuration : homogeneous
+> fluid in a
+> square domain but with the source not situated at the center of the
+> domain so that reflection angles greater than 45 degrees can occur.
+> Justly, it seems that a spurious reflection is starting at an
+> angle of
+> 45 degrees. Is it something that you consider as normal with the
+> parameter values present in PML_init ? With the parameter values you
+> suggested in the new version of PML_init do you have an idea of
+> the kind
+> of angle value at which this spurious reflection occurs ?
+> It would be nice if you could commit the new pml_init file with
+> perhaps
+> a new constants.h file including the variables you added.
+> I know that commitments with the Git system is something
+> cumbersome. You
+> can send Dimitri the files so that he will do the commit.
+>
+> Thank you so much
+> Best regards
+>
+> Paul
+
+-------------------------------------------------------------------------------------------------------
+-------------------------------------------------------------------------------------------------------
+
+4/ Other emails for PML_init.f90:
+
+Subject: Fwd: Re: Strange behavior of CPML in fluid domains
+Date: Sat, 31 May 2014 23:49:20 +0200
+From: Dimitri Komatitsch
+Organization: CNRS, Marseille, France
+To: è°¢å¿—å— <xiezhinan1984, Paul Cristini
+
+Dear Zhinan,
+
+there was also this one. If possible, let us fix everything
+simultaneously in PML_init, this way all the small bugs or problems will
+be permanently fixed.
+
+Thanks,
+Dimitri.
+
+Subject: Re: Strange behavior of CPML in fluid domains
+Date: Mon, 12 May 2014 09:06:01 +0800
+From: è°¢å¿—å— <xiezhinan1984
+To: Dimitri Komatitsch
+CC: cristini
+
+Hi Dimitri,
+
+Thank you so much.
+When I am ready, I will commit a slightly new version pml_init.F90.
+
+Thanks again.
+Best regards,
+Zhinan
+
+
+2014-05-12 8:08 GMT+08:00 Dimitri Komatitsch:
+
+ Hi Zhinan,
+
+ Great, thank you very much. I agree with your analysis. Thus, when
+ you have time please send me the modified Fortran files and I will
+ commit them to GIT (or if you prefer you can commit them directly
+ and I will approve the Pull Request through the GitHub Web site).
+
+ Thanks,
+ Best wishes,
+
+ Dimitri.
+
+
+ On 11/05/2014 03:29, è°¢å¿—å— wrote:
+
+ Hi Dimitri,
+
+ I agree.
+ Then we should desigh a rough judgement to set parameters in
+ streching function used in the code.
+
+ Thank you so much, Sir.
+
+ Best regards,
+ Zhinan
+
+
+ 2014-05-09 21:30 GMT+08:00 Dimitri Komatitsch:
+
+ Hi Zhinan,
+
+ I agree with you that the process of selecting the PML
+ parameters
+ should be as automatic as possible, i.e. if possible the
+ code itself
+ should decide and the user should not have to enter all the
+ damping
+ parameters.
+
+ However in the automatic decisions made by the code I think
+ it makes
+ sense to distinguish the thickness and the damping
+ parameters along
+ X from those along Z, since it is very common to have very
+ elongated
+ models (for instance in ocean acoustics, but also in oil
+ industry
+ large-offset models).
+
+ Thanks a lot,
+ Best wishes,
+
+ Dimitri.
+
+
+ On 07/05/2014 23:14, è°¢å¿—å— wrote:
+
+ Hi Dimitri,
+ Thank you so much.
+ After I get a more clean solution to Paul's problem, I
+ will
+ commit the
+ change but set the streching function in different
+ direction
+ equal in
+ default and leave a comment.
+ Due to the fact that there is no clear guideline on
+ choosing the
+ parameters inside streching function, maybe it is
+ useless to
+ leave the
+ general user a flexible choice to define the streching
+ function.
+ If not, please correct me, Sir.
+ Thanks again.
+ Best regards,
+ Zhinan
+
+ 2014-05-07 22:41 GMT+08:00 Dimitri Komatitsch:
+
+ Hi Zhinan,
+
+ Thank you so much. Could you please commit the
+ changes to GIT?
+
+ (if you think these changes are only useful for
+ Paul but not in
+ general, then please commit them as comments, i.e.
+ leave
+ the current
+ values but put the new lines (the modified lines) as
+ comments in the
+ routines, and then please create a Pull Request on
+ GitHub.
+ (otherwise the changes will quickly be lost)
+
+ Thank you very much,
+ Best regards,
+
+ Dimitri.
+
+
+ On 07/05/2014 10:47, è°¢å¿—å— wrote:
+
+ Hi Paul,
+
+ I confirmed this problem comes from the grazing
+ incident of wave.
+
+ As suggested in our solid PML paper, the idea is
+ originally from the
+ paper of Zhang, we need to carefully design
+ the stretching
+ function to
+ achieve an excellent absorption. I.E. we need
+ to carefully
+ choose both
+ d, k, and alpha.
+
+ I have tuned the parameter inside pml_init.F90 to
+ achieve a good
+ result
+ for the example you send to me. Both the
+ result and
+ pml_init.F90
+ have
+ been attached.
+
+ Currently the solution is not perfect, since I
+ still
+ have small
+ reflection from the side PML due to the use of
+ varying
+ K, which is
+ bigger than 1.
+ But I think this problem can be solved by
+ admitting
+ different
+ choice of
+ d_max, k_max,, and alpha_max, along difference
+ space
+ coordinate,
+ which
+ is not allowed in our current implementation.
+ I will
+ keep you
+ confirmed.
+
+ Thanks again,
+ Best regards,
+
+ Zhinan
+
+
+ 2014-05-07 8:43 GMT+08:00 è°¢å¿—å— <xiezhinan1984
+
+ Hi Paul,
+
+ I am really sorry that I missed this email.
+
+ The reflection come from the bottom PML,
+ but seems
+ work
+ fine for
+ side PML and the corner PML.
+ Thus the problem may come from the wrong
+ definition of the PML
+ element in the bottom
+
+ I will have a test today and keep you
+ confirmed.
+
+ Best regards,
+ Zhinan
+
+ 2014-04-30 18:23 GMT+08:00 cristini
+
+ Dear Zhinan,
+
+
+ I am in the process of adding a new
+ example in the EXAMPLES
+ directory corresponding of our Jasa
+ Express
+ Letter on
+ underwater
+ acoustics and I am facing a problem
+ with CPML
+ in fluid
+ domains.
+ The configuration is a fluid layer
+ overlying a
+ sediment
+ which
+ can be either fluid or elastic but
+ with the same
+ velocity for P
+ waves. As you can see in the attached
+ file the
+ CMPL is
+ working
+ when the sediment is elastic but when
+ it is
+ fluid there
+ is a
+ spurious reflection.
+ Do you have any ideas of what's going
+ on ?
+
+ Thanks
+
+ Best regards
+
+ Paul
+
+-------------------------------------------------------------------------------------------------------
+-------------------------------------------------------------------------------------------------------
+
+5/ plane wave boundary conditions maybe have a (small) bug in SPECFEM2D, see https://github.com/geodynamics/specfem2d/issues/83
+
+On 07/03/2014 09:02, è°¢å¿—å— wrote:
+> Dear Dimitri,
+>
+> I think this bug we have not fixed yet.
+> I will fix this during the commit of kernel code.
+>
+> I am really sorry for the delay.
+>
+> Thank you so much.
+> Best regards,
+> Zhinan
+>
+>
+> 2014-03-05 2:45 GMT+08:00 Dimitri Komatitsch:
+>
+> Dear Zhinan,
+>
+> Do you remember if this bug (plane waves that did not work fine any
+> more on the edges of the grid in the 2D code) has been fixed or not?
+>
+> (I think so, but I am not 100% sure; if so, please let me know, and
+> I will then remove it from the list of things to do).
+>
+> Thank you very much,
+> Best regards,
+>
+> Dimitri.
+>
+> On 18/09/2013 16:50, Dimitri Komatitsch wrote:
+>
+> Dear Diego,
+>
+> Zhinan has told me that he will fix this next week.
+> Sorry about the delay, we were finishing another project. He
+> will send
+> you an email when the problem is fixed and will cc us.
+>
+> Thanks,
+> Cheers,
+>
+> Dimitri.
+>
+> On 05/06/2013 12:32 AM, Dimitri Komatitsch wrote:
+>>
+> Dear Diego,
+>
+> Florian Cachoux (a student of Raphael Garcia and me) has
+> found the same
+> bug. Zhinan is currently investigating. The bug will be
+> fixed soon
+> (sometime this month). We will let you know. I cc everybody.
+>
+> Thanks,
+> Cheers,
+>
+> Dimitri.
+
More information about the CIG-COMMITS
mailing list